[ 1 /6 ]

F O N T N A M I N G I N T ER FAC E

ree premises : () Most of FontLab Studio’s FontInfo and preferences options pay
tribute to the PostScript Type  font format. () Adobe is phasing out Type  fonts.
() All important operating systems support either  or  OpenType fonts, or both.
is suggests that by the time when the next big updates of Fontographer  and
FontLab Studio will be published, export of PostScript Type  fonts is not required any
more. Which means that many Type  related options can be omitted in future versions
of Fontographer and FontLab Studio.
I don’t claim to cover all possible options but provide a rough sketch only !

is text will discuss a simplified font naming dialog : Provided that a Fontographer .
will export  and  OpenType fonts only, this dialog can remain very simple, with
very few parameters to be adjusted. All additional names are generated automatically.
And even a FontLab Studio  could profit from this – alongside the advanced font
naming dialog it could offer a simplified dialog, with an effect on export options too.
My assumption is that the interface described below would serve most designers’ needs.

           

e relevant name entries are :

–  Family Name [ name   ]
–  Style Name [ name   ]
– weight / width / bold / italic settings [ resulting in usWeight Class, usWidth Class,
fsSelection values ]
– Family Name [ name   ]
– Style Name [ name   ]

e very simple dialog could look like this :

  bold √ 

 condensed √ 

     

My Font  Cn Bold ◊

      

   

My Font  Cn Bold

. Even more, PostScript Type  fonts will not be supported by future Windows Vista’s Avalon. However, older Windows
versions recognize  OpenType fonts als  fonts. And with help of ,  OpenType fonts can be used in Mac  .
. I am aware that still users have reservations as regards OpenType. I am also aware that many type designers prefer to
produce Type  fonts as this is what they are used to. However, these are ideological or educational issues. What I consider
to be a real problem though is that OpenType specifications are still subject to change. Settlement can be expected only
after the publication of Windows Vista, Quark X Press  and other companies’ applications – including the freeware and
public domain segment. But this is another story.

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698
 [ 2 /6 ]

Notes on the arrangement of these fields :

() In the context of -savvy applications it is  Family and Style Name [ name
  and  ] which determine a font’s identity. So they are mentioned first.
() Family and Style Name [ name   and  ] are regarded as legacy or necessary evil.
() is is a bit unhappy visually, but weight, width, bold, italic settings precede the
entries of () to indicate that from these settings, family and style name entries will be
generated. (e arrangement resembles a calculation.) More below. e weight value
is more important than the descriptive names ( considering applications’ misbehavior if
values are too low or too high ), so the value precedes the descriptive name.

To ensure a maximum of compatibility, Style Name [ name   ] allows only the entries
Regular, Italic, Bold, Bold Italic – just like FontLab Studio ’s popup. But unlike the
eqivalent field in  , it does not allow any other entries.
FontLab Studio’s Menu Name and  Name are for generating Type  and Mac
Type  font specific name entries only and thus can be omitted altogether.
 Font Name [ name   ] and Full Name [ name   ] are generated automatically
from the above mentioned name entries :  Font Name is generated by combining 
Family Name [ name   ] and  Style Name [ name   ], omitting blanks and in-
serting a hyphen between family and style name. Full Name is generated by combining
Family Name [ name   ] and  Style Name [ name   ], and inserting a blank
inbetween them. us the entries which are not shown any more in the interface :
  

My Font-CnBold

 

My Font  Cn Bold

Export options ‘ Use Fontname as Full Name on Windows’ and ‘ names as Menu
Names on Mac’ are not shown but active by default. Additional ( to the user invisible )
name entries are generated the same way as in FontLab Studio .

Moreover :
To make things easier, all style entries could be restricted to  characters maximum.
(en it is not necessary to abbreviate individual name entries.)
‘ Reorder glyphs’ may be omitted too ( this is one of the factors ensuring that the Euro
maps correctly in Mac   with  ) as soon as   is considered dead.
ere may be an option ( active by default ) declaring that the  Font Name is used
as .vfb file name and, upon export, as font file name. Otherwise, Full Name is used.
More comments on the automatic generation of Style Names – by considering
entries for weight, width, bold and italic – follow in the next section.

 . It would be worth rethinking some of the FontInfo dialogs. Right now, the visual arrangement of dialogs also suggests
