[mpeg-OTspec] AHG on Open Font Format kick off

[Ken Lunde]

Vladmir,

Many thanks for setting up this AHG. I have a lot of irons in the fire  
at the moment, and I am guessing that others can say the same.

Still, it is important for this project to move forward.

One of the sticking points in previous discussions, which may have  
caused them to stall, was our insistence that the resulting fonts be  
cross-platform, which meant limiting the font format of the component  
fonts, and requiring built-in Unicode support. After discussing this  
point with key people from Apple, we now agree to lift this  
restriction. Instead, I would strongly recommend that the format  
supports a flag that indicates that the Composite Font format is  
intended to be cross-platform, and if it is enabled, some aspects  
become more strict, such as limiting the font format to those that can  
be cross-platform (this would exclude OCF, sfnt-CID, and any resource- 
fork font) and requiring built-in Unicode support. With this flag  
turned off, correctly handling the component fonts then becomes the  
responsibility of the client, which may be an OS.

As stated in previous discussions, Adobe Systems has implemented  
Composite Font support in several ways. Our ATC (Adobe Type Composer)  
application was a rather simple front-end to our AdobeTypeComposer  
ProcSet that allowed various components to be used together, and was  
limited to Shift-JIS encoding with its user-defined region. Some of  
our flagship applications, such as InDesign and Illustrator, include  
built-in Composite Font support that allows customers to select a Base  
Font, then select other fonts to serve as replacements for various  
character classes, such as Latin, symbols, punctuation, and kana. At a  
high level, perhaps for Composite Fonts that are not declared to be  
cross-platform, script-based labels can suffice. But, for those that  
have been declared for cross-platform use, the script-based labels  
should function to specify specific Unicode ranges. The format itself  
should also allow the granularity to be at the code point level,  
meaning that specific code points, not code point ranges, should be  
permitted. Specifying language also has value, in that it allows this  
format to accommodate the building of Pan-CJK fonts.

One of my preferences, as conveyed in previous discussions, is that  
Composite Font definitions be flat, meaning that a Composite Font  
cannot use another Composite Font as a component. A front-end for  
creating Composite Font definitions could allow a user to specify a  
Composite Font as a component, but that it would need to be flattened.  
Considering how complex fonts can become, limiting (or preventing, in  
this case) recursion is probably a good thing.

In terms of the file format itself, for obvious reasons it should be  
XML, which means that it can be human- and machine-readable.

Lastly, I would like to request that Karsten Luecke (karsten.luecke at kltf.de 
) be added to this discussion. His insights and opinions will be  
valuable.

Regards...

-- Ken

On 2009/02/17, at 10:58, Levantovsky, Vladimir wrote:

>
> Dear AHG OFF members,
>
> First of all, I would like to welcome our new members of the group  
> and thank all group members for their contributions and continued  
> participation.
>
> This message is an official kick off of the new AHG exploration  
> activities.
> The AHG mandates, as established at the 87th WG11 meeting are:
> 1. To explore possible ways to overcome the 64K limit of the number  
> of glyphs in the existing font format specification. The preferred  
> way should not adversely affect any existing implementations and  
> should be backward compatible with the existing OFF specification.
>
> 2. To produce a report outlining the results of the exploration  
> activities and propose a way forward for WG11 to achieve stated goals.
>
> All activities of the AHG will be conducted on this reflector; a  
> telephone conference call can be arranged and, if necessary, should  
> be scheduled with advanced two-week notice. The group members also  
> have unrestricted access to Web-based message archive (http://tech.groups.yahoo.com/group/mpeg-OTspec/messages 
> ) and file storage (http://tech.groups.yahoo.com/group/mpeg-OTspec/files/ 
> ).
>
> The subject of 64K limit in OFF/OpenType/TrueType fonts have been  
> raised a number of times in the past. Many of AHG participants have  
> voiced their opinions on the issue and I would like to invite all of  
> you to contribute your ideas and suggestions to this group for  
> continued discussion. Our goal is to come up with the  
> recommendations and working draft of the future specification that  
> will help to eliminate or overcome the restriction of 64K glyphs in  
> a font.
>
> Thank you very much for your efforts.
> With kind regards,
> Vladimir
>
>
>