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? 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. As for the paperwork...no biggie...we've got an Apache committer on staff and know the drill! Thanks! 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: Thursday, November 29, 2007 8:05 AM To: fop-dev@xmlgraphics.apache.org Subject: Re: Custom Fonts in Java2DRenderer & Hardcoded ColorModel Hi Patrick On 29.11.2007 14:41:30 Patrick Jaromin wrote: > Hi all! > > I've been working on a project and was bitten by a couple known issues. > I've resolved them for *my* project and would be interested in > creating a patch or at least assisting with it...but could use some > additional information/advice. Great. Let's see what we can do for you... > First one...I can't find a bug report for it, but the issue is > discussed in an archived list post > (http://marc.info/?l=fop-user&m=115895490501970&w=2) and there's a > TODO in the code in HEAD - Java2DRenderer, line 933. Is anyone > currently working to resolve this? I don't really know much about > color spaces but I can't find a situation in my tests where the > current model > (CS_LINEAR_RGB) is preferable. From the page on sRGB > (http://www.w3.org/Graphics/Color/sRGB.html), I can see that it > appears to be web-specific. But none of the images I've tried with the > CS_LINEAR_RGB are practically usable. What's the current thought on > this or is it just a corner-case that no one really cares much about? > Or -- is there a plan to replace the unencoded bitmap arrays with > Java-native images for this renderer? Yes, I've done that. I'm currently rewriting the whole image subsystem for FOP to address various shortcomings (such as the color space problem in the Java2DRenderer). And incidentally, I've just committed code [1] half an hour earlier (although on a temporary branch) which already addresses this. [1] http://svn.apache.org/viewvc?rev=599436&view=rev Concerning the color spaces: sRGB is the main color space used by XSL-FO and SVG. All colors are defined in that color space. But not all bitmap image formats support color spaces or define in which color space the colors are. In such a case RGB colors are in a device-specific RGB color space (CS_LINEAR_RGB). Since I've implemented PDF/A support in FOP, I've started paying more attention to sRGB. In some cases device-specific RGB already gets treated as if it were sRGB which does not in all cases make people happy. There has been the occasional complaint that red rgb(255,0,0) is no longer "red" but actually something else (it appears slightly differently on a screen, depending on the viewer and the devices attached to the computer). But that's an expected side-effect from color management and today's treatment in FOP is much more compliant to the FO spec than in earlier versions of FOP. In general, I think it's safe to transfer device-specific RGB into sRGB by default (which matches your statement above). FO doesn't say what should be done with bitmap images which don't indicate their color space. So this is a decision we must take ourselves. Anway, it will take a few more days until I've finished the image package rewrite only after which it will be merged back into FOP Trunk. So my changes may not immediately be available to you. > The second item is support for user-configured fonts for > Java2DRenderer produced documents. I've made this work for me by > extending the Java2DRenderer (I needed to do this for other reasons > anyway), and FontMetricsMapper along with a fair bit of unfortunate > cut-n-paste from FontSetup. I could see this being refactored into a > patch -- but I didn't want to take the considerable time to do this if > someone already had a fix in the works. Also, I'm very new to FOP (a > few weeks) and there are likely some significant issues that would > need to be considered in a formal patch for the general library. I know of noone who works on this. I didn't consider it important because you can always install the fonts in the operating system and they will then be available in FOP. Especially after the recent round of improvements in the font area, I didn't think there would be many open desires. But if you can provide a patch which does not involve too much copy/paste, but cleanly refactored code, that's great and we will certainly review that. I guess the only thing to remind you about is that we will require an ICLA (and if necessary a CCLA) from you on file if your patch is a bit bigger than just a few lines of code in a Java class. More info here: http://www.apache.org/licenses/#clas http://xmlgraphics.apache.org/fop/dev/index.html#patches HTH Jeremias Maerki
