[mpeg-OTspec] Composite Font syntax

[Ken Lunde]

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