[mpeg-OTspec] CFF data guidelines

[Thomas Phinney]

I agree with you on points 1, 2 and 11 for sure.

I DISagree on points 3 and 4. Transformation matrix has been used in real
fonts, though arguably not needed.Non-1000-unit em squares, although
unusual, are used in shipping fonts. Sometimes they are a near-necessity.

Most of your other points seem reasonable, but would require some homework
to verify. If I recall correctly in regards to point 10, the two entries
should be EQUIVALENT, but in one case underline position is calculated from
the middle and the other is calculated from... it's either the top or the
bottom.

Cheers,

T

On Wed, Dec 16, 2009 at 8:37 AM, Manlio Perillo <manlio.perillo at gmail.com>wrote:

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


-- 
"It is difficult to get a man to understand something when his salary
depends on his not understanding it." — Upton Sinclair
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091216/19c57ff3/attachment.html>