Open tphinney opened 4 years ago
Accept the copyright symbol '©' without error.
The reason I specified this check is that I want the copyright notice to be the same everywhere, as the OFL requires the notice to be retained, and the CFF table's copyright notice key is ascii only.
�[1;91;107mFAIL�[0m: Bad string at [nameID 0, 'mac_roman']: 'b'Copyright © 2019 Font Detective LLC.'' [code: bad-string]
BTW, I am curious why your copy & paste includes the ansi terminal color code characters? Is that a fontbakery bug?
Just noticed that this seems like a duplicate of #1718
AFAIK Adobe has continuously released OpenType CFF fonts from at least 2000 to very recently, with the copyright symbol in the name table. Back in the day it was a requirement for every Adobe font.
From Minion Pro from circa 2002, early OpenType releases
<namerecord nameID="0" platformID="1" platEncID="0" langID="0x0" unicode="True">
© 2000, 2002 Adobe Systems Incorporated. All Rights Reserved. U.S. Patent Des. 337,604. Other patents pending.
From Minion Variable Concept released around 2018
<namerecord nameID="293" platformID="1" platEncID="0" langID="0x0" unicode="True">
MinionConceptRoman-DisplayBold
</namerecord>
<namerecord nameID="0" platformID="3" platEncID="1" langID="0x409">
© 1990-2018 Adobe. All rights reserved.
@tphinney right, the name table supports that character in CFF same as TTF, but the CFF table itself has a copyright notice key, and that is ascii only.
@davelab6, please reconsider.
The whole section about Copyright and Trademark Notices has been removed from the CFF specification back in 2000 (see appendix I here), but even before that this field was specified as optional and without any strictness (section 18 here, also this comment).
Furthermore, Adobe itself stopped supporting Type 1 fonts in their products last year, telling users to switch to OpenType fonts instead. And, as you know, OpenType fonts have a separate unicode-compatible table for storing copyright strings, which (again per comment linked above) has higher priority than the strings in the CFF table.
IMO, requiring font authors to limit themselves to ASCII in 2024 just because there exists a legacy field in one of the OpenType tables with such constraint doesn't make sense. Why not replace this requirement with a check that no copyright string is stored in the CFF table, for example?
Observed behaviour
I was surprised that FontBakery rejects non-ASCII characters in the name table, especially the © copyright symbol, which is a natural in the copyright notice. Certainly a very large number of fonts in the world use this.
Additionally, sometimes project authors or even project names themselves might contain accented characters and other non-ASCII. (Perhaps even non-Latin, but even if we stick to basic Mac/Windows characters....)
The single example of a copyright notice in the current OpenType spec uses a copyright symbol.
In my case, it was:
Expected behaviour
Accept the copyright symbol '©' without error.
Resources and exact process needed to replicate
Run FontBakery on most any major vendor’s fonts. I found Apple Color Emoji and Verdana both have this issue, for example.
See also: https://github.com/tphinney/science-gothic/issues/238