Unpatched CommitMono and patched CommitMono looks different
doongjohn opened this issue · 15 comments
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
CommitMono-400-Regular vs CommitMonoNerdFont-Regular looks different.
Unpatched font is little bit thicker than patched font.
Expected Behavior
They should be same.
Example Symbols or Text
Any text.
Font Used
CommitMonoNerdFont-Regular.otf
Source of Font File
https://github.com/ryanoasis/nerd-fonts/releases/download/v3.2.1/CommitMono.zip
Terminal Emulator (and the title of the terminal window)
No response
Operating System and Version
Windows 11
Screenshots
I actually think patched version looks better. 🤔
Strange, the original font does not have hints ("blue zones" as that is a postscript open type font):
The outlines are identical but the hints help to render text at small sizes better.
I assume the difference gets smaller and smaller the bigger the size is?
I believe we do not ever add any hints to truetype opentype fonts (ttf), but I never checked it explicitly; and I never even looked at it for otf fonts. Trying to find something...
Edit: Here blue zones in the patched font but not in the original
Hmm, in fontforge even when one disables generating postscript hints in the "generate" dialog, the created font file does contain Blue values 🙄
This is also true if given in the Python font.generate(..., flags=('no-hints',)) function... 🤔
This is a bug with the CommitMono repo
We fix the problem of the original font automagically when patching 😬
I will try to get the original with blues...
Edit: Add 'when patching'
Please try the original fonts from THIS link:
https://github.com/eigilnikolajsen/commit-mono/tree/main/src/fonts/fontlab
First uninstall the current CommitMono fonts; do not install the font from the link above just "over" existing fonts - the version is the same so Windows will not detect any change and use the cached font file.
BlueValues from the files in the link above (400-Regular)
[-10 0 740 750 700 710 540 550]
BlueValues we deduce and put into the patched font, same same, reconstruction / repair successful 🎉
[-10 0 540 550 700 710 740 750]
(Hmm, normally the BlueValues should be ordered, like we do - no clue if that has any detrimental effect. Can not find any real specs for Postscriptfonts 😬 )
Please do a comparison and report back 😺
This is how the hints of the original-original CommitMono looks like: Blues and Stem definitions 👍
But all is absent in the CommitMono release font files.
Patching creates the smallest set of hints as default Fontforge behavior.
Please try the original fonts from THIS link:
https://github.com/eigilnikolajsen/commit-mono/tree/main/src/fonts/fontlab
Please do a comparison and report back 😺
Unpatched one is still thicker than the patched one.
fontlab one looks different to zip one.
If you see f, i, h, ... it is quite different.
I still think nerd font version is the best looking one. 😮
Screenshots assembled
400% no interpolation (dot for dot)
Hmm, I do not quite understand it.
Anyhow, checked what happens if we patch a 'correct' Postscript font, i.e. one with Blue values. Took the "fontlab" font and patched it. The Blue values are preserved, just a BlueShift is added. With 6 that should make no difference at your font size. [1]
Maybe you can check that font, and produce a screenshot like the ones before. Sorry to bother you with this, but I have no Windows box here; usually I test via RDP or NX on some other machine, but especially hinting is often completely ignored over network protocol.
CommitMonoV143400NerdFont-Regular.otf.zip 2MB
private BlueValues (-10.0, 0.0, 740.0, 750.0, 700.0, 710.0, 540.0, 550.0)
private OtherBlues (-210.0, -200.0)
private FamilyBlues (-10.0, 0.0, 540.0, 550.0, 700.0, 710.0, 740.0, 750.0)
private FamilyOtherBlues (-210.0, -200.0)
private StdHW (55.0,)
private StdVW (60.0,)
private StemSnapH (55.0,)
private StemSnapV (60.0,)
privateState A
CommitMonoV143-400Regular.otf
private BlueValues (-10.0, 0.0, 740.0, 750.0, 700.0, 710.0, 540.0, 550.0)
private OtherBlues (-210.0, -200.0)
private FamilyBlues (-10.0, 0.0, 540.0, 550.0, 700.0, 710.0, 740.0, 750.0)
private FamilyOtherBlues (-210.0, -200.0)
private BlueShift 6.0
private StdHW (55.0,)
private StdVW (60.0,)
private StemSnapH (55.0,)
private StemSnapV (60.0,)
privateState A
CommitMonoV143400NerdFont-Regular.otf
and additionally:
privateState 10000
CommitMono-400-Regular.otf
private BlueValues (-10.0, 0.0, 540.0, 550.0, 700.0, 710.0, 740.0, 750.0)
private OtherBlues (-205.0, -200.0)
private BlueShift 20.0
private StdHW (53.0,)
private StdVW (296.0,)
private StemSnapH (53.0, 70.0, 74.0, 82.0, 88.0, 126.0, 149.0, 172.0, 272.0, 300.0)
private StemSnapV (65.0, 78.0, 296.0, 339.0)
privateState 0
CommitMonoNerdFont-Regular.otf
[1] https://glyphsapp.com/learn/hinting-postscript-autohinting#g-blueshift
Edit: Add link to Glyphs
Fired up Glyphs3 to examine the fonts further...
Note:
- patched and release zip look similar
- fontlab moves glyphs around
- the file sizes!
Screen.Recording.2024-08-29.at.12.15.02.mov
Maybe you can check that font, and produce a screenshot like the ones before. Sorry to bother you with this, but I have no Windows box here; usually I test via RDP or NX on some other machine, but especially hinting is often completely ignored over network protocol.
I think CommitMonoV143400NerdFont-Regular.otf looks same as CommitMonoV143-400-Regular.otf
I still think nerd font version is the best looking one. 😮
After using CommitMonoV143 400 for a bit, I think the "proper" version looks better than the bugged one.
Glad to hear that :-)
I will try to help upstream to get the font file bugs squished out (see eigilnikolajsen/commit-mono#69 further down).
The next NF release will use the 'correct' CommitMono files.
Thank you so much for helping actively!! 💚
@allcontributors please add @doongjohn for bug
I've put up a pull request to add @doongjohn! 🎉