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/
> 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/
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/
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=rev&rev=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
>
Jeremias Maerki
