On Jul 20, 2007, at 05:47, Manuel Mall wrote:
Moving this to a separate thread with a more meaningful subject (at
least
I think so).
Looking back at something like font-selection strategy: the more I
look at it, the more I agree with the initial suggestion to deal with
it during the layout-phase. Instead of generating multiple FOText
instances that are tied to different fonts, the CommonFont
information should precisely be moved away from the FOText.
I agree with the sentiment that this is a layout function and that
generating separate FOText nodes during parsing is not the way to go.
What ultimately convinced me was a suggestion (from way back when)
that certain merging and substitution of unicode sequences into
characters should also be performed much later in the process (if and
when implemented). I would presume that font-selection needs to take
into account the results after those have been applied.
In my mind if we solve the issue how to get the applicable font
list to
TextLM the task of modifying TextLM to generate separate knuth
boxes and
later areas when the font changes shouldn't be too hard. Yes, there
are
text alignment issues to be dealt with but that could even be
deferred to
a second step. So, instead of a CommonFont object do we need a
List<CommonFont> object in the FO tree to deal with this?
Not exactly a list of CommonFont info, if I'm correct, but more a
list of references to the Font instances that are covered by each
CommonFont. In fact, if you look at CommonFont, apart from the
private fontState, it seems to be a possible candidate for caching as
well.
The only obstacle is the font-size, which can be percentage. AFAICT,
this makes each CommonFont instance essentially dependent on the FO
it is attached to...
The image that was beginning to take form in my mind for the basic
font-family fallback implementation:
- make it CommonFont.fontState*s* a List<Font> instead of a single Font
and
- either add a char parameter to CommonFont.getFontState(),
and have it return the first Font instance containing a mapping
for the given char
- or make it getFontStates() and have it return the entire List
for the TextLM to sort out
As to how the TextLM should then further handle it, I hadn't really
looked deeper into so far, but it seems like you have... 8-)
Cheers
Andreas
