Yesterday I added a couple of comments concerning this bug; at the moment I haven't received the bugzilla email yet, so here is a copy-and-paste of the last message.

I added a comment after the copied text, so this message would not be completely useless even if you received the original one! :-)

 ------- Additional Comment #8 From Luca Furini  2005-10-18 12:53

Quotation from the pdf reference, version 1.6, section 5.2.2 Word spacing:

  "Word spacing is applied to every occurrence of the single-byte character code
32 in a string when using a simple font or a composite font that defines code 32
as a single-byte code. It does not apply to occurrences of the byte value 32 in
multiple-byte codes."

So, it seems that at least we have found where the problem lies ... anyone has
an idea how to solve it too? :-)


At the moment, my only idea about how fixing this is go back to the creation of several text areas, one for each word or space: so the multibyte space character could be converted to the single-byte space, or we could leave it as it is and "forcing" the adjustment modifying the ipd of the area created for a space.

A disadvantage of this solution would be the big increase in the area tree size.

An advantage could be the possibility to get rid of errors due to the adjustment rounding: at the moment the letter space can lead to an "error" of the order of the number of letter spaces, as the adjustment is rounded up to the nearest millipoint and is applied to all the letter spaces in a line. Having distinct text areas for each word, we could correct this error setting appropriately each area ipd.


Reply via email to