If we can reliably find out which characters are spaces and we know their widths, then we can fall back to the behaviour as in FOP 0.20.5 just advancing the cursor when a space is found. That puts some additional logic into the renderer and we could avoid creating and area per word. Putting more detail in the area tree however, would improve the consistency of the output between renderers since they have to deal with less logic (or implied functionality as Tw in PDF).
I'd prefer to make the area tree more detailed and the renderers simpler. Maybe we could use a trick to minimize the memory increase by creating an additional "word" area as a child to the text area so we don't have to replicate the traits for each word. WDYT? On 19.10.2005 10:18:20 Luca Furini wrote: > 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 Jeremias Maerki
