Soliciting comments on draft OFF amendment

[Greg Hitchcock]

Vladimir asked if I would make a few comments on Ken’s proposal. I’ve not done deep research, but here are a few thoughts.

Re: File Extensions
I’m fine with the new wording. Some old Windows systems might struggle with CFF data in TTCs, but I’m not too concerned about this.

Re: First Four Glyphs
I think most of the requirements came from Apple and applied to the platform 1 mapping. I don’t believe we (Microsoft) made use, on our own platform 3, of glyph IDs 1 or 2. I’m OK with moving space to Glyph ID 1. Should the recommendation also include for U+00A0 to point to this glyph? As Ken notes, previous recommended mappings should not be rejected. I think it is important to get input from Apple on this one.

Re: Shape and mapping of Glyph ID 0 (the .notdef glyph)
This sounds reasonable. I suspect that color support would also be reasonable for Glyph ID 0. I agree that no mappings should point to this glyph.

GregH

From: mpeg-OTspec at yahoogroups.com [mailto:mpeg-OTspec at yahoogroups.com] On Behalf Of Ken Lunde lunde at adobe.com [mpeg-OTspec]
Sent: Thursday, July 30, 2015 8:12 AM
To: mpeg-OTspec at yahoogroups.com; 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

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