[mpeg-OTspec] Soliciting comments on draft OFF amendment

Sat Aug 29 00:48:59 CEST 2015

Re. item (2):

I’m not comfortable inserting a new recommendation to map the space character (U+0020) to GID 1 for TT. Apple’s own requirements/recommendations page for “Apple TrueType fonts” doesn’t make this recommendation: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM07/appendixB.html.

At first I thought of suggesting instead that the OFF recommendations simply point to Apple’s page for such stuff. However, we’ll have to get Apple’s agreement that that page is accurate and maintained, and I’m not sure OFF wants such a dependency. Also, Apple’s page details plenty of requirements/recommendations that aren’t in OFF currently.

I’d love to hear what Apple recommends. I’ll forward this to some of my Apple colleagues offlist.

In general, if we had specific recommendations, especially those against the spirit of OpenType (e.g. that a character map to a specific GID), I’d say we should try giving an indication of what software has this dependency, so that font creators can make more informed choices.

Re. item (3):

“Also, Glyph ID 0 should not map from any Unicode value.”

I’m hesitant about the above statement. There are cmap subtable formats (e.g. format 0) in which “gaps” are required to map to GID 0 to indicate “no valid mapping.” Thus, an OFF engine must already have to treat a character’s explicit mapping to GID 0 in a cmap subtable the same as that character not having any mapping in that subtable.

Whether GID 0 is mapped explicitly in the subtable should be up to the font compilation software. I haven’t scoured all the cmap subtable formats recently enough to see if there are cases where inserting a mapping to 0 here or there could help overall size optimization.

The cmap spec https://www.microsoft.com/typography/otspec/cmap.htm already says:  “Character codes that do not correspond to any glyph in the font should be mapped to glyph index 0.” This is a bit of an overstatement, but it’s embedded in a lot of platform recommendations, so it will have to wait for some future cleanup/refactoring effort.

Thanks, Ken, for leading the charge on this part of the recommendations.

Sairus

From: <'Levantovsky>, "Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec]" <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>>
Reply-To: Vladimir Levantovsky <Vladimir.Levantovsky at monotype.com<mailto:Vladimir.Levantovsky at monotype.com>>
Date: Tuesday, August 25, 2015 at 1:40 PM
To: Ken Lunde <lunde at adobe.com<mailto:lunde at adobe.com>>, "mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>" <mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>>, "opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>" <opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>>
Subject: RE: [mpeg-OTspec] Soliciting comments on draft OFF amendment

Hi Ken, all

Thank you for providing your comments on the text of the specification. I would like to clarify some things related to your comments and prior discussions:

1) While checking your comments and proposed changes against the OFF spec - it appears that you found a mismatch between the new OFF text and the current public version of the OpenType 1.7 spec. It seems that what you're actually proposing here is to update the text of the OpenType spec to match the OFF - if this is the case there is no official ballot comment needed here since the OpenType 1.7 is published by Microsoft and can to be updated freely. Is it the case here or did I miss something?

2) I remember we had an extended discussion of this particular part of the proposal but I am not sure if we reached a consensus on the proposed changes (see attached). I would like to ask all to review the proposed updates to the Recommendations section and respond if you have any objections to the proposed changes.

3) This is a call for consensus - please respond to this email with your comments and objections (if any).

Silence will be treated as a consensus approval!

Thank you,
Vladimir

-----Original Message-----
From: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com> [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com<mailto:lunde at adobe.com> [mpeg-OTspec]
Sent: Thursday, July 30, 2015 11:12 AM
To: mpeg-OTspec at yahoogroups.com<mailto:mpeg-OTspec at yahoogroups.com>; opentype-list at indx.co.uk<mailto:opentype-list at indx.co.uk>
Subject: Re: [mpeg-OTspec] Soliciting comments on draft OFF amendment

Vladimir and others,

In addition to considering the registration of the proposed 'vrtr' feature and the modification of the description of the registered 'vert' feature, please consider the following three additional ballot comments:

1) The "Filenames" subsection in Section 7 ("Recommendations for OFF fonts") does not match the corresponding section in the OpenType Specification.

The current language is below:

--- BEGIN ---
OFF fonts may have the extension .OTF, .TTF, or .OTC, depending on the type of outlines in the font and the presence of OFF layout tables.

· Fonts with CFF data always have an .OTF extension.

· Fonts containing TrueType outlines that have OFF layout tables should use the .OTF extension when backward compatibility is not an issue. Fonts without OFF layout tables, or fonts that have backward compatibility issues should use the .TTF extension. TrueType Collection fonts should have a .TTC extension whether or not the fonts have OFF layout tables present.
--- END ---

The proposed new language is what is shown in the corresponding section of the OpenType Specification (but, changing OpenType to OFF):

--- BEGIN ---
OFF fonts may have the extension .OTF, .TTF, .OTC or .TTC, depending on the type of outlines in the font and the desired backwards compatibility.

· A standalone font file with TrueType outlines should have either .OTF or .TTF extension, depending on the desire for backward compatibility on older systems or with previous versions of the font

· A Font Collection file should have filename extension .TTC or .OTC whether or not the fonts have OFF layout tables present, and regardless of the kind of outlines present. TTC may be used for CFF Font Collections if needed for backward compatibility with older software that was not aware of the .OTC extension.

