Patching Berkeley Mono v2 leads to incorrectly spaced chars
Requirements
- [X] I have searched the issues for my issue and found nothing related or helpful
- [X] I have searched the FAQ for help
- [X] I have checked the Wiki for help
Experienced Behavior
The arrow ligature is offcentered to the left, and the r in the import word is to far to the right. It happens for many characters.
Even if the font is behind a paywall, the issue should also happen on the free trial version of Berkeley Mono v2. Command used to patch fonts:
sudo docker run --rm \
-v /home/clementpoiret/.local/share/fonts/TX-02:/in \
-v /home/clementpoiret/.local/share/fonts/TX02-NerdFont:/out \
nerdfonts/patcher \
--progressbars \
--mono \
--adjust-line-height \
-c
Expected Behavior
Same behavior as for other fonts, centered chars and glyphs.
Example Symbols or Text
-> import but it happens for a lot of characters and nearly all ligatures.
Font Used
Berkeley Mono v2
Source of Font File
https://usgraphics.com/products/berkeley-mono
Terminal Emulator (and the title of the terminal window)
ghostty, kitty
Operating System and Version
NixOS Unstable
Screenshots
Unpatched font:
Patched font:
Sorry to hear of your problems.
Just from your discription I'd say the problem is how the font constructs the ligatures. Probably not as CALT what is customary. If that is the case there is nothing we can do for the parameters yoy give.
I guess the patched font is ok if you omit --mono? What is the reason for that flag, maybe we can solve that differently.
Also --adjust-line-height, do you have a specific reason to give that? I in fact wanted to remove that option several times already and I search for ppl to give me reason why to keep it.
Sent from Nine
From: ClΓ©ment POIRET @.***> Sent: Monday, 30 December 2024 11:05 To: ryanoasis/nerd-fonts Cc: Subscribed Subject: [ryanoasis/nerd-fonts] Patching Berkeley Mono v2 leads to incorrectly spaced chars (Issue #1772)
Requirements I have searched the issues for my issue and found nothing related or helpful I have searched the FAQ for help I have checked the Wiki for help Experienced Behavior The arrow ligature is offcentered to the left, and the r in the import word is to far to the right. It happens for many characters. Even if the font is behind a paywall, the issue should also happen on the free trial version of Berkeley Mono v2. Expected Behavior Same behavior as for other fonts, centered chars and glyphs. Example Symbols or Text -> import but it happens for a lot of characters and nearly all ligatures. Font Used Berkeley Mono v2 Source of Font File https://usgraphics.com/products/berkeley-mono Terminal Emulator (and the title of the terminal window) ghostty, kitty Operating System and Version NixOS Unstable Screenshots Unpatched font: 2024-12-30-At-10h39m30s.png (view on web) Patched font: 2024-12-30-At-10h37m13s.png (view on web) β Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
Ah, I see this person uses the same additional flags, and you just use -c (complete) for easiness :+1:
I believe in the demo of TX-02 there are no ligs, as this became an add on buy option? [1]
Anyhow, --mono does mess around with the source font in ways that you probably do not need. It forces the whole font to be some specific kind of monosopaced that ALL terminals recognise. When I see the issues that you describe I guess the reason is that the font is forced into being really monospaced.
So you should propably avoid that.
Please try without --mono, which will also leave you with bigger icons - which most (?) people prefer anyhow.
If you must have small (within one monospace cell) icons, that would need a script change (a very simple one), maybe we should add an option for that. If we tried and found it is a solution for you. In retrospect --mono should have been two options maybe from the start because it does two things. Well, usually you want both. π€
The demo font FX-050 (?) has to be obtained via some fake order π [2]
Anyhow. It would be good if you could run the patcher with --debug 2 and post the first lines where the source font analysis is output.
I'm not sure that it works correctly with the docker image, and anyhow it would be good if you either
- enter the docker image into a shell and run there interactively
- or use the FontPatcher.zip without docker on your machine directly with all dependencies installed
In that way I can have a look at the debug output and tweak the font-patcher script to not touch the ligs on patching even with --mono.
[1] https://usgraphics.com/catalog/FX-102 [2] https://usgraphics.com/catalog/FX-050
Oh, the misaligned letter r ... I have no explanation for that. Are more ordinary letters misaligned?
You say you are on NixOS π€ There are issues on Windows that could explain it, but none I'm aware of on Nix π
This looks like a Font Family mixup. Maybe try to install only one font file of all the files and try again.
If that solves it we would need to have a look on the naming. You did not specify any --makegroups, what you need can be decided on the complete output of --debug 2 when you patch all fonts in the family that you plan to install in parallel.
Thanks for your replies. I'm not in front of my computer right now, but I'll come back with debug logs asap. In the meantime, I have some more details:
- As this is a v2, I simply naively tried commands others used to patch Berkeley Mono v1,
- I tried with and without
--monoand--adjust-line-height, same issue, - The
ris not the only char to be moved, I don't know why but it's the most visible one, - it reminds me an issue I had when trying (an earlier version of) MonaSpice, which had similar ligature issues on my side. I didn't patch this one myself,
- patching the TTF files produces correct fonts, only patching the OTF ones are producing those weird misalignments
Hmm, the demo font is kind of useless. It just contains these basic glyphs, and no ligatures or any other stuff.
patching the TTF files produces correct fonts, only patching the OTF ones are producing those weird misalignments
Hmm, is there a specific reason that you prefer the otf variant? The ttf is also an OpenType font, nowadays ;) and it has technically more capabilities. If I have a choice here we usually patch (only) the ttf variants.
Just the basic glyphs
While the otf has the blues defined the ttf seems to be not even autohinted
Just ran into this myself. So far I am unable to find a solution playing around with a whole bunch of options to the patcher docker image. You can see the issue very clearly in the two screenshots of fastfetch, things like the "mor" in my name with the o and r being spaced too far apart and r and m in "arm64" being too close together.
I can confirm patching the ttf font works correctly. Only the otf seems to result in a buggy patched font.
First image is the unpatched (trial) font. Second is patched.
I believe, what destroys the ligs is this
if self.args.single:
# Force width to be equal on all glyphs to ensure the font is considered monospaced on Windows.
# This needs to be done on all characters, as some information seems to be lost from the original font file.
self.set_sourcefont_glyph_widths()
I will just quickly create a new docker image with an option to suppress that. But I think that will not solve the 'r' issue. Maybe one step at a time.
Lets see.
Will open a PR now and merge it, maybe we can discuss if this is a viable solution there.
Wait, what, it is in the trial font? Testing myself.
Wait, what, it is in the trial font? Testing myself.
Yes I am using the trial font (wanted to see if I could patch it before buying it as it isn't cheap!). It is a little annoying you have to "sign up" to get the trial download.
Well, see it. Should be easy to find the reason...
Hmm, the demo font has this defect on purpose π¬ This is not added by the patcher script.
Interestingly can not see that in neither Glyphs3 nor FontGoggles π€
The shifted letters like r seem to be a fontforge bug.
Built HEAD from git, and it is still there. The glyphs are all somehow 'right aligned'-ish, with some it is most obvious, with some it is not so much. See image below.
This does not happen when the ttf is opened, just the otf has that.
Also tried to convert the otf to ttx and back to otf, and it is still the same.
While the individual glyphs in ttx look ok, here the vertical bar (where the code is very easy):
<CharString name="bar">
262 -86 rmoveto
76 872 -76 hlineto
endchar
</CharString>
It has 262 left hand side bearing, is 76 wide and with a an advance width of 600 the right hand side bearing calculates also to 262 (600 - 262 - 76). Strangely this is not how fontforge reads it.
Opened with self-built from HEAD fontforge
Description of 'bar' as decoded by ttx
As opened in Glyphs3
As opened in fontforge
Thanks a lot for your investigations. You're right, I don't particularly need OTF, it was just the default format when downloading the fonts :)
Here are the debug 2 logs when converting one of the OTF files, if this can help you :+1:
logs.txt
EDIT: And happy new year!
The log looks excellent π€ Thanks for sharing.
I would propose to
- Ignore the
otfproblem for now (I fear that is a fontforge bug, and that will take a day or two to find) - Check if the ligature problem can be solved by the new option from the PR
- Let me check if the PR does not change anything unwanted
- And then pull, a new docker image will be crated
- You can check the real font
Is that a good plan?
Happy new year to you also π π, thank you!
$ grep -ve '\(^ *$\)\|^Updating\|^Adding' logs.txt
Running with options:
--mono --debug 2 --careful --makegroups 2 --complete --has-no-italic --no-progressbars
Parallelism 0
Nerd Fonts Patcher v3.3.0 (4.16.2) (ff 20230101)
DEBUG: Naming mode 2
DEBUG: Monospace check: Panose says "monospaced"; glyph-width-mono True
INFO: Font vertical metrics slightly off (0.1%)
DEBUG: Font has negative right side bearing in extended glyphs
DEBUG: Final font cell dimensions 600 w x 1201 h (with icon cell 853 h)
DEBUG: 57/160 box drawing glyphs will be replaced
Done with Patch Sets, generating font...
DEBUG: Weight approximations: OS2/PS/Name: 400/400/400 (from 400/'Book'/'Regular')
DEBUG: =====> Family (ID 1) ok (19 <=31): TX02 Nerd Font Mono
DEBUG: =====> SubFamily (ID 2) ok ( 7 <=31): Regular
DEBUG: =====> Fullname (ID 4) ok (19 <=63): TX02 Nerd Font Mono
DEBUG: =====> PSN (ID 6) ok (11 <=63): TX02NFM-Reg
DEBUG: Tweaking 1/1
DEBUG: Changing flags from 0xB to 0x3
DEBUG: Changing lowestRecPPEM from 8 to 6
TX02 Nerd Font Mono
\===> '/out/TX02NerdFontMono-Regular.otf'
Everything looks good to me! And you are right, ignoring OTF issues seems the way to go :+1:
Please fetch a new docker font-patcher image.
The version tag should be 4.18.0 or later.
https://hub.docker.com/r/nerdfonts/patcher/tags
Then patch with these options:
sudo docker run --rm \
-v /home/clementpoiret/.local/share/fonts/TX-02:/in \
-v /home/clementpoiret/.local/share/fonts/TX02-NerdFont:/out \
nerdfonts/patcher \
--progressbars \
- --mono \
+ --single-width-glyphs \
--adjust-line-height \
-c
I.e. with the new single-width-glyphs that is a softer form of mono: It does not touch existing glyphs.
Maybe together with --careful which will prevent destroying preexisting glyphs by (not) overpatching.
Edit: Well, and of course please use the ttf font, as I did not find time to dive (again :roll_eyes:) into font-forge for the otf problem.
Hello all! I bought into the Berkeley Fonts and noticed 2 things.
- OTF - 2.3 MB per file which includes the ligatures (or at least the ligatures work)
- TTF - 24 kb per file and I don't think ligatures are included
- Nerd Font Patcher works perfectly for TTF more or less (Exports BerkeleyMono Nerd Fonts) each file is about 4.7 MB
- Nerd Font Patcher kinda sorts works with OTF but will only create a single file (multiple font types fail). It's pretty large and includes the ligatures but the weights are completely wrong. So far I have not been able to find any kind args that could fix this (I've tried --careful --adjusted-line-height --complete --single-width-glyph) the letters themselves seem to no longer have the weird offset but ligatures become tiny and/or shifted way to the left and most of it is hidden. I tried this on kitty, ghostty, macos terminal, and gnome terminal.
- Currently kitty loads glyphs from another source while using the OG Berkeley OTF font. But this does not work on different Terminals (ex. VS Code terminal).
If possible could we re-open this issue?
+1 got here noticing the same.
If possible could we re-open this issue?
Sure!
For me the problem is that I can not directly examine the font files. I also considered buying them (I do buy fonts that I like), but that font is rather expensive and no font I would ever use. So I would spend that money just for this issue.
Then, I must admit I have forgotten what was the problem and what has been solved. So if you say 'me too' that can means a lot different things. At least attach images and kind-of fill the issue report (i.e. what OS, what has been done exactly, etc).
Also please give the in-parenthesis version of the patcher script, and possibly the version of fontforge. A screenshot or text capture of the patching is always good. Maybe add --debug 2 to the patcher options.
tried
--careful--adjusted-line-height--complete--single-width-glyph
Explanations of the options are here: https://github.com/ryanoasis/nerd-fonts/wiki/ScriptOptions
Then I think, as this seems rather complex, we should focus on one font (one weight/style) first, e.g. -Regular. Only patch and install that one, test, then - if ok - remove the font, continue on with the next one. That minimizes inter-font-family problems and makes the issues more reproducible.
Well, how to continue? I guess I could write some 'diagnostics scripts' that one of you runs on the fonts and with the results maybe I get an idea what is going wrong. Not sure how effective that is. Or someone 'borrows' the problematic font file to me. I always respect font designers work and will neither use (nor forbid: share) the font, just analyze and try to patch. Afterwards I will give it back (i.e. erase on my machine). My email address is in every commit message.
But maybe we can gleam the reason from seeing the issues. Please provide images, with arrows probably pointing at the problem if it is subtle. Share patching output, run patching with --debug 2. Usually I run fontforge font-patcher --debug 2 --complete SomeFont.otf 2>/dev/null to ignore the fontforge output. Ah, do you run the docker, or direct, etc? Best is to not-use the docker version because there are some problems with forwarding the error messages (or did I fix it?).
Ah, - no image π¬ - but if the ligatures are too small and the rest is ok: Is that the Nerd Font Mono (--mono) variant? Ligatures can be formulated in so many different ways, and the usual 'ideoms' are supported by the patcher. For example Monaspace also had a Ligature problem with patching, but that was in effect a problem in the original font, and I believe they changed the way the ligatures are 'spelled out' in the font files. "Normal" fonts, and what font designers are usually working with, have a straight forward way for ligatures. But that breaks on terminal use, and a way that feels strange (if you never did terminal fonts) must be used (one recent post that turned up on Hacker News: [1]).
Well. Too long already.
Cheers, Fini
[1] https://joshleeb.com/posts/monospace-ligatures.html
Usually I run
fontforge font-patcher --debug 2 --complete SomeFont.otf 2>/dev/nullto ignore the fontforge output.
Ah, obviously I added a new option just for Berkeley, and you need to give --single-width-glyphs instead of --mono; if you target a Nerd Font Mono font variant.
That resonates with but ligatures become tiny and/or shifted way to the left. Hmm. Well, I mostly poke in the dark here, you need to share concrete information with images ;)
- Nerd Font Patcher kinda sorts works with OTF but will only create a single file (multiple font types fail). It's pretty large and includes the ligatures but the weights are completely wrong. So far I have not been able to find any kind args that could fix this (I've tried --careful --adjusted-line-height --complete --single-width-glyph) the letters themselves seem to no longer have the weird offset but ligatures become tiny and/or shifted way to the left and most of it is hidden. I tried this on kitty, ghostty, macos terminal, and gnome terminal.
This is the behavior I noticed as well that led me here. I am not font-savvy at all, but inspected the "SuperType Compiler"-emitted OTF files in FontForge. One thing I noticed is that, in the TrueType metadata (TTF Names), the Styles (SubFamily) field for all OTF files is the same, Regular. My uninformed guess is that FontForge is keying off that value somehow? Metadata (clipped license data at bottom):
However, I also noticed that, in FontForge, the variant I am inspecting ("Bold Oblique") has some very misaligned characters. So it didn't seem worthwhile to edit and re-export to test my theory. Sample (note the C, T, Y characters, in addition to others):
I'm not sure if getting TTF vs OTF variants would be helpful to me in terms of the converter, though I will try it after responding here and see how it goes. I like the ligatures quite a lot, but it sounds like I might either lose them or suffer degraded quality by going from OTF->TTF?
Lastly, @Finii, I am happy to cover the cost of the font license for you to assist in debugging this on your end, if that is something you'd be interested in. I'm way out of my depth here, but I adore this font, and would like to get the extended Nerd Fonts glyphs working with it. :)
Are the fontforge images of the font before or after patching? The name does not have "Nerd Font" in it π€
This is the behavior I noticed as well that led me here. I am not font-savvy at all, but inspected the "SuperType Compiler"-emitted OTF files in FontForge. One thing I noticed is that, in the TrueType metadata (
TTF Names), theStyles (SubFamily)field for all OTF files is the same,Regular. My uninformed guess is that FontForge is keying off that value somehow?
Fontforge is working fine in that regard. If that is post-Nerd-patching ... The patcher script needs to understand the naming of the font to come up with correctly grouped new names that include 'Nerd Font' or 'NF'. Maybe it can not determine the original weight and thus assumes 'Regular'. It would be helpful if you can post the font-patcher output if run with --debug 2 - there will be information on the weight and possible problems with the different places a font has for the weight.
<image>
If that is after patching this is really wrong and should not have happened. But there is something amiss with the naming anyhow, as there is no "Nerd Font" or "NF" in the name? If the renaming is turned off it will/should not touch the names (weights etc) at all. π€
However, I also noticed that, in FontForge, the variant I am inspecting ("Bold Oblique") has some very misaligned characters.
I'm not sure how well font-patcher handles Oblique (and there are bugs handling Slanted). Best would be to look at other fonts first.
I'm not sure if getting TTF vs OTF variants would be helpful to me in terms of the converter, though I will try it after responding here and see how it goes. I like the ligatures quite a lot, but it sounds like I might either lose them or suffer degraded quality by going from OTF->TTF?
Quoting from above:
- The ttf is also an OpenType font, nowadays ;) and it has technically more capabilities. If I have a choice here we usually patch (only) the ttf variants.
- While the otf has the blues defined the ttf seems to be not even autohinted
- OTF - 2.3 MB per file which includes the ligatures (or at least the ligatures work) TTF - 24 kb per file and I don't think ligatures are included
- The shifted letters like r seem to be a fontforge bug. Built HEAD from git, and it is still there.
So it seems we need to patch the otf fonts. The fontforge bug needs to be fixed first, of course. Did fix already some bugs upstream (i.e. at fontforge), but that fix can be difficult or easy, you never know. Hmm, very disappointing.
Lastly, @Finii, I am happy to cover the cost of the font license for you to assist in debugging this on your end, if that is something you'd be interested in. I'm way out of my depth here, but I adore this font, and would like to get the extended Nerd Fonts glyphs working with it. :)
It should be possible to fix it if I get my hands on the real fonts.
Ah, quoting myself from this comment above
Are the fontforge images of the font before or after patching?
This is the output of their "Compiler", i.e. 'original' font.
- Do the Compiler fonts differ from the stand-alone fonts? I have seen problems with 'font customizer' stuff in the past; there are several (!) bugs in opentype JS, and altough I PR'ed fixes the library is still broken (fixes not merged) π
- If I read that correctly it is 75+20 for the font with ligatures?
So, I am happy to cover the cost of the font license for you to assist in debugging this on your end, if that is something you'd be interested in. There are several problems with this font I guess. The displaced characters are also in the example font, so the fontforge bug could be tackled with the example font files. The naming ... there could be a problem in the (my) FontnameParser, esp Oblique and Slanted is not very well supported. To find problems with the names of the original or patched fonts we could use the bin/scripts/name_parser/query_* scripts on your machine.
If the ligature problem goes away with --single-width-glyphs there seems to be no real need for the font files, except that it's of course much easier than 'remote debugging'.
Also interesting if you want a Nerd Font font or a Nerd Font Mono font; noone seems to have that answered above. There is not a good documentation about the variants, but maybe this helps: https://github.com/ryanoasis/nerd-fonts/discussions/1103
Update from my end: spoke to Neil from US Graphics and he advised to go with .ttf. Since switching, everything looks good. @Finii you might want to reach out to Neil and see if you could get a developer license for the font.