On 01.03.2006 15:30:09 Luca Furini wrote:
> Jeremias Maerki wrote:
> > Still trying to fix my problem with letter-spacing and fixed width
> > spaces. Do I understand that correctly that XSL-FO's view of
> > letter-spacing is different than, say, PDF's? PDF's character spacing
> > (PDF 1.4, 5.2.1) is designed so it advances the cursor for each (!)
> > character by the Tc value.
> Yes, I remember that when I was working on letter spacing it took me a
> while to understand what was wrong with the resulting pdf! :-)
> > letter-spacing="1pt":
> > |_t__e__x__t_ _t__e__x__t_ _t__e__x__t_|
Hey, I'm again making a complete fool of myself. Mr. Space-Resolution
doesn't get the simplest of rules right. Of course, the first and the
last space is removed due to conditionality="discard" (starts/ends a
reference area). So it must actually be:
|t__e__x__t_ _t__e__x__t_ _t__e__x__t|
> At the moment, fop has
> |t__e__x__t t__e__x__t t__e__x__t|
> in other words there are letter spaces only between letters, and not
> between a letter and a space.
Yes, so even correcting my example we have a difference left to what the
> The recommendation states that "The algorithm for resolving the adjusted
> values between word spacing and letter spacing is User Agent dependent."
> (7.17.2 in the candidate recommendation), so I think this is not a wrong
> behaviour: it just assumes that word spaces have a higher precedence than
> letter spaces.
No, actually in both cases the precedence is "force" so all spaces
survive the resolution process.
> Another little difference: each letter space depends on the preceding
> letter size, instead of depending on both the preceding and following
> letters sizes; but this has some visible effect only when a word is
> composed of letters having different sizes.
> > PDF's character spacing would work like this, I think (although the last
> > character space needs to be eliminated by the layout manager ):
> > |t__e__x__t__ __t__e__x__t__ t__e__x__t|(__) <-- 
> This is why the word spacing adjustment stored in the textAreas is not the
> computed one, but is specifically modified in order to counterbalance the
> 2 letter spaces that the pdf will add.
> > If I'm right here (not really sure, that's why I'm asking), it would
> > mean that we should probably stop using the Tc feature from PDF and
> > instead control the glyph positioning ourselves like we already do in
> > PostScript.
> > WDYT?
> As long as we have just two character categories (letter / spaces) the two
> pdf operators were enough.
> Now, with fixed width spaces too, which should be unaffected by the both
> word spacing (such being different from spaces) and letter spacing
> (differing from normal letters), two operators are too few.
> I don't think we need to set the horizontal positioning of each character
> or word, but just fix the placement of a character sequence following a
> fixed width space, removing the letter spaces wrongly added by the Tc
> operator, alternating character sequences and horizontal adjustments in
> the TJ array.
It does. Thanks. Means I'm not on the wrong track. However, while I was
out for a few hours I was thinking about this and I came to the
conclusion that it may make sense to keep an array of character offsets
as an attribute of a WordArea in the area tree. Different reasons:
- The layout manager already knows exactly where each character should
go. At the moment we're somewhat mapping that knowledge into generic
properties and the renderer has to reproduce the effect. There's a
potential source for errors here.
- When at one point we go into details of letter-spacing and
word-spacing, this will get more important and most of all more
- The renderer code for text becomes simpler if it simply can use the
relative offsets from the area tree.
This change doesn't have to happen right now, but it may be worth
keeping in mind for later. I think we can still live with a few
simplifications for now.