Re: svn commit: r474387 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/fonts/type1/
Jeremias Maerki a écrit : Another of my travel projects checked in: I wanted to know how easy it is to load fonts without the XML metrics file. As you can see from the amount of code, it was rather easy. Makes me wonder why we didn't do it earlier. :-) Nice work, Jeremias. Well, definitely an additional point for FOPFont. Please note that the existing functionality is still fully there. The only change is that you can simply now omit the metrics-url attribute in the font configuration and the font will still load. What you lose in this case is the ability to manually tweak the XML metrics file or to specify WinAnsi encoding for TrueType fonts. Furthermore, you currently don't have control over TrueType Collections. The WinAnsi feature should not be necessary anymore now that we have ToUnicode CMaps. The Collection feature is easily added again through an additional attribute in the font configuration. ... and I don't see why one would need to tweak the metrics of a font? I'd be grateful if anyone could test what happens if you load a Type 1 fonts on a Unix where the PFM file has an uppercase extension, e.g. FUTURA.PFM. I have to construct the URI to the PFM manually from the PFB and use a lowercase extension (.pfm). Maybe we have to improve that to check with upper- and lowercase to account for case sensitive file systems. This fails. IMO the safest solution is to require that the name of the pfm file is specified in the config file. All the more so it should also be possible to give an afm file instead of a pfm one (BTW, Fop can't read afm files, can it? Because FOrayFont can...). If this is ok for you I'll implement these changes. Oh, or perhaps wait that a final decision about FOrayFont is made. Vincent
Re: svn commit: r474387 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/fonts/type1/
Jeremias Maerki a écrit : I'd be grateful if anyone could test what happens if you load a Type 1 fonts on a Unix where the PFM file has an uppercase extension, e.g. FUTURA.PFM. I have to construct the URI to the PFM manually from the PFB and use a lowercase extension (.pfm). Maybe we have to improve that to check with upper- and lowercase to account for case sensitive file systems. This fails. IMO the safest solution is to require that the name of the pfm file is specified in the config file. All the more so it should also be possible to give an afm file instead of a pfm one (BTW, Fop can't read afm files, can it? Because FOrayFont can...). Make that optional, if the pfm file name deviates from the normal pattern. Simon
Re: svn commit: r474387 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/fonts/type1/
On 14.11.2006 11:28:10 Vincent Hennebert wrote: Jeremias Maerki a écrit : Another of my travel projects checked in: I wanted to know how easy it is to load fonts without the XML metrics file. As you can see from the amount of code, it was rather easy. Makes me wonder why we didn't do it earlier. :-) Nice work, Jeremias. Well, definitely an additional point for FOPFont. Please note that the existing functionality is still fully there. The only change is that you can simply now omit the metrics-url attribute in the font configuration and the font will still load. What you lose in this case is the ability to manually tweak the XML metrics file or to specify WinAnsi encoding for TrueType fonts. Furthermore, you currently don't have control over TrueType Collections. The WinAnsi feature should not be necessary anymore now that we have ToUnicode CMaps. The Collection feature is easily added again through an additional attribute in the font configuration. ... and I don't see why one would need to tweak the metrics of a font? Fonts like ZapfDingbats or Symbol don't work out of the box. There are a lot of fonts out there which use strange values in their PFMs. Without the ability to parse AFMs we will always have a restricted support for Type 1 fonts. I'd be grateful if anyone could test what happens if you load a Type 1 fonts on a Unix where the PFM file has an uppercase extension, e.g. FUTURA.PFM. I have to construct the URI to the PFM manually from the PFB and use a lowercase extension (.pfm). Maybe we have to improve that to check with upper- and lowercase to account for case sensitive file systems. This fails. IMO the safest solution is to require that the name of the pfm file is specified in the config file. Thanks for the feedback. Just as I suspected. I agree with your view. All the more so it should also be possible to give an afm file instead of a pfm one (BTW, Fop can't read afm files, can it? Because FOrayFont can...). /me is looking jealously over to ForayFont for its PostScript interpreter and AFM parser which uses that. If this is ok for you I'll implement these changes. Oh, or perhaps wait that a final decision about FOrayFont is made. Vincent Jeremias Maerki
Re: svn commit: r474387 - in /xmlgraphics/fop/trunk: ./ src/java/org/apache/fop/fonts/ src/java/org/apache/fop/fonts/truetype/ src/java/org/apache/fop/fonts/type1/
Another of my travel projects checked in: I wanted to know how easy it is to load fonts without the XML metrics file. As you can see from the amount of code, it was rather easy. Makes me wonder why we didn't do it earlier. :-) Please note that the existing functionality is still fully there. The only change is that you can simply now omit the metrics-url attribute in the font configuration and the font will still load. What you lose in this case is the ability to manually tweak the XML metrics file or to specify WinAnsi encoding for TrueType fonts. Furthermore, you currently don't have control over TrueType Collections. The WinAnsi feature should not be necessary anymore now that we have ToUnicode CMaps. The Collection feature is easily added again through an additional attribute in the font configuration. I'd be grateful if anyone could test what happens if you load a Type 1 fonts on a Unix where the PFM file has an uppercase extension, e.g. FUTURA.PFM. I have to construct the URI to the PFM manually from the PFB and use a lowercase extension (.pfm). Maybe we have to improve that to check with upper- and lowercase to account for case sensitive file systems. On 13.11.2006 17:28:14 jeremias wrote: Author: jeremias Date: Mon Nov 13 08:28:13 2006 New Revision: 474387 URL: http://svn.apache.org/viewvc?view=revrev=474387 Log: Added initial support for loading fonts without a pre-created XML font metrics file. Added: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontLoader.java xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/truetype/TTFFontLoader.java xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/type1/Type1FontLoader.java Modified: xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/CustomFont.java xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/FontSetup.java xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/LazyFont.java xmlgraphics/fop/trunk/src/java/org/apache/fop/fonts/MultiByteFont.java xmlgraphics/fop/trunk/status.xml snip/ Jeremias Maerki
