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

Mon Dec 14 15:38:21 CET 2009

Hello Ken, all,

I agree that Composite Fonts activity would benefit from the new name to prevent the conflict between Composite Font and Compact Font Format (CFF). However, there is an organization called the Khronos Group that develops specifications for graphics acceleration and system integration APIs, and their trademarked names always start with Open... - they are most famous for the names like OpenGL and OpenGL ES, but there are many other specs that already have been released under the names like OpenVG, OpenMAX, OpenML, OpenKODE, OpenWF and OpenCL (to name a few). I am afraid the name like OpenCF may be mistakenly attributed to their line of standards, and may even be viewed as a trademark violation  - I am not a lawyer, so the above statement should be considered a concern, not a legal opinion.

I believe that the future Composite Font specification will likely become a new clause of the ISO OFF spec, and I like one of the names "Composite Font Standard"  John Hudson has proposed. IMHO, CFS would fit well with the existing abbreviations OFF and CFF.

Thank you,
Vladimir

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde
Sent: Sunday, December 13, 2009 8:47 AM
To: leonardo at chiariglione.org
Cc: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Re: A path through the thicket

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<mailto:lunde%40adobe.com>]
> Sent: 12 December 2009 14:39
> To: leonardo at chiariglione.org<mailto:leonardo%40chiariglione.org>; mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec%40yahoogroups.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
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20091214/1d87e9a9/attachment.html>