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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
