[Textures] A bit of everything (1/7)
p.n.matteucci at gmail.com
Tue Mar 29 06:40:02 EDT 2011
2011/3/28 Michael Sharpe <msharpe at ucsd.edu>
> On Mar 28, 2011, at 8:59 AM, Paolo Matteucci wrote:
> > Some [far from enlightening :-/] comments [on PS fonts], as promised…
> > 2011/3/22 Bruno Voisin <bvoisin at me.com>
> > General principles: Fonts
> > =========================
> > TeX fonts generally come in PostScript Type 1 format (either PFB binary
> files or PFA ascii files), often accompanied with metric files in AFM format
> (if not, the AFM files can be recreated from the PFB or PFA files). To be
> used by Textures, the fonts must be converted to a format recognized by OS
> X, which may raise license issues. I won't enter into these, except in one
> case (Lucida), and leave it to the reader to assess the matter…
> > PostScript
> > ----------
> > The Mac version of a PostScript font is a screen font suitcase, in FFIL
> resource format or DFONT data format, plus printer font files in LWFN
> format. These are legacy formats inherited from Mac OS Classic. On OS X they
> are deprecated and may stop being supported at any point in the future
> > […]
> > In addition, FFIL/DFONT screen fonts are required. These are only used by
> OS X to locate the LWFN files and get basic metric info, no character
> bitmaps or outlines from the screen fonts are actually used. For that
> reason, the Windows-only Y&Y Font Manipulation Package (see "Creating Mac
> screen fonts from Type 1 outlines" at the bottom of <
> http://www.faqs.org/faqs/fonts-faq/part7/>) included a tool AFMtoSCR for
> creating fake Mac screen fonts from AFM metric files.
> > […]
> > AFMtoSCR still lives as C source <
> but I do not think it has ever been ported to the Mac or to Unix.
> > Actually, the code seems to make use of fairly standard libraries
> (different paths [and path separator] aside), and I believe it would be
> worthwhile porting not just AFMtoSCR, but the whole Y&Y Font Manipulation
> Package to Mac/Linux, but am afraid that would require someone better at C
> than me! :-(
> > This only leaves FontForge <http://fontforge.sourceforge.net/>, using
> the binary packages now relegated at <
> FontForge can be scripted, and the GW Extras i-Package includes such a
> script dumpafm.pe for extracting AFM files from a DFONT suitcase or a TTC
> collection (see the penultimate message in this series). However, I am
> totally helpless at scripting and won't venture into this territory.
> > So let's go GUI: with FontForge installed, practically any font file can
> be double-clicked in the Finder and it will open in FontForge. For each PFB
> file you must first create a bitmap version by going to
> > Element > Bitmap Strikes Available
> > (namely, go to the Element menu and select "Bitmap Strikes Available").
> Check the Mac checkbox and enter a bitmap size; I chose 4 pt, which was the
> bitmap size of the screen fonts in BSR's distribution of the Lucida fonts
> (this is immaterial, since the bitmaps are not actually used). Then go to
> > File > Generate Fonts
> > and select
> > PS Type 1 (Resource) + NFNT (Resource)
> > This will create a .bmap screen font in FFIL format, and a LWFN printer
> font file. The FFIL file will have the name of the AFM metrics inside the
> PFB file, and the LWFN file will have a name satisfying some norm like
> 3-letter abbreviations for each of Bold, Italic, etc.
> > However, the result doesn't work because of the way the fonts are grouped
> in families by Mac OS.
> > Actually, this doesn’t work for me even for a single font! (FontForge
> 20090923) …whereas it works perfectly if I use FontLab Studio (v5.0.4). :-?
> > […]
> I don't have a recent Textures that can serve as the ultimate test, but
> with a small change to Bruno's instructions, I can produce a PS Type 1
> (Resource) + NFNT (Resource) that works when installed via Fontbook.
> Before opening your pfb, make sure that the corresponding afm is in the
> same folder, so that when FontForge opens the pfb, it picks up the complete
> metrics from the afm.
> After you open the pfb, select the menu item Encoding > Reencode >
> Macintosh Latin. (The font may print OK, but will not show correctly on the
> screen without this step.)
> Then follow the remaining steps to generate the single old-style Macintosh
> font pair. I didn't try it, but I think the same should work for a family if
> you choose instead File > Generate Mac Family.
Thank you, Michael.
Actually, I don’t think the AFM step is necessary: after all, FontLab Studio
doesn’t need it, and most TeX [PS] fonts are supplied as PFB + TFM pairs, so
the AFMs would have to be recreated from those, anyway.
What did eventually make FontForge generate a Mac OS X-valid LWFN + FFIL
pair is the "Macintosh Latin" re-encoding (script-wise, it’s enough to add
the line Reencode("mac") before generating the fonts), *but* this is not
always what you want, and did not work for the fonts at hand: as in the CFF
case, the characters got slotted into the *correct* positions (e.g., alpha
into the "alpha" slot, not into the "a" slot), which seem to lie *beyond*
what Textures is able to see *even if* you explicitly set the encoding to
"MacintoshStandard" in the TeX metrics window.
I tried also with the "Symbol" encoding, but FontForge didn’t seem to be
able to generate a Mac OS X-valid LWFN + FFIL pair in that case, whereas I
didn’t try with the "Adobe Standard" one.
I must admit I ran *very* quick tests, so OS and/or Textures font caching
might have played a role there, but they seemed to confirm the impression
that FontForge (unlike FontLab Studio) is unable to generate a valid LWFN +
FFIL/NFNT pair for "custom" encodings… :-(
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Textures