Closed Bug 1732251 Opened 4 years ago Closed 4 years ago

Variable font Noto Sans Telugu is rendering incorrectly if font weight is more than 400

Categories

(Core :: Layout: Text and Fonts, defect)

Firefox 92
x86_64
Windows 10
defect

Tracking

()

RESOLVED DUPLICATE of bug 1587094

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.

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.

Component: Untriaged → CSS Parsing and Computation
Product: Firefox → Core
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64
Component: CSS Parsing and Computation → Layout: Text and Fonts

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.

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.

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.

Status: UNCONFIRMED → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: