[mpeg-OTspec] Composite Font syntax

[Mikhail Leonov]

Hi Ken,
I think we are in agreement on the basic structure of file format and design principles.

At this point, I believe it would be useful to split proposed features of the format in two broad classes:
1. Mandatory, such as interpreting entries in the correct order, parsing code point ranges and specifying language tags.
2. Optional, such as digital signature verification, selection based on the optical size, suppression of font style attributes, etc.

The idea is to establish enough common ground for the format to be meaningfully used by the producers, and at the same time provide enough flexibility to serve existing end to end scenarios.

I can drive creating a list of the optional features for the first revision of the format if that is OK with everyone.

Best regards,
Mikhail Leonov
Microsoft

-----Original Message-----
From: Ken Lunde [mailto:lunde at adobe.com]
Sent: Wednesday, July 08, 2009 9:30 AM
To: Mikhail Leonov
Cc: mpeg-OTspec at yahoogroups.com
Subject: Re: [mpeg-OTspec] Composite Font syntax

Mikhail (and others),

There has been no further discussion on this important issue, and I have also not seen any comments about daan Strebe's "Policy proposal"
that was sent to the AHG mailing list on June 1st. I am assuming that no one has any objections to his policy proposal, which was well- written, and covers all of the bases extraordinarily well.

Although I will be on vacation for the next days, mainly in South Dakota for the 2009 Prairie Dog Safari, and to compete with in Cooper Arms' 2009 One-Shot Competition in Montana, I will have email access.

In any case, I'd like to see some more discussion about what led up to the topics below.

Thanks...

-- Ken

On 2009/06/25, at 10:39, Ken Lunde wrote:

