Closed Finii closed 4 months ago
To catch too-wide glyphs after patching we have code that checks the patched font (each glyph individually) in the end for monospace-iety. Overlap is allowed/needed for some glyphs - the powerline 'landing platform'.
# Check if the inserted glyph is scaled correctly for monospace
if self.args.single:
(xmin, _, xmax, _) = self.sourceFont[currentSourceFontGlyph].boundingBox()
if int(xmax - xmin) > self.font_dim['width'] * (1 + (overlap or 0)):
logger.warning("Scaled glyph %X wider than one monospace width (%d / %d (overlap %s))",
currentSourceFontGlyph, int(xmax - xmin), self.font_dim['width'], repr(overlap))
Hmm, it just takes the width of the bounding box, which would not detect if the glyph is shifted outside the 'cell', but the code did catch a lot problems in the past even as it is.
Just threw the code on Cascadia Code NF, these glyphs in the codepoint range E000
- FFFF
are unexpectedly wider than the normal advance width 1200:
F159 1202.0
F16A 1202.0
F4F0 1566.0
F4F1 1566.0
F533 1396.0
The move-to-
icons are also from Octicons, and according to the mapping file the original codepoint is
...
F2C1 F4EE moon
F2C2 F4EF move-to-bottom
F2C3 F4F0 move-to-end
F2C4 F4F1 move-to-start
F2C5 F4F2 move-to-top
F2C6 F4F3 multi-select
...
is in this scale group:
OCTI_SCALE_LIST
f2c2 - f2c5 # move to
Octicons has no codepoint stability guarantee. To be able to upgrade Octicons we introduce a remapping that keeps old icons at their old codepoints and possibly moves new glyphs around to fill in dropped codepoints and/or fill other gaps.
The octicons.ttf
in the Nerd Fonts repo is a manipulated font and not the upstream version.
See
Edit: Add side note
Thanks for the thorough review @Finii! I am going to spend some time going through these. I suspect most of the errors are of omission where I missed some glyphs that needed adjustment, or chose the wrong one as the reference scaling glyph for the scale groups :|.
Caskaydia on the other hand does a not so nice job on F246 (circled pink). It fills the whole 'cell' like a powerline glyph; that is not very nice. Note to self: Check if we can do something about that.
One thing I wanted to mention for your reference right away is a fix for the glyphs in Caskaydia that are too tall. To solve that, I implemented this code:
if (FONTWIDTH-SIDEBEARING)/width < FONTHEIGHT/height:
xAdjustment = (FONTWIDTH-(2*SIDEBEARING))/width
else:
xAdjustment = FONTHEIGHT/height
yAdjustment = xAdjustment
Essentially it is a catch for glyphs that, when maximized horizontally, end up massively tall. So I see which of the scale factors is the smallest: the vertical scale (scale to baseline to capHeight height, or 1420 in the case of Cascadia) or the horizontal scale (to advancedWidth or 1200 in the case of Cascadia). Then I use that as the overall scale factor for the glyph. You'll also note I also have SIDEBEARING
which allows me to control if the glyph is fully maximized, or a small gap is left on either side (I chose 20 funits).
Alright! Here's an updated file for you to consider :) CascadiaCodeNF.ttf.zip
bookmarkslash too big
Fixed. The python range
command doesn't include the final number in the range, so I have to manually increment it. Seems I missed that one! Also, it looks like my merge script was having some issues with similarly named glyphs, causing some to be missed, which I’ve sorted out.
gender circle too big
Same as above
Moon phases
Added some special casing for the moon phases to ensure that they stay in alignment through the cycle.
more weather icons
I added some more special casing to center the various scale groups a bit better, while preventing the thermometers from getting out of alignment
PL glyphs
Since we already have Cascadia PL as it is, with its wonkiness, I’m less driven to make a change at this (late) hour, but when I do the re-master version of Cascadia I’ll be replacing all of the PL glyphs with ones produced via the same script as the NF versions, so everything will be better in alignment.
Also, there’s some complexity in the positioning of the tip of the triangle due to the multiple different metrics options present in Cascadia currently. Again, this will be solved in the next version (no more sTypo).
won / youtube
Must be some weird rounding bug. I’ve added a special transform just for them.
move-to
I picked the wrong reference glyph for these symbols. Fixed that, which has resolved the oversizing.
octicon codepoints
That’s fine. I’m likely going to be following whatever you modify the codepoints to be. :)
Thanks for the possibility to have a look at the newest CascadiaNF iteration :+1: That also makes me look more hard on the Nerd Fonts patch, improving it.
Since we already have Cascadia PL as it is, with its wonkiness
I fully understand the problems, just wanted to point out differences and possibly improvements. The next NF release will get some new Powerline glyphs btw, requests years old that were approved and merged but never released :grimacing:
Must be some weird rounding bug.
We also had strange rounding errors that I could not really comprehend. At some point I changed the algorithm to first really insert the glyph (unscaled/unshifted) into the to-be-patched font and scale it afterwards - all rounding issues gone. Before we scaled on insertion.
should be a scale group probably. Now the small arrows are just heavier normal arrows :thinking: Otoh, I almost already hear the complaints: Where are the heavy arrows that I love so much, they are now very small :grimacing:
I got much more rigorious with font-logos, but Nerd Fonts' own glyphs are still borderline For example NF own glyph
"seti-livescript": {
"char": "",
"code": "e671"
},
Possibly related:
I found some issues while processing the outlines (these are cases of poorly-made TTFs) that I’ve corrected in the UFOs:
- font-awesome-extension (cc-by, soup)
- materialDesignIconsDesktop (lightbulb-group-off-outline,lightbulb-multiple-off-outline)
- font-logos(Tux) :astonished:
- octicons(smiley)
It would be good to fix these in the binaries too, but I guess the upstream maintainers would need to do it.
Nerd Fonts copies the glyph name of the original set to the patched in glyph, while Cascadia NF uses the standard uniXXXX
.
Interestingly sometimes the original set's name is ridiculous (and we copy that) instead to use the correct name, that we have in the database https://github.com/ryanoasis/nerd-fonts/blob/master/glyphnames.json
I wonder where the names in the database come from. I should know because I invented it :sob: I remember some icon sets got scraper scripts that collect the names from somewhere.
"fa-slack": {
"char": "",
"code": "f198"
},
In the weather set, I modified the longest wind speed glyphs (10, 11, 12) to be the same width as 7. It is a minor shift to the design, but allows all of the wind speed icons to be a bit bigger.
This comment waits now already some days to be finished, but I just can not find time. Maybe better to just fire this off unfinished and add more later.
to be continued,
Fini
On the glyph names item – the merge script I use for the current version of Cascadia is several years old, kind of dumb, and particular about names. So I have to make sure that there are no duplicated names anywhere, or it will fail to import the glyph. The easiest way I could come up with to resolve the issue was to just rename the glyph based on the unicode value. Names don't really matter, so I wasn't too concerned.
The newer build script I'm going to put together will have error catching so if there's duplicate names it'll just import anyway. Then I can leave them as is :). Or parse the JSON that you have to give it the "proper" name.
Just ran the font though VTT, because I noticed a lot glyphs in Nerd Fonts are not clock-wise oriented and I wondered if I should fix it. But also your original glyphs have the same 'problem', so I guess that is not worth the work.
and then ... why is E0D3
so tall? :thinking:
Ah, looks like some kind of placeholder-leftover.
Edit: Typo
Hm. I thought I'd oriented everything in Cascadia the right way. Will have to look into that.
As for NF, though, it appears that FontParts has a function to correct winding direction glyph.correctDirection()
. And FontForge seems to have a similar function: https://fontforge.org/docs/scripting/scripting-alpha.html#CorrectDirection
Might be easy to integrate into the NF merge script?
The situation is as bad as suspected... I checked all glyph sources:
glyph font | number of glyphs | open contour | self intersecting | reverse direction | after fixing, still reverse direction |
---|---|---|---|---|---|
codicon.ttf | 389 | 0 | 41 | 234 | 1 |
devicons.ttf | 201 | 0 | 160 | 34 | 0 |
font-awesome-extension.ttf | 172 | 0 | 17 | 147 | 0 |
FontAwesome.otf | 705 | 0 | 91 | 18 | 0 |
font-logos.ttf | 119 | 0 | 28 | 0 | 0 |
materialdesignicons-webfont.ttf | 2119 | 0 | 52 | 1004 | 0 |
MaterialDesignIconsDesktop_orig.ttf | 6934 | 0 | 443 | 4210 | 2 |
MaterialDesignIconsDesktop.ttf | 6936 | 0 | 443 | 4210 | 2 |
octicons.ttf | 314 | 0 | 18 | 0 | 0 |
original-source.otf | 189 | 0 | 27 | 6 | 1 |
Pomicons.otf | 16 | 0 | 1 | 0 | 0 |
PowerlineExtraSymbols.otf | 74 | 0 | 5 | 6 | 0 |
PowerlineSymbols.otf | 9 | 0 | 0 | 0 | 0 |
Unicode_IEC_symbol_font.otf | 5 | 0 | 1 | 4 | 0 |
weathericons-regular-webfont.ttf | 247 | 0 | 0 | 131 | 0 |
After automatic correction some self-intersections are cured and some are inflicted... it seems; but that being fontforge
I believe that only after generating the fixed font and reopening it again.
Hmm, here the one glyph that can not be auto-fixed in original-source
:
There is some mess that needs to be removed probably.
Codicons ... zero with opening (maybe check & report upstream):
Material Design... zero width 'exaust fumes thing'?
I remember you also reported some broken glyphs, I need to find that information again, I had not checked yet.
Might be easy to integrate into the NF merge script?
Very easy, I will try some test-patches with the Nerd Font patcher with auto-correction. Ans I also wanted to check how the source-fonts are, if they all are good.
upstream fixed it by replacing completely
Should we update?
One more similar looking glyph is affected, while the other two similar books do not have this?!
Is still present, reported as bug upstream as (not backlinking link): https://www.github.com/Templarian/MaterialDesign/issues/7401
Also found your report on glyph problems:
font-awesome-extension (cc-by, soup)
materialDesignIconsDesktop (lightbulb-group-off-outline,lightbulb-multiple-off-outline)
font-logos(Tux)
octicons(smiley)
Ah, I see...
Will be fixed with (no-backlink-link) https://www.github.com/lukas-w/font-logos/pull/127 There are two more glyphs with ridiculous number of points that will be changed.
Already fixed with this PR: https://www.github.com/ryanoasis/nerd-fonts/pull/1542
Also fixed livescript and R https://www.github.com/ryanoasis/nerd-fonts/pull/1543
Is worse than shown above:
I tested some and I will put the direction correction into the nerd fonts patcher.
Having self-intersecting glyphs or glyphs with wrong direction seems to be not too uncommon though, here an overview of all Regular
fonts in Nerd Fonts (before patching):
file | #glyphs | open | self | dir |
---|---|---|---|---|
0xProto-Regular.ttf |
845 | 0 | 0 | 0 |
3270-Regular.ttf |
2226 | 0 | 0 | 0 |
Agave-Regular.ttf |
2487 | 0 | 22 | 19 |
Anonymous Pro.ttf |
623 | 0 | 0 | 0 |
Arimo-Regular.ttf |
3306 | 0 | 3 | 0 |
AurulentSansMono-Regular.otf |
267 | 0 | 0 | 0 |
BigBlue_TerminalPlus.ttf |
781 | 0 | 146 | 0 |
VeraMono.ttf |
269 | 0 | 0 | 0 |
CascadiaCode-Regular-vtt.ttf |
3199 | 0 | 2 | 0 |
CascadiaMono-Regular-vtt.ttf |
3199 | 0 | 2 | 0 |
Code New Roman-Regular.otf |
2738 | 0 | 0 | 0 |
ComicShannsMono-Regular.otf |
619 | 0 | 14 | 0 |
CommitMono-400-Regular.otf |
1924 | 0 | 3 | 0 |
Cousine-Regular.ttf |
2391 | 0 | 0 | 0 |
D2Coding-Ver1.3.2-20180524-ligature.ttf |
26559 | 0 | 82 | 8 |
DaddyTimeMono.otf |
918 | 0 | 0 | 0 |
DejaVuSansMono.ttf |
3392 | 0 | 9 | 0 |
Droid Sans Mono for Powerline.otf |
907 | 0 | 1 | 0 |
Envy Code R.ttf |
648 | 0 | 13 | 16 |
FantasqueSansMono-Regular.ttf |
1046 | 0 | 0 | 0 |
FiraCode-Regular.ttf |
2030 | 0 | 1 | 79 |
FiraMono-Regular.otf |
1485 | 0 | 0 | 0 |
GeistMono-Regular.otf |
694 | 0 | 0 | 15 |
gohufont-uni-14.ttf |
841 | 0 | 582 | 0 |
Go-Mono.ttf |
711 | 0 | 1 | 1 |
Hack-Regular.ttf |
1572 | 0 | 3 | 0 |
Hasklig-Regular.otf |
1611 | 0 | 2 | 0 |
heavy_data.ttf |
252 | 0 | 0 | 0 |
Hermit-Regular.otf |
393 | 0 | 0 | 0 |
iAWriterMonoS-Regular.ttf |
850 | 0 | 1 | 0 |
IBMPlexMono-Regular.ttf |
1032 | 0 | 2 | 0 |
Inconsolata-Regular.ttf |
963 | 0 | 2 | 18 |
InconsolataGo-Regular.ttf |
306 | 0 | 0 | 0 |
Inconsolata-LGC.ttf |
885 | 0 | 3 | 0 |
iosevka-regular.ttf |
30414 | 0 | 59 | 0 |
iosevka-term-regular.ttf |
30414 | 0 | 59 | 0 |
iosevka-term-slab-regular.ttf |
29667 | 0 | 71 | 0 |
JetBrainsMono-Regular.ttf |
1743 | 0 | 3 | 0 |
Lekton-Regular.ttf |
953 | 0 | 4 | 0 |
LiberationMono-Regular.ttf |
2423 | 0 | 0 | 2 |
Lilex-Regular.ttf |
1230 | 0 | 2 | 0 |
MartianMono-Regular.ttf |
557 | 0 | 0 | 1 |
Meslo LG M Regular for Powerline.ttf |
2714 | 0 | 7 | 2 |
MonaspaceNeon-Regular.otf |
782 | 0 | 0 | 95 |
Monofur for Powerline.ttf |
690 | 0 | 11 | 0 |
Monoid-Regular.ttf |
785 | 0 | 0 | 0 |
mononoki-Regular.ttf |
932 | 0 | 2 | 2 |
Mplus1Code-Regular.ttf |
6582 | 0 | 206 | 65 |
NotoMono-Regular.ttf |
896 | 0 | 0 | 0 |
NotoSansMono-Regular.ttf |
3919 | 0 | 3 | 0 |
OpenDyslexic-Regular.otf |
748 | 0 | 1 | 541 |
overpass-mono-regular.otf |
987 | 0 | 0 | 1 |
ProFontIIx.ttf |
270 | 0 | 2 | 0 |
ProggyClean.ttf |
256 | 0 | 173 | 0 |
RobotoMono-Regular.ttf |
1003 | 0 | 29 | 601 |
ShareTechMono-Regular.ttf |
267 | 0 | 0 | 0 |
SourceCodePro-Regular.ttf |
1568 | 0 | 2 | 0 |
SpaceMono-Regular.ttf |
732 | 0 | 0 | 10 |
TerminusTTF-4.49.2.ttf |
1358 | 0 | 2 | 0 |
Tinos-Regular.ttf |
2583 | 0 | 0 | 0 |
Ubuntu-R.ttf |
1266 | 0 | 0 | 0 |
UbuntuMono-R.ttf |
1298 | 0 | 0 | 0 |
VictorMono-Regular.ttf |
1331 | 0 | 12 | 0 |
Some self-intersecting glyhs reported here have touching points, like this (left side):
Cascadia Code shown, interestingly the 'opposite' quadrant looks different
Found another problematic glyph which is identified as has-an-open-path :unamused:
$ fontforge bin/scripts/name_parser/check_glyphs patched-fonts/NerdFontsSymbolsOnly/SymbolsNerdFont-Regular.ttf 2>/dev/null | grep open
...
E7B6 0008008B open direction uniE6B6
:grimacing: Looks innocent
Ah...
I will fix that in the source at Nerd Fonts, and report upstream if possible. Well, I need to examine further first, but I need to send this off as my family is waiting with dinner.
Thanks for investigating all of this @Finii. I'm thinking that the current state of the Cascadia NF version is good enough to merge for now, and I'll do a review of everything in a couple months (probably around June/July?) to make any necessary updates to clean up the NF glyph set when I'm getting Cascadia Next pulled together.
Thanks for inviting me to have a look!
Btw, I tried to mass-correct the path directions which works in some cases while in others it seems to make the glyph even worse with self intersections etc. Will abandon that for now, more important would be to substitute fontforge for something more modern.
Yeah… I think that fixing all of that will require an involved overhaul of all the source files. I might be able to assist with that later this year if I don’t have more large projects come up!
On examining the result of the NF2 branch preview there seem to be some issues. I feel it easier to report them as a Github Issue as pictures can be included and so on.
Thanks to @aaronbell for the possibility to see the progress and comment on it.
This is a unsorted list of things I found while reviewing the
CascadiaCodeNF.ttf
file. These are almost all not bugs. Just my thoughts.bookmarkslash too big
The icon is wider than one advance width and therefore this is not really the 'monospaced' variant. Codepoint is
F533
, original codepoint isF306
.That is in the scale group:
Lets have a look at the other 3:
Ah,
F07B
is still missing:and the filled pair seems to be good:
So maybe this is because
F07B
is still missing, or some other reason.gender circle too big
Codepoint
F22D
. It should be in a scale group (if you use the same scale groups):After seeing this and the other issue above... Maybe the last icon in a scale group is always not included in the group? Just a hunch. But then the hand-symbols (see above, between the hourglasses and
TM
(F255
-F25B
) are all nicely matching, including the last one :thinking:Caskaydia on the other hand does a not so nice job on
F246
(circled pink). It fills the whole 'cell' like a powerline glyph; that is not very nice. Note to self: Check if we can do something about that.More examples where Cascadia shines and Caskaydia needs to hide ;)
Scale group synchronized shift (and not only scale)
The moon phases, patched codepoints
E38D
-E3A8
do not keep the center of the moon in the center. This can of course also be a design choice (I believe both have advantages and drawbacks).Here how they look like if people switch from one to another:
More on weather icons
This can all be design choices, but wanted to point out:
clouds sit on the baseline instead being centered
wind directions are centered
turning wind and other arrows are top-aligned (?!)
Thermometer scaled ridiculously big in Caskaydia, see comment already above. But that is a really hard problem when you do not know the metrics of the target font. There are some strange designs out there...
Chess pieces have a sane scale in Cascadia, but then iirc, I tried to make them smaller and then some people complained that they have a chess program and the pieces are now so small one can hardly see them, give us the bigger chess pieces back. Every change breaks someone's workflow :grimacing: But in principle I envy Cascadia here.
Bricks lost aspect ratio
It is hard(er) to recognize the click bricks (to not-mention the company that starts with L and end in EGO).
Powerline symbols
I know this is maybe too late as we already have Cascadia Code PL and changing this (if wanted at all) can break the experience for users who already use them)...
Usually "I like" to have the center of the 'cell' and with it the tip of the triangular powerline glyphs to be the middle of the ordinary capitals which usually is also the middle of square brackets etc and the same height as 'minus' and so on. At least roughly. This is not the case for Caskadia: