[mpeg-OTspec] Composite Font syntax

[Ken Lunde]

Mikhail,

Sorry for the delay in replying. I was on a hunting trip from 07/09  
through 07/21, and returned to work on 07/22.

I am glad to hear that you're willing to drive this.

Regards...

-- Ken

On 2009/07/14, at 12:23, Mikhail Leonov wrote:

>
>
> Hi Ken,
> I think we are in agreement on the basic structure of file format  
> and design principles.
>
> At this point, I believe it would be useful to split proposed  
> features of the format in two broad classes:
> 1. Mandatory, such as interpreting entries in the correct order,  
> parsing code point ranges and specifying language tags.
> 2. Optional, such as digital signature verification, selection based  
> on the optical size, suppression of font style attributes, etc.
>
> The idea is to establish enough common ground for the format to be  
> meaningfully used by the producers, and at the same time provide  
> enough flexibility to serve existing end to end scenarios.
>
> I can drive creating a list of the optional features for the first  
> revision of the format if that is OK with everyone.
>
> Best regards,
> Mikhail Leonov
> Microsoft
>
> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com]
> Sent: Wednesday, July 08, 2009 9:30 AM
> To: Mikhail Leonov
> Cc: mpeg-OTspec at yahoogroups.com
> Subject: Re: [mpeg-OTspec] Composite Font syntax
>
> 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
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
> >
>
>
>