font-patcher: Really set SubFamily to what we want

[Finii]

Description

[why]
The most convenient way to set something in the SFNT table is by using
Fontforge's appendSFNTName(). When we try to set the SubFamily, this
will succeed in many instances, but not in all. Sometimes the function
seems to be ignored.

This is for example the case for VictorMono-Medium.ttf where we want to
set the SubFamily "Regular", but the final patched file has the
SubFamily "Medium".

[how]
The reason for the unexpected behavior of Fontforge is as follows. It
almost seems like a bug, but then it is coded explicitely in this way.
Maybe noone ever stumbled about it, or it has only been designed only
with creating new fonts in mind.

Fontforge lets you set any value, unless it is the default value. If it
is the default value it does not set anything. It also does not remove
a previously existing non-default value. Why it is done this way is
unclear:

  fontforge/python.c SetSFNTName() line 11431
    return( 1 ); /* If they set it to the default, there's nothing to do */

Then is the question: What is the default? It is taken from the
currently set fontname (??!). The fontname is parsed and everything
behind the dash is the default SubFamily:

  fontforge/tottf.c DefaultTTFEnglishNames()
  fontforge/splinefont.c _GetModifiers()

To stick to the example above, the fontname is there
"VictorMonoNerdFontM-Medium". Afterwards we want to set the SubFamily to
"Medium" - which is the 'default' and Fontforge decides that nothing has
to be done. Albeigth the current SubFamily is "Regular" (from the source
font load).

Well.

To fix this without touching Fontforge we need to set the SubFamily
directly in the SFNT table, which is a little bit unhandy but possible.

Now in the generated files the SubFamily is again as expected the same
es the fontname's last part.

Requirements / Checklist

• Read the Contributing Guidelines
• Read or at least glanced at the FAQ
• Read or at least glanced at the Wiki
• Scripts execute without error (if necessary):
  • If any of the scripts were modified they have been tested and execute without error, e.g.:
    • ./font-patcher Inconsolata.otf --fontawesome --octicons --pomicons
    • ./gotta-patch-em-all-font-patcher\!.sh Hermit
• Extended the README and documentation if necessary, e.g. You added a new font please update the table

What does this Pull Request (PR) do?

How should this be manually tested?

Any background context you can provide?

What are the relevant tickets (if any)?

In progress of fixing issue #663

Screenshots (if appropriate or helpful)

font-patcher run with debug stuff enabled, see https://gist.github.com/Finii/a496cff7eb38933b169110be3e4e8af2

[Finii]

I guess in the end this fix will not be needed.
Leave it in for now, to document that the code seems to be doing something that it is in fact not.

I still fight with tables with all naming details of all 741 font, while in parallel setting up Christmas stuff for the children ;-)

Do not really like the fontforge behavior, maybe should MR there. Anyhow, the unexpected-behavior safes us as we can not overwrite the SubFamily with the ridiculous stuff we want to write ;)

[Finii]

Here some examples:

Overpass Extrabold for example, we rip out the weight from the family name and try to stuff it into the SubFamily, that fails, and so the information is lost ;-)

[Finii]

Just that I do not forget..

Other ppl have the same problem with fontforge and write their own SFNT accessor:

https://github.com/ToxicFrog/Ligaturizer/blob/master/ligaturize.py