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

[Levantovsky, Vladimir]

Dear Ken,

First of all, addressing the last point in your email - I've sent an
invitation to Karsten to join this group. I also would like to remind
people once again that the participation in this group is open to any
individual, regardless of their affiliation. A participant does not need
to receive an invitation in order to join the group - it can be done
either through the web (http://tech.groups.yahoo.com/group/mpeg-OTspec/)
or by sending email to 
mpeg-OTspec-subscribe at yahoogroups.com

Thank you for providing the summary of Adobe composite fonts solution.
Since prior discussions happened outside the scope of this AHG, I think
that in order to have a productive discussion we should make an effort
to bring everyone up to date regarding different ideas and proposals
discussed earlier. Your email is a very good step in this direction and
I would like to ask other participants to present their views and ideas
on this subject on this email list. Alternatively, any participant may
prepare a document outlining your views and ideas, and upload it to AHG
file storage for further review and discussion on this email list.

Thank you,
Vladimir


> -----Original Message-----
> From: Ken Lunde [mailto:lunde at adobe.com] 
> Sent: Thursday, February 19, 2009 5:06 PM
> To: Levantovsky, Vladimir
> Cc: mpeg-OTspec at yahoogroups.com; Karsten Luecke
> Subject: Re: [mpeg-OTspec] AHG on Open Font Format kick off
> 
> 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
> >
> >
> > 
> 
>