[mpeg-OTspec] Re: A path through the thicket

[Ken Lunde]

Many thanks, Leonardo. This is incredibly helpful. I will work on a revised document on Monday, which will reflect your suggestions.

With regard to the full name and abbreviation, as Manlio pointed out, CFF is not a good choice because it conflicts with another font-related format, specifically Compact Font Format, and is also the tag for the corresponding OpenType table. I completely agree.

Given the cross-platform and rich nature of this Composite Font format, along with the fact that it is XML-based, I have one abbreviation/name suggestion:

  OpenCF (Open Composite Font)

I chose OpenCF over OCF as the abbreviation for "Open Composite Font" because OCF is already an abbreviation for a legacy PostScript font format called "Original Composite Font." I also like the emphasis of the word Open, which works well with OFF.

Regards...

-- Ken

On 2009/12/12, at 9:17, Leonardo Chiariglione wrote:

> Ken,
> Thank you. This time I could see your attachment.
> I have comments to your document.
> At the beginning you say
> 
>> The purpose of this Composite Font specification is to replace existing
> Composite Font and Fallback Font formats, as used by today's OSes and
> applications, with one that is cross-platform and standards-based, thus
> bringing uniformity to the specification and use of Composite Fonts.
> 
> In the MPEG world this does not convey a lot of meaning as the Composite
> Font Format (what about CFF?) will (we hope it will) become an ISO standard.
> 
>> Another purpose is to allow a Composite Font to reference more than 64K
> glyphs by virtue of being able to reference two or more component fonts that
> each can include up to 64K glyphs.
> 
> This is very good because it describes features of CFF that are not
> currently provided by existing formats.
> 
> Therefore what about the following
> 
> The Composite Font Format (CFF) is an ISO standard with the following
> features:
> 1. is cross-platform
> 2. allows a Composite Font to reference more than 64K glyphs by virtue of
> being able to reference two or more component fonts that each can include up
> to 64K glyphs (a bit long, but I am unable to make it shorter without
> damaging the message)
> 3. is expressed in XML, and any non-ASCII characters that are specified
> (e.g. for localized menu names), are to be represented via UTF-8 or as
> Numeric Character References (shorter would be better but this is as much as
> I can do).
> 
> If there are more features that you think are important for our "customers"
> please add.
> 
>> The Composite Font recipe is the means by which the creator specifies the
> intent to the consumer
> 
> Whose intent is it? From the text following it seems the creator. If that is
> the case let's spend another word. But then, the intent of what?
> 
>> it is the responsibility of the consumer to support as much of the
> creator's intent as possible for the benefit of the user
> 
> There is clearly a gap in our historical background. But don't worry the
> reason (one of the reasons...) I am interested in you work is because I want
> to understand what it is. MPEG may have something to learn, after all ;-)
> 
> The perception of a gap stems from the fact that in a typical MPEG standard
> a conforming "decoder" of a certain profile and level has all the tools (the
> intelligence) to carry out the work to the encoder expected it to do.
> What I think I understand from your words (please correct me if I am wrong)
> is that a CFF receiver, because of the nature of font information, can still
> do a decent or passable job, even if it does not have the intelligence to do
> what the encoder expects.
> In some MPEG standard we have something resembling this. An MPEG-1 Audio
> layer II decoder can decode an MPEG-2 Audio layer II bitstream, but don't
> expect the output to be 5.1. because it will only be stereo. 
> If I am still in sync with you, what about replacing your text above (and
> following) with
> 
>> the decoder will support as much of the creator's intent as instructed by
> the user, bearing in mind that missing component fonts and technical
> limitations may impair a consumer's ability to completely support the intent
> of the creator.
> 
> In the MPEG world this is kind of obvious, but let's keep it, at least for
> moment.
> 
>> It is the intent of this specification that a Composite Font recipe
> specifies only the information that the creator wishes to convey, and
> nothing more. For any attribute that is not specified by the Composite Font
> recipe, the consumer must therefore defer to the appropriate component
> fonts.
> 
> At this moment the implications of this sentence are not clear to me.
> May I propose that you to edit your text according to my suggestions, of
> course to the extent that they do not alter your intention :-( and send it
> back for another round?
> Leonardo 
> 
> 
> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com] 
> Sent: 12 December 2009 14:39
> To: leonardo at chiariglione.org; mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Re: A path through the thicket
> 
> Leonardo and others,
> 
> Attachments seem to be easy to overlook due to where and how they are
> attached when sending to this distribution list. I am attaching the PDF file
> again, but I have also hosted it at the following URL, giving everyone two
> chances to grab the document:
> 
>  http://lundestudio.com/PDF/CompositeFont-11252009.pdf
> 
> Regards...
> 
> -- Ken
> 
> 
> No virus found in this incoming message.
> Checked by AVG - www.avg.com 
> Version: 8.5.427 / Virus Database: 270.14.102/2556 - Release Date: 12/11/09
> 19:37:00
>