[mpeg-OTspec] Composite Font syntax

Tue Jul 21 21:03:18 CEST 2009

Mikhail,

Thank you for taking the initiative to draft the proposed features and
split them into mandatory and optional lists. This would be very useful
first step in creating a future Composite Font spec and your efforts are
very much appreciated.

At the last MPEG meeting the AHG mandate has been extended. The goals of
the group have not changed - we are expected to produce a working draft
specification of the Composite Font solution. This working draft would
evolve as we go along in the development process and would become the
foundation for a future amendment to ISO/IEC 14496-22.

I would like to encourage you and all AHG members to consider the
opportunity to introduce the working draft specification at the next
MPEG meeting (Oct. 26-30). The deadline for submitting the spec would be
October 20, 2009.

Thank you and best regards,

Vladimir

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com]
On Behalf Of Mikhail Leonov
Sent: Tuesday, July 14, 2009 3:24 PM
To: mpeg-OTspec at yahoogroups.com
Subject: RE: [mpeg-OTspec] Composite Font syntax

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 <mailto:lunde%40adobe.com> ]
Sent: Wednesday, July 08, 2009 9:30 AM
To: Mikhail Leonov
Cc: mpeg-OTspec at yahoogroups.com <mailto:mpeg-OTspec%40yahoogroups.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
> > >
> > >
> > >
> > >
> >
> >
>
>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090721/b5db901a/attachment.html>