[mpeg-OTspec] Composite Font syntax

[Ken Lunde]

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