>>>Hi Rick,
>>>
>>>IMHO, the bug is in another place, see to previous loop in code.
>>>
>>>1) Split to text to lines (array p)
>>>2) Calculate width for each line
>>>3) If line's width is greather then original text width, then split line to two lines
>>>
>>>MartinaJ
>>
>>I agree you could fix it there by not creating the new array entries. I considered that, but rather than changing existing code that have effects I may not be aware of elsewhere, I wanted to simply put a guard up on the line that actually emits it to the PDF writer.
>>
>
>May be yes, may be no.
>Report listener calculate text lines count by textbox width with using GDI+API
>But PDF (builder) use GDI API.
>It's strange so algorithm in pdf3 calculate more lines then GDI+ API.
>
>MartinaJ

I think that's where the rectangle constraint comes in. There is information given to report listeners on that rectangle to populate, which means anything that gets populated must fit into that rectangle and not exceed it.

I think internally VFP's own report engine must trim and truncate the text down (as pdf3 does) because when you use the normal print to printer feature of VFP's report engine and print to something like CutePDF, it works properly. And if you add the EvaluateContents() method as was described recently and is in the modified pdf3.prg program I posted, you can see how VFP is sending us the whole field and is expecting us to truncate it as necessary to do the actual writing, because failing to truncate it will result in horizontal and verticla overruns.

I think we're essentially replicating what VFP's own internal engine must do here, but there wasn't a constraint on the height being considered.