Hi Adrian

On 30.04.2008 13:19:37 Adrian Cumiskey wrote:
> Hi Jeremias,
> I'm not sure I fully understand, maybe it might clarify this a little for me 
> if you could explain 
> how the font reference mapped to an actual font? 

Sure. For all font triplets that match the criteria in the configuration
a transient field on the associated EmbedFontInfo is set to tell the
font loading code later that it shouldn't set the URL for the font file
on the loaded font which effectively causes the font to be referenced.
The field in EmbedFontInfo is transient as this information doesn't
belong to the part that is cached in the cache file. More beautiful
would obviously be a way to hold this field separately. But creating too
much new stuff just for a boolean seems impractical.

> And what classes would implement Matcher? (I'd 
> probably call that interface FontMatcher).

See the attached patch (not ready to apply, one thing I have to look
into). I've called it Matcher as it's an inner interface for FontTriplet,
i.e. FontTriplet.Matcher. If it's not an inner interface it should
rather be called FontTripletMatcher as the "Font" class is something
else. The two implementations I have are inner classes to
PrintRendererConfigurator as they are only needed there at the moment.

I mentioned the Matcher as you assume you also have to match font
triplets. But you don't do it in the configurator, but in FontInfo.

Maybe later someone needs to add something else, for example, add some
matchers to treat some TrueType fonts not as CID fonts but in
single-byte mode. Who knows: at some point, the matcher might even be
used to implement a different ruleset for font fallbacks than are
already in FontInfo.

> Also would your <fonts/> matching configuration definition reside under each 
> <renderer/> or would it 
> reside more globally and apply to all the renderers as a sibling of 
> </renderers>?  I would propose 
> that in the *future* it would be better if font configuration is managed in 
> the configuration at a 
> global level above <renderers/> in a <fonts/> declaration.
> In this way, fonts would be managed globally in a FontManager and then each 
> Renderer exposes what 
> their font support capabilities are (see 
> http://xmlgraphics.apache.org/fop/trunk/fonts.html#intro). 
>   This would work in a similar way to how image support is communicated.  
> Then at some point in the 
> future when FopFactory, UserAgent etc dependencies have been removed from 
> high level components, 
> there would be an opportunity to migrate more to xmlgraphics-commons.

Sure, the old idea of font sources (see Wiki
http://wiki.apache.org/xmlgraphics-fop/FOPFontSubsystemDesign and the
archives). I'm all for it. I'm annoyed about the font config duplication
myself. But it's not something that can be done on-the-fly. Starting the
bits of the generalization now would just add confusion if you ask me. I
was actually thinking about tackling that as I move the whole thing
to Commons. During the move I don't have to look after backwards
compatibility and anything. At any rate, this has to be designed
carefully so we don't create a mess right from the start.


Jeremias Maerki

Attachment: font-referencing-draft.diff
Description: Binary data

Reply via email to