[mpeg-OTspec] Proposal related to Last Resort fonts

Thu Apr 9 21:59:17 CEST 2009

Hi Sairus,

My original impression (maybe incorrect) was that it would be okay to
have both standard cmap table support and 'last resort' cmap in the same
font. It's feasible that one may want to create a Unicode fonts where
supported code points would be encoded using e.g. cmap formats 0, 4 and
12, and unsupported code points would be encoded using cmap format 13
(although I am still trying to wrap my head around this as to why a
different glyph rather than .notdef glyph would be needed to convey the
same thing, maybe we should say something about it). 

As far as possible duplication of the same code point in both standard
and "last resort" tables is concerned, I am not sure if we need to
explicitly handle this in the spec. Right now, it is feasible that the
same code point could be encoded in different standard cmap formats
(e.g. format 4 and 12) and that the same code point could be (by
mistake) mapped to different glyphs. This may simply constitute a bad
font but the spec doesn't address this issue. For "last resort" fonts,
we could just say that a font engine should look into "last resort"
mapping table only if the code point is not present in the standard
table.

I like your proposal to provide explicit definition of the Encoding ID
values.

Thank you,

Vlad

From: Sairus Patel [mailto:sppatel at adobe.com] 
Sent: Thursday, April 09, 2009 2:03 PM
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_AdobePro
posal.doc
<http://groups.yahoo.com/group/mpeg-OTspec/files/lastResortFonts_AdobePr
oposal.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_Adob
eProposal.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/20090409/a1a24623/attachment.html>