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.
Regards
Luca
