[mpeg-OTspec] CFF data guidelines

Tue Jan 12 02:00:46 CET 2010

Hello Manlio,

Thanks for your efforts to clarify this area of the spec. We've discussed this a bit internally at Adobe:

1, 2, 6: These sound like excellent clarifications. We would also extend 6 to specify that an OpenType glyph index is the same as the CFF glyph index for all glyphs in the font.

3, 4: head.unitsPerEm needn't be 1000, and we think more discussion is needed before we disallow non-uniform scaling in the CFF's FontMatrix.

5, 7-13: There are several more equivalences, or rough equivalences, between CFF data and data in the rest of the sfnt. Instead of enumerating and correlating all these equivalences, it may be more useful simply to state something like "The CFF table must be used only for glyph outlines, glyph images, and glyph names." More discussion needs to happen on this; for example, what to say about hinted glyph widths.

For this round of the OFF spec (i.e. for consideration at the 91st MPEG meeting), we'd like to move forward with 1, 2, and 6 (and our extension to 6), and table the rest of the clarifications until the next round.

Here is our OFF proposal (I'll massage this into the required template in consultation with Vlad):

<<<<
{Append the following paragraphs to the end of OFF section 4.4.1 "CFF - PostScript font program (Compact Font Format) Table":}

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

The CFF Top DICT must specify a CharstringType value of 2.

The numGlyphs field in the 'maxp' table must be the same as the number of entries in the CFF's CharStrings INDEX. An OpenType glyph index is the same as the CFF glyph index for all glyphs in the font.
>>>>

Best,
Sairus

-----Original Message-----
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Manlio Perillo
Sent: Wednesday, December 16, 2009 8:37 AM
To: mpeg-OTspec at yahoogroups.com
Cc: opentype-migration-list at indx.co.uk
Subject: [mpeg-OTspec] CFF data guidelines

-----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-----

------------------------------------

Yahoo! Groups Links