CFF data guidelines

[Manlio Perillo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi.

Some time ago I posted some questions (on opentype-migration-list) about
specific restrictions about CFF data, when embedded in an OpenType font.

The problem is that CFF contains an *entire* font, that is embedded in
another Font (OpenType).


Now I have finally added support to CFF table, in my OpenType parser,
and I would like to share some details with you.

In my implementation I'm enforcing the following constraints:

1) The Name INDEX *must* contain only one entry;
   that is, there *must* be only one font in the FontSet.

   I think that this is an important constratint, and should be added in
   the CFF specification, in the CFF table description.

   The following restrictions, instead, should be added in a separate
   Annex.

2) CharstringType entry in the Top DICT *must* be 2.

3) FontMatrix entry in the Top DICT *must* be [0.001 0 0 0.001 0].

   Note that I'm not sure about this.
   The Type 1 specification highly recommends this value, and I would
   like to know if other values are actually being used.

   I would also like to know if the FontMatrix can define more complex
   transformation, instead of a simple scaling; and if this can cause
   problems for an OpenType font.

4) unitsPerEm parameter in the "head" table *must* be equal to 1000.

   In this case, as long as the FontMatrix is in the form
   [1/x 0 0 1/x 0],
   this parameter can take any value.
   I'm not sure, however, that a font maker would like to use different
   scales for the font metrics; so this value *should* be the same as x.

5) xMin, yMin, xMax and yMax parameters in the "head" table *must* be
   the same as the FontBBox entry in the Top DICT.

6) numGlyphs parameter in the "maxp" table *must* be the same as the
   number of entries in the CharStrings INDEX.

7) The Postscript name in the "name" table *must* be the same as the
   font name found in the Name INDEX.

   I'm not sure how the PostscriptCIDName should be handled, if defined.
   In the CIDFonts from Adobe Acrobat Reader, this name is never
   defined.

8) There should be some simple algorithm for build some of the names in
   the "name" table, starting from FullName and FamilyName entries in
   the Top DICT.

9) The value of the italicAngle parameter in the "post" table *must* be
   the same as the ItalicAngle entry in the Top DICT.

10) The value of underlinePosition parameter in the "post" table,
   computed as described in the Open Font Format specification, *must*
   be the same as the UnderlinePosition entry in the Top DICT.

11) The value of the underlineThickness parameter in the "post" table
    *must* be the same as the UnderlineThickness entry in the Top DICT.

12) The value of the isFixedPitch parameter in the "post" table
    *must* be the same as the isFixedPitch entry in the Top DICT.

13) The value of the usWeightClass parameter in the "OS/2" table
   *should* be compatible with the Weight entry in the Top DICT.

    A precise restriction can not be written, since in Type 1 fonts the
    Weight is a string, and these string names are not standardized.


I tried different fonts to check if these constraints are valid.
Fonts from Adobe Acrobat Reader seems to be ok.

Fonts produced by FontForge fails to meet these constraints.
As an example a Times-Roman ttf font converted to otf have:

Top DICT:
  FontBBox: [-569, -307, 1133, 1007]
  UnderlinePosition: -100
  UnderlineThickness: 50

"head":
  bbox: [-568, -306, 1132, 1006]

"post":
  underline-position: 0
  underline-thickness: 0


An OTF font that come with Opera (if I remenber correctly) Inconsolata:

Top DICT:
  FontBBox: [-1, -177, 510, 835]
  UnderlinePosition: -100
  UnderlineThickness: 50

"head":
  bbox: [0, -176, 509, 834]

"post":
  underline-position: -125
  underline-thickness: 50
  computed-underline-position: -150



There is something that is wrong here.



Thanks   Manlio
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkspDMYACgkQscQJ24LbaUT3DgCfVV0p1FETFop8xF2VfzKyq6d+
MXMAnRakTQ6MXnCK+MQ22zL33dZ1EP2L
=4h9H
-----END PGP SIGNATURE-----