How to change generated Font's names?

[Derpitron]

My original font family is called Iosevka Derp.

Upon patching the fonts using FontPatcher from Docker, the font family name is changed to IosevkaDerp Nerd Font.

This means that I would have to change all of my program's font family settings or configurations to IosevkaDerp Nerd Font, which is too cumbersome to practically do.

How can I change the generated font-family name back to Iosevka Derp for compatibility and ease-of-use?

[Finii]

If I remember correctly you can give --makegroups -1 to tell the patcher to not-touch the naming and some other properties.

Please reopen if Im wrong.

[Derpitron]

I will try this later today.

Other question: I notice there are other makegroups, e.g -1, 0, 1, 2, 3, 4, 5, 6.

What are the meanings of these?

[Finii]

I know I wrote it down somewhere but I can not find it 😬

So maybe this will become the manpage for that feature.

The problem the patcher faces is this:

• We want to change the name of the font somehow to indicate it is patched (you do not, but usually)
• The name parts in fonts have a length limit (on some platforms)

The name of a font consists of multiple fields, usually you have a family (Times New Roman) and the weight (Bold) and style (`Condensed´) parts. All these fields must be changed in a way that makes sense to the font engine on the machine, so that fonts that belong to each other are ordered in groups correctly (in the font choosers and other places). This is all not based on rules but on conventions that are usually followed.

If for example the unpoatched font has the name Fantasque Sans Mono (19 chars) and we add Nerd Font Propo (15 chars) to it, the new name will be 19+1+15 = 35 chars long. This is longer than the expected 32 (or even less for older systems) chars.

So the first possibility is to either add a short or a long form of our addendum: Nerd Font Propo or NFP.

Sometimes, through the interplay of the different name fields and their limit on "combinded length" 🙄 the problem arises only with the styles and weights. In that case these can be shortened like ExtraBold becomes ExtBld, or even XBd. These are the conventional short forms that need to be selected usually by the font designer.

So we have these possibilities: Keep all name parts long, shorten the family name (NF), shorten the styles (ExtBd), shorten the styles aggressively (XBd).

The --makegroups option lets you select what you like best. Keep in mind that people might prefer the longer names even if the limits are exceeded, because ... they are soft limits and it depends on your use case what length they really can have.

To be able to specify the shortening preference in a concise manner this is all condensed into one value:

    # --makegroup has an additional undocumented numeric specifier. '--makegroup' is in fact '--makegroup 1'.
    # Original font name: Hugo Sans Mono ExtraCondensed Light Italic
    #                                                              NF  Fam agg.
    # -1  no renaming at all (keep old names and versions etc)     --- --- ---
    #  0  turned off, use old naming scheme                        [-] [-] [-]
    #  1  HugoSansMono Nerd Font ExtraCondensed Light Italic       [ ] [ ] [ ]
    #  2  HugoSansMono Nerd Font ExtCn Light Italic                [ ] [X] [ ]
    #  3  HugoSansMono Nerd Font XCn Lt It                         [ ] [X] [X]
    #  4  HugoSansMono NF ExtraCondensed Light Italic              [X] [ ] [ ]
    #  5  HugoSansMono NF ExtCn Light Italic                       [X] [X] [ ]
    #  6  HugoSansMono NF XCn Lt It                                [X] [X] [X]

The value 0 uses the old naming code which, especially for bigger font families, produces unusable results.
The code is just kept for people that want the old often strange names.

And the there is the even more undocumented feature of giving -1. That disables all renaming, and all name fields and related information in the font files are untouched. That also disables the RFN algorithm (some fonts must be renamed on patching for licensing reasons).

[Derpitron]

Very in-depth answer. Thank you!