fonttools / fontbakery

🧁 A font quality assurance tool for everyone
https://fontbakery.readthedocs.io
Apache License 2.0
549 stars 101 forks source link

FontBakery does not accept the © copyright symbol and other non-ASCII in copyright notices #2854

Open tphinney opened 4 years ago

tphinney commented 4 years ago

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.

The following are examples of how these strings might be defined, based on Times New Roman Bold:

  1. The copyright string from the font vendor. © Copyright the Monotype Corporation plc, 1990

In my case, it was:

FontBakery complaint

  • �[1;91;107mFAIL�[0m: Bad string at [nameID 0, 'mac_roman']: 'b'Copyright © 2019 Font Detective LLC.'' [code: bad-string]
  • �[1;91;107mFAIL�[0m: Bad string at [nameID 0, 'utf_16_be']: 'b'Copyright © 2019 Font Detective LLC.'' [code: bad-string]
  • �[1;91;107mFAIL�[0m: There are 2 strings containing non-ASCII characters in the ASCII-only NAME table entries. [code: non-ascii-strings]

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

davelab6 commented 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?

tphinney commented 10 months ago

Just noticed that this seems like a duplicate of #1718

tphinney commented 10 months ago

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.
davelab6 commented 9 months ago

@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.

rimas-kudelis commented 3 weeks ago

@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?