On Wed, 19 Oct 2005 04:34 pm, Jeremias Maerki wrote: > 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? > What about traits like text decoration, don't they span spaces? Would simply advancing the IPD cause unwanted gaps in an underline for example? I am not that much in favour of another area type. Isn't that another complication for the renderers. I am wondering any way why we have a space area, a character area and a text area. They seem all the same to me. By just having a text area layout can decide what to generate, e.g. one text area per glyph, or a text area per word or a text area per line whatever suits best and it doesn't matter to the renderers. If everything has a fixed space just generate a single text area. If we have some variable word spacing generate a text area per word with the appropriate space-before/after values. For more complicated scripts with ligatures, etc. we may have to generate per glyph text areas.
> 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 Cheers Manuel
