[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