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 biggie...we've got an Apache committer on
staff and know the drill! 


Patrick K. Jaromin
VP Technology
312.943.1600 * fax 312.640.8100
JGSullivan Interactive, Inc.

-----Original Message-----
From: Jeremias Maerki [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 29, 2007 8:05 AM
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
> 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
> ( 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 
> (, 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.


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
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:


Jeremias Maerki

Reply via email to