The userconfig.xml contains a fonts tag enabling custom fonts to be used in rendering. The awt and pdf output render these fonts differently. A way to render such fo documents more consistantly across different outputs is to enable configuration roles for the fonts xml tag.
Created attachment 13246 [details] Describes the source changes to enable roles to be defined in the userconfig.xml
Created attachment 13248 [details] A simple fo document to replicate the error with.
Created attachment 13249 [details] Fop configuration xml file
Created attachment 13250 [details] An executable batch file to show the difference between pdf and awt outputs
Created attachment 13251 [details] Example fop config xml that works with the patched files.
Hi Peter: What you propose here is interesting, but I am a bit confused. You have split the font configuration into two parts, one for awt and one for pdf, and I see a few differences between them, but I don't understand what these differences are accomplishing. Would you please elaborate a bit on *why* this change solved your problem? My current theory is that any improvement that you have in making awt comparable to pdf is probably due to unintentionally getting the awt renderer to use the free-standing fonts instead of the system fonts (see below) or maybe vice versa. Also, the issue is somewhat bigger than awt vs. pdf, although that can be solved by adding some more roles. The real issue is system fonts (those registered with the o/s), which awt uses, vs. what I call free-standing fonts (those using an independent registration system), which pdf and PostScript use. System fonts don't use or need most of the stuff in the font configuration. The fonts used by the two systems can be different, and even if the fonts are identical, the metrics are obtained differently between the two systems. I have spent much of the past six months refactoring and improving the FOP font system, and I have partly addressed the issue that you mention, by adding a system-font element in the font configuration file. It doesn't do much ATM except recognize that there is a difference. See the notes here: (http://www.foray.org/release.html). If you will elaborate a bit on what you would like to see happen, I am interested. Victor Mote
The latest changes [1] should achieve the intended goal of this entry as far as it is currently possible. Improvements are certainly still possible, for example for Type 1 fonts by implementing a PFB and/or PFA parser like FOray has. For Type 1 fonts, the "full name" of a font is still not properly reported. An additional idea in this context is to implement a "font substitution" section in the configuration file which becomes somewhat necessary now that we have font auto-detection. [1] http://svn.apache.org/viewvc?rev=593189&view=rev
batch transition pre-FOP1.0 resolved+fixed bugs to closed+fixed