[mpeg-OTspec] Toward a Composite Font format specification

[Ken Lunde]

Jeff,

When discussing these and related things, I suggest that it be done in  
the context of the functional tags for which they serve as attributes.

The following three are attributes for the <ComponentFont> tag:

> A few thoughts ...
>
> Target Font - how will this be specified?  Does it need to be on the  
> same system -or- can it be on a server / internet  e.g. http://ibm.com/fonts/CourierIBM.ttf 
>  ? What is the 'unique name' ... Full Font Name - file name - WWS -  
> combination of these?   I would like to see a way to specify a font  
> that isn't on the current system.  Possibly, define a web solution  
> then get W3C to use this iso standard - just so the W3C doesn't come  
> up with another mechanism to implement.

The current plan is for this to be somewhat opaque. And yes, besides  
figuring out what name to use (I suggested specific strings from the  
'name' table), there is also the issue of location. We have identified  
three "locations" for fonts: device, embedded, and web.

> Scaling - we have implemented vertical size and a horizontal scale  
> factor (percentage of the vertical) - but we're ok with going with  
> any scheme.
>
> Baseline Shift - we have implemented this function on some of our  
> system and we're ok with going with any scheme.

That's good news about these two items.

The following is an attribute of the <Encoding> tag, and specifically  
describes the Unicode ranges that are used for the Composite Font  
instance:

> Other parameters such as Unicode Ranges - we haven't done but it's  
> on my list.

The "Target" attribute handles this. There is also an "Original"  
attribute that is used if the Component Font uses a different  
encoding, either different Unicode code points (such as PUA versus non- 
PUA) or a different encoding entirely (non-Unicode).

The following is an attribute of the <Language> tag:

> Language Tag - do we need a method of stating that the language is  
> Complex and that layout engines shouldn't try to use other  
> ComponentFonts during composition?  Do we intend on allowing Complex  
> Scripts to span ComponentFonts?  This could get messy.

I don't see why this needs to be explicitly stated, because whether a  
language is considered complex from a layout perspective is sort of a  
binary condition, and can be inferred from the language itself. The  
current recommendation is that IETF language tags, as specified in RFC  
4646, are used. And yes, it can become messy. That is the nature of  
complex scripts.

Can you provide some examples for the following?

> Sizing - it would be helpful to be able to specify a different font  
> depending on the pointsize requested.  This would help with  
> migration of legacy applications.

Having a usage scenario is helpful.

Thanks...

-- Ken