[mpeg-OTspec] Proposal related to Last Resort fonts

[Levantovsky, Vladimir]

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
<http://tech.groups.yahoo.com/group/mpeg-OTspec/files/lastResortFont_Ado
beProposal.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/4ffefe10/attachment.html>