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

[Ken Lunde]

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