[mpeg-OTspec] Composite Font syntax

Karsten Luecke karstenluecke at yahoo.de
Thu Jun 25 19:07:04 CEST 2009


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



More information about the mpeg-otspec mailing list