Iosevka is not a monospaced font

[JCKodel]

🎯 Can't use Iosevka on Putty, VSCode or Windows Console.

Ioskevka NF is being registered as a non monospaced font, thus, not loading on programs that requires monospaced fonts. VSCode complains that Iosevka NF is not a monospaced font and terminal can only use that kind of font. Putty don't show Iosevka NF. When we choose "[X] Allow selection of variable-pitch fonts", it works, but everything is now extremely laggy. Windows Console (the original) doesn't show the font (it only allows to select fixed-width fonts) (Windows Terminal works fine)

🔧 Your Setup

• Iosevka Complete Windows Compatible
• Windows Console, VSCode, Putty
• Windows 10

[b-]

I made my own build of Iosevka and patched it with the patcher, and this one's not showing up in Windows Terminal at all for me. It works in ConEmu, and under WSLg, but it's clearly picky. I'm probably doing something wrong, though

[Finii]

@b- Can you show a screenshot how you called font-patcher and the first lines it outputs?

[Finii]

@b- For further diagnostics, maybe you can do

ttfdump SomeFontName.otf | grep 'advanceWidthMa|maxCompositePoin|xAvgCharWi'

which will show us some relevant properties of the original and patched fonts.

Edit: Hmm, ttfdump is probably not avail on Windows :grimacing:

[b-]

@b- For further diagnostics, maybe you can do

ttfdump SomeFontName.otf | grep 'advanceWidthMa|maxCompositePoin|xAvgCharWi'

which will show us some relevant properties of the original and patched fonts.

Edit: Hmm, ttfdump is probably not avail on Windows 😬

Anyone who uses Windows instead of WSL to build things is probably a masochist. I can most certainly just install ttfdump on my WSL build environment and get you that output later today.

I didn’t keep such great logs and whatnot, but I can say that almost definitely I called the font-patcher script using fontforge -script font-patcher -o ../out -c -w path/to/input.ttf

I think the issue might have been related to the input font having had some powerline symbols in it to begin with, because I think what I did that fixed the issue for me is using --careful to not stomp on those. It also seemed like it might have something to do with the file name. I built using the -w option, anyway, but I noticed that with the input font named briosevka-1 I ended up with output fonts named like briosevka NFM forgoing my -1

I’m not super sure, though.

I did manage to get a working patched version built,

[Finii]

Interesting would be the font-patcher script version (not to be confused with nerd font version), you see it near the top of the script:

#!/usr/bin/env python
# coding=utf8
# Nerd Fonts Version: 2.3.0-RC
# Script version is further down

from __future__ import absolute_import, print_function, unicode_literals

# Change the script version when you edit this script:
script_version = "3.3.3"

The output file name has 'nothing' to do with the input file name, but is rather like the postscript-font-name with some changes. This is why you do not get the -1 through.

[b-]

I think you may be right about the version -- when I first tried patching a font myself I realized way too late that I was using an outdated patching script from another repository (in order to avoid the 30 GB of monorepo history and whatnot from here), but that was a mistake.

I'm not sure where I found the repository I mentioned, but I'm gonna see if I still have it somewhere on my hard drive so I can file a report or a pull request or something there.

I apologize, I think that I hijacked this issue with my own unrelated problems. I need to double- and triple-check, but I think everything is okay with my customized version of Iosevka that I built at the default branch of https://github.com/b-/Iosevka when I used the latest version of the patcher.

The output file name has 'nothing' to do with the input file name, but is rather like the postscript-font-name with some changes. This is why you do not get the -1 through.

I do want to mention that I used my own custom build of Iosevka for an input font, which I changed the actual internal name of to "briosevka-1". I'm not sure if it chopped the -1 off because I used the -w option to prevent the font name from being too long for Windows's comfort, but the pre-patched input font shows up named as briosevka-1 in font viewer and applications.

I ended up renaming it to briosk anyway, though, because if we have, like, 32 characters to make Windows happy then I'd rather not take up 11 of them :)

[Finii]

in order to avoid the 30 GB of monorepo history and whatnot from here

Well, in the meantime we have a single zip file that holds the last release script with all additional files needed for patching: https://github.com/ryanoasis/nerd-fonts/releases/download/v2.3.0-RC/FontPatcher.zip

But well, that is not master. And it is very badly documented. We need to

• promote that more (who wants to write docs?)
• install some CI that keeps one version of that zip as 'rolling release' on master

I'm not sure where I found the repository I mentioned, but I'm gonna see if I still have it somewhere on my hard drive so I can file a report or a pull request or something there.

I guess there are lots of forks out there that are outdated. But people should be able to find HERE something usable, which does not drive them to forks.

I apologize, I think that I hijacked [...] with my customized version of Iosevka that I built at the default branch of https://github.com/b-/Iosevka

No apologies needed, this IS about a non monospaced Iosevka, right? I will check that font. But however the original font is layed out, font-patcher must come out with a monospaced font or tell you it is not possible (unless you specify --proportional-font (well the flags has a different name, I forgot it).

I do want to mention that I used my own custom build of Iosevka for an input font, which I changed the actual internal name of to "briosevka-1". I'm not sure if it chopped the -1 off because I used the -w option to prevent the font name from being too long for Windows's comfort, but the pre-patched input font shows up named as briosevka-1 in font viewer and applications.

Hmm. I'm not sure how the script (without --makegroups) handles the naming. Apart from that a dash - has the specific meaning of style separator in font names (sometimes), so that is not a good idea.

So, btw, I strongly advise you to patch any Iosevka with --makegroups, because without it the fonts will be unusable if multiple weights are installed (single font file install would be fine, though).

I ended up renaming it to briosk anyway, though, because if we have, like, 32 characters to make Windows happy then I'd rather not take up 11 of them :)

I still searcjh for people who actually suffer from that ... 32 char limit. I never used a Windows Compatible Nerd Font on Windows and never had any issues. If you encountered one, please describe! (See also https://github.com/ryanoasis/nerd-fonts/discussions/891#discussioncomment-3852372)

[b-]

No apologies needed, this IS about a non monospaced Iosevka, right? I will check that font. But however the original font is layed out, font-patcher must come out with a monospaced font or tell you it is not possible (unless you specify --proportional-font (well the flags has a different name, I forgot it).

Mine should be monospaced, but actually this reminds me: perhaps something relevant to the issue is related to the choice of spacing in private-build-plans.toml? https://github.com/be5invis/Iosevka/blob/07b74b95723020dba95b85bb859faa9f0c206cad/private-build-plans.sample.toml#L6

[b-]

When I first built the "briosevka-1" font (before renaming it, etc.) I think I used the default spacing option. I really don't fully understand what the given options do, anyway, although I imagine they have something to do with double-width characters

[Finii]

All code has been enhanced with v3.0.0, so I would guess this is fixed. Run the font-patcher with --debug to collect more information if still problematic and open new issue.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity (i.e. last half year) after it was closed. It helps our maintainers focus on the active issues. If you have found a problem that seems similar, please open a new issue, complete the issue template with all the details necessary to reproduce, and mention this issue as reference.