On Jul 20, 2007, at 11:56, Andreas L Delmelle wrote:

On Jul 20, 2007, at 08:02, Manuel Mall wrote:

On Jul 20, 2007, at 05:47, Manuel Mall wrote:

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

Andreas, how about this as a way forward: You implement the font lists in the Property system / FO Tree and I deal with the implementation of the font selection based on char, Knuth box and area creation logic in TextLM
using the font data structures you come up with?

Good idea. It should not take me too much time to finish that. Something for the weekend, maybe.

I've looked a bit closer, and bumped into something I would like to address as well concerning fonts, so thought I'd check here to see if anyone has had similar thoughts before.

org.apache.fop.fonts.Font contains a fontSize member. I would like to see this separated from the Font instance somehow. Instead of fetching a Font corresponding to given triplet and font-size, we would get one corresponding to the triplet. In the Font-methods that use the font-size, I would then add an int parameter, so the font- size can be passed in by the caller.

No idea if this makes sense, or what the initial motivation was to embed the font-size in the Font instance. If there's a good reason, please enlighten me...

Once this is done, the basic Font instances corresponding to the triplets as specified on the FO, could be fetched/checked very soon in the process, since the dependency on the only layout-dependent component is removed. Much sooner than is the case now: ultimately the instances are created following the call to CommonFont.getFontState() in TextLM.initialize(). (To be more precise, currently "the instance (singular) corresponding to the first specified font-family is created ...")

As to then further addressing the font-family fallback/font-selection issue, as indicated, I would replace in CommonFont:

    private Font fontState;


    private Font[] fontStates;

Change the getFontState() signature:

- either make it
    public Font[] getFontStates()

- or add an extra char parameter to getFontState(), that would allow CommonFont to seek a Font in its list that contains a mapping for the given char

Which strategy is preferred? I'm even thinking that maybe it would even be better design not to store/create Font instances in CommonFont at all, and instead of doing so, *always* forward the font- lookup to FontInfo (not only the first time getFontState() is called, as is the case now).




Reply via email to