>
>
> Karsten,
>
> With regard to there being no fixed hierarchy for the three possible
> elements, that is very intentional. The moment we impose a fixed
> hierarchy, we will immediately discover that a Creator will be unable
> to express their Composite Font. Some Composite Font instances will be
> driven by Encoding, others by Language, and perhaps even some by
> Component Fonts. Where each of these elements are in the hierarchy
> depends on the Creator.
>
> And, other than at least one instance of a Component Font, the other
> two elements are optional. If they are needed, they are specified. If
> not, they are left undefined, and the Consumer is then free to set
> these as best they can, using attributes from the specified Component
> Fonts.
>
> Regards...
>
> -- Ken
>
> On 2009/06/25, at 10:07, Karsten Luecke wrote:
>
> >
> >
> > Hello Mr Lunde,
> >
> > thanks, also for the enhanced example, the second-last for (1). So
> > there is no fixed hierarchy for the Encoding/ComponentFont/Language
> > elements.
> >
> > Indeed my second example was not particularly effective. :D
> >
> > Best wishes,
> > Karsten
> >
> > Ken Lunde wrote:
> > > Karsten,
> > >
> > > Many thanks for the prompt feedback.
> > >> Looks elegant. To be sure I understand:
> > >>
> > >> (1)
> > >> How would the re-encoding mechanism fold in? Starting from your
> > >> example:
> > >>
> > >> <!-- Latin -->
> > >> <Encoding Target="0000-007F">
> > >> <ComponentFont BaselineShift="12" ScaleFactor="95"
> > >> Target="LatinFont-1"/>
> > >> </Encoding>
> > >>
> > >> Since ComponentFont is inside Encoding, does one need to define
> > >> ComponentFont again per each such re-encoding entry? E.g., with
> > >> nonsense values:
> > >>
> > >> <!-- Latin -->
> > >> <Encoding Target="0000-007D">
> > >> <ComponentFont BaselineShift="12" ScaleFactor="95"
> > >> Target="LatinFont-1"/>
> > >> </Encoding>
> > >> <Encoding Target="007E" Original="FE59"> <ComponentFont
> > >> BaselineShift="12" ScaleFactor="95"
> > >> Target="LatinFont-1"/>
> > >> </Encoding>
> > >> <Encoding Target="007F" Original="FE61"> <ComponentFont
> > >> BaselineShift="12" ScaleFactor="95"
> > >> Target="LatinFont-1"/>
> > >> </Encoding>
> > >>
> > > Yes, that would work, but given that the <ComponentFont> element
> is
> > > the same within each <Encoding> element, that could potentially be
> > > placed higher in the hierarchy.
> > >
> > > The re-written example below does this, and also demonstrates how
> > the
> > > original PUA mappings can be retained, effectively allowing both
> > > character codes to be used in the Composite Font definition (note
> > that
> > > I corrected the PUA mappings, to make them genuinely PUA code
> > points):
> > >
> > > <!-- Latin -->
> > > <ComponentFont BaselineShift="12" ScaleFactor="95"
> > Target="LatinFont-1">
> > > <Encoding Target="0000-007D"/>
> > > <Encoding Target="007E" Original="E81E"/> <Encoding Target="007F"
> > > Original="E826"/> <Encoding Target="E81E"/> <Encoding
> > > Target="E826"/> </ComponentFont>
> > >
> > > This means that U+007E and U+E81E (PUA) will map to the same
> glyph.
> > > Likewise, U+007F and U+E826 (also PUA) will map to the same
> glyphs.
> > >
> > > Also, I should point out that my example did not use PUA code
> > points,
> > > and instead used GB 18030 code points. Here it is in its corrected
> > form:
> > >
> > > <Encoding Target="9FB4" Original="E81E"/> <Encoding Target="9FB5"
> > > Original="E826"/> <Encoding Target="9FB6-9FB7" Original="E82B"/>
> > > <Encoding Target="9FB8" Original="E832"/> <Encoding Target="9FB9"
> > > Original="E843"/> <Encoding Target="9FBA" Original="E854"/>
> > > <Encoding Target="9FBB" Original="E864"/> <Encoding Target="20087"
> > > Original="E816"/> <Encoding Target="20089" Original="E817"/>
> > > <Encoding Target="200CC" Original="E818"/> <Encoding
> > > Target="215D7" Original="E831"/> <Encoding Target="2298F"
> > > Original="E83B"/> <Encoding Target="241FE" Original="E855"/>
> > >
> > > Sorry about that. Maybe it was the brandy. ;-)
> > >> (2)
> > >> Following the description of the fallback mechanism, could one do
> > >> this?
> > >>
> > >> <!-- ENGLISH -->
> > >> <Language Target="eng">
> > >> <Encoding Target="0028-0029, 002C, 002E, 0041-005A, 0061-007A,
> > >> 2018-2019, 201C-201D"><!-- POSSIBLY OBSOLETE IN EXAMPLE -->
> > >> <ComponentFont Target="LatinFont-1"/> <ComponentFont
> > >> Target="LatinFont-2"/> </Encoding> </Language>
> > >>
> > >> <!-- OTHER LATIN-SCRIPT LANGUAGES, without Language --> <Encoding
> > >> Target="0000-[...]"> <ComponentFont Target="LatinFont-1"/>
> > >> <ComponentFont Target="LatinFont-2"/> </Encoding>
> > >>
> > > Yes. The earlier declaration is given priority. However, I would
> > think
> > > that you'd want to specify different Component Fonts for the
> second
> > > portion. In your example, without explicitly declaring Language in
> > the
> > > second portion, you could eliminate the first portion, and get the
> > > same results.
> > >> (3)
> > >> Even if given as percent, perhaps ScaleFactor better be a float
> > rather
> > >> than integer, for higher precision?
> > >>
> > > I agree. If the Consumer cannot handle a floating point value, it
> > can
> > > then handle it as its wants, meaning to either truncate or round
> the
> > > value to an integer value. The important thing is that the format
> > > allows the Creator to specify the value as intended.
> > >
> > > Regards...
> > >
> > > -- Ken
> > >
> > >
> > >
> > > ------------------------------------
> > >
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> >
> >
>
>
>