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

[Ken Lunde]

John,

What you have described, along with your useful examples, demonstrated  
that font names and Unicode ranges alone are not sufficient to define  
the Composite Font, and that language tagging is a necessary  
component. In other words, glyphs that are expected to interact via  
GSUB or GPOS features should be in the same component font, and  
because the same punctuation ("same" in the sense that they share the  
same Unicode code points) is shared by multiple languages, this issue  
arises.

Of course, there will be times when the Composite Font explicitly  
specifies punctuation from a separate font, in which case the glyphs  
cannot interact, at least via GSUB or GPOS features. In this case, the  
desire or intent to use different punctuation precludes the ability  
for the glyphs to interact, and this should be okay. Our Composite  
Font mechanisms do this, and it has been acceptable.

Regards...

-- Ken

On 2009/05/11, at 23:00, John Hudson wrote:

>>> Advanced Layout Features
>
>>>  - Each component font should have code ranges and language tags
>>> identified, and will be used based on this information.
>
> Before committing to agreement with MS and Adobe on layout
> non-interaction between component fonts, I just want to confirm that  
> my
> understanding of intended code range and language tag behaviour is
> correct. The attached image shows text strings containing two  
> different
>  scripts, typeset using two different fonts which, for purposes of  
> this
> illustration represent two component fonts in a composite font. In  
> this
> illustration, for clarity, I have set the two fonts in distinct  
> colours,
> but one may presume them to represent text in a single colour.  
> Language
> tagging is indicated.
>
> There are two layout issues at work here. One is selection of an
> appropriate font for common punctuation characters adjacent to
> alphabetic characters, and hence correct kerning relationship between
> those glyphs. The other is the more complex selection of appropriate
> closing parenthesis to match opening parenthesis (as the illustration
> shows, there will definitely be cases in which this results in
> collisions between adjacent glyphs from different component fonts).
>
> Given the language tagging illustrated in the graphic, is my
> understanding of the expected component font selection and layout  
> correct?
>
> I'm leaving aside, for now, posssible fallback behaviours, based on
> algorithms, if accurate language tagging is not applied.
>
> Regards, John
>
>
> -- 
>
> Tiro Typeworks        www.tiro.com
> Gulf Islands, BC      tiro at tiro.com
>
> I'm like that Umberto Eco guy, but without
> the writing.   -- anonymous caller
> <CompFontLayout.gif>