[Textures] A bit of everything (1/7)

[Paolo Matteucci]

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
> (Lion?).
>
> […]
>
> 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 <
> http://code.google.com/p/yytex/source/browse/trunk/src/c32/afmtoscr.c>,
> 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 <
> http://sourceforge.net/projects/fontforge/files/fontforge-executables/>.
> 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 did actually create (read: "snatch" —see
http://fontforge.sourceforge.net/scripting-tutorial.html) a simple
FontForge script,
which would come in extremely handy (if I could just make the result work
for me, that is! [N.B. the result is the same for me if I follow the above
steps for the FontForge GUI, instead]):

#!/usr/local/bin/fontforge
i = 1
while(i < $argc)

Open($argv[i])

BitmapsAvail([10])

Generate($argv[i]:r + ".res", "bin")

i = i + 1

endloop


Call it, say, convert.pe, place it into your PFB files folder, cd to that
directory in the Terminal and issue

$ chmod +x convert.pe
$ convert.pe *.pfb


The latter will generate the LWFN + FFIL files for all the PFB files in that
directory for you.

To test something different, yet pretty "standard", I ran my tests against
Claudio Beccari’s greek fonts (
http://www.ctan.org/tex-archive/fonts/greek/cbfonts). The results for a
couple of fonts (for both FontForge [via scripting, *not* working] and
FontLab Studio [via GUI —but apparently it could be {Python-} scripted,
working) are attached.

As metrics, I simply used CTAN’s TFMs directly since Textures 2.2.0b16 can
handle them fine.

The good thing about this method (again, *if* I could make FontForge work
for me!) is that for most ["standard"] TeX [PFB] fonts we’d have a way to
easily and quickly convert them for use with Textures. (N.B. LWFN [silly]
naming limitations [enforced by both FontForge and FontLab Studio, though
probably no longer necessary on Mac OS X?] *can* be an issue when converting
a lot of "similarly named" fonts.)

I don’t think TrueType is really an option for the [potential] degradation
and licensing issues already mentioned by Bruno — see below about OTF/CFF.


> OpenType
> --------
>
> OpenType OTF format is the next candidate, called "OpenType (CFF)" by
> FontForge. As far as I understood this is mostly a container preserving the
> PostScript nature of the PFB font, namely the fact that the glyphs are
> defined by cubic splines.
>
> Unfortunately in all the tests I did, trying all possible prior
> re-encodings, no glyph showed up in Textures when drawing char tables, or at
> best the 24 alphabet letters and a couple of other characters showed up but
> no accents, no diacritics, etc.
>
> The reason for this remains a mystery to me: is there some step I missed or
> some setting I did wrong in FontForge, or is Textures 2.2 unable to use
> OpentType fonts?
>

I think I can shed some light on this: the PFB to CFF ("PS-flavo[u]red" OTF)
conversion tests I ran for the greek fonts above [with both FontForge and
FontLab Studio] were successful in creating the relevant OTF files, "but"
placed the characters into the *correct* Unicode slots, which Font Book,
Linotype FontExplorer, FontForge, FontLab Studio, etc. could all interpret
correctly, but Textures couldn’t because —I believe— it doesn’t have a, say,
"Unicode" encoding to render the fonts against.

Actually, I think the CFF route is the way to go, in that Mac OS X is likely
to keep on supporting PS-flavoured OpenType fonts in the future (unlike the
old Mac Type 1 fonts), and no degradation should be involved in the PFB to
CFF conversion, aside from sparing us all the "malarkey" associated with the
LWFN + FFIL combination.

So, I guess we just have to wait for Textures to support them/introduce the
relevant "encoding" (it would be interesting to know what the Blue Sky guys
have to say about this…).

Paolo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://email.esm.psu.edu/pipermail/textures/attachments/20110328/a0c41948/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FontForge 20090923.zip
Type: application/zip
Size: 120548 bytes
Desc: not available
URL: <http://email.esm.psu.edu/pipermail/textures/attachments/20110328/a0c41948/attachment.zip>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FontLab Studio 5.0.4.zip
Type: application/zip
Size: 197918 bytes
Desc: not available
URL: <http://email.esm.psu.edu/pipermail/textures/attachments/20110328/a0c41948/attachment-0001.zip>