[tx] non-ASCII in CFF TopDict

[frankrolf]

The makeotf process uses .fea files for a lot of purposes, including name table overrides. For a while now (since #1133), UTF-8 has been accepted in those files – which is great!

Here is one such override (from https://github.com/adobe-fonts/source-serif/blob/main/familynameIDs.fea):

nameid 9 "Frank Grießhammer";

In the dark past, this would have been

nameid 9 "Frank Grie\00dfhammer";

This is all great, and produces .fea files of superior readability.
However, there’s one problem – the copyright string (nameID 0):

currently

nameid 0 "© 2014 - 2023 Adobe (http://www.adobe.com/), with Reserved Font Name ‘Source’.";

previously

nameid 0 "\00a9 2014 - 2021 Adobe Systems Incorporated (http://www.adobe.com/), with Reserved Font Name \2018Source\2019.";

The issue:
The following CFF TopDict strings are not in the ASCII range: - Copyright: © 2023 Adobe. All rights reserved, with Reserved Font Name 'Source'. [code: cff-string-not-in-ascii-range] (adobe-fonts/source-code-pro#339)

It seems that makeotf writes the nameID 0 string into the CFF TopDict as-is. The CFF TopDict only accepts ASCII.
The solution is to go back to escaped notation – I wonder if this could happen behind the scenes, rather than forcing the user to remember doing this for a single override?

[frankrolf]

Okay, I might have mis-interpreted things. The CFF TopDict is not fed by the name table overrides.

The copyright string seems to come directly from the UFO file. When the UFO does not contain a copyright string, there won’t be anything in the TopDict, either.

This is the result of my testing (escaped on the left, UTF-8 on the right):

[frankrolf]

reopening after further discussion.

[skef]

Given the symptoms, the likely cause of this problem is TX adding the string (probably as a Notice) to the Type1 generated from the UFO, which is then imported by makeotfexe to convert to a CFF2.

The new code (in the addfeatures branch) doesn't work this way. It uses tx to generate a CFF directly from the UFO. So the place to fix this going forward is likely in that path. An easy fix would be to test if the UFO string has non-ASCII characters and not include the string in that case (also issuing a warning).

The question with Type 1 would then be less urgent given that the Type 1 format is officially retired, but perhaps we could do the same thing in that case.