[mpeg-OTspec] AHG conference call - Composite Fonts Requirements

Tue May 12 23:42:15 CEST 2009

Ken,

Thanks for the detailed notes. Lots of good thinking.

I have an alternate perspective on your final comments:

Related to this, I still like the idea of a flag or setting that
effectively increases the strictness. This setting should be off by
default, but when it is turned on, several requirements kick in, such
as format and encoding restrictions, and specifying version numbers of
Component Fonts. I think that this is within the spirit of the third
policy choice as indicated above. It provides to the Composite Font
author flexibility in the degree to which aspects of the format are
mandated. That is also the spirit of XML, which is the format that we
have chosen.

My thoughts are that the creator's intent is already demonstrated by the presence of the information in the composite font recipe, insofar as we do not capriciously mandate that recipes carry information the creator does not care about. How far to enforce that intent is a decision that properly belongs to the consumer. Therefore I would view a "strictness" setting as redundant. If the creator did not intend something, then it should not be in the recipe. Even if the creator did intend something, it has no way (or reason) to enforce it in an inclement environment. A consumer should do its best to preserve the intent as implied by the recipe in all cases. That is the best anyone can hope for. Hopefully any consuming environment that cares about fidelity will always notify the human of problems in reconstructing the intent expressed by the recipe.

Regards,
- daan Strebe

On 09/05/11 11:55, "Ken Lunde" <lunde at adobe.com> wrote:

Vladimir,

Thank you for distributing the meeting notes.

We are one week from the next meeting, and it seems that some of the
discussions that need to take place before then have not yet started.

In an effort to kick this off, I decided to comment on the meeting
notes. I extracted the text, and reformatted it as plain text.

> Composite Fonts
> AHG conference call minutes
> May 4th 2009, 3:00 pm PDT
> List of Participants
> Jeff Carey (Monotype Imaging)
> Peter Constable (Microsoft)
> Greg Hitchcock (Microsoft)
> John Hudson (Tiro Typeworks)
> Mikhail Leonov (Microsoft)
> Vladimir Levantovsky (Monotype Imaging)
> Ken Lunde (Adobe)
> Sergey Malkin (Microsoft)
> Michelle Perham (HILL) (Microsoft)
> Daniel Strebe (Adobe)
> Suzuki Toshiya (Hiroshima University)

I am glad that we seem to have the right mix of people and companies
for this, but there is one rather large hole, specifically the lack of
someone from Apple. I realize that they are busy, but I am sure that
the rest of us can state the same thing. Is anyone from Apple on this
mailing list? In other words, did they choose not to attend last
week's meeting, or were they simply not aware of it. I simply want to
know that they are on board, either in person or in spirit. In other
words, if we settle on a format, but if it doesn't serve Apple's
needs, that's a huge strike against it from Day One.

> Advanced Layout Features
>
> o Should cross-Component Font layout (e.g. GSUB / GPOS, kerning
> between glyphs from different Component Fonts) be considered?
>   - Microsoft is against allowing interaction on GPOS/GSUB level
> between different component fonts (this is glyph specific for each
> component font, interactions between components are very complex)
>   - Each component font should have code ranges and language tags
> identified, and will be used based on this information.
>   - Adobe's position is similar to Microsoft
>   - There may be a need to identify / implement additional language
> or script tags
>   - "Master font" may serve as a default fallback in a Composite
> Font solution
>   - A separate email thread will be setup to continue this
> discussion and define the appropriate solution

Advanced layout feature operate at the glyph (GID) level, so this
limitation is reasonable. Furthermore, GIDs cannot serve as the glue
to hold together a Composite Font. That is where encoding comes in.

> Character Encoding
>
> o Should Component Fonts be required to support the same CMAP table
> format(s)
>   - No, Composite Fonts will need to support component fonts with
> different CMAP subtable formats

The example I provided during the meeting was that BMP-only fonts may
use Format 4, but that fonts with mappings beyond the BMP may use
Format 12. Of course, this is considering only Unicode. Speaking of
Unicode...

> o Should at least one Unicode based CMAP be mandated
>   - No, Unicode mapping should not be a requirement but a font
> engine should be able to map Unicode code points to internal font
> character mapping table

While I agree that this should not be mandated, Unicode should be very
strongly encouraged. While it is true that non-Unicode encodings can
interoperate with Unicode for the most part, it does mean that
heuristics will be involved, and clients will need to ether provide
their own mapping tables, or rely on those provided in a library or
through an OS-level API. The danger, of course, is that the way in
which the glyphs are mapped to Unicode may slightly differ from one
client to another. There may also be a change over time. When this
information is included in the font, it is used as-is.

Looking at the current Composite Font solutions, such as Adobe Type
Composer and the Composite Font feature of some Adobe applications,
encoding is the glue that holds the fonts together. There are, of
course, some limitations, but customers define Composite Fonts because
their advantages outweigh their disadvantages. Adobe Type Composer
used Shift-JIS encoding as its glue, and newer solutions are using
Unicode.

