On May 29, 2008, at 13:47, Max Berger wrote:
Hi Max
Just some comments on this work:
- it implements a word-by-word selection as the "auto" font-selection
strategy. It will always pick the first font, which is able to display
the most characters in a word. This behavior needs to be documented
(I'll do that)
- character-by-character is still TDB. I am currently thinking about
creating breaks within one word if the font changes, then most of this
implementation could be reused (and a font-change is a break in the
word anyways)
Good work! Thanks for getting FOP this far already.
There is still an open issue: When the font is changed, the metrics
for the line are not. E.g. when i have something like
test SIGMA test
<fo:block>test ∑ test</fo:block>
the SIGMA character is set lower than it should be. At this time I was
unable to find the cause of this behavior. Maybe someone has a hint as
to why this happens?
To further investigate, compare the behavior with:
<fo:block>test <fo:inline font-family="Symbol">∑</fo:inline>
test</fo:block>
<fo:block>test <fo:character font-family="Symbol"
character="∑" /> test</fo:block>
The fo:inline or fo:character trigger the creation of a new
org.apache.fop.layoutmgr.inline.AlignmentContext, which is taken into
account by the LineLayoutManager associated to the fo:block.
That context is used to determine the alignment point for the content
of the fo:inline vis-à-vis the dominant-baseline of the enclosing line.
The above would expand to:
<fo:block alignment-adjust="auto"
alignment-baseline="auto"
baseline-shift="baseline"
dominant-baseline="auto">
test <fo:inline font-family="Symbol"
alignment-adjust="auto"
alignment-baseline="auto"
baseline-shift="baseline"
dominant-baseline="auto">∑</fo:inline> test
</fo:block>
(analogously for the fo:character)
Strictly following the XSL-FO Rec, the behavior for the initial
sample should be identical to using a fo:character, so most likely,
something similar should happen when the font is switched in the
TextLayoutManager internally. TextLayoutManager.AreaInfo does not
carry a reference to any AlignmentContext like
LeafNodeLayoutManager.AreaInfo. Instead the used AlignmentContext is
always the one passed by the parent.
(see TextLayoutManager.getNextKnuthElements(), third line in the method:
alignmentContext = context.getAlignmentContext()
-> that context is used in addElementsForAWordFragment() when
creating the corresponding KnuthInlineBox)
If we can simply make sure that each box gets the alignment context
appropriate for the font used for the word-fragment, that should
suffice.
This could be done either by passing the AlignmentContext via the
AreaInfo, as is done in the superclass, or by having the TextLM hold
a reference to a collection of AlignmentContexts (one for each
effectively used font), and use the appropriate one when creating the
boxes.
HTH!
Cheers
Andreas
