Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enlarged glphys in FiraCode Mono #1229

Closed
3 tasks done
thpani opened this issue May 11, 2023 · 5 comments · Fixed by #1232
Closed
3 tasks done

Enlarged glphys in FiraCode Mono #1229

thpani opened this issue May 11, 2023 · 5 comments · Fixed by #1232

Comments

@thpani
Copy link

thpani commented May 11, 2023

🗹 Requirements

  • I have searched the issues for my issue and found nothing related and/or helpful
  • I have searched the FAQ for help
  • I have searched the Wiki for help

🎯 Subject of the issue

Experienced behavior:
After the v3.0.0 release, the Mono variant of FiraCode contains enlarged glyphs at codepoints U+276C to U+276F, compared to non-Mono variant and parent FiraCode 6.2.

Expected behavior:
Equal glyphs in all 3 fonts, as before v3.0.0

Example symbols:
U+276C to U+276F: ❬❭❮❯

🔧 Your Setup

  • Which font are you using (e.g. Anonymice Powerline Nerd Font Complete.ttf)?
    • FiraCodeNerdFontMono-Regular.ttf
  • Where did you get the file from (download link, self patched, source downloaded from link...)
    • Homebrew font-fira-code-nerd-font: 3.0.0
  • Which terminal emulator are you using (e.g. iterm2, urxvt, gnome, konsole)?
    • kitty, macOS Terminal, also occurs in macOS TextEdit
  • Are you using OS X, Linux or Windows? And which specific version or distribution?
    • macOS Ventura 13.3.1

★ Screenshots (Optional)

Screenshot 2023-05-11 at 11 29 00
@Finii
Copy link
Collaborator

Finii commented May 11, 2023

Fira Code 6.2 does not contain 276C - 276F (but just 2770 and 2771):

image

The glyphs you see there are inplace replacements via fontconfig.

They are patched in with these settings

{
   'Enabled': True,                                
   'Name': "Heavy Angle Brackets",         
   'Filename': "extraglyphs.sfd",                                     
   'Exact': True,       
   'SymStart': 0x276C,      
   'SymEnd': 0x2771,      
   'SrcStart': None,        
   'ScaleRules': None,                  
   'Attributes': SYM_ATTR_HEAVYBRACKETS       
}

SYM_ATTR_HEAVYBRACKETS = {
    'default': {'align': 'c', 'valign': 'c', 'stretch': 'pa', 'params': {'careful': True}}
}

probably we should add some padding? 🤔
Otoh, these glyphs are different to ordinary glyphs, they should somehow always be scaled also in Nerd Font (i.e. just setting the padding will not help there).

Thanks for reporting! Need to think a bit about the solution.

@Finii Finii added this to the v3.0.1 milestone May 11, 2023
@Finii
Copy link
Collaborator

Finii commented May 11, 2023

You see this only with v3.0.0 because previously Nerd Font did not patch in these glyphs, so you had fontfallback to the same font as with your original Fira Code. But there are a lot (?) people out there who do not have any font with the heavy brackets installed, that's the reason they are now added.

You can find out who supplies them with

$ fc-list ':charset=276c'

On my system it is mainly DejaVu:

$ fc-list :charset=276c -f '%{file}\n' | grep -v Nerd | grep '^/usr'
/usr/share/fonts/truetype/dejavu/DejaVuSans-BoldOblique.ttf
/usr/share/fonts/type1/urw-base35/D050000L.t1
/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-Bold.ttf
/usr/share/fonts/truetype/freefont/FreeSerif.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-BoldOblique.ttf
/usr/share/fonts/X11/Type1/D050000L.pfb
/usr/share/fonts/truetype/dejavu/DejaVuSans.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansMono-Bold.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansMono.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed-Oblique.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSansCondensed.ttf
/usr/share/fonts/truetype/dejavu/DejaVuSans-Oblique.ttf

@Finii
Copy link
Collaborator

Finii commented May 11, 2023

They are even scaled differently, because one is width limited and the other height limited 😒

image

Creating some PR.

@Finii
Copy link
Collaborator

Finii commented May 11, 2023

Hmm, notes for PR preparation:

image

Height of The Three Stooges is

1495, 1495, 1682, cell height in Hack 2408.

That calculates to a padding of 15% top and bottom. Sounds reasonable.

Maybe putting in old-style ScaleGlyph group to keep the scaling identical but individually centered. The un-centeredness really bothers me... What the heck Hack?!

Finii added a commit that referenced this issue May 11, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want.

Pad the brackets with 30% (15% top and 15% bottom).

This has only effect in Nerd Font Mono fonts.

Fixes: #1229

Signed-off-by: Fini Jastrow <[email protected]>
Finii added a commit that referenced this issue May 12, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want.

Pad the brackets with 30% (15% top and 15% bottom).

This has only effect in Nerd Font Mono fonts.

Fixes: #1229

Signed-off-by: Fini Jastrow <[email protected]>
Finii added a commit that referenced this issue May 12, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want.

Pad the brackets with 30% (15% top and 15% bottom).

This has only effect in Nerd Font Mono fonts.

Fixes: #1229

Signed-off-by: Fini Jastrow <[email protected]>
Finii added a commit that referenced this issue May 12, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

With some proportional fonts the brackets look tiny.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want (and it distorts)).

Pad the brackets with 30% (15% top and 15% bottom).

This is used for all fonts (monospaced or not) so that the new glyphs
fit nicely with the existing ones. For some definitions of 'nicely', but
that is as good as we can get with automatism. It's not worse than
font-fallback.

Fixes: #1229

Signed-off-by: Fini Jastrow <[email protected]>
Finii added a commit that referenced this issue May 12, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

With some proportional fonts the brackets look tiny.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want (and it distorts)).

Pad the brackets with 30% (15% top and 15% bottom).

This is used for all fonts (monospaced or not) so that the new glyphs
fit nicely with the existing ones. For some definitions of 'nicely', but
that is as good as we can get with automatism. It's not worse than
font-fallback.

Fixes: #1229

Signed-off-by: Fini Jastrow <[email protected]>
@Finii Finii reopened this May 12, 2023
@Finii Finii removed this from the v3.0.1 milestone May 12, 2023
@Finii Finii closed this as completed May 12, 2023
Copy link
Contributor

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.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 13, 2023
LNKLEO pushed a commit to LNKLEO/Nerd that referenced this issue Nov 24, 2023
[why]
The added heavy brackets are maximized within the cell size as all
normal other symbols. But in fact they should not be maximized but
rather be the size of 'normal brackets'.

Furthermore they are all scaled individually, making the size
differences less.

With some proportional fonts the brackets look tiny.

[how]
Introduce new y-padding parameter (because a negative overlap also acts
in x direction, what we do not want (and it distorts)).

Pad the brackets with 30% (15% top and 15% bottom).

This is used for all fonts (monospaced or not) so that the new glyphs
fit nicely with the existing ones. For some definitions of 'nicely', but
that is as good as we can get with automatism. It's not worse than
font-fallback.

Fixes: ryanoasis#1229

Signed-off-by: Fini Jastrow <[email protected]>
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants