Variable font Noto Sans Telugu is rendering incorrectly if font weight is more than 400
Categories
(Core :: Layout: Text and Fonts, defect)
Tracking
()
People
(Reporter: sriharshachilakapati, Unassigned)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:92.0) Gecko/20100101 Firefox/92.0
Steps to reproduce:
Open Quora Telugu URL https://te.quora.com/%E0%B0%B9%E0%B1%86%E0%B0%AF%E0%B0%BF%E0%B0%B0%E0%B1%8D-%E0%B0%A1%E0%B1%88-%E0%B0%A4%E0%B1%8B-%E0%B0%B5%E0%B0%AF%E0%B0%B8%E0%B1%8D%E0%B0%B8%E0%B1%81%E0%B0%A8%E0%B1%81
Inject the following CSS:
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+Telugu:wght@400&display=swap');
html[lang="te"] .q-text {
font-family: 'Noto Sans Telugu', sans-serif !important;
}
The font is a variable font.
Actual results:
The title has issues with applying the font weight since it has font-weight: bold set. The element is with this text:
హెయిర్ డై తో వయస్సును దాచుకోవడాన్ని మీరు సమర్థిస్తారా? మీరూ డై చేస్తారా? ఎందుకు ?
The character య in the title is being rendered with different weights partially.
Expected results:
The character య in the title should have uniform weight. I can confirm that this is not an issue with Font or CSS, because it is rendering fine in macOS (Firefox, Safari & Chrome) but in Windows 10, only Firefox is having this issue. Chrome renders fine.
Comment 1•4 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
| Reporter | ||
Updated•4 years ago
|
Updated•4 years ago
|
Comment 2•4 years ago
|
||
The Google fonts URL
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+Telugu:wght@400&display=swap');
does not actually load a variable font. It returns a CSS @font-face rule that looks like:
/* telugu */
@font-face {
font-family: 'Noto Sans Telugu';
font-style: normal;
font-weight: 400;
font-stretch: 100%;
font-display: swap;
src: url(https://fonts.gstatic.com/s/notosanstelugu/v9/0FlxVOGZlE2Rrtr-HmgkMWJNjJ5_RyT8o8c7fHkeg-esVC5dzHkHIJQqrEntezbaWkzY2X7n7oQp.woff) format('woff');
unicode-range: U+0951-0952, U+0964-0965, U+0C00-0C7F, U+1CDA, U+200C-200D, U+25CC, U+0000-00FF, U+0131, U+0152-0153, U+02BB-02BC, U+02C6, U+02DA, U+02DC, U+2000-206F, U+2074, U+20AC, U+2122, U+2191, U+2193, U+2212, U+2215, U+FEFF, U+FFFD;
}
which is a single-weight (regular) face, not a variable font; inspecting the .woff resource confirms that it contains no variation tables.
Therefore, when this font is used in the heading with font-weight: bold, the browser may apply a synthetic-bold effect to try and simulate boldness, because the font family in use does not have an actual bold weight.
Firefox does this by using the Windows DirectWrite "bold simulation" effect, but unfortunately this has poor results with some fonts. We've seen a few similar examples before.
If you modify the Google Fonts link to:
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+Telugu:wght@400;700&display=swap');
so as to load the actual bold weight of the font as well as the regular one, this won't occur.
| Reporter | ||
Comment 3•4 years ago
|
||
Thanks! This works good. But what if I explicitly remove the weight?
Setting the URL as
@import url('https://fonts.googleapis.com/css2?family=Noto+Sans+Telugu&display=swap');
is also causing the same issue in Firefox, where as the rendering is fine in Chrome. Is it that Chrome is doing something else? Asking just cause I'm curious. You can close this ticket as it is not relevant anymore.
Comment 4•4 years ago
|
||
Generally I think Chrome uses a different method to do "fake bold", using its embedded copy of FreeType, and this doesn't exhibit the problem that DirectWrite sometimes shows.
Bug 1587094 is an older report of similar bad DirectWrite glyph rendering; closing this as a duplicate.
Description
•