DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=28208>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=28208 [PATCH] justification in PDF Renderer ------- Additional Comments From [EMAIL PROTECTED] 2004-04-07 12:17 ------- Hi Chris, I'm here again. I have done some tests, and it seems to me that a second Tw operand inside the array ... Tm 4 Tw [(first fragment ) 0 1 Tw (second fragment of text)] TJ affects EVERY space in the array, not only the ones in the following string. This is quite counter-intuitive, but you can see this if you look at the pdfs genereted in the two ways we proposed: with your patch it seems that the first space in the second line (which belongs to the first fragment of text) is as long as the other spaces (which belongs to the second fragment), while with mine it is visibly longer. On this subject, I have a few doubts: - is this behaviour (spaces in a same line are sometimes different) acceptable? Surely it is easier, as the LineLM has to compute only one adjustment factor which every TextLMs involved in the line building uses. - if this is ok, then there are problems with fragments of text without spaces (this can happen with the last word before a linefeed treated as space, or the first after); maybe in these cases we could use letter spacing instead of word spacing. Luca
