[mpeg-OTspec] New cmap format

[John Hudson]

Thomas wrote:

>  From a font dev POV, how useful is it when you still have to also
> support older cmap formats in the font? It seems like it won't come into
> its own in that respect until you can dispense with including coverage
> for the same characters in legacy cmap formats. Is that fair?

> Of course, depending on the intended usage of the font, even one savvy
> consumer might be enough. If you're making a font to be embedded in a
> device, you just need that device to support the new functionality.

Yes, that was my thought.

In theory, what I would like to do should already be possible via 
character level processing for Unicodes with canonical decompositions -- 
e.g. performing on-the-fly decompositions if a cmap does not contain a 
mapping for U+00C4 but does contain the necessary mappings for U+0041 
and U+0308 --, but I'm not aware of any text engines that do this.

My proposed approach takes this kind of decomposition a step further, by 
enabling mapping to specific glyph forms rather than first mapping to 
default encoded forms that might require contextual substitution. It 
would also enable things like mapping to archigraphemes and dot glyphs 
for Arabic, which in OpenType at least must be done at the GSUB level.

> trivia: I assume "dieresiscob.cap" is a typo for "dieresiscomb.cap"
> ("comb" being short for "combining")

Yes.

J.



-- 

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

The criminologist's definition of 'public order
crimes' comes perilously close to the historian's
description of 'working-class leisure-time activity.'
  - Sidney Harring, _Policing a Class Society_