a certain order of filling them out. However, entries in ‘ later’ dialogs has an effect on automatic generation of entries in
‘earlier’ dialogs. E.g. copyright entries have an effect on additional opentype name entries ...
. Above, I followed the alternative way as described by .. in the Font Family Naming tips & tricks. Whether this or
the other way ( i.e.,  Font Name goes into Full Name ) is used, depends. Question is, which of them allows for greater
compatibility. ( Is the Full Name displayed in applications ? )
. A general issue in   is that the generation of the kern table is not possible if ‘ Reorder glyphs’ is on. Something
must be wrong with the order in which these operations are performed upon font export. ( I don’t use the oldfashioned
kern table myself in  s, so this is not really an issue for myself.)

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698
 [ 3 /6 ]

                  

e image below indicates how FontLab Studio  generates style names from weight,
width, bold & italic settings.

us, weight and width values go into the Style Name [ name   ] – for which  
correctly offers only the four Windows compatible standard style names. So it is a bit
surprising that the current auto function creates critical result.
In our dialog however, the full style name generated by the auto button only goes
into the  Style Name [ name   ] which is o.k. It is bold and italic settings alone
which go into Style Name [ name   ] :

  bold √ 

 condensed √ 

     

Cn Bold ◊

      

   

Bold

Rules for family naming are very simple now :

() Fill in weight, width, bold, italic settings.
() Use the  Style Name auto button.
() Fill in  Family Name.
() Copy  Family Name to Family Name, and copy elements that are covered in
 Style Name but not in Style Name (‘ Cn’ in our example ) to the Style Name field.
See page  for the result of this. An even simpler approach is demonstrated in the
section Two methods of naming fonts below.

An aside. It appears that only few current applications make use of weight and width
settings. Correct order would be : First width. en weight. en ( regular and ) italic.
Especially for large families it still remains a convenient solution to split a family up
into different families, one for each width. Width thus becomes part of the () Family
Name. As nice as big families may be, too many styles in the submenu obscure clarity.

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698
 [ 4 /6 ]

Another aside. I would suggest to use ‘ Regular Italic’ instead of ‘ Italic’ in the  Style
Name [ name   ]. is would automatically go into  Font Name [ name   ] and
Full Name [ name   ]. is makes sure that in applications with limited style sorting
capabilities ( e.g. those that sort styles alphabetically ), Regular and Italic styles are
close to each other. Sorting would be more consistent, as you get Light / Light Italic,
Regular / Regular Italic, Bold / Bold Italic, &c.

         

Below I will show that even the simplified interface allows for the two main methods of
assigning font names for non -savvy applications.
() Splitting up a family into smaller families. Practiced by Adobe & recommended
by Adam Twardoch. is has been demonstrated in the previous section already.
() Splitting up a family into individual fonts, by merging both family and style
name into Family Name [ name   ], with Style Name [ name   ] becoming ‘ Regular’
for all styles. Which actually creates many one-font-families.

  bold √ 

 condensed √ 

     

My Font  Cn Bold ◊

√       

   

My Font  Cn Bold Regular

For the second method, there could be a checkbox ‘ Generate name s  and 
automatically’. en these are created automatically by placing both  Family Name
[ name   ] and  Style Name [ name   ] into Family Name [ name   ], separat-
ed by a blank, and setting Style Name [ name   ] to ‘ Regular’. With this method,
both  Font Name [ name   ] and Full Name [ name   ] may omit the notion
of ‘ Regular’. Activating the checkbox ‘ Generate name s  and  automatically’ may
cover this too.
Fields for Family and Style Name may be greyed out to indicate that no editing is re-
quired, or remain intact in case that entries are too long and need manual abbreviation.

So, a simplified font naming dialog could make font naming very easy for the two most
common methods. As more and more applications become -savvy in future, it will
be irrelevant which method is applied – only  related name entries are shown in font
menus anyway. In fact, it is not much more complicated that Fontographer’s earlier
naming interface.
As mentioned in the beginning, also FontLab Studio would profit from it. It is not only
type design beginners who have troubles naming their fonts correctly.

. With possible compatibility issues in mind, ‘-Regular’ could be added to the  Font Name though.
. Personally, I am not satiesfied with method  as it violates the idea of cross-platform compatibility. How shall the user
know that medium is light + bold ?

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698
 [ 5 /6 ]

      :     -      

Aside from ‘ Key dimensions’ there are the ‘TrueType-specific metrics’. I wonder if
these couldn’t be simplified a bit too. is is with the Setting Font Family Metrics docu-
ment and last year’s discussion on the OpenType List in mind.

Key dimensions TrueType-specific settings

