问题
I use getNumLines() to estimate the number of lines before writing the text, besause it has to be positioned accordingly.
It seems that getNumLines() calculates more space for the text then MultiCell() actually needs. A long line, that still fits into the cell when writing with MultiCell() seems to be soft-wrapped by getNumLines():
$lines = $pdf->getNumLines($text, $width);
$pdf->MultiCell($width, 50, $text, 0, "L");
In my test $lines is 3 while only 2 lines are printed. If I increase the $width a bit I get the right value. And it is the first line that is the longer one. So it can't be a non-printing-character in the end that is wrapped.
Maybe it's because of the align parameter "L" I pass to MultiCell()? But there isn't such for getNumLines() ... any suggestions?
Version of TCPDF: 5.9.156
回答1:
There is another technique described in the comments of this ticket of tcpdf's bugtracker, which sounds very promissing:
If you want o know the exact number of lines you have to use the following technique:
// store current object
$pdf->startTransaction();
// get the number of lines
$lines = $pdf->MultiCell($w, 0, $txt, 0, 'L', 0, 0, '', '', true, 0, false,true, 0);
// restore previous object
$pdf = $pdf->rollbackTransaction();
回答2:
Ha! Found the bug: getNumLines() calculates space for newlines and carriage returns.
To avoid this I edited the font definition files: There is an array called $cw defining the width of each character. I added two entries: 10 => 0, 13 => 0 to set the width of newline and carriage return to zero.
回答3:
Finally fixed this same bug for a 'dirty' html-string table in TCPDF. JohJoh's answer about 10 => 0, 13 => 0 put me in the right direction. I changed it to 10 => 8750, 13 => 8750 to push the content of other td's down the right amount.
来源：https://stackoverflow.com/questions/10952848/tcpdfs-getnumlines-is-sometimes-wrong