Jeremias- Alright. Between the kid's naps, I've managed to create a patch to allow for user-configured fonts in Java2DRenderers. I've tested it with the PNG and TIFF renderers.
A couple things... 1) I've renamed the original "FontMetricMapper" to "SystemFontMetricMapper" and created a new interface "org.apache.fop.fonts.FontMetricMapper". Then the new implementation is called "CustomFontMetricMapper," which represents the fonts *not* installed on the system but described in the fop config. I looked at maintaining the original naming but just didn't like any of the names I could think of. If this won't fly perhaps someone can suggest an alternative naming strategy. 2) I changed the signature of the FontInfo.setup method (the java2d version of that class). It actually now more closely resembles its counterpart. Since the PCLRenderer uses this same class I changed the call there as well. However, I don't know how to test that renderer properly and am just guessing that it would be fine. If not, it would be simple to overload the setup method with the former signature and revert PCLRenderer. 3) I don't really know how to write tests for these changes and so, consequently, I didn't. I used the fop script to output PNG and TIFF images with various combinations of settings in my userconfig.xml and it ultimately worked as expected. I'm a pretty big proponent of test-driven development but it wasn't obvious to me how to add new tests -- I'm not familiar with what's setup here and don't have a ton of free time to research it. Let me know if there's something I could read that would help me resolve that quickly. 4) A minor thing...I had originally implemented "CustomFontMetricsMapper.mapChar()" method to simply return the character provided (as the original FontMetricsMapper did). However, there is a side-effect in the underlying Typeface implementation delegate - MultiByteFont - of calling it's mapChar() method. If you *don'* call it, then "embeded fonts" (which these are considered since they pass the test (MultiBytFont.isEmbedable()) ) won't work...NPE on getWidth(). I didn't spend much time looking for a solution to this -- I simply delegated the mapChar method to the internal typeface, which solved the problem. I don't think this is wrong, just don't like to leave these side-effect. I could see somehow re-working the definition of "embeded font" and come up with some way to make it so that these fonts aren't classed "embeded"...though it's probably far more trouble than it's worth...but thought I'd mention it. I've attached the patch to this message...I apologize if this is problematic but I wanted to check primarily on the FontMetricMapper rename before doing anything else with it, like sumbmitting to Bugzilla. Let me know. Thanks! - Patrick Patrick K. Jaromin VP Technology 312.943.1600 * fax 312.640.8100 JGSullivan Interactive, Inc. http://JGSullivan.com -----Original Message----- From: Jeremias Maerki [mailto:[EMAIL PROTECTED] Sent: Friday, November 30, 2007 1:13 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel 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 currnt > 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
fop-java2d-configured-fonts.patch
Description: fop-java2d-configured-fonts.patch
