AHG kick-off - Composite Font Representation work

Thu Nov 18 17:18:35 CET 2010

Peter,

Thank you for your message and for your interest in the development of the a Composite Font representation.

This work started back in early 2009 (http://tech.groups.yahoo.com/group/mpeg-OTspec/message/96) as an exploration activity based on the proposal from Microsoft and other members - you may find all the related discussions in the AHG email archive. There are also intermediate documents that AHG produced and discussed during the course of the exploration activity, and the draft descriptions of the requirements and use cases that were considered. The documents are available from the AHG File storage: http://tech.groups.yahoo.com/group/mpeg-OTspec/files/.

The issues you outlined in your email are exactly the problems that we are trying to solve, and I believe this was clearly documented in the Requirements document. The Call for Proposals was closed at the last SC29/WG11 meeting in October, and the Working Draft is now being prepared. I welcome your feedback and contributions to this work, we are in the very beginning of the development process and the input from the members of the group would be valuable to ensure the quality of work and the resulting standard.

I will let the original proposers answer the specific questions regarding some of the proposed  elements and attributes, and the specific examples.

Thank you,
Vladimir

From: Peter Constable [mailto:petercon at microsoft.com]
Sent: Thursday, November 18, 2010 4:10 AM
To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
Subject: RE: AHG kick-off - Composite Font Representation work

I admit I haven't been involved in discussions regarding a composite font format over the past couple of years, so perhaps I'm asking for something that has been clear to others:

I would find it helpful to see a clear statement of the specific problem that this proposal is trying to solve.

Standardizing a file format is useful for data interchange between different users and different products. I don't see what scenarios would require interchange of data describing a combining of font resources in the abstract.

Font resources may need to be combined for use together in relation to text styling in particular text-layout applications. So, for example, the CSS Font Module has provisions for describing font styling that combines multiple font resources in ways that are applicable to use in styles used in an HTML environment. The data being interchanged, in that case, is intrinsically related to the application to CSS and HTML and to the particular HTML content for which it was intended. This is one possible application scenario for such a data format, but I'm not aware of any application or operational environment in which the proposed standard would be used.

A rather different problem that a description for combining font resources might apply to is addressing the conflict between the large repertoire of Han ideographic characters encoded in Unicode / ISO 10646 on the one hand and the 64K glyph limit inherent in the OpenType format on the other. In a text layout system, there could potentially be benefits to describing a relationship between two font resources that have glyphs for Han ideographs and that exist as distinct resource only because of the 64K limitation. But it's not clear if there's a _data interchange_ need in this regard.

I don't know if either of these possible issues are what this proposal is intended to solve. Whether it is these or something else, the intended implementation environments or actual need in interchange are also not clear to me. I'm also unclear regarding provisions of the format in the proposed working draft. For instance, the last example includes this snippet:

<cmapOverride>
<map charValue="0x0020" charName="SPACE" glyphRefID="231"/>
                <map charValue="0x0021" charName="EXCLAMATION MARK" glyphRefID="232"/>
                <map charValue="0x0022" charName="QUOTATION MARK" glyphRefID="12087"/>
...

It's completely unclear how character names in this context could be anything but superfluous information or, worse, information that is potentially in conflict with other standards (if, for instance, the first map associated charValue="0x0020" with charName="EXCLAMATION MARK").

I'm sure there are reasonable responses that can be provided to some or all of my questions. If not, though, or if there isn't clear consensus on what particular problems are being solved and why these are problems that entail data interchange, I think it would be good to get some clarification and consensus on those points. A key to writing a good specification is understanding what problems are needing to be solved and what important principles should be applied to ensure that the "solution" is successful.

Peter Constable

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Levantovsky, Vladimir
Sent: Tuesday, October 26, 2010 10:27 AM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] AHG kick-off - Composite Font Representation work

Dear all,

The purpose of this email is to kick off the activity of the ad-hoc group and to update you on the results of the last MPEG meeting. As you know, we had a Call for Proposals issued for Composite Font standard, and two proposals were submitted for consideration by the MPEG Committee at the last meeting on October 10-15. Both proposals (one from Apple inc. based on the Apple Spliced Font Format, and the joint proposal from Apple and Adobe with Spliced Font Format extensions) were accepted, and the Working Draft of the future standard was prepared. One of the requirements of the Call for Proposals was to provide the full description of the proposed technology - this requirement was partially satisfied by the proposal submissions; however, the original proposers have agreed to provide the needed additional information if the proposals are accepted.

The mandate of this AHG is to finalize the Working Draft of the Composite Font Representation document before the next MPEG meeting in January 2011. I uploaded the working draft to the AHG file repository, and the document can be downloaded using the following URL:
http://groups.yahoo.com/group/mpeg-OTspec/files/w11572_14496-28_WD-CFS.doc

I would like to ask all group members and the original contributors of the proposed technical solutions to review the prepared Working Draft and to provide the missing details. If necessary, the conference call can be scheduled to discuss the technical and editorial work items.

Thank you and best regards,
Vladimir

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20101118/3b541fdc/attachment.html>