In all cases, software must determine the kind of outlines present in a font not from the filename extension but from the contents of the file.
--- END ---

I could not find this updated language in the latest amendments nor in the current ballot (if I missed it, I apologize), and considering the emergence of and recent support for OpenType/CFF Collections, synchronizing OFF and the OpenType Specification makes a lot of sense.

2) The "First four glyphs in fonts" subsection in Section 7 ("Recommendations for OFF fonts") should be changed to reflect modern environments, and should provide a recommendation only for GID+1.

The current language is below:

--- BEGIN ---
TrueType outline fonts should have the following four glyphs at the glyph ID indicated.

Glyph ID Glyph name Unicode value
0 .notdef undefined
1 .null U+0000
2 CR U+000D
3 space U+0020

Additional recommendations:

Glyph 1 should have no contours and zero advance width.
Character U+000D (carriage return) should map to a glyph with a positive advance width.
Characters U+0001-001F (misc ASCII control codes) and U+007F (delete) should be mapped to glyph 0 (with some exceptions noted below).
Characters U+0000 (null), U+0008 (backspace) and U+001D (group separator) should map to glyph 1.
Characters U+0009 (horizontal tabulation), U+0020 (space) and U+00A0 (no-break space) should map to a glyph with no contours and a positive advance width.
Characters U+0009 and U+0020 should map to a glyph with the same width.
--- END ---

The proposed new language is below:

--- BEGIN ---
TrueType outline fonts should have a glyph with no contours and a non-zero advance width at Glyph ID 1, and the Unicode value U+0020 SPACE should map to it. Note that previous versions of this specification provided different recommendations that also included Glyph IDs 0, 2, and 3, and that some font development tools may still adhere to those recommendations.
--- END ---

Note that I intentionally excluded Glyph ID 0 from this subsection because it is a required glyph, and the following subsection, "Shape of .notdef glyph," covers it more completely. One of the motivations for this proposed change is because modern environments do not require Glyph IDs 1 through 3 to follow these recommendations, and font development tools continue to adhere to them because they are still mentioned in this specification. This is somewhat of a chicken and egg situation, and the only way out of this rut is to change the recommendations in this subsection.

3) The "Shape of .notdef glyph" subsection in Section 7 ("Recommendations for OFF fonts") should be changed to reference Glyph ID 0 and no mapping.

The current language, including the subsection title to be changed, is below:

--- BEGIN ---
Shape of .notdef glyph

The .notdef glyph is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font's limitation.

It is recommended that the shape of the .notdef glyph be either an empty rectangle, a rectangle with a question mark inside of it, or a rectangle with an 'X'. Creative shapes, like swirls or other symbols, may not be recognized by users as indicating that a glyph is missing from the font and is not being displayed at that location.
--- END ---

The proposed new language, which includes a new subsection title, is below:

--- BEGIN ---
Shape and mapping of Glyph ID 0 (the .notdef glyph)

Glyph ID 0, the required .notdef glyph, is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font's limitation. Also, Glyph ID 0 should not map from any Unicode value.

It is recommended that the shape of the .notdef glyph be either an empty rectangle, a rectangle with a question mark inside of it, or a rectangle with an “X”. Creative shapes, like swirls or other symbols, may not be recognized by users as indicating that a glyph is missing from the font and is not being displayed at that location.
--- END ---

The changes are to explicitly correspond Glyph ID 0 with the .notdef glyph, and to state that no Unicode value should map to it, which is effectively material that is proposed to be removed from the "First four glyphs in fonts" subsection that precedes it (see ballot comment #2 above).

Regards...

-- Ken

> On Jul 20, 2015, at 9:23 AM, 'Levantovsky, Vladimir' vladimir.levantovsky at monotype.com<mailto:vladimir.levantovsky at monotype.com> [mpeg-OTspec] <mpeg-OTspec-noreply at yahoogroups.com<mailto:mpeg-OTspec-noreply at yahoogroups.com>> wrote:
>
>
> Dear all,
>
>
>
> Based on the proposal we submitted at the last WG11 meeting (https://groups.yahoo.com/neo/groups/mpeg-OTspec/conversations/messages/1321) the new amendment was started and its proposed draft text is now published under ballot (essentially including the content of AHG proposal attached to my earlier email as a whole).
>
>
>
> The ballot comments are due by early September (so that there is enough time to process and submit them through the official channels in time for ballot closing in October 2015) – this is our biggest chance to introduce any additional changes to the recently finalized 3rd edition of the standard. In order to facilitate the discussion of the proposed changes (if any) and speed up the process of getting to a consensus point within the AHG discussions – I would like to ask you to send your proposed changes to this email list in the following format:
>
> - Brief description of the proposed change(s);
>
> - Quote of the “current language” of the specification;
>
> - Proposed “new language” to be included (either adding or replacing the “current language”)
>
> - Reasons for the change (use cases to be addressed / new features added / problems fixed, etc.)
>
>
>
> Thank you,
>
> Vladimir

------------------------------------
Posted by: Ken Lunde <lunde at adobe.com<mailto:lunde at adobe.com>>
------------------------------------

------------------------------------

Yahoo Groups Links

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.aau.at/pipermail/mpeg-otspec/attachments/20150828/7394c712/attachment.html>