[OpenType] OpenType "Recommendations": First Four Glyphs in Fonts

Ken Lunde lunde at adobe.com
Wed Jul 15 14:31:44 CEST 2015


To clarify, I was not proposing any changes to GID+0, and merely made a side comment about its glyph name, or lack thereof for some formats. Of all of the glyphs that can be in an OpenType font, the only one that is required is GID+0, which means that a reference to GID+0 does not belong in a section that is detailing recommendations. In other words, a reference to GID+0 simply doesn't belong in the table in the "First Four Glyphs in Fonts" subsection.

Based on the comments thus far, revisiting the recommendations for GIDs 1 through 3 seems like a worthwhile exercise. It is also useful to point out that there is nothing wrong with existing fonts that follow the current recommendations, especially if current versions of some tools happen to enforce those recommendations.

At this point in the discussion, about the only recommendation that may be worth considering is that GID+1 should be a "space" with a non-zero advance width.


-- Ken

> On Jul 14, 2015, at 4:34 PM, Mike Kamermans <nihongo at gmail.com> wrote:
> The problem with allowing glyph 0 to also be the "space" is that having
> white-space double as non-resolving character makes typesetting dreadfully
> hard: tofu blocks are extremely valuable when applying a font to a stretch
> of text. If those turn into spaces, it becomes much harder (certainly not
> impossible, but needlessly so) to determine what is genuine spacing and
> what is an actual missing glyph.
> Leaving glyph 0 as is ("notdef" semantics, with an outline of the
> designers' choice, which may include whitespace) and then critically
> reexamining what the spec says on what glyphs 1, 2 and 3 are allowed to be
> (given actual use in the wild) seems a safer course of action.
> - Mike "Pomax" Kamermans
> On Tue, Jul 14, 2015 at 3:46 PM, Richard Wordingham <richard.wordingham at ntlworld.com> wrote:
>> On Tue, 14 Jul 2015 12:52:34 +0000 "Karsten Luecke" <karsten.luecke at kltf.de> wrote:
>>> given this and your OT list exchange with Adam, there could be a
>>> single recommendation:
>>> Make space glyph the first glyph of the font.
>>> (It would "automatically" serves as .notdef – with or without a name
>>> –, albeit a shapeless one.)
>> I can't help feeling that that helps criminals hide text.
>> Richard.

> On Jul 14, 2015, at 5:13 PM, Behdad Esfahbod <behdad at behdad.org> wrote:
> On 15-07-13 10:14 PM, Ken Lunde lunde at adobe.com [mpeg-OTspec] wrote:
>> Besides, I also suspect that that "Additional recommendations" are also
>> suspect (pun intended). At the very least, we should consider adding a
>> statement to the effect that these recommendations are based on older
>> environments, and that modern environments no longer depend on them.
> Correct.
> My experience is that it's part of the design of both the cmap table, and that
> of CFF table, that gid 0 means "not found".  The gids 1..3 are game these days
> as far as rendering environments are involved, and should be relaxed IMO.
> On 15-07-14 01:52 PM, Karsten Luecke  wrote:> given this and your OT list
> exchange with Adam, there could be a single
>> recommendation:
>> Make space glyph the first glyph of the font.
>> (It would "automatically" serves as .notdef – with or without a name –,
>> albeit a shapeless one.)
> This is problematic as many APIs, as well as certain cmap subtables assume gid
> 0 to mean "glyph not found in font".
> b

> On Jul 14, 2015, at 9:16 AM, John Hudson <john at tiro.ca> wrote:
> On 14/07/15 05:21, Ken Lunde lunde at adobe.com [mpeg-OTspec] wrote:
>> Anyway, the reason I am bringing up the issue of the "First Four Glyphs
>> in Fonts" subsection is that many people who read it treat it as gospel,
>> but actual practice indicates that there are no dependencies on GIDs 1
>> through 3, in terms of their names and other characteristics. If anyone
>> has any evidence to the contrary, that would be most interesting to me.
> I can think of one possible tool dependency. When we made the Adobe Arabic, Devanagari, etc. fonts, we were dependent at the time on using the MS VOLT tool, since AFDKO at the time didn't support the all the functionality we needed. We made the CFF glyph set to Adobe's spec, without GID 1 and GID 2 as NULL and CR, but we discovered that VOLT seemed to expect the standard first four glyphs as per the recommendation, and that parts of some cmap subtables written by VOLT got messed up without them. We had to post-process the cmap table in TTX to clean it up. Since then, Sergey has provided an option for VOLT not to rewrite the cmap table, which can be used to bypass this dependency, but I mention it because I'm cautious about endorsing the view that there are no dependencies.
> J.
> -- 
> John Hudson
> Tiro Typeworks Ltd    www.tiro.com
> Salish Sea, BC        tiro at tiro.com
> Getting Spiekermann to not like Helvetica is like training
> a cat to stay out of water. But I'm impressed that people
> know who to ask when they want to ask someone to not like
> Helvetica. That's progress. -- David Berlow

More information about the mpeg-otspec mailing list