Re: OpenType font support
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: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
OpenType font support
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]
RE: finalize style wiki?
Victor Mote wrote (on July 7): > Please review the remaining issues & comment/vote on them so that > we can get > them resolved & be done with style issues for awhile: > http://nagoya.apache.org/wiki/apachewiki.cgi?FOPDevelopersStyleGuide > > At some point, I will clean out any topics that have no content or > discussion, or that are not resolved. OK, I have removed the following sections, which were either empty, were already resolved, had all negative votes, or which attracted no new comments: * Declaration Placement (empty) * Grouping of Imports (empty) * Scope and Reuse of Variables (2-2 split vote, confusion about the content, no explanation forthcoming) * How to Use Certain Control Structures (empty) * Higher Design Patterns to Apply (empty) * Glossary (3 negative votes, no positive) * Exception Handling (Remaining) (no new content, these are design issues that are being addressed in other places on the project) * Mailing List Usage (all this content is now on our maillist.html page on the website) This leaves the following topics: * Checkstyle version * Spelling Rules * Personal Attribution Please review the wiki again to make sure that you have weighed in on any topics you think are important: http://nagoya.apache.org/wiki/apachewiki.cgi?FOPDevelopersStyleGuide Any that aren't resolved in the near future will be deleted, and can be reopened on the mailing list or the wiki. Victor Mote - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
