Nunito Character Sizes Inconsistent with Certain "font-size" Values #632
Comments
thomas-j-moffett
changed the title
|
@tmoffett-centrify thanks for reporting this! It looks like ttfautohint (maintained by @lemzwerg) is doing this, and it might be possible to tweak its args to prevent this. Meanwhile @m4rc1e and @felipesanches are planning to re-ttfautohint the whole GF collection, so it would be good to get to the bottom of this :) |
|
This is a bug in FreeType's auto-hinter (and thus in ttfautohint also). Will fix it soon. |
|
Fix now in git. |
Problem reported as google/fonts#632 The font in question (Nunito) has values 705 and 713 for the reference and overshoot values, respectively, of the first blue zone. Blue zone 2, however, has value 710 for both the reference and overshoot. At 12ppem, reference and overshoot of blue zone 0 becomes 8px, while blue zone 2 becomes 9px. A peculiarity of this font is that the tops of isolated vertical stems like `N' have a slight overshoot also. The auto-hinter tries to find the nearest blue zone using the *original* coordinates. For vertical stems, this is value 713. For normal horizontal tops like in character `E', this is value 710. Since value 713 is mapped to 8px but value 710 to 9px, `N' and similar characters are one pixel higher than `E', which looks very bad. This commit sanitizes blue zones to avoid such a behaviour. * src/autofit/aflatin.c (af_latin_sort_blue): New function. (af_latin_metrics_init_blues): Sort blue values and remove overlaps.
|
Thank you!!
…On Feb 13, 2017 3:37 AM, "lemzwerg" ***@***.***> wrote:
Fix now in git.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#632 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAP9y_P1bRDegbPxvMgll2furnU2XCnJks5rcBZagaJpZM4L2sqW>
.
|
|
Cool! Glad to see this addressed so quickly! Thanks! |
|
Haha its still a ways off from a fix; @m4rc1e has to rebuild the fonts, and
make a PR to this repo, and then I have to work with the GF eng team to get
the update pushed all the way... it can take a while.
|
|
Well, with a git version of FreeType you get immediately better results if auto-hinting is activated ('slight hinting') on a GNU/Linux box... |
|
@davelab6 Well, I've seen some projects where issues go on for years not addressed at all, so I was glad to see that you guys jumped on this one quickly and have a resolution. Thanks! |
Problem reported as google/fonts#632 The font in question (Nunito) has values 705 and 713 for the reference and overshoot values, respectively, of the first blue zone. Blue zone 2, however, has value 710 for both the reference and overshoot. At 12ppem, reference and overshoot of blue zone 0 becomes 8px, while blue zone 2 becomes 9px. A peculiarity of this font is that the tops of isolated vertical stems like `N' have a slight overshoot also. The auto-hinter tries to find the nearest blue zone using the *original* coordinates. For vertical stems, this is value 713. For normal horizontal tops like in character `E', this is value 710. Since value 713 is mapped to 8px but value 710 to 9px, `N' and similar characters are one pixel higher than `E', which looks very bad. This commit sanitizes blue zones to avoid such a behaviour. * src/autofit/aflatin.c (af_latin_sort_blue): New function. (af_latin_metrics_init_blues): Sort blue values and remove overlaps. Signed-off-by: mydongistiny <[email protected]>
|
Just adding further info: I have been noticing the same issue with Nunito on our website, with uppercase glyphs in small font sizes in Windows only. On the image below, you can see that the
On the next one,
The results are consistent between different browsers in Windows. Folks using mac over here don't experience the issue. |
|
By default Glyphs generates CFF based webfonts. To avoid this @schriftgestalt recommends adding a Can this be the issue? |
|
No, because GF on boards TTFs not web font formats
…On Nov 23, 2017 9:53 AM, "Alexei Vanyashin" ***@***.***> wrote:
By default Glyphs generates CFF based webfonts. To avoid this
@schriftgestalt <https://github.com/schriftgestalt> recommends adding a Save
as TrueType custom parameter. https://forum.glyphsapp.com/t/
ttfautohint-different-from-project/3186/5
Can this be the issue?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#632 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAP9yw7sXJJZZbTuXfrSXOommBTgVkr-ks5s5aMSgaJpZM4L2sqW>
.
|
|
I am experiencing the exact same issue when using text-transform: uppercase; font-size: 12px; with Nunito on Windows, Chrome. Any update on when an actual fixed Nunito font will be available for download on Google Fonts? |
|
Sadly, the designer of Nunito, Vernon Adams, passed away in 2016 - so unless Google Fonts can fix the font on his behalf, it's unlikely this issue will be resolved. You can read more about Vernon at SansOxygen.com/Donate. He was a talented designer. |
|
Re-generating from GlyphsApp with @ 11-12px the x-height jump is evident
Below is a test with no hinting. The issues is fixed at the expense of poor rendering of other sizes. I need to experiment with custom options like |
|
Exported from Glyphs with no hinting, used ttfa options
I made a testing html here: http://www.cyreal.org/test4/index.html |
|
Accessing http://www.cyreal.org/test4/index.html in Windows 10, Chrome 63.0.3239.132 64-bit, I see no mismatching size artefacts on the font. Looks good! |
|
@nolde thank you for the confirmation. Here is a pre-release with the fixed fonts: https://github.com/alexeiva/NunitoFont/releases/tag/v3.502 |
|
@davelab6 fixed now |
|
@alexeiva Will this fix be applied to the version of Nunito on Google Fonts? As is, the height of uppercase letters on smaller font sizes is still inconsistent: |
|
@m4rc1e is responsible for pushing this out |
|
@alexeiva I'll inspect what you've done. If its fine, we'll make a pr to the official googlefonts Nunito repo. |
|
@alexeiva @ben4d85 I haven't been able to replicate this issue on any of the browsers listed. I wonder if the users raising this issue are using custom rasterization settings? Anyways, if people want to test this themselves, I've uploaded Alexeiva's version against the current hosted GF version. http://www.gf-regression.com/compare/9c0b77a8-eeef-4af1-9700-ecfcf13b9a0d Toggle the before and after button and let me know what you think. |
|
Using the gf-regression link left by @m4rc1e , I can see the following results: FONT BEFORE:
FONT AFTER:
The issue seems to be fixed, no size differences between glyphs. And about the reproducibility, @m4rc1e , it seems to be related to very small font-sizes and Windows, not browsers. It is also affected by the system's DPI settings. |
|
@nolde Interesting thank you very much for checking! This release also has significant improvements over the version currently served. I'll get it pr'd into the upstream then push it here. |
|
<3 it |
|
Thanks a lot for the pull request, @m4rc1e ! Quick question: how long after the merge does it become available through https://fonts.googleapis.com ? |
|
'It depends'. The family usually goes through another round of checks and is then pushed. Could be a week, could be longer. |
|
To confirm, using the gf-regression link left by @m4rc1e , the problem of size difference between glyphs does appear for Fonts Before, but does not appear for Fonts After. So it seems to be fixed! Please update this thread once the new version is available through https://fonts.googleapis.com/ Thanks for your help! Can't wait to use this! |
|
The following screenshot was taken today:
Nunito font coming from https://fonts.googleapis.com is still showing this problem. We are now around two months from the fix; any idea on why it is not deployed yet? Sorry for being annoying, I just want to know if I can drop my workaround for small font sizes or not. =) |
|
Bottlenecks on me; with vacations I don't expect this to ship until August
|
|
@davelab6 - Any hope of this getting shipped soon? :) |
|
@davelab6: Any update on when this will be live? Looking forward to using Nunito in an active project. Thanks! |
|
@davelab6 We really need the fix for this - any update on when we can expect it to be released? |
|
@davelab6 This problem was reported more than a year ago, and now another month has passed without any update or fix. I understand we're all busy here, but if the issue is fixed and it just need to be released, it really shouldn't take this long. Issues like this affect our customers perception of the quality of our products, and it forces us to make less than ideal design choices, in an attempt to avoid those font sizes. That's not a sustainable situation, and if this is the level of support we can expect from Google fonts, then we're better off giving up on it. |
|
@m4rc1e you said,
googlefonts/nunito#12 was the upstream PR which was merged But AFAIK there hasn't yet been a PR to this repo, is that right? |
|
@m4rc1e Any updates on this? google fonts still seems to supply the version with the problem. |
|
What's the current status? |
|
Nunito Sans is the fixed version |
|
Yep, it seems to be for the fonts dashboard. EDIT: Plain Nunito is not fixed. |
|
Same issue with https://fonts.google.com/specimen/Titillium+Web?selection.family=Titillium+Web On macOS 10.6 to 10.14..x it look perfect at defined pt/px font size or any zoomed size. Windows and Linux, the digits are very much noticeably a different height Digits 1, 4, 5, 7 0 next to 4, the 4 is tiny On Linux change the zoom in browser and the difference in digit height is less noticeable, I don't have Windows now to look bit probably is similar observation. |
|
Hello! Just confirming that, after the merge in 21 Nov 2019, I cannot reproduce the issue using the fonts dashboard. Seems finally fixed. |
This is happening for me on Windows 10 on latest Chrome, Firefox and IE 11 (but doesn't seem to be on Microsoft Edge).
I tested the problematic
font-sizethat I was having on the Google fonts page and it produced the same results:(click image for larger size)
The way I tried that was to go to this specimen page, https://fonts.google.com/specimen/Nunito, and select the element (shown in the picture above) and add a
font-size: 0.8571rem;property to the styles (using Chrome). This resulted in a computedfont-size: 11.994px, which is exactly thefont-sizeI was seeing on my site that was having the issue. I noticed that the issue seems to go away (haven't done extensive testing though) when the computed font size is somewhere between 12.5px and 13px and higher.I guess this is mostly an issue with the capital letters, however, I am using all uppercase letters for some buttons and other things on the site I am working on, and it is causing very noticeable differences for letters within the same word.
I wanted to add that I tried this same thing on the Muli font (since I was looking at that as a possibility instead of Nunito), and Muli does not have this issue.
**UPDATE: I investigated this issue a little more and I guess it might not be caused by a fractional computed
font-sizevalue. I triedfont-sizeof 11px and 12px directly and it seemed to be an issue for those cases and just happened that my fractional value fell in that range, but 10px seemed normal and 13px and above as well (didn't try less than 10px).The text was updated successfully, but these errors were encountered: