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 
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



Reply via email to