Nerd-fonts: patched font variants (bold, semibold etc) show up as duplicate in fontbook osx

[alexanderjeurissen]

Installing multiple font variants (bold, semibold, light, etc) on OSX using fontbook results in warnings and the font variants are all in separate "font families" ..

I tried installing multiple patched fonts (both Hack and Source Code Pro) so that should rule out that a single patched font is causing the issue.

As can be seen in the screenshot, multiple font families are created for the font variants while I expect a single font family named Sauce Code Pro containing all the variants. Also all the fonts are named: "NerdFontCompleteMono"

I hope we can sort this out because I really want to use the awesome glyphs in my setup

[adambiggs]

I reported this in #25 which appeared to be fixed, but I didn't actually have a chance to test it because I stopped using the install script in favour of manually installing just the font I use... Would love to see this resolved though!

[ryanoasis]

Yes this should be fixed.. thanks for the details here.

I don't have a mac to test on but perhaps I can setup a test branch where others can try it out :smile:

[thewatts]

Looks like it's still an issue (shown after installing master)

[thewatts]

Which, I must say - this project is _LEGIT_. Really thankful for it!

[ryanoasis]

@thewatts, @adambiggs

Yes this should be fixed.. thanks for the details here

Err I apologize for not making my point clear. :blush: What I meant here was that this should _get_ fixed not that it _already_ was fixed. i.e. Yes this is still a problem AFAIK :+1:

I will be leaving this ticket open until someone can confirm an attempted fix :smile:

---

@thewatts

Which, I must say - this project is _LEGIT_. Really thankful for it!

Thanks! That means a lot

[ryanoasis]

I will be pushing up a test branch that should address this issue. Maybe even as early as tomorrow if I get time.

I will link to it on this ticket when I do.

Thanks

[eugenesvk]

