Liga SF Mono fonts clobber the original SF Mono fonts

[seanf]

I just went to install all the input and output fonts, and when installing the output fonts, I found that I already had "SF Mono Regular" and "SF Mono Semibold" - it looks like these two are the only output fonts which have exactly the same name as their input fonts. Most of the fonts have "Liga " prepended.

However, a couple of the other fonts are named a little inconsistently, because they don't have a space after "Liga", ie

• "Ligaedlo Regular" (from "Edlo Regular")
• the "IBM Plex Mono" fonts become "LigaIBM Plex Mono"

Also the Meslo LG fonts have different spacing in Liga form, eg "Meslo LG S DZ Regular" became "Liga MesloLGSD Z Regular".

[ToxicFrog]

The renaming stuff is, honestly, a quick hack that I did not test rigorously and (in particular) assumes:

• the fonts are all named with the CamelCase-Weight convention (this is not true of edlo.ttf)
• the filename is either the authoritative source of the font name or is consistent with the name information embedded in the font (this is not true of LG S DZ Regular, largely because there's no way to deal with ALLCAPS sensibly in the CamelCase-Weight naming scheme)

I'm not sure what's going on with SF Mono.

I think this should be fixable by looking at the font metadata first and prepending "Liga " to it, and falling back to filename-based naming only if that fails.

[seanf]

Thanks @ToxicFrog. I guess the exact names don't matter so much, but where on earth is that "Liga " prepend happening? I guess it has something to do with get_output_font_details in https://github.com/rojiani/Ligaturizer/blob/828d376809fc83557a7db82949fb2911b059dfce/ligaturize.py#L37 but I can't see any code which would prepend "Liga ".

Ohhhh. If I'm reading it correctly, "Liga" (no space) is prepended to the output file name coming from the Makefile: https://github.com/rojiani/Ligaturizer/blob/828d376809fc83557a7db82949fb2911b059dfce/Makefile#L16 and the Python code above is using camel case to reverse engineer everything from the filename.

The SF Mono case is a weird one though. It looks like all the metadata is the same as the original, almost like it was a straight copy.

[ToxicFrog]

All the metadata is copied from the original, and then some specific fields are overriden in change_font_names based on the information inferred from the filename. The sfnt_names field in particular is a mystery to me and most of it is left untouched; whatever metadata is confusing the font selector could easily be stored there.

I haven't really had a chance to look into this yet, but it will probably involve dumping all the metadata from fonts like SF Mono and seeing where it differs from fonts that work as expected.

[ToxicFrog]

This should be fixed for Edlo, IBM Plex Mono, and Meslo fonts as of 670d05e.

It is not fixed for SF Mono (in either weight), and I have no idea why -- I can see the field getting set properly, but then the original field value gets written to the new font file. Further investigation required.

[kabouzeid]

When running make for SF Mono in the output there is:
The following table(s) in the font have been ignored by FontForge
Ignoring 'meta'

This is not true for the other fonts. So for some reason font merge refuses to rename SF Mono.

[ToxicFrog]

This might have been fixed in 6d3070a.

[sisomollov]

still is there, I think