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:
<snip/>
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;
by
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).
WDYT?
Cheers
Andreas
