On 29.11.2007 17:00:40 Patrick Jaromin wrote: > Jeremias- > > Thanks! Sounds great on #1. > > As for the font stuff...we need to be able to have "per template" fonts > as the application allows for dynamic addition of new ones and there are > multiple independent users. One of the problems with our current system > is having to manage fonts for multiple projects on a system-wide > basis...and automating their installation. > > Here's a "sneak peak" at how I've done it in my environment...let me > know if you see any "gotchas" in this 30,000ft view.... > > In my application I've already created a custom renderer that extends > Java2DRenderer, so I overrode "setupFontInfo" with code essentially > copied from org.apache.fop.fonts.FontSetup.addConfiguredFonts(). Then, > due to the cast to the concrete class "FontMetricsMapper" in > Java2DGraphicsState.updateFont line 131 from HEAD, I created a new class > that extends FontMetricsMapper, overriding *all* of the methods and > using an underlying "LazyFont" for the metrics and the java.awt.Font for > the actual font. Clearly this is a messy work-around, but I didn't want > to muck-about with my own fork of FOP. > > My first thoughts regarding a patch would be to turn FontMetricsMapper > into an interface or abstract class (haven't reviewed that closely > yet)...or look into the addition of a separate interface for the methods > required by Java2DGraphicsState. Then the current FontMetricsMapper > would be refactored into a new concrete class -- same code -- and a new > "UserFontMetricsMapper" or something would implement the same ints. > > So first, does this seem reasonable?
Yes, I think so. If you need to load your own fonts from font files (java.awt.Font.createFont(int, InputStream)) that could be a reasonable approach. Java2DGraphicsState simply needs access to the java.awt.Font, so an abstract base class (extending Typeface, implementing FontMetrics) would make sense there. > Second - my version of this (I named it 'UserFontMetricMapper') > delegates the "Typeface" methods to a LazyFont instance -- so basically > I'm using the generated font metrics from the xml file, *not* calculated > from the actual awt Font. It *looks* good to me onscreen, but I don't > know if this is a reasonable strategy or not. Since I'm generating > *both* PDFs and bitmaps using the same templates, it seemed reasonable > to use the same font metrics. But I don't know enough to be confident > about that. Just this morning I noticed a "CustomFont" class and the > "FontLoader" which seem like they could have a role here in place of the > LazyFont class and my loading code...though I haven't had a chance to > review these more closely and give it much thought. You noticed FontLoader. That's good because it allows you to skip the XML font metric file entirely which simplifies things a lot for the users. We've discussed sharing of font metrics between PDF/PS and Java2D/AWT before but never had time to really do experiments. However, in my recent effort to improve font handling for SVG->PDF output I basically just did that, although in the other direction: Batik uses AWT font metrics but the PDF handling code finally uses FOP's own font subsystem to actually "paint" the fonts. It turned out that the font metrics were "good enough" to get matches. It only looks very bad if no matching font can be found in which case the wrong font metrics of the substituted font can make the whole thing look really ugly. The tricky thing was matching the font family names between AWT and FOP's own font subsystem. But that is now improved, too. So in the end, I think your idea could work. > As for the paperwork...no biggie...we've got an Apache committer on > staff and know the drill! :-) <snip/> Jeremias Maerki
