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. 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? Any ideas, suggestions from the property gurus? Manuel
