On Fri, 28 Oct 2005 06:06 pm, Luca Furini wrote:
> Manuel Mall wrote:
> > > I added a boolean attribute in SpaceArea that is true for
> > > adjustable spaces (at the moment it is not used, but I will fix
> > > it soon).
> >
> > Why would you envisage this is required by the renderers?
> I can only speak of the PDFRenderer, as I don't know the other
> formats very well.
> Remember that this started from the bug 36238: in the pdf format, the
> multi-byte "normal space" character is not affected by the Tw
> operator (that sets the word adjustment) so we needed a way to apply
> this adjustment in another manner. The pdf format allow to specify an
> horizontal offset between fragments of text, so that their distance
> can be increased or reduced: if the font is multy-byte, using this
> feature we can adjust the spaces.
> But we need to know which spaces can be adjusted, and which cannot.
> If we don't wont to duplicate the logic for the "space recognition",
> the SpaceAreas must simply have a boolean value stating whether the
> space is adjustable, so that the renderers won't need to look at the
> space and decide.

I don't get that point. Isn't it enough for the renderer to know the 
offset for the area in question? What additional decisions would the 
renderer make based on the "adjust" flag? Or do you mean we still have 
the twsAdjust on the TextArea and the offset is only relative to 
twsAdjust? Do we really gain anything with that instead of making the 
offset the corrected twsAdjust value?

> > > At the moment the offset in SpaceArea and WordArea are unused,
> > > but this is how I think they could be used: if, because of the
> > > rounding in the adjustment computation, the applied adjustment is
> > > different than the needed one, the TextLM should distribute this
> > > difference (a few millipoints) among the SpaceAreas and / or
> > > WordAreas, setting their offset.
> >
> > I see. Not sure if offset is the correct attribute though. Its
> > stated purpose is for offsetting in the bpd direction. Overloading
> > it with a different meaning is questionable.
> Maybe "offset" is not the most appropriate name, even if the pdf
> specification calls it that way (last line in the last row of table
> 5.6); at least it is can be misleading in the context of fop.
> > Instead for SpaceAreas we could use the IPD trait. Basically the LM
> > tells the renderers via the SpaceArea 'I want an <ipd> mpt wide
> > space here'. How the renderers make this space happen is up to
> > them. Not sure if we should even consider distributing the rounding
> > errors to the WordAreas. I would leave them with the SpaceAreas.
> At the moment neither the WordAreas nor the SpaceAreas have the ipd
> explicitly set, so it is 0 (the ipd is set for the parent TextArea):
> these kind of area were initially thought of as "light weight areas",
> in order to increase the size of the area tree as little as possible,
> and we could even define them in a minimal fashion, so that they have
> no unused inherited attributes and methods.
As you said a saving would only be achieved if you actually change the 
Area class hierarchy such that those fields are not carried by every 
instance. Otherwise setting ipd to 0 or anything else is not saving a 
single bit.

> Setting the ipd for each word and each space is another approach: it
> would give the full control on the text positioning to fop's layout
> enginge, while at the moment we control the overall text using the
> adjustment parameters.
Isn't that the same if you set an offset on each of those, LM takes 
control and tells the renderers the detail of the positioning for each 
fragment including spacing?

> The drawback of this increased control is that the renderers would
> need to be more complex in order to handle the extra information.
> > A different approach would be not to have the space areas at all
> > and simply set space-start/space-end traits on the word areas but
> > that may be a bit radical (in the sense of its impact on the
> > renderers) at this stage (but see below - CJK).
> [1] My only concern is: if we "show" spaces but don't insert space
> characters, how would the text extracted from such an output look
> like? Wouldn'titbesomethinglikethis? :-)

Good point - we probably need the space char in the pdf otherwise we 
would have some unhappy users later.

> > Of course we could also use space-start/space-end traits on the
> > SpaceAreas to model shrink/stretch instead of the IPD trait. May be
> > that would be preferable?
> Well, this is not very different from what is now (improperly) called
> offset :-)
Correct, it is logically the same.

> > > The renderers will use this according to their own adjustment
> > > rule: for example the PDFRenderer would add it to the text
> > > adjustment if the character is multibyte.
> > >
> > > The offset could come in handy for the cjk support (bug 36977):
> > > in this case there are no adjustable spaces, and if text is
> > > justified all the difference between line width and unadjusted
> > > character width could be handled modifying the offsets of some
> > > special characters.
> >
> > Hmm, in the CJK case it appears most characters will become a
> > single WordArea. If justification is required we either need to
> > insert SpaceAreas between the WordAreas or add a property to the
> > WordAreas.
> If adding a SpaceArea means adding some kind of space character, this
> could "corrupt" the cjk text that could be extracted from the output;
> otherwise goto [1] :-)
> > If we go for the additional property I would opt for setting
> > space-start/space-end traits on those areas. This seems to me to be
> > more in 'the spirit of XSL-FO'.
> So, what if we rename offset -> spaceAfter? It seems to me that we
> are here speaking of the same thing using two different names. :-)
Fair enough, I agree we do.

> Regards
>      Luca

Reply via email to