This content has been marked as final. Show 6 replies
What info is actually read from the fontinfo files? It seems that it is only the FontName, IsItalicStyle, and IsWindowsBold that is used from this file and that all other information is retrieved from the T1 font file header and from the feature file.
hi, im a novice when it comes to font development. i want to convert mac math fonts to pc-compatible fonts. ive been trying to follow the guidelines on how to do it but i cant seem to have an output. dont know how python works and i dont know if my files are correct. i have "PalatBol, PalatBolIta, Palatino, PalatIta and PalatRom" and some other mac math fonts. so how do i put it in features file, etc. and what is "an outline font" mentioned in the overview? i dont see also the window wen i double-click on the makeotf.py (regarding makeotf.py, mentioned and shown on page 2 of the documentation).
pls help me as i have a deadline to meet.
im pc-based by the way. thank you very much.
For that kind of thing, you should not be using the FDK. It is really only helpful for experienced developers. I would recommend TransType, from the same folks who make FontLab.
You're right about what is used from the FontInfo files. They are really just leftover from our older Type 1 development process. I have suggested that the necessary info be incorporated into the feature file instead.
Marten is correct about which keywords are used. The FontName is used to look up name table info in the FontMenuNameDB,. The IsItalicStyle, and IsWindowsBold keywords set the style bits.<br /><br />I can and will implement Adam's suggestions, since they are very easy to do. makeOTF will first search for fontinfo, then for <fontname>.inf. Likewise, it will first search for 'features', then for <PSName>.fea". Note, however, that inf files do not contain the " IsItalicStyle" keyword, unless you edit it in manually.<br /><br />I will also be adding support to the features file for overrides the style settings. If you use these, and there is no fontfino file, then makeOTF will use the PS name from the source font, and the style bits from the feature file table override. Slow evolution, but new fonts can use just the feature file.
these are great news. I also have a few more suggestions.
1. OTFTableEditor crash
There is this nasty bug that makes OTFTableEditor crash when it is running from within FDK.py (when running alone, it is OK). Just dump any table from a font to a file and try adding it to a different font. After selecting the filename of the table file, a "Select table name" dialog appears when OTFTableEditor is running from OTFTableEditor.py. But when running from FDK.py, the editor crashes in this place. I think I already reported it but I'll mention it to be sure.
2. Auto-naming in OTFTableEditor
Upon selecting a font in OTFTableEditor, it would be very helpful if the editor automatically created a unique name (appending 1 to base name or so) for the new font file. This would speed up table copy-paste actions.
3. Copying tables in OTFTableEditor
Currently, copying tables between font files is quite tedious. You need to open a font file, dump the tables into separate files. Then, open a 2nd font file, type in a 3rd filename, add one table. You open the 3rd font, type in a 4th filename and add another table. And so on, one table at a time. This means that to copy GSUB, GPOS, GDEF and BASE from one font to another, you need three intermediate font files and several steps.
Please add a "Copy Selected Tables to font file" button. It would bring up a dialog box to select an .otf or .ttf file. Then, it would open that file, automatically overwrite existing tables (no "Select table name" dialog), and write the new font into the file that has the name which is in the "New File" textbox. Would be very powerful and fast.
4. Make all FDK apps "remember" settings
Ideally, the last folder, and maybe last files I used, per-app, could be stored in a a simple config file.
5. Add the glyph OTFProof CFF plot functionality the functionality into CFFChecker
Currently, the CFF proofing part of OTFProof does similar but slightly different things than CFFChecker.
The CFF portion of OTFProof contains "glyph plot", "glyph synopsis", "alternate glyph synposis" and "glyph synopsis one per page". CFFChecker contains "text dump", "metrics", "text of CFF", "AFM", "PDF proof", "PostScript proof" (yet another alternate glyph synopsis) and "rendered".
Ideally, CFFChecker should contain *all* of the functionality of the CFF portion of OTFProof, plus more.
Hence, please add to CFFChecker:
a) In the Output section, a new tab "Glyph plot", which would duplicate all of the glyph plot functionality of OTFProof.
b) Make the output of CFFChecker's PostScript output and of OTFProof's glyph synopsis output identical
c) In the "Proof" tab, add "PostScript (alternate)" which would be same as OTFProof's alternate glyph synopsis
c) In the "Proof" tab, add "PostScript (one per page)" which would de same as OTFProof's glyph synopsis one per page.
This would make the CFFChecker "the thing" for proof generation, eliminating the necessity of jumping between OTFProof and CFFChecker. Especially adding the glyph plot functionality to CFFChecker would help.
Most of this is feasible and will appear in 1.7 if I have time.
I didn't know that anyone else ever used OTFTableEditor! Suggestion is good. In the meanwhile, you can do a lot by using the command-line version, and scripting in DOS or tcsh, which is why the direct copy has never been implemented in the UI version.
About #5. This list will not be practical in the time I have. However, I can expand a bit on the current "-pdf' option, which directly writes pdf files of the font glyphs. Say "tx -pdf -h" to get the minimal option set.
Also, most of the FDK tools are thin wrappers around a library that takes a single call, passing a string which is the same command line that you would use with the command line version of the tool. As a result, you can easily write your own Python scripts to use them.