[mpeg-OTspec] FW: [Proposal] Improve the definition of the 'CFF ' table

Levantovsky, Vladimir vladimir.levantovsky at monotypeimaging.com
Mon Dec 7 16:54:00 CET 2009


Dear Ken, John, all,

Thank you very much for looking into the CFF proposal and providing with the suggested wording to clarify this in the OFF spec.

I’d like to bring your attention to another email sent a while ago to the public OpenType list, copied below (with some cosmetic editorial cuts):


On Tuesday, November 03, 2009 7:41 AM Manlio Perillo wrote:

> Subject: [OpenType] some questions about CFF data in OpenType fonts

> Message from OpenType list:

>

> Hi.

>

> My name is Manlio Perillo, and I'm a freelance Italian developer.

>

> I'm working on a PDF generation tool [1], in Python, and recently I

> have implemented support for OpenType and Compact Font Format fonts

> and Type 2 Charstring format.

>

> For OpenType, I'm using the ISO Open Font Format specification.

>

> I have found some problems with the OFF specification, for fonts with

> CFF data.

>

> The specification only states:

> This table contains a compact representation of a PostScript Type 1, or

> CIDFont and is structured according

> to Adobe Technical Note #5176: "The Compact Font Format Specification"

> [5] and Adobe Technical Note #5177: "Type 2 Charstring Format" [4].

>

> I thik that this statement is not sufficient to describe CFF data

> embedded in a OFF font, since additional constraints SHOULD be placed

> on the CFF data.

>

> 1) CFF data can contain multiple fonts in the FontSet.

>    It is rather obvious, to me, that CFF data embedded in OFF font

>    **can not** contain multiple fonts.

>

>    The PDF specification, just to make an example, explicitly forbids

>    embedding of CFF fonts containing multiple fonts.

>

> 2) The CFF font top DICT contains the CharstringType entry, and this

>    entry can have values 1 and 2.

>

>    Since the OFF spec references the "Type 2 Charstring Format", is

>    seems to be obvious that only type 2 is supported;

>    however I think that the OFF spec should explicitly state this.

>

> 3) Since the OFF "head" table contains the `unitsPerEm` parameter, it

> is

>    rather obvious that the FontMatrix array entry in the CFF top DICT

>    **can only** have values:

>    [1/unitsPerEm 0 0 1/unitsPerEm 0 0].

>

>    Again, I think that this should be explicitly stated by the OFF

>    specification.

>

> 4) Since an OFF has the cmap table, the encoding and charset data in

>    the CFF font should no more be used and they may only take

>    additional space.

>    This is the same for CIDFonts, but I'm not sure.

>

>    The CFF specification allows compact representation of these table,

>    for know encoding and charsets, but I think that the OFF

>    specification should contain a recommendations section dedicated to

>    CFF data embedded in an OFF font.

>

> Thanks   Manlio Perillo

Eric Muller from Adobe replied to this email with the following:


On Tuesday, November 03, 2009 1:30 PM Eric Muller wrote:

> Subject: Re: [OpenType] some questions about CFF data in OpenType fonts

> Message from OpenType list:

>

> I fully agree with your points 1, 2, 4, but I am not so sure about 3:

> > 3) Since the OFF "head" table contains the `unitsPerEm` parameter, it is

> >    rather obvious that the FontMatrix array entry in the CFF top DICT

> >    **can only** have values:

> >    [1/unitsPerEm 0 0 1/unitsPerEm 0 0].

> >

>

> One could consider that there are two metric spaces used by the font,

> one for in htmx, OS/2, GPOS, etc. and the other for CFF. They don't

> need to be in the same units.

>

>

> Similar to your 4), there is the equivalent for metrics: the values in

> hmtx, OS/2, etc are "the truth" and the metrics in the CFF dictionaries

> are to be ignored outside the context of rasterization.

>

>

> One additional constraint (may be the most important?): the GIDs are

> interpreted as charstring ids (in CFF)

>

> Eric.

The wording of the comment that John and Ken proposed  and agreed upon only addresses the point 1 of the original email. I would like to ask everybody to review the text of the OFF specification and the rest of the proposal from Manilo and Eric, in order to determine if any additional clarification or comments would be useful in OFF specification.

Thank you and best regards,
Vladimir


From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde
Sent: Thursday, December 03, 2009 2:51 PM
To: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] FW: [Proposal] Improve the definition of the 'CFF ' table



Vladimir,

I second John's suggested wording, which is clear and concise.

-- Ken

On 2009/12/02, at 16:41, John Hudson wrote:

> Ken wrote:
>
>> In any case, I agree that clarifying this limitation in the
>> specification is a good thing.
>
> Suggested wording:
>
> Although Adobe's Compact Font Format Specification enables multiple
> "FontSets" to be included in a CFF file, the implementation of CFF
> within OpenType is limited to a single FontSet. Hence, a CFF table
> must
> consist of exactly one name-keyed or CID-keyed font.
>
> JH
>
> --
>
> Tiro Typeworks www.tiro.com
> Gulf Islands, BC tiro at tiro.com<mailto:tiro%40tiro.com><mailto:tiro%40tiro.com>
>
> Car le chant bien plus que l'association d'un texte
> et d'une mélodie, est d'abord un acte dans lequel
> le son devient l'expression d'une mémoire, mémoire
> d'un corps immergé dans le mouvement d'un geste
> ancestral. - Marcel Pérès

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091207/8b5b4b72/attachment.html>


More information about the mpeg-otspec mailing list