Composite Font Requirements (was RE: [mpeg-OTspec] AHG on Open Font Format kick off)

[John Hudson]

Responding to those of Jeff's questions on which I have some immediate 
-- and hence entirely rejectable -- thoughts:


> 2.        what are the defining metrics (e.g. max ascender, descender, 
> leading) of the composite font and how closely do the components of a 
> composite need to adhere to these metrics?

I consider avoiding restrictions of shared metrics to be one of the 
primary goals of a composite font format, alongside of overcoming the 
TT/OT maximum glyph ID limit. One of the problems we regularly face when 
clients want us to produce individual multi-script fonts is the natural 
deviation in the user of vertical space between different writing 
systems. This is particularly problematic if, for backwards 
compatibility, we are unable to edit the metrics of existing fonts that 
will be extended to support more scripts (or even some single-script 
extensions involving stacked marks such as Vietnamese).

So my inclination would be to say that the metrics of a composite font, 
insofar as they affect no-clipping zones and linespacing, should be the 
highest ascender value and the deepest descender value among all of the 
component font metrics. Certainly this should be the case with regard to 
no-clipping zones. Ideally, linespacing should be calculated 
independently of no-clipping zones, although historically this has not 
been the case.

In the most recent versions of the OT spec, fsSelection bit 7 is used to 
signal that an app should use the OS/2 Typo metrics for linespacing 
rather than the Win metrics. I'd like to suggest that in the composite 
font format this should be the default behaviour, regardless of the 
fsSelection bit 7 settings of the component fonts.

> 3.        which component of the composite font would be responsible for 
> providing the “no-glyph glyph” when a particular character is not found 
> anywhere?

Presuming all the component fonts contain a .notdef glyph, I don't think 
it much matters which one is displayed. Presuming the component fonts 
are enumerated in some way, I'd say the first one.

> 4.        what are the limitations and/or flexibility with regard to 
> character encodings, for example, one component supporting Unicode CMAP 
> table “3,10” and another only “3,1”?

In order to display text in the specified script or language, a 
component font will need to support at least one cmap table useable by 
the target OS or app. Other than that, I don't see a need for a 
limitation in terms of e.g. every component supporting exactly the same 
cmap formats. We already have closely related fonts with varied cmap 
format support, e.g. the Cambria Math font cmap table now includes 
format 14 support for variation selectors, while the Cambria Regular, 
which ships as a TTC with the Math font, does not.

> 6.        when the client includes OpenType Layout (advanced typographic 
> extension) processing, how will the composite present related tables 
> (GSUB, GPOS, GDEF, etc.) to the layout engine?

I would assume via the script and language linking that accesses the 
individual component fonts in the first place. In other words, the 
selection of an individual component font would already be made before 
OTL is applied. At that point, the layout engine will be dealing with an 
individual component font, which should be pretty much indistinguishable 
from dealing with an independent, non-composite font.

Still, this question raises the interesting notion of cross-font layout, 
e.g. kerning between glyphs from different composite fonts....


John Hudson

-- 

Tiro Typeworks        www.tiro.com
Gulf Islands, BC      tiro at tiro.com

The Lord entered her to become a servant.
The Word entered her to keep silence in her womb.
The thunder entered her to be quiet.
             -- St Ephrem the Syrian