I don’t know much about EndOfLines. What I would do is try EndOfLine.UNIX then EndOfLine.Windows to see if there is any difference.
I’m sure Christian will respond soon. I don’t know exactly but maybe is just put a break and inspect my_return, for example with EndOfLine.Windows you get 0D0A:
With EndOfLine.UNIX you just get 0A:
Maybe you just have 0A and you need 0D0A for your PDF? Sorry, if I’m wrong.
For what it is worth… the PDF document format doesn’t give a hoot about Linefeed characters, in much the same way that HTML doesn’t either … so any problems are with how or if the app (DynaPDF?) creates the file
my_return=address1_s + endofline.windows //but it might already have one!!!
Anyway, the big question remains : HOW is the text being inserted into the PDF.
We know what the string can look like, but not the actual code being used.
The answer lay in the data itself. There were a bunch of hidden characters in the imported data. Teh hex view made them clear. Once the data was scrubbed, the problem “wen away”