On 19.10.2005 10:57:36 Manuel Mall wrote: > 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?
No, because the traits would be set on the text area and painted for the whole (text) area. The "word" areas would only be used to place the words (x-offset). > I am not that much in favour of another area type. Isn't that another > complication for the renderers. Not much in this case IMO. > 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. Well, the character area doesn't really make much sense I think. It's basically the same as text. The space is a different story. > 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. Hmm, but that introduces special knowledge about renderer specialities into the layout engine which shouldn't happen IMO. > 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. I think my approach would cover this. A light-weight approach to easily position single glyphs if necessary while basic trait are handled by the parent text area. > > 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 Jeremias Maerki
