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



Reply via email to