[mpeg-OTspec] Re: A path through the thicket
Leonardo Chiariglione
leonardo at chiariglione.org
Sat Dec 12 18:17:31 CET 2009
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
More information about the mpeg-otspec
mailing list