AHG kick-off - Composite Font Representation work

[Peter Constable]

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/5055921b/attachment.html>