Make OTFUser Guide
MakeOTFUserGuide
MakeOTFUserGuide
User Manual:
Open the PDF directly: View PDF .
Page Count: 16
MakeOTFv2.5 User Guide 1
MakeOTF v2.5 OpenType/CFF compiler
User Guide
Overview
MakeOTF is a tool designed to create an OpenType® font from a source font le and from a text le
containing high-level descriptions of OpenType layout features. It is designed to run as command-
line tool: a command typed into the Terminal window on Mac OS® X, or in the DOS window on
Windows®. Note that MakeOTF is only a compiler of font data, not a font editor.
MakeOTF requires a number of source les that can all be specied through options for the
makeotf command:
font. Usually named font.pfa or cidfont.ps. is can be either a Type or CID font le, a Tru-
eType font le, or an OpenType/CFF font le. Note that only the glyph outlines are taken from
the source font..
features. A text le which provides the denitions for the OpenType layout feature rules, and
species values for some of the OpenType table elds that will override the default values
calculated by MakeOTF.
FontMenuNameDB. A text le which provides the Windows and Mac menu names for the font.
GlyphOrderAndAliasDB. is le serves three purposes. One purpose is to establish the glyph ID
order in the font. Another is to allow glyphs in the output .otf le to have dierent names
than the glyphs in the input source font data. is permits developers to use friendlier names
during development of a font, and use dierent names in the nal OpenType le. e third is
to provide Unicode® values for the glyphs. MakeOTF will provide Unicode values by default
for some glyphs, but not all.
An additional le, fontinfo, is not required, but if present, will be examined for keywords that
cause MakeOTF to set some specic options.
In order to avoid having to enter the options to specify the necessary les every time you want
to build an OpenType font, MakeOTF can save a font project le that stores all desired options.
MakeOTF will always write the last set of options used, to a le named current.fpr located in the
same directory as the input font le. (Project les can also be saved under other names)
Options can be added to the makeotf command to set parameters that change how MakeOTF
builds an OpenType font. When options conict, the last one on the command line will override
any earlier conicting options.
Using MakeOTF
MakeOTF comes in two parts which can actually be called independently:
makeotfexe is a program written in C, and is actually the tool that builds the OpenType font le.
It requires, however, that all the source les be explicitly specied with options on the com-
mand line.
MakeOTFv2.5 User Guide 2
makeotf
is a commadn shell that calls the Python™ script MakeOTF.py. is will look for the
source les in some standard locations, and ll in default values for options. It can also read
the options needed from a project le (current.fpr), which means that for a particular font,
one only needs to type-in all the options once. When MakeOTF.py has gathered all the source
les, it will call the makeotfexe program.
In general, one should invoke MakeOTF.py with the makeotf command. is way, the last set of
options used will always be recorded in a project le.
e rst step in using MakeOTF is to assemble the source les. It is oen a good idea to organize
the les in a directory tree, like this:
MyFont Family/
FontMenuNameDB
GlyphOrderAndAliasDB
Roman/
features.family
MyFont-Bold/
font.pfa
features
features.kern
MyFont-Regular/
font.pfa
features
features.kern
Italic/
features.family
MyFont-Italic/
font.pfa
features
features.kern
MyFont-BoldItalic/
font.pfa
features
features.kern
e idea is that some data, such as the les FontMenuNameDB and GlyphOrderAndAliasDB, will be
shared between all members of the type family, whereas other data will only apply to a subgroup of
the family. By placing the shareable data at a higher level in the directory tree, one can avoid having
multiple copies of the same data, which means there will be less les to edit, in case the data needs
to be changed. is is most important for the features.family le.
Usually, positioning rules such as kerning (
features.kern
) are specic to each font, but most
(or all) of the substitution rules are likely to be the same for all fonts. A good practice is to have a
features le for each family member, in the same directory as the source font le, and then use an
include
statement to reference feature les located higher in the directory tree. In the example above,
there are two separate features.family les, one for Roman and another for Italic. ese can, in
turn, be shared between all family members under each branch. e need for two dierent
features.
MakeOTFv2.5 User Guide 3
family les, comes from the fact that Roman and Italic styles might not have the same number of
substitution (GSUB) rules — Italic tends to have more.
Once one has assembled all the necessary les, the next step is to open a command window — the
Terminal program on Mac OS X, or the Command program on Windows —, and use the cd com-
mand to set the current working directory to the directory which contains the set of source les to
compile the OpenType font:
cd <path to font directory>
and then type the makeotf command, with the options needed. For example:
makeotf –f myfont.pfa –ff myfeatures –b –r
or
makeotf –fp myproject.fpr
MakeOTF options
Option Setting Description
–fp <file path> Specify path to project le. If no path is given, the default is current.fpr.
MakeOTF will read the options from this project le. e project le
contains values only when they dier from the default value. e –fp op-
tion can be used with other options, but must always be rst. Additional
options will override those read from the project le. For example, –fp
release.fpr –o test.otf
will build an OpenType font with all the options
in the release.fpr project le, but will write the output le as test.otf,
instead of <PostScript-Name>.otf.
–f <file path>
Specify path to input font. If not provided, MakeOTF assumes the le
name is font.pfa.
–o <file path> Specify path to output font. If not provided, MakeOTF assumes the le
name is <PostScript-Name>.otf.
–b
Set style to Bold. Aects style-linking. If not provided, MakeOTF assumes
that the font is not bold.
–i
Set style to Italic. Aects style-linking. If not provided, MakeOTF as-
sumes that the font is not italic.
–ff <file path> Specify path to features le. If not provided, MakeOTF assumes the le
name is features.
-gs Omit any glyphs that are not named in the GOADB le. Works only if
either the -ga or -r options is specied.
–mf <file path> Specify path to FontMenuNameDB le. If not provided, MakeOTF will
look in the current directory for a le named FontMenuNameDB, and then
one directory up, and nally two directories up.
MakeOTFv2.5 User Guide 4
Option Setting Description
–gf <file path> Specify path to GlyphOrderAndAliasDB le. If not provided, MakeOTF
will look in the current directory for a le named GlyphOrderAndAliasDB,
and then one directory up, and nally two directories up. Also, if this
option is specied, and the
–r
or
–ga
options are NOT specied, the eect
is to use the Unicode assignments from the third column of the GOADB
without renaming the glyphs.
–r
Set release mode. is option turns on subroutinization, applies the
GlyphOrderAndAliasDB le, and removes the word Development from
the name table Version (Name ID ) string.
–S Turn on subroutinization.
–ga Apply the GlyphOrderAndAliasDB le. Use when the –r option is NOT
specied.
-rev [<number>]
Attempts to edit the feature le before makeotfexe is run, in order to incre-
ment the head table fontRevision eld. is only works if the head table
override is already dened in the features le. Without the optional ver-
sion number, increments the version number by . With an integer argu-
ment, it increments the minor version by that number. With a fractional
argument, it sets the version to the fractional argument; the number must
then be decimal with three decimal places, e.g. “.”, not ‘.’..
–osbOn <number>
Turn on the specied bit number(s) in the OS/ table fsSelection eld.
In order to turn on more than one bit, must be used more than once.
–osbOn 7 –osbOn 8 will turn on bits and . See section below on New OS/2
Bits.
–osbOff <number>
Turn o the specied bit number(s) in the OS/ table fsSelection eld.
Can be used more than once to turn OFF more than one bit at a time.
–osbOff 7 –osbOff 8 will turn o bits and . See section below on New
OS/2 Bits.
-osv <number> Set version number of the OS/ table. e default value is if none of the
bits specied only in version and later are used; otherwise, the default
version is . See section below on New OS/2 Bits.
-addn
Replace the .notdef glyph in the source data (if any) with a standard .notdef
glyph, that will match the font’s weight and width.
-adds
Create any Apple Mac Symbol glyphs missing from the font. Added glyphs
will match the font’s weight and width. .
-serif Specify that any added glyph will use the serif Multiple Master built-in
glyph data.
-sans
Specify that any added glyphs will use the sans-serif Multiple Master built-
in glyph data.
-cs
Override the heuristics, and specify the script ID for the Mac cmap
subtable.
MakeOTFv2.5 User Guide 5
Option Setting Description
-cl Override the heuristics, and specify the language ID for the Mac cmap
subtable.
-cm <file path>
Specify path to CID CMap encoding le for the font Mac encoding. (CID-
keyed fonts only)
-ch <file path>
Specify path to CID CMap encoding le for the font Unicode UTF-
encoding for horizontal glyphs. (CID-keyed fonts only)
-cv <file path>
Specify path to CID CMap encoding le for the font Unicode UTF-
encoding for vertical glyphs. (CID-keyed fonts only)
-ci <file path> Specify path to Unicode Variation Sequence specication le.
-dbl Map glyph names to two Unicode values rather than one. is was the
default behaviour of makeotf in FDK . and earlier. e Adobe Type
Department now discourages this practice. e option exists only to al-
low building fonts that match original versions. See makeotf –h for the
hard-coded list of glyphs.
-dcs
Set OS/.DefaultChar to the Unicode value for ‘space’, rather than ‘.notdef.
e latter is correct by the OT spec, but QuarkXPress . requires the
former in order to print OTF/CFF fonts.
-fi <file path> Path to the fontinfo le. If no path is given, the default is to look for rst
‘fontinfo’, then ‘cidfontinfo’, in the current directory. Used to set some de-
fault values. is are overridden by any conicting settings in the project
le and then by command-line options. is option is processed before
any others, so if the path is relative, it is relative to the current working
directory. All other relative paths are relative so the source font’s parent
directory..
-sp <file path>
Save the current options to the le path provided, as well as to the
current.fpr le.
-nb
Turn o the Bold style. Can be used to override a project le setting,
otherwise has no eect.
-ni
Turn o the Italic style. Can be used to override a project le setting,
otherwise has no eect.
-nS Turn o subroutinization.
-nga Turn o applying the GlyphOrderAndAliasDB le.
-naddn Turn o adding a standard .notdef. Can be used to override a project le
setting, otherwise has no eect.
-nadds Turn o adding Apple symbol glyphs. Can be used to override a project
le setting, otherwise has no eect.
Options are applied in the order in which they are specied: –r –nS will not subroutinize a font,
but –nS –r will subroutinize a font. Option values are read (in order of increasing priority) from
rst the fontinfo le keyword/value pairs, then the specied project le, if any, and then from the
command line, in order from le to right.
MakeOTFv2.5 User Guide 6
Subroutinization is a process by which common elements in a set of glyphs are decomposed in
separate subroutines. is can reduce the size of the nal font but can require extreme amounts of
memory and time for a large font, such as CID fonts. MakeOTF may need as much as Mbytes of
memory for large Roman fonts, and will do most with only Mbytes, but it may need Mbytes
of memory to subroutinize a -Mbyte CID font. Subroutinizing is reasonably fast when done all in
memory: a few minutes for a Roman font, half an hour to three hours for a CID font. However, if
the system must use virtual memory, the time required can increase by a factor of or more. Sub-
routinizing is likely to be useful for Roman fonts, and for Korean CID fonts. Japanese and Chinese
CID fonts usually only yield a few percent size reduction with subroutinizing, due to fewer repeating
path elements.
FontMenuNameDB - Version 2.
Previous versions of MakeOTF used a dierent version of the FontMenuNameDB le, and wrote the
Macintosh font menu names dierently than the Windows font menu names, and not according to
the OpenType spec. is is because of some history of the early eorts to get OpenType fonts work-
ing on the Mac OS. However, for some years Apple has been following the OpenType spec when
making Apple OpenType fonts, and has fully supported the OpenType font menu names. As a result,
this version of MakeOTF has implemented new syntax for the FontMenuNameDB, and will create
the name table according to the OpenType spec when this new syntax is used.
Fonts made with earlier versions of MakeOTF will not be disadvantaged, as all Adobe fonts to
date and many third-party fonts were made this way, and all programs look rst to the Windows font
menu names when they exist, as this is where the style-linking names can most reliably be found.
e earlier version of the FontMenuNameDB may still be used. e main reason to change is that
the newer version is easier to explain and understand.
e FontMenuNameDB le is used to specify font menu-naming information. It consists of a text le
that may contain information for several dierent fonts. Each font entry starts with the <PostScript
Name>, and is followed by the various menu names. ese names are used to build the name table
strings that describe the font. is allows one to put the menu names for all the fonts in a single le,
making it easier to coordinate menu names across a family.
Font Entry Description
[<PostScript Name>]
f= Preferred Family name
s= Subfamily name (a.k.a. Style name)
l= compatible family menu name
m=1, Macintosh compatible Full name
Each FontMenuNameDB entry is composed of at least:
Preferred Family name, which is specied with the key f=, followed by the family name;
In many programs’ font menus, the fonts will be listed in a cascading menu showing the Family
names in the rst level, followed by a pop-out list of Style names, containing all fonts that share the
same Family name. In other programs, the menus will show a “at” list of all fonts using the Full
name. makeotf will build this by concatenating the Family name, a space character, and the Style name.
MakeOTFv2.5 User Guide 7
However, additional names may need to be supplied. is happens because style-linking (selecting
another font of the same family by applying Bold or Italic options to the current font) only allows
for families to have up to four members. is means that only four fonts can share the same Family
name. If the family has more than four members, or has members which are not style-linked, it is
then necessary to divide the family into sub-families which are style-linked, and to provide each
sub-family with a unique compatible family menu name.
Only fonts that share the same compatible family menu name can be style-linked, and each
-element group can only contain one font of each of the styles Regular, Bold, Italic, and BoldItalic.
e compatible family menu name is specied with the key l=, followed by the name. When-
ever this name needs to be dened, a compatible Full name for the Mac must also be specied. e
Macintosh compatible menu name is specied with the key m=1,, followed by the name. is name
is normally built by concatenating the compatible family menu name, a space character, and the
appropriate choice of one of the four supported styles.
Although these naming conventions are necessary for correct style-linking, they are not sucient.
e font style ags for Bold or Italic must also be set correctly. is can be done either with the make-
otf options –b and –i, or by providing a fontinfo le located in the same directory as the font and
which contains the key/value pairs IsBoldStyle true and IsItalicStyle true, with true or false
being set appropriately.
Compatible family menu names are also used in font menus by applications that are not OpenType
savvy.
If the family only has four faces that are meant to be style-linked, then the compatible and pre-
ferred family menu names are the same, and only the “f=” entry is needed. e names specied with
the key f= will then be written to the name table Name ID . If there is a compatible family name
entry which diers from the entry supplied with the key “f=” , then the “f=” family name is writ-
ten to Name ID . e compatible name from l= is then written to name table Name ID , and the
name table Name ID is chosen by makeotf to be one of Regular, Bold, Italic, or BoldItalic, based
on the font’s style ag. e value set by m=1, is written to the Mac platform name table Name ID .
e key “s=” only needs to be used when you want a style name which is dierent than the choice
from the styles Regular, Bold, Italic, and BoldItalic that would be dictated by the font’s style. When
used, and dierent than the default style name, the style name is written to name table NameID .
Otherwise, it is written to name table NameID .
For complete description of these issues, please read the OpenType specication section on the name
table, available from http://partners.adobe.com/public/developer/opentype/index_name.html.
Examples
Regular font of Adobe® Garamond® Pro
[AGaramondPro-Regular]
f=Adobe Garamond Pro
s=Regular
e l= key is not used, so the compatible family menu name is the same as the Preferred Family
name. e m=1, key is not used, so the Macintosh compatible menu name built by MakeOTF will be
Adobe Garamond Pro Regular . e key “s=” is not actually necessary.
MakeOTFv2.5 User Guide 8
Bold font of Adobe Garamond Pro
[AGaramondPro-Bold]
f=Adobe Garamond Pro
s=Bold
e l= key is not used, so the compatible family menu name is the same as the Preferred Family
name. is font will be style-linked with the Regular, because they share the same compatible family
menu name.
Italic font of Adobe Garamond Pro
[AGaramondPro-Italic]
f=Adobe Garamond Pro
s=Italic
Same as above.
Semibold font of Adobe Garamond Pro
[AGaramondPro-Semibold]
f=Adobe Garamond Pro
s=Semibold
l=Adobe Garamond Pro Sb
m=1,Adobe Garamond Pro Sb
is font needs to be part of a new style-linking subgroup. is means the key l= is used to set a
compatible family menu name dierent from Preferred Family name. In consequence, a Macintosh
compatible Full name is also assigned with the key m=1,. e default style will be Regular. e com-
patible family menu names are abbreviated to Adobe Garamond Pro Sb rather than Adobe Garamond
Pro Semibold, in order to keep the menu names, of the remaining fonts belonging to this style-linked
subgroup, within the -character limit. e key “s=” had to be used, as the preferred style name is
not “Regular”, the style-linking style.
Semibold Italic font of Adobe Garamond Pro
[AGaramondPro-SemiboldItalic]
f=Adobe Garamond Pro
s=Semibold Italic
l=Adobe Garamond Pro Sb
m=1,Adobe Garamond Pro Sb Italic
is font is part of the same style-linking subgroup as the font in the previous example. In order
to be style-linked, they share the same l= key, but the default style will be set to Italic in this case. e
Macintosh compatible Full menu name was be built by appending the default style to the compat-
ible family menu name.
MakeOTFv2.5 User Guide 9
Note on length restrictions
Because of limitations in operating systems and common applications, it is recommended that none
of these keys contain names longer than characters. is results in menu names for legacy envi-
ronments being characters or less.
e OpenType menu name (used in Adobe InDesign® and future Adobe applications) may be
thought of as the combination of the f= and s= keys. Since each of these can be up to characters,
the OpenType menu name can be up to characters.
Note on accented/extended characters
To use accented characters in Latin menu names, one needs two
f=
entries, one for Windows and one
for Mac. e Windows entry species the character by Unicode. e Mac entry species it by the hex
value of the Mac char code from the font’s mac cmap table, when dierent from the ASCII value.
Arnold Böcklin
f=Arnold B\00f6cklin Windows
f=1,Arnold B\9acklin Mac
00f6 is the Unicode for odieresis (ö). Unicode hex values must have digits.
9a is MacRoman encoding for odieresis. Mac char code hex values must have digits for Western
script encodings, and may have or digits for CJK encodings.
In general, the f=, s=, and l= can be extended to set non-Latin strings by adding the triplet (plat-
form code, script code, language code) aer the equal sign (=). e values are the same as described
for the name table name ID strings. For example:
小塚明朝 Pro (Kozuka Mincho® Pro)
[KozMinPro-Bold]
f=3,1,0x411,\5c0f\585a\660e\671d Pro Windows, Unicode, Japanese
f=1,1,11,\8f\ac\92\cb\96\be\92\a9 Pro Mac, Japanese, Japanese
e AFDKO contains the le FDK/Tools/SharedData/FontMenuNameDB, which shows the entries for
several families of the Adobe Type Library.
FontMenuNameDB - Version 1.
Versions of MakeOTF prior to FDK . used a similar synax in the FontMenuNameDB le. When
this older version syntax is used, MakeOTF will build the name table font menu names as it did in
FDK version . and earlier. ese earlier versions built the Windows platform names the same.
however, only the Preferred Family and Style names were written in the Mac platform name strings,
and in respectively name ID and name ID . e key “c=” set the compatbile family name for the
Windows platform. ere was no way to specify a compatible family name for the Mac platform. e
key “c=,” set instead a compatible value for the Mac platform Full Name String, name ID .
.
MakeOTFv2.5 User Guide 10
Font Entry Description
[<PostScript Name>]
f= Family name
s= Subfamily name (a.k.a. Style name)
c= Windows compatible menu name
c=1,
Macintosh compatible menu name
If the key “c=” is used. then MakeOTF will build the older style name table. If the keys “l=” or
“m=” are present, it will build the newer style name table . If none of these are present, then there
is no dierence in how the name table is built.
GlyphOrderAndAliasDB (GOADB)
e GOADB le is used to rename and to establish an order for the glyphs in a font. It is a simple
text le with one line per glyph name. Each line contains at least two elds, and optionally three
elds. e rst eld is the nal glyph name to be used in the output font. e second eld is the
‘friendly’ name used in the source font data. e third eld is a Unicode value, specied in the form
uniXXXX or uXXXX, where XXXX is a Unicode value. e source font is not required to have any
glyphs that are named in the GlyphOrderAndAliasDB le. ere is a sample version of this le at the
folder FDK/Tools/SharedData/.
It should be noted that the ordering, renaming, and Unicode override operations are applied only
if the –r option or the -ga option is specied. ese operations work as follows.
) Establish a specic glyph order in the output OpenType font. Any glyph names in Appendix A
– Standard Strings of Adobe’s Technical Note , e Compact Font Format Specication, will
be ordered rst in the font, in the order given in the CFF specication. All other glyphs will
be ordered as in the GOADB le. Glyphs not named in either the CFF specication nor in the
GOADB le, will be ordered as they were in the original source font. e CFF specication can
be found at http://partners.adobe.com/public/developer/en/font/5176.CFF.pdf
) Rename glyphs in the source font to dierent names in the output OpenType font. Note
that both the source font le and the features denition le must use the same glyph names
– one cannot use a source font le with development names, together with a features le that
contains nal names, unless the options –r or –ga are used.
) Override the default Unicode encoding by MakeOTF. MakeOTF will assign Unicode values
to glyphs in a non-CID font when possible. (For a CID font, the Unicode values are provided
by the Adobe CMap les.) e rules used are as follows:
a) If the third eld of the GOADB record for a glyph contains a Unicode value in the form
uniXXXX or uXXXX (where XXXX stands for a Unicode value), assign that Unicode value
to the glyph. Else b);
b) If a glyph name is in the Adobe Glyph List For New Fonts v1.6 (FDK/Technical Documentation/
GlyphNames/aglfn13.txt), use the assigned Unicode value. Else c);
MakeOTFv2.5 User Guide 11
c) If the glyph name is in the form uniXXXX or uXXXX (where XXXX stands for a Unicode
value), assign the Unicode value. Else d);
d) Do not assign any Unicode value.
Note that MakeOTF cannot re-order glyphs when the source font is a TrueType or OpenType/
TTF font: the glyph order in the source font and the glyph order in the GlyphOrderAndAliasDB le
must be the same. It can, however, still rename glyphs and assign Unicode values.
Note that MakeOTF no longer assigns glyphs Unicode values from the Private Use Area (PUA)
block. If such Unicode values are needed, they must be specied in a GOADB le.
fontinfo
e fontinfo le is a simple text le containing key-value pairs. Each line contains two white-space
separated elds. e rst eld is a keyword, and the second eld is the value. makeotf will look for
a fontinfo le in the same directory as the source font le, and, if found, use it to set some default
values. ese values will be overridden if they are also set by a project le, and then by any makeotf
command-line options. e keywords and values currently supported are:
Keyword Values Eect
IsBoldStyle true/false
Set the font style to Bold. Same as the command-
line option –b
IsItalicStyle true/false Set the font style to Italic. Same as the command-
line option –i
PreferOS/2TypoMetrics true/false
Set the OS/ table fsSelection bit , __
-
. Same as the command-line option –osbOn 7.
IsOS/2WidthWeigthSlopeOnly true/false
Set the OS/ table fsSelection bit , _
__. Same as the command-line
option –osbOn 8.
IsOS/2OBLIQUE true/false
Set the OS/ table fsSelection bit , .
Same as the command-line option –osbOn 9.
Adobe character code map (CMap)
A CMap le maps character codes to glyph selectors. It is only necessary for CID fonts. is le
may be located anywhere within the le system, as long as the directory path is stored in the
FontEnvironment.txt le, or the le is chosen explicitly via the UI. e default CMap les are
automatically selected by MakeOTF when the cidfontinfo le is selected.
e Mac CMap le provides the encoding for a Mac platform cmap subtable in the OpenType
font cmap table. is is required. e script and language of this Mac platform cmap subtable is
determined by heuristics in MakeOTF, but can be specied by MakeOTF options. ese apply only
to CID source fonts.
MakeOTFv2.5 User Guide 12
e Vertical and Horizontal CMap les supply the Unicode encoding for all the glyphs in the font.
Note that for CID fonts, only glyphs named in these three les are encoded in any of the OpenType
font cmap table subtables. e many alternates can oen be accessed only through OpenType layout
features.
When looking for default CID CMap les, MakeOTF uses the following rules:
) e default CMap les will be in a subdirectory of the default path which is specied in the
FontEnvironment.txt le. If this is a relative rather than absolute path, it will be assumed to be
under FDK/Tools/SharedData/.
) e CMap les will be under a directory which is named aer the Registry-Order-Supplement
from the cidfontinfo le, e.g. Adobe-Japan-, Adobe-GB-.
) e les will be named:
for R-O Mac CMap Unicode H CMap Unicode V CMap
Adobe-Japan: pv-RKSJ-H UniJIS-UTF-H UniJIS-UTF-V
Adobe-Japan: pv-RKSJ-H UniJIS-UTF-H UniJIS-UTF-V
Adobe-GB: GBpc-EUC-H UniGB-UTF-H UniGB-UTF-V
Adobe-CNS: Bpc-H UniCNS-UTF-H UniCNS-UTF-V
Adobe-Korea: KSCpc-EUC-H UniKS-UTF-H UniKS-UTF-V
If one wants to use a CMap, which would not be found by these assumptions, one must specify
them explicitly on the command-line while using makeotf.
For further information on CMaps, please read the many Adobe’s Technical Notes available from
http://partners.adobe.com/public/developer/font/index.html#ckf.
Unicode Variation Sequence (UVS) File
A UVS le is a list of records, each of which species the glyph which should be displayed for a
given combination of a Unicode encoding value and a Unicode Variation Selector. You can read
about Unicode Variation Sequence in the publication “Unicode Technical Stadard , Ideographic
Variation Database , at http://unicode.org/reports/tr/. e format depends on the source font
format: CID-keyed fonts require three elds in each record, non-CID fonts require only two.
For CID-keyed fonts:
e makeotf command will look for a UVS le under FDK/Tools/SharedData/Adobe CMAPS/<R-O-
S>, where <R-O-S> stands for the font’s CID Registry-Order-Supplement. e le will be assumed
to be named “<R-O>_sequences.txt . For a CID font with the R-O-S “Adobe-Japan-”. the default
UVS le path woudl be “FDK/Tools/SharedData/Adobe CMAPS/Adobe-Japan1-6/Adobe-Japan1_
sequences.txt“ . e option “-ci <path>” may be used to specify a UVS le path other than the
default
e le format is a n ASCII text le. Each line represents one Unicode Variation Sequence(UVS).
A line may be blank, or contain a comment that starts with the charater “”.
MakeOTFv2.5 User Guide 13
Each line contains three elds. Fields are separated by a semicolon followed by whitespace. e
elds are:
) Variation Sequence. Two hexadecimal value, with no leading “x” or “x, separated by a space.
e rst is the Base Unicode Value, and the second is the Variation Selector value..
) Adobe CID Registry and Order. e CID Registry and Order names, joined by a hyphen.
) CID Value. A decimal value, prexed by “CID+”.
Example UVS le:
Registered Adobe-Japan sequences
Version //
Prepared by Ken Lunde (lunde@adobe.com), Adobe Systems Incorporated
E; Adobe-Japan; CID+
E; Adobe-Japan; CID+
E; Adobe-Japan; CID+
E; Adobe-Japan; CID+
....
For non CID-keyed fonts:
e path to the variation sequence le must be specied with the option ‘-ci <le path>’.
e format for the UV and UVS sequence is the same. However, the Registry-Order eld is omit-
ted, and the glyph is identied by a glyph name from the GOADB le.
Example UVS le for a nonCID-keyed font:
E; checkbox
E; checkedbox
New OS/2 Bits
In , Microso and Adobe began discussions to dene three new bit values in the OS/ table
fsSelection eld: bit __, bit ___, and bit , .
ese bits have meaning only in OS/ table version and later; in earlier versions, they are reserved,
and should be set o. e Adobe Type Department will set the bits in our new fonts.
__. When bit is on, programs are supposed to use the OS/ table sTypoAscent/
Descent/LineGap for vertical line spacing. is bit was dened because the Windows layout
libraries have been using the OS/ table winAscent/Descent values instead. e next release
of Windows Presentation Foundation, on which new versions of Microso programs such as
Word will be based, and which is due in late , will use the sTypo values instead – but only
if this bit is on. is bit certies that the OS/ sTypo values are good, and have the side eect
of being present only in new fonts, so that reow of documents will happen less oen than
if Microso just changed the behaviour for all fonts. For example, it is rumored that some
TrueType fonts have bad values for the sTypo values, making it undesirable to apply the sTypo
values for all existing fonts.
MakeOTFv2.5 User Guide 14
e next two bits have to do with the fact that future generations of Microso programs, and
programs from other vendors that use the Windows Presentation Foundation (WPF) libraries, will
use the Cascading Style Sheet (CSS) v. specication for specifying fonts. e provisions of this
specication can be seen at http://www.w3.org/TR/CSS2/fonts.html.
In brief, a CSS font declaration within a document will describe a font by specifying the family
name, and one or more properties; there is no way to refer directly to a specic font. e possible
styles are Regular, Italic and Oblique. Weight and width are specied with separate keywords, with a
limited and dened set of possible values. An example (in a simplied syntax) is “Family: TimesStd,
Style: Italic, Weight: 700, Width: Normal”. One requirement of a CSS family is that each font has
to have a dierent set of properties. ere cannot be two fonts in a CSS family which both have the
properties “Style: Italic, Weight: 700, Width: Normal”. For OpenType fonts, the name table Preferred
Family Name is used as the CSS family name. Nonetheless, OpenType font families may well contain
more than one font with a particular set of properties, but this fact will create a conict in a CSS-
based environment. When WPF encounters one of such families, it will divide the family into groups,
so that only one font in each group has a given set of properties. However, that will allow WPF to
provide new family names for each group, and these might not correspond to the type designer’s
initial intentions.
Similarly, WPF will infer the font’s properties by analyzing its Preferred Family and Style names,
and may mistakenly conclude that any two fonts in a family cannot be uniquely assigned dierent
sets of font properties. In this case, WPF will also divide the family into groups, and generate new
family names for them. e ___ bit was added to deal with this latter case.
When this bit is set in a font’s OS/ table fsSelection eld, the application is requested to trust that
all fonts sharing the same Preferred Family name, will dier from all the remaining with respect to
their CSS properties. at given, the application can use the OpenType name table font menu names.
___. When bit is on, a program can be condent that all the fonts
which share the same Preferred Font Family Name will all dier only in weight, width, and
slope. e Preferred Font Family Name is dened as name table Windows platform Name
ID Preferred Family Name, or, if name ID is not present, then Windows platform Name
ID Family Name. If the OS/ table version is and this bit is not on, the program will use
heuristics to divide the faces with the same Preferred Family Name into CSS family groups,
and assign family and property names.
Yet another issue, is that WPF uses heuristics applied to the font menu names to determine if
the font has the Oblique style. e Oblique style can be used for either a font that was designed as a
slanted form of a typeface – as opposed to a true italic design –, or for a font which has been created
by a program by algorithmically slanting a base font. ere is no information in current OpenType
fonts to indicate whether a font is Oblique. e only way to know if a current OpenType font is
Oblique is through the use of heuristics based on analyzing the font name. However, no set of heu-
ristics will be perfect. e Oblique bit was proposed in order to solve this problem, thus providing
a way to clearly indicate if the font should be assigned the CSS Oblique style. As an example from
the CSS specication, a Regular font within a family could be classied as Oblique just because the
word “Inclined” is used in its name.
. When bit is on, programs that support the CSS font specication standards will
consider the font to have the Oblique style, otherwise not. If the document species an Oblique
style font, and no Oblique font is present within the CSS font family, then the application may
MakeOTFv2.5 User Guide 15
synthetically create an Oblique style by slanting the base font. is will occur even if there is an
Italic font within the same CSS font family. However, if a document font specication requires
an Italic style, but only an Oblique font is available, then the latter will be used.
An additional proposal suggests that if this bit is not set and the OS/ version is or greater, then
the application would look for Windows platform names ID and . If present, name ID would
supply the CSS compatible family name, and name ID would supply the CSS-compatible property
name. As of the writing of this document, the status of this proposal is still uncertain – please check
the latest OpenType specication. If this proposal is accepted, the additional names can be specied
in the feature le.
Note that if any of these three new bits is turned on, with the option –osbOn <n>, then makeotf will
require that all three values be explicitly set to be on or o. is is because, if any of new the bits is
set on, makeotf will by default set the OS/ version number to . When the version number is , then
both the on and the o setting has a specic meaning for each bit.
Synthetic Glyphs
MakeOTF includes two Multiple Master fonts built-in, one serif and one sans-serif. With these it can
synthesize glyphs that match (more or less) the width and weight of the source font. It requires the
glyphs zero and O to be present in the font, in order to determine the required weight and width. If
the option –adds is used, the list of glyphs to generate will be derived from the concatenation of the
following three groups of glyphs:
) Euro
) Apple Symbol glyphs. ese glyphs were formerly supplied by the Macintosh ATM™ and the
Laserwriter® drivers. is is no longer true for OpenType fonts.
) A miscellany of glyphs missing from some of the Adobe Type Library fonts, which were just a
few glyphs short of containing the full Adobe PostScript Standard glyph set.
Synthetic Glyphs
€ Euro ∆ Delta Ω Omega
≈ approxequal ^ asciicircum ~ asciitilde
@ at \ backslash | bar
¦ brokenbar ¤ currency † dagger
‡ daggerdbl ° degree ÷ divide
= equal ℮ estimated ⁄ fraction
> greater ≥ greaterequal ∞ infinity
∫ integral < less ≤ lessequal
litre ¬ logicalnot ◊ lozenge
− minus × multiply ≠ notequal
numbersign ½ onehalf ¼ onequarter
¶ paragraph ∂ partialdiff ‰ perthousand
π pi + plus ± plusminus
MakeOTFv2.5 User Guide 16
∏ product " quotedbl ' quotesingle
√ radical § section ∑ summation
¾ threequarters 0 zero
e glyphs are synthesized from the MM fonts which MakeOTF has built-in. It will try to match
the glyph width of the zero and the dominant stem width of the target font. However, MakeOTF
cannot stretch the MM font data to match very thick strokes, very wide glyphs, and it cannot match
the design’s stem contrast.