[mpeg-OTspec] Proposal related to Last Resort fonts

[Sairus Patel]

All,

I've modified the proposal per 1 and 2 below.
http://groups.yahoo.com/group/mpeg-OTspec/files/lastResortFonts_AdobeProposal_v2.doc

Sairus


From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: Thursday, April 09, 2009 11:03 AM
To: Levantovsky, Vladimir; mpeg-OTspec at yahoogroups.com
Cc: Michelle Perham (HILL); John H. Jenkins; Daniel Fenwick; Julio Gonzalez; Simon Daniels; Sergey Malkin; John Hudson; Peter Constable; Peter Lofting; Greg Hitchcock; Christopher Slye
Subject: RE: [mpeg-OTspec] Proposal related to Last Resort fonts




Vladimir,

1. The intention of head.flags bit 14 being set to 0 is that this is not a last resort font (and we can append this to the proposed spec for bit 14 to clarify things):
"If unset, indicates that all glyphs encoded in the cmap subtables represent support for those code points."

Since this is a font-wide flag defined in the above way, we aren't allowing for fonts that mix standard support and last-resort support (if we did, we've have to account for how conflict resolution is done, i.e. if there exists a standard mapping and a last resort mapping for the same code point, and this functional area is not worth this complication).

2. Actually, Unicode platform encoding IDs 3 and up (including encoding ID 6) are all "Unicode 2.0 and onwards semantics" - we've just stopped saying that explicitly since Unicode has guaranteed a while back not to change code point assignments. What differentiates encoding ID 6 from encoding ID 4 is not the version of Unicode supported but the list of cmap subtables that are allowed to be used.

So the parenthetical references to the OT spec versions are in fact references to particular lists of cmap subtable formats. We can make this explicit, if you'd rather not have OT spec version numbers in OFF (I've also clarified encoding ID 5 for completeness here):

encodingID Description
---------- -----------------------
3          Unicode 2.0 and onwards semantics, Unicode BMP only (cmap subtable formats 0, 4, 6)
4          Unicode 2.0 and onwards semantics, Unicode full repertoire (cmap subtable formats 0, 4, 6, 10, 12)
5          Unicode Variation Sequences(cmap subtable format 14)
6          Unicode full repertoire (cmap subtable formats 0, 4, 6, 10, 12, 13)
---------- -----------------------

This makes the Descriptions in the table a bit longer, but they're very explicit (which is good) and don't refer to specific versions of OT (which I'm hearing you say is good for OFF). The paragraph describing them can be modified suitably. I think this should address your concerns. I can write up a revised proposal if there is agreement around this.

Note that the parenthetical additions to the Descriptions for encoding IDs 3-5 above are not new specifications, they're just put all in one place; they currently exist in different parts of the spec.

And thanks for correcting the URL; I changed the name of the file at the last moment and forgot to update the link.

Sairus

[BTW, my messages to this list composed in Outlook 2007 sometimes seem to appear with multiple blank lines inserted when I receive the message from the list... let me know if there's a way in which I can address this.]


From: Levantovsky, Vladimir [mailto:Vladimir.Levantovsky at MonotypeImaging.com]
Sent: Thursday, April 09, 2009 9:27 AM
To: Sairus Patel; mpeg-OTspec at yahoogroups.com
Cc: Michelle Perham (HILL); John H. Jenkins; Daniel Fenwick; Julio Gonzalez; Simon Daniels; Sergey Malkin; John Hudson; Peter Constable; Peter Lofting; Greg Hitchcock; Christopher Slye
Subject: RE: [mpeg-OTspec] Proposal related to Last Resort fonts
Importance: High

Thank you Sairus for presenting your proposal.

All, please notice that the corrected link to the uploaded file is
http://groups.yahoo.com/group/mpeg-OTspec/files/lastResortFonts_AdobeProposal.doc

I would urge all AHG members to review the proposal from Adobe and provide your feedback and any objections to it no later than Monday, April 13th. The deadline for input contribution to the WG11 meeting is April 14th.

The proposal addresses important subject of backward compatibility with the existing font engines, and helps insure that processing of fonts implementing newly introduced functionality (cmap format 13) will not affect existing rasterizers.

Sairus, I have some questions and comments regarding your proposal:

1) My understanding is that by introducing the new encoding ID = 6 we will provide a clear indication that a font may be developed using new cmap format 13, in addition to any other cmap formats defined in the previous versions of the specification. You also proposed to use bit 14 of the 'head' table to indicate that the glyphs encoded in the cmap subtables do not truly represent the encoded code points.

Question:
Is it your intention that
- when bit 14 is set to '1' it indicates that the all code points encoded in a font are not truly represented, and the font can only be used as a last resort font, while
- when bit 14 is set to '0' it would mean that any cmap subtable format can be used by a font, and that a font may contain a mix of glyphs, some of them providing true representation of encoded code points and other glyphs used as a "last resort" glyphs for particular ranges of code points?

If this is true, it seems that the use of bit 14 may be redundant, since the new Encoding ID = 6 would clearly differentiate a font that can use any cmap subtable format, including format 13. It seems likely that most fonts would use different subtable formats (including format 13 for unsupported code points), and that in rare circumstances a font may only provide cmap format 13 subtable as a last resort. However, I don't see why we would need to flag this font. Existing font engines would likely not bother checking this new flag and the new rasterizers will be able to properly handle the font with the support for the new Encoding ID.

2) I think that providing historical references to previous versions of the OpenType specification as part of the Encoding ID descriptions would be detrimental to the readability of the OFF spec. I suggest that we should rather stick with the established naming conventions of different Encoding IDs. I propose that we should add new row in the Encoding ID table with the value = 6 and the description field "Unicode 5.0 and onward semantics, Unicode full repertoire", and leave all other description fields unchanged. This description would provide distinct meaning for the new ID, and at the same time can be used to encode cmap table encoding records.

Thank you,
Vladimir


________________________________
From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Sairus Patel
Sent: Thursday, April 09, 2009 12:24 AM
To: mpeg-OTspec at yahoogroups.com
Subject: [mpeg-OTspec] Proposal related to Last Resort fonts




I've discussed the concepts in the following Adobe proposal with various interested parties, including MS and Apple, on an off-list thread:
http://tech.groups.yahoo.com/group/mpeg-OTspec/files/lastResortFont_AdobeProposal.doc
I think it will very nicely allow for "Last Resort" fonts and cmap subtable format 13 to fit cleanly into the OpenType/OFF specifications.
Since this proposal has Apple's LastResort.ttf in mind (this is a Snow Leopard pre-release font), Adobe would like it to be introduced as an amendment to the OFF standard at the next WG11 meeting (April 19-24). Thus, please review it at your earliest convenience.
Best,
Sairus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090410/6a9e839e/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 322 bytes
Desc: image001.jpg
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090410/6a9e839e/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/x-ygp-stripped
Size: 322 bytes
Desc: image002.jpg
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20090410/6a9e839e/attachment-0001.bin>