@ryanoasis I think this is an issue with FontForge not giving scripts access to font style names (https://github.com/fontforge/fontforge/issues/1061) and relying on autogessing style. Hence you get very strange styles in your fonts such as NerdFontComplete instead of Regular.
The resulting PS Font Name ($fontname set to _fontname + Suffix_ in your patcher) is identical for all different styles (e.g. SauceCodeProNerdFontComplete for both Regular and Medium instead of SauceCodeProNerdComplete-Regular and SauceCodeProNerdComplete-Medium) and Mac throws this error.

After I've used your script to generate the required fonts the only perfect solution to the naming mess I've found was to use FontLab

1. set a proper Family name (e.g. Sauce Code ProNerdC for the 'Complete' version) — this would be the same for all the generated fonts with a given variation of extra glyph sets
2. Auto-generate everything with 3 buttons (Build Style Name, Build Names, and Build OpenType Names) to get clean names
3. Propagate these changes by clicking 'Import Names' in Additional OpenType Names
4. Generate a clean set of files like _SauceCodeProNerdC-MediumItalic.ttf_

Then, you'd get the following clean names (based on Source Code Medium Italic)
Family Name: Sauce Code ProNerdC
Style Name: Medium Italic
PS Font Name (the one that was conflicting on a Mac): SauceCodeProNerdC-MediumItalic (it gets automatically shortened to e.g. "It" if it's >~32 symbols)
Full Name: Sauce Code ProNerdC Medium Italic
(OT-Specific names) Mac Name: Sauce Code ProNerdC Medium Italic (though I'm not sure where these OT-specific names are relevant)

No more naming conflicts, no more "NerdFontComplete" in drop-down menus in apps!
Now, this could also be accomplished in FontForge GUI, but would be much more cumbersome. When FontForge allows access by scripts to style names as well, this could all be automated in a script.

I think it might be even possible as is if you can try to guess a style name from a file name or font properties and try to trick FontForge into reading a specially constructed full name (with a hyphen separating name from style) to write the correct style name, but I don't know how FontForge autoguess is working

[eugenesvk]

Actually, was wrong about FontForge not allowing scripting access to all the names — that github ticket threw me off. The sfnt_names from FF scripting commands is a string that has all the SFNT fields (see Name IDs) and appendSFNTName command allows to change any of them with either a name ID listed in the link.
So it's possible to do everything inside a FontForge script without the help of any other application (and, more importantly, without having to do any manual adjustments).

[ryanoasis]

@eugenesvk Yep! I was aware of the sfnt_names and actually I _think_ I have the changes that should solve the issue right now. Just haven't released or pushed to any branch.

Thank you for the detailed info I think it is helpful :+1:

I think at some point adding configuration files to denote the subfont/style name might be needed. Because some fonts have it after the dash in the filename as a convention but some don't. Also some fonts have the incorrect Styles (SubFamily) when viewed in FontForge (e.g. SourceCodePro-ExtraLight.ttf) as shown below:

WIP Changes preview:
https://gist.github.com/ryanoasis/af51f008838aaa46fb61

particularly of note: sourceFont.appendSFNTName('English (US)', 'SubFamily', subFamily)

[eugenesvk]

Yeah, Source Code is unfortunately a mess in this regard (I also had to change all the font names for these fonts to be correctly reflected in e.g. ST3 — didn't understand why the same name would work on Mac, but fail to work on a Windows, then realized the font names are inconsistent).
I think the reason why Source Code SubFamily here is _Regular_ instead of _ExtraLight_ is that there is a stupid old convention of limiting styles to 4 (regular, bold, italic, bold italic). So ExtraLight doesn't fit and has to be included in a separate family "Source Code ExtraLight" with Regular/Bold/Italic/BI substyles of its own.
However, the OpenType names of this font are correct (because OT got rid of that 4-style limitation), so in your scripts you'd want to read OpenType names ('Preferred Styles' and 'Preferred Family') instead of just 'SubFamily' and 'Family'. And only if OpenType names aren't present, use the regular ones.

Thanks for the gist — I'm also trying to adjust exactly this so that I don't have to do any manual changes, so it's helpful to see what you've done.

And just to reiterate — to me the default FontLab options I've described above are ideal, so I'd suggest you follow them in your scripts as well (overwriting the default Source Code mess, for example), but of course it's up to you.

[eugenesvk]

I'd also suggest in the output to write OpenType names in addition to the regular ones, as they have a priority (e.g. Mac would display OpenType names over regular ones on conflict, think same is true for Windows, but haven't checked)

A quick reference table from my script (names in comments are from FontLab)

sourceFont.appendSFNTName('English (US)', 'Family', "family")                # 'Family Name', 'Menu Name'
sourceFont.appendSFNTName('English (US)', 'SubFamily', "SubFamStyle")        # 'Style Name'
sourceFont.appendSFNTName('English (US)', 'Fullname', "fullname")            # 'Full Name'
sourceFont.appendSFNTName('English (US)', 'PostScriptName', "PS Name")       # 'PS Font Name'
sourceFont.appendSFNTName('English (US)', 'Preferred Family', "PrefFam")     # (OT-specific) 'OT Family Name'
sourceFont.appendSFNTName('English (US)', 'Preferred Styles', "PrefSubFam")  # (OT-specific) 'OT Style Name'
sourceFont.appendSFNTName('English (US)', 'Compatible Full', "CompatFull")   # 'FOND name', (OT-specific) 'Mac Name'

And just FYI similar reference re. default naming functions (FF) is FontForge app names

familyname   # (FF) 'Family Name', overwrites 'Family' if not set via appendsfnt
fullname     # (FF) 'Name For Humans', overwrites 'Full Name' if not set via appendsfnt
fontname     # (FF) 'Fontname', overwrites 'PS Font Name' if not set via appendsfnt"

P.S. Just realized during testing that FontForge introduces another layer of useless quadruplication — the fullname, familyname, and fontname variables are actually NOT the same as any of the SFNT variables. These are unique names present in the PS Names menu within 'Font Info' — and these names aren't even visible in other apps (checked FontLab, FontCreator, though can see (FF) 'Family Name' in Mac Glyphs)

[ryanoasis]

old convention of limiting styles

Did _not_ know this thanks!

read OpenType names [...] And only if OpenType names aren't present, use the regular ones.

Nice. I think I even overlooked that in the screenshot I posted :blush: . Yes I think this makes sense and I this seems like the logic to go with here.

FontLab options

Sorry I did read your suggestion but have not really gone through it in detail. Just FYI the gist I posted was work done before any of your messages so the new information you have provided will help me greatly in making this patcher 'do the right thing'. :+1:

shortening font names always

Also as you mentioned in #58, this one is the only one I am still not sure on. I will reply there

[eugenesvk]

old convention of limiting styles

That's what I got from that Adobe document

"16 Preferred Family; For historical reasons, font families have contained a maximum of four styles, but font designers may group more than four fonts to a single family. The Preferred Family allows font designers to include the preferred family grouping which contains more than four fonts. This ID is only present if it is different from ID 1."

.

have not really gone through it in detail

I'm basically arguing for three key principles:

1. Putting full style (weight, width, and angle) in style name (e.g. Condensed Bold Italic) instead of only doing this for OpenType-specific names and following the useless tradition in regular names. This also means that no style information is contained in the 'Family Name' (no more _Source Code Pro ExtraLight_ as a different family from _Source Code Pro_)
2. Making OpenType-specific names and regular names identical
3. Filling in all available naming fields so that you can control the consistency of names along that unnecessary complexity of legacy duplicates

Re. https://github.com/ryanoasis/nerd-fonts/issues/58 — while thinking about shorter names, don't forget about the larger point of reducing ~36 combinations to 2 :)

[ryanoasis]

Good stuff thanks again.

Yeah I think I am in agreement with you on all 3 of the main points as you described them.

58 - yeah that is definitely something to consider. Also claiming a bunch of font variations is a bit deceiving if most of them aren't very useful :stuck_out_tongue_closed_eyes:

[jrolfs]

Just noticed this thread after I created #61, hopefully it's a start towards solving this?

[ryanoasis]

@jrolfs Yes and I replied on #61, seems like your work at least will help solve. I might have a bit of conflict with https://gist.github.com/ryanoasis/af51f008838aaa46fb61 but I think I soon need to setup a test branch for us to check how the fonts come out.

[adamclaxon]

I have run into a variant of this issue as well. The script seems to assume the font name is the same as the family name. While the font's I have generated are now organized correctly in Font Book, all variants are generated with the same font name, and Font Book interprets them as Duplicates. The proper method I have found (at least on OS X) is for the style to be included in the font name ("OperatorMonoItalic", for instance).

[ryanoasis]

@adamclaxon

Thanks I think we are getting close to getting this fixed now. You are correct it seems that the font name needs the style to identify it properly as a separate font variant.

If you want (and it would be a great help!) you can try patching with the 0.7.0 branch because it seems to be solving most of the issues so far at least.

[Undistraction]

Similar / related issue:

Fontname: Example-ReguarItalic
Fontfamily: Example
Name For Humans: ExampleRegularItalic
Weight: Regular

When I generate an .otf file and open it in Fontbook, the font is shown within Example as 'Regular' rather than RegularItalic, meaning it conflicts with the genuine Regular (non-italic) face.

[shelldandy]

I'm having similar issues still in the sense that I have several weights of fonts with italics versions however all of the italics get assigned the Bold weight for some reason

[ryanoasis]

@Undistraction Sorry that I never replied to you. I will test the scenario you mentioned

@mike3run Can you tell me which fonts you have patched?

[shelldandy]

@ryanoasis the Operator Mono font family, so I cannot directly share it but here let me show you a screen capture of the folder with all the patched fonts and on my fontbook program you can see that for example today only the light italic version is detected (up until yesterday it had been the bold version)

[ryanoasis]

@mike3run Thanks. Yep no worries I know about that font and yes we will comply with licenses here :smile:

[shelldandy]

hey there @ryanoasis just wondering if by any chance this got solved?

Thanks a lot!

[ryanoasis]

@mike3run Hey just tested this.. so unfortunately I cannot test on macOS with fontbook but seems to me it might use the weight to differentiate the fonts.

Are you seeing the same issue with unpatched versions of the same font and same weights or does it only occur after patching?

---

Here is what I see on Linux and it seems to differentiate fine, however there does seem to be something going on:

[shelldandy]

@ryanoasis its a bit weird since i mean the font gets actually rendered and you can _select_ it but it will look like other weight.

So even if it says its the light font it will show as bold 🤔

[shelldandy]

also forgot to add, yeah the bug happens only after patching

[ryanoasis]

@mike3run Oh! So it's not an issue with some showing up or not showing up as selectable but how the style is rendered?

I wonder if the same thing would happen for you with for instance with Hasklug (Hasklig). It seems to render the correct style/weight for me on Linux:

[shelldandy]

Is a mixture of both, on the official fontbook app they do show with names but in a more specialized app like the one on my screenshot above or below they do not show possibly since they are being repeated:

[shelldandy]

So you can see on the right I have all the fonts + italic versions but when imported on the italic ones only the light shows up.

On my laptop the same installed fonts make only the bold one show up as italic

[ryanoasis]

Thanks, this might take some more digging :worried:

[zxaos]

If your system is affected by this, note that having the fonts that Font Book flags as duplicates (i.e.more than a single Italic variant) active will crash iterm2 if you try to set any font from the family in use. Disabling all italic variants but one will resolve the issue.

[shelldandy]

But then you wouldn't have bold support :(((((((((((
Although yeah I actually did what you say a year ago and it works

[zxaos]

I'm not _happy_ without bold italic support, but I'd rather have the icons at all than it.

... But as this issue is happening on 1.2.0 still, it might need to be reopened? ( @ryanoasis ? )

[ryanoasis]

Going to reopen because:

1. Obviously still an issue
2. The commit to close was an "Attempt to fix" and no verification was done to ensure
3. This issue was fallen off of the radar.. I last commented almost a year ago. Apologies to @Undistraction and @mike3run

Thanks @zxaos for getting this back to visibility for me.

I don't know if this will be apart of the next release or not. Goal of 1 per month has been severely lagging. Need to revisit methodology perhaps

[ryanoasis]

Maybe we can make some traction on this again this month. I won't be able to test any potential fixes but I could upload zips if others (who are on macos) can test them out?

[zxaos]

@ryanoasis Can do! Thanks for looking into it, happy to help with testing out fixes

[jackcogdill]

+1 this issue is still happening.

[MarioRicalde]

Here's the manual solution to the problem: https://github.com/ryanoasis/nerd-fonts/issues/257#issuecomment-661153972

@ryanoasis I think it's just a matter of having better Fontname generators that output shorter names.

[ryanoasis]

I know this has fallen off the radar. Trying to come up with better system to keep up with the issues