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. <snip/> Jeremias Maerki
Description: Binary data