[mpeg-OTspec] Composite Font syntax

[Ken Lunde]

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
> > >
> > >
> > >
> > >
> >
> >
>
>
>