= auto = zero by default

So :

[ key dimensions ] Ascender = [ /] TypoAscender

[ key dimensions ] Descender = [ /] TypoDescender

[ /] WinAscent = [ hhea ] Ascender

[ /] WinDescent = [ hhea ] Descender
ese to exceed the most extreme dimensions as can be found in the font.

Furthermore, we just define : [ hhea ] LineGap = zero by default

is makes sure that two conditions are met :

(a) [ /] WinAscent = [ hhea ] Ascender
and [ /] WinDescent = [ hhea ] Descender
( b) [ /] WinAscent + |[ /] WinDescent|
= [ hhea ] Ascender + |[ hhea ] Descender| + [ hhea ] LineGap

In a last step : [ /] TypeLineGap = auto, i.e.

[ /] TypoLineGap = ( [ hhea ] Ascender + |[ hhea ] Descender| ) –

( [ /] TypoAscender + |[ /] TypoDescender| )

us :

[ /] TypoAscender + |[ /] TypoDescender| + [ /] TypoLineGap

= [ hhea ] Ascender + |[ hhea ] Descender| + [ hhea ] LineGap
= [ /] WinAscent + |[ /] WinDescent|

Which means that ‘ Key dimensions’ would need to cover two additional entries only :
Maximum Ascender and Maximum Descender. Plus an auto-button to find maximum
dimensions from all glyphs in the font.
e names of the new fields should indicate that, while [ key dimensions ] Ascender
+ Descender =  ( regardless of individual larger glyphs ), Maximum Ascender and
Maximum Descender values should equal or exceed maximum glyph dimensions.
Moreover, Maximum Ascender and Maximum Descender could be generated
automatically. However, manual input or correction may be required to make sure
that metrics are identical in all fonts which are part of a family. Also see p., bottom !

is method would cover even typefaces with extreme ascenders and descenders.
In this case, default line spacing may increase, but as Mr Hudson indicated in the
OpenType List, this can be compensated for in almost every application.

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698
 [ 6 /6 ]

              .   

() Fontographer . should use the .vfb file format.

() Glyph rendering should be greyscaled as in  .

() e entire interface should get more in line with other FontLab applications, by
renaming menu entries and replacing the functions behind them. Maybe this has
to be done carefully, in two or more updates.

() Generate the kern feature from ( class based ) kerning pairs when a font is exported,
and overwrite an existing one. Could interact with an InDesign kerning plug-in. ;-)

() Generate features from an external feature definition file : commands, and features,
go it into the final font only if relevant glyphs are present. e feature definition file can
be selected both in the application’s export options ( for all fonts ) and in the particular
font’s FontInfo ( as an exception to the global selection ). It would be possible to provide
Fontographer users – students, collegues – with feature definitions.

() Similarly, classes could be taken directly from class definition files upon export
of fonts ( and when displaying kerning in the Metrics / Kerning Panel ). Which file
shall be used is defined in the FontInfo only – thus individually for each font.

e latter three points were nice additions to FontLab Studio too. For a rather batch-
oriented way of working, e.g. with larger families. I don’t see why these advantages
should be reserved for Python-users. Still had no time for getting deeper into this ...

 () Apropos ‘batch-oriented’ and ‘ larger families’. Wouldn’t it be a nice addition if a

‘family head’ could be defined for each font ? is is a particular font from which infor-
mation are copied automatically to other fonts which have a link set to the ‘family head’.
en, for every FontInfo page, there is a checkbox – on by default – ‘Use the family
head’s settings’. ( Similar to ‘Use default as export options’ in the TrueType export
options.) is could be useful for most information like copyright, embedding, designer,
license, version & identification, metrics and dimensions, encoding and unicode, &c.
Here I think of FontLab Studio as well as of Fontographer.

 () I mentioned that it is awquard that it is not really transparent, which information
go into other pages upon using the auto-button there. In combination with (), couldn’t
critical fields ( e.g. copyright entry, if designer entry is altered ) be accompanied by a
button, ‘Update automatically’ ?

. December  // v .

( First version : . November  // v .)

©  Karsten Lücke

All rights reserved.

Font Lab Studio’s interface as shown above is © of FontLab.

All product and company names mentioned in this document may be trademarks or registered trademarks of their
respective companies.

Download  for this document is http://www.kltf.de /downloads / Font NamingInterface-kltf.pdf

ka r s te n lücke
� www.kltf.de · kl@kltf.de · +49-163-4689698