com_google_fonts_check_074: Why must name ID 0 (copyright) be ASCII only?

In the Ms name table spec, https://docs.microsoft.com/en-gb/typography/opentype/spec/name#enc1 I see no mention of nameID 0 needing to be ASCII.

Imo, there’s nothing wrong with having genuine copyright, tm and registered symbols. As long as the characters are within the Mac Roman encoding, https://en.wikipedia.org/wiki/Mac_OS_Roman for Mac entries and the BMP plane for Win entries, I don’t think we’re violating anything.

The reason I’m bringing this up is because Plex has the following copyright.

© 2017 IBM Corp. All rights reserved.

Am I missing something?

[readroberts]

When CFF data is present as a CFF table in an OpenType font, there is a bunch of CFF data which is not relevant, and should be ignored in favor of the equivalent data in other tables - see the differences between the CFF2 and CFF table definitions. The CFF Copyright should be ignored, and certainly can be different than name table ID 1 - Adobe uses ‘@’ in name id 0, but not in the CFF Copyright string. The specification of the encoding of a copyright string in CFF is indeed poorly specified. The PostScript Language Reference Manual says that the ‘Notice’ field is a ‘string’ type, and then in section 3.3.7, says the encoding is unspecified and is whatever you want - the only limitation stated is that to enhance portability for strings that are present literally in the data, is charset can be limited to ASCII, but I haven’t seen a tool that will reject a font for any encoding in the ‘string’ fields. I now recommend omitting the Notice or Copyright field from the CFF table.

[anthrotype]

I’m not sure we’ll ever release type 1 fonts

of course not. I mentioned Type1 because the CFF spec refers to that for the meaning of those TopDict operators. The text encoding is still unclear, but ascii is indeed the safest bet for CFF strings. What you’re mostly interested in is not that it doesn’t display garbage, because those strings are dead weight and they will never be seen by human beings – unless one opens up the font in a hex editor or decompiles it with ttx, or perhaps if the CFF font is embedded in a PDF (not sure). It’s the name table strings the ones the user will be shown. What you’re interested in is that the rest of the CFF table isn’t rejected because of those useless pieces of string.