OpenType font support

[Victor Mote <vi...@outfitr.com>]

Jeremias et al:

None of this has been committed --

I have working fonts.apps.OTReader and fonts.opentype.OTFile classes, which
allow us to build font metrics for OpenType fonts that wrap CFF (Type 1)
files (the regular TTFReader appears to work fine for OpenType fonts that
are TTF or TTC files). I haven't messed with the embedding side yet. I
mostly just copied the TTFReader & TTFFile classes & made a few adjustments
to handle the wrapper. I had to make some of the classes in the
fonts.truetype package public to get this to work. The font metrics info for
*all* OpenType files, whether TrueType or Type 1, are stored in
TrueType-style tables. I suspect that when I get to embedding, there will be
code shared with the Type 1 fonts.

Ideas:
1. Since there is so much shared code, do you have any objection to either
1) putting all of this in the same package, or 2) making the needed classes
public?
2. Our main class for this work is TTFFile, which is a good name. Since the
file can encapsulate x typefaces, where x >=1, I would like to break the
typeface-specific part of this into a separate class (an implementation of a
new TypeFace Interface), then break each table into a separate class (this
has already been done for some of the tables). This would make sharing it
with OpenType much cleaner.
3. I haven't looked much at the Postscript side, but assume that we probably
have some similar things to do there.
4. I would like to go ahead & start building the TypeFace Interface that
these various concepts can all use.
5. It wouldn't be hard to have a generic font reader that handles creating
the font metrics files for all three types of fonts automatically.
6. Unless there is a performance hit (which seems unlikely since we have to
parse the metrics file anyway), we might think about eliminating the font
metrics file completely, and simply parse the information directly out of
the font file at runtime. The config file has to point to a physical font
file, but this would eliminate a whole category of user interaction.

We still have some open issues on how the interface ties in with the rest of
FOP, but I think all of this can be done without treading into that area.
Also, once the above is implemented, I think the rest of the issues will be
easier to see.

Victor Mote


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org

Re: OpenType font support

[Jeremias Maerki <de...@greenmail.ch>]

Hi Victor

On 19.07.2003 21:37:17 Victor Mote wrote:
> Jeremias et al:
> 
> None of this has been committed --
> 
> I have working fonts.apps.OTReader and fonts.opentype.OTFile classes, which
> allow us to build font metrics for OpenType fonts that wrap CFF (Type 1)
> files (the regular TTFReader appears to work fine for OpenType fonts that
> are TTF or TTC files). I haven't messed with the embedding side yet. I
> mostly just copied the TTFReader & TTFFile classes & made a few adjustments
> to handle the wrapper. I had to make some of the classes in the
> fonts.truetype package public to get this to work. The font metrics info for
> *all* OpenType files, whether TrueType or Type 1, are stored in
> TrueType-style tables. I suspect that when I get to embedding, there will be
> code shared with the Type 1 fonts.
> 
> Ideas:
> 1. Since there is so much shared code, do you have any objection to either
> 1) putting all of this in the same package, or 2) making the needed classes
> public?

No objections, but I'd prefer the second option so different things
don't get mixed.

> 2. Our main class for this work is TTFFile, which is a good name. Since the
> file can encapsulate x typefaces, where x >=1, I would like to break the
> typeface-specific part of this into a separate class (an implementation of a
> new TypeFace Interface), then break each table into a separate class (this
> has already been done for some of the tables). This would make sharing it
> with OpenType much cleaner.

+1

> 3. I haven't looked much at the Postscript side, but assume that we probably
> have some similar things to do there.

Probably.

> 4. I would like to go ahead & start building the TypeFace Interface that
> these various concepts can all use.

+1. Sorry BTW for not being more reponsive to your "font wiki" mail.
I've had a quick glance at it but I didn't have the time to put enough brain
time into it. I'm pretty busy ATM.

> 5. It wouldn't be hard to have a generic font reader that handles creating
> the font metrics files for all three types of fonts automatically.

+100!

> 6. Unless there is a performance hit (which seems unlikely since we have to
> parse the metrics file anyway), we might think about eliminating the font
> metrics file completely, and simply parse the information directly out of
> the font file at runtime. The config file has to point to a physical font
> file, but this would eliminate a whole category of user interaction.

+100, too. If there IS a performance hit we can also write that XML file
on the fly if it doesn't exist and reuse it in subsequent runs. But I'm
pretty confident that this won't be necessary. But: The Type 1 side will
need a PFA parser for better font metrics extraction. With the PFM there
is just too much guessing involved. Additionally the PFB reader could be
extended to parse the first ASCII-part which also contains many values
from the PFA.
> 
> We still have some open issues on how the interface ties in with the rest of
> FOP, but I think all of this can be done without treading into that area.
> Also, once the above is implemented, I think the rest of the issues will be
> easier to see.

I agree. Have fun!


Jeremias Maerki


---------------------------------------------------------------------
To unsubscribe, e-mail: fop-dev-unsubscribe@xml.apache.org
For additional commands, email: fop-dev-help@xml.apache.org