Clearly, when a Composite Font based on this new format is defined,
Unicode ranges will play an absolutely huge role in defining how the
component fonts are to be used.

> Composite Fonts Metrics
>
> o No-clipping zones (should max ascender and descender values from
> different Component Fonts be used to calculate no-clipping zones?)
>   - not discussed at this time
>
> o Line spacing
>   - using ascender and descender to define line metrics may be
> deficient - certain scripts may be affected by much wider spacing
> defined for other languages / scripts.
>   - Using BASE table is recommended but its presence in a component
> font is not required
>   - Will have a separate discussion on the email list

This is complex. While Adobe Systems is including the 'BASE' table in
every OpenType font it builds, we realize that it cannot be required.
In lieu of the 'BASE' table, Apple includes the 'bsln' table in its
AAT fonts.

The issue is how these are defined. Ideally, they would be calculated.
And, this calculation is not so simple. It is likely that only a
fraction of the glyphs in a Component Font are referenced in a
Composite Font, meaning that it would be unwise (and inaccurate) to
use the advertised ascender and descender values as-is.

Clearly, this area needs further and deeper exploration.

> o Whether a single Component Font should be considered as a "default
> font" for the purpose of defining Composite Font metrics
>   - No. The preferred (agreed) way is to have default line metrics
> specified in the Composite Font header.

The Composite Font formats that we (Adobe Systems) have defined in the
past have used the notion of "default font," and leveraged it to
define the Composite Font line metrics. But, I agree that for this
format, due to its wider application, that this should not be done.

> Items for Consideration
>
> o Use of recursion in Composite Fonts
>   - Recursion is not allowed, a Composite Font can not include
> another Composite Font as a component

I'd like to stress the importance of this. Given the current state of
the discussions, the more unknowns that we remove, the better.
Recursion adds complexity with little benefit. While a client that
builds a Composite Font file might allow this, when the Composite Font
file is written, any Component Fonts that are Composite Fonts must be
flattened. This is an implementation issue.

> o Component Font formats
>   - Composite Font solution will not impose any requirements on the
> underlying component font formats
>   - Format ID field is not required
>   - Mapping of the component font to a specific font resource is TBD

There are three issues here. One is how to identify fonts. Another is
where they are located. A third is how to handle font families.

While I cannot speak about TrueType, when an OpenType font is handled,
there are two choices for identifying the font by name:

   name.ID=6
   name.IDs 16 and 17 (1,3,0x409; if defined), otherwise name.IDs 1
and 2 (1,3,0x409)

Of course, the advantage of using name.IDs 16 and 17 (or 1 and 2, if
16 and 17 are not defined), is that the handling of the font family
becomes possible. I also specified the 1,3,0x409 (Microsoft, Unicode,
English) strings, because they represent the lowest common denominator.

For legacy PostScript-based font formats, such as OCF and sfnt-CID,
only the PostScript name can be reliably used.

There was also discussion about more positively identifying the font,
which would be done by specifying a version number. This could be
exact, or as a minimal value.

Locating the fonts should not be part of the format, because it is
implication-specific. Because the Composite Font is merely a recipe,
if an environment is missing any Component Fonts, the likelihood of
missing fonts is rather high. It depends on the nature of the
Composite Font and its use. If it is built and supplied by the OS, the
likelihood will be low. If it is built by an end user, the likelihood
will be high. This is the nature of Composite Fonts.

Handling font families needs to be defined in the format. Why? The
mapping between font families is not one-to-one. CJK fonts, for
example, do not include italic versions of their ideographs. But, if
the Composite Font is expected to handle italic text for the Latin
glyphs, this behavior, and mapping of family members, must be
specified. Also, the full range of font family members cannot expected
to be handled via this format. I envision such limitations.

> Composite Font policy decision
>
> o In order to facilitate the design of the Composite Font solution
> we need to agree on the general policy:
>   - Make it as simple as possible, or
>   - Mandate all sorts of things to make sure everything works, or
>   - Mandate as little as possible but provide as much information as
> possible to insure that everything can work as intended

I am gravitating toward the third one. It seems to have the right
balance. Whether the Composite Font works as intended depends on how
it was defined.

Related to this, I still like the idea of a flag or setting that
effectively increases the strictness. This setting should be off by
default, but when it is turned on, several requirements kick in, such
as format and encoding restrictions, and specifying version numbers of
Component Fonts. I think that this is within the spirit of the third
policy choice as indicated above. It provides to the Composite Font
author flexibility in the degree to which aspects of the format are
mandated. That is also the spirit of XML, which is the format that we
have chosen.

> o A separate follow-up discussion on the AHG email list is needed

Let's try to continue these discussions this week so that we can make
progress during next Monday's meeting. :-)

Regards...

-- Ken

------------------------------------

Yahoo! Groups Links

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