1828325 - Firefox no longer offers a way to mitigate unwanted space between lines in Japanese OpenType fonts, now that browser.display.normal_lineheight_calc_control was removed

Status: RESOLVED WONTFIX

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

Description

[Yukinoroh[:Yukinoroh]]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0

Steps to reproduce:

I updated Firefox.

Actual results:

Both the UI and the default font is now displayed with one line between each line of text.
For years, browser.display.normal_lineheight_calc_control has been a workaround for bug #68735, but now it just doesn't work. The config seems to be ignored. I understand it was a "not our bug" bug, but still, MATE and all the rest of my OS (LinuxMint) displays it fine.

Expected results:

Has the feature been discarded or what?

Comment 1

[Alice0775 White]

The preference is removed by Bug 1814626

Comment 2

[Yukinoroh[:Yukinoroh]]

I'm trying to find a workaround, but the following code in userChrome.css only fixes the menus.

*{
line-height: 1em !important;
}

P.S.: I talked about bug #68735, but that was a LibreOffice bug, that is still not fixed:
https://bugs.documentfoundation.org/show_bug.cgi?id=68735

By the way, all the commercial opentype Japanese fonts have the same behaviour, and that include Adobe's.
(but also Morisawa's, Fontworks', etc.)

I believe the 1000 heading on these fonts is for them to display correctly when written vertically.

Comment 3

[Daniel Holbert [:dholbert]]

Two requests:

(In reply to Yukinoroh from comment #0)

Both the UI and the default font is now displayed with one line between each line of text.

Could you attach a screenshot to demonstrate? I don't see this locally; it sounds like this requires a particular configuration and/or font setup.

By the way, all the commercial opentype Japanese fonts have the same behaviour, and that include Adobe's.

Just to remove ambiguity/variables for folks who are looking to recreate the issue by matching your setup as precisely as possible: could you clarify which font is the one that's actually being used when triggering this?

Comment 4

[Daniel Holbert [:dholbert]]

We should probably re-title the bug to cover the issue that you're actually encountering and trying to address. Per comment 1, the preference-having-no-effect is expected, since the preference was removed. I'm guessing the bug title would be something like "certain fonts get displayed with unwanted space between lines", or something to that effect?

(In reply to Yukinoroh from comment #2)

I'm trying to find a workaround, but the following code in userChrome.css only fixes the menus.

*{
line-height: 1em !important;
}

Just to clarify, how are you changing the menu-font itself? (Was that via userChrome.css, or via some OS setting, or the Firefox localization, or something else?)

Comment 5

[Yukinoroh[:Yukinoroh]]

Daniel, as I said, all commercial Japanese OpenType fonts have this behaviour. I am using Morisawa's ShinGo, but Adobe's Kozuka Gothic and Kozuka Mincho, which are more common and come with Adobe Products, also.
If I understand well those fonts use the heading value to indicate to the software the space between the bottom of two characters in vertical writing, while other fonts use it to indicate the space between the bottom of the character and the top of the next one.

Attaching screenshot of the current behaviour, from the section 法的保護 of this Wikipedia page, with both css style on and off:

https://ja.wikipedia.org/wiki/%E3%83%95%E3%82%A9%E3%83%B3%E3%83%88

Also attaching screenshots of how it shows in Xed and Thunderbird. This is a more normal way of displaying the text...
(In Thunderbird 102.10.0, there is also a browser.display.normal_lineheight_calc_control, that is, fortunately, still working.)

The menu fonts are set by the OS (Linux), userChrome.css only fixes the heading thing in the menus.
It won't affect the settings page either, and as that page's font is set by the OS but rendered by Firefox, the UI ends up being very ineffective - some of it is even truncated, as shown in font_option.png.

Comment 6

[Yukinoroh[:Yukinoroh]]

Attachment: firefox_stylesheet.png

Comment 7

[Yukinoroh[:Yukinoroh]]

Attachment: firefox_nostylesheet.png

Comment 8

[Yukinoroh[:Yukinoroh]]

Attachment: xed.png

Comment 9

[Yukinoroh[:Yukinoroh]]

Attachment: thunderbird (customized with `browser.display.normal_lineheight_calc_control`)

Comment 10

[Yukinoroh[:Yukinoroh]]

Attachment: font_option.png

Comment 11

[Yukinoroh[:Yukinoroh]]

By the way, Inkscape and GIMP deal with all Japanese fonts smoothly, both in horizontal and vertical writing. LibreOffice and the Mozilla suite don't.

Comment 12

[Yukinoroh[:Yukinoroh]]

P.S.: One little exception for GIMP though, for the very small number of fonts that have vertically-proportional glyphs. So yeah, Inkscape acts as a reference for me.

Comment 13

[Yukinoroh[:Yukinoroh]]

Attachment: inkscape-horizontal.png

Comment 14

[Yukinoroh[:Yukinoroh]]

Attachment: inkscape-vertical.png

Comment 15

[Emilio Cobos Álvarez (:emilio)]

(In reply to Yukinoroh from comment #0)

For years, browser.display.normal_lineheight_calc_control has been a workaround for bug #68735

wrong bug #? That pref was introduced in bug 76097.

Comment 16

[Daniel Holbert [:dholbert]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #15)

wrong bug #?

See comment 2; the reporter was referring to that bug number in a different bug tracker, https://bugs.documentfoundation.org/show_bug.cgi?id=68735. They were saying this pref functioned as a a workaround in Firefox, for Firefox issues similar-to-what's-described-in-that-LibreOffice-bug.

Comment 17

[Daniel Holbert [:dholbert]]

(In reply to Yukinoroh from comment #5)

Attaching screenshot[s]

Thanks for the screenshots & additional info. I'll clarify the bug title here to be more direct about the real issue here, and I'll defer to emilio/jfkthame on what to do with this, since they were involved on bug 1814626 which removed the pref.

Also attaching screenshots of how it shows in Xed and Thunderbird. This is a more normal way of displaying the text...
(In Thunderbird 102.10.0, there is also a browser.display.normal_lineheight_calc_control, that is, fortunately, still working.)

Right, since it's based on the same rendering engine as Firefox 102 ESR, which predates the behavior-change here. The next Thunderbird major-version will presumably be based off of Firefox ESR 115 (that Firefox version being released later this year per https://wiki.mozilla.org/Release_Management/Calendar ), so that Thunderbird version will share whatever the current Firefox behavior is at that point.

It won't affect the settings page either, and as that page's font is set by the OS but rendered by Firefox, the UI ends up being very ineffective - some of it is even truncated, as shown in font_option.png.

Thanks, that's definitely unfortunate -- I spun off bug 1830742 for that specific problem. We should make that preferences UI more graceful, in the face of fonts with tall lines. (regardless of whether or not there are ways to make those fonts render with less-tall lines.)

Comment 18

[Emilio Cobos Álvarez (:emilio)]

301 Jonathan on whether we should somehow hack around known-bad Japanese OTF font metrics (by clamping them or something), but the discussion in https://bugs.documentfoundation.org/show_bug.cgi?id=68735 seems to indicate this is just an issue with the fonts, and those should be fixed.

An off-by-default workaround for this seems like the wrong way to go around this. Plus, that particular pref seemed like the wrong way to hack around font metrics issues. Changing how we compute line-height: normal maybe works for simple cases, but it doesn't change everything else that might depend on the relevant font metrics (like font-metric-dependent CSS units or basically anywhere else where we read font ascent).

I lean towards WONTFIXing this, but I defer to Jonathan and I'm happy to implement any suggested fix if he wants.

Comment 19

[Yukinoroh[:Yukinoroh]]

You guys are talking about line height, but if it's line height what is being computed is actually double the line height (1000 X 2). There's no possible way the font makers crafted a line height that's double the height of the characters, knowing that Japanese characters are always square-shaped, have no actual ascent or descent and are stacked neatly against each other. Well, theorically it would be possible to design a font with strokes that jut out of the ascent/descent values and would thus justify a 1000 value, but to my knowledge that is not being done, for conservative reasons.

Comment 20

[Jonathan Kew [:jfkthame]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #18)

301 Jonathan on whether we should somehow hack around known-bad Japanese OTF font metrics (by clamping them or something), but the discussion in https://bugs.documentfoundation.org/show_bug.cgi?id=68735 seems to indicate this is just an issue with the fonts, and those should be fixed.

Yes, I think https://bugs.documentfoundation.org/show_bug.cgi?id=68735#c2 makes it clear that this is an issue with the metrics in the Adobe Japanese fonts.

(In reply to Yukinoroh from comment #19)

There's no possible way the font makers crafted a line height that's double the height of the characters

The metrics shown in the documentfoundation.org bug:

Adobe Heiti Std		Ascent = 880, Descent = 120, Leading = 1000
Adobe Ming Std		Ascent = 880, Descent = 120, Leading = 1000
Adobe Myungjo Std	Ascent = 880, Descent = 120, Leading = 1000
Adobe Song Std		Ascent = 880, Descent = 120, Leading = 1000
Kozuka Mincho Pr6N	Ascent = 880, Descent = 120, Leading = 1000

do specify exactly this: the ascent + descent equals the height of the em-square (1000 units), and then there's 1000 units of leading between lines. I agree this isn't what the font maker probably wanted, but it's what the font says. So to get it fixed, report the problem to Adobe.

(FWIW, I also see similar spacing if I use Adobe Myungjo Std etc with line-height:normal in Edge or Chrome. It's a font bug, not a browser bug.)

Comment 21

[Yukinoroh[:Yukinoroh]]

"to to get it fixed, report the problem to Adobe."

Again, this is not only true for Adobe fonts but ALL Japanese professional opentype fonts. ALL large Japanese font makers use these values, like Morisawa, Dynafont, Typebank, Iwata, Motoya, and so on. There's definitely something the community does not want to understand on how Japanese fonts are actually processed. This is exactly what is keeping Japanese users out of open source software.

Comment 22

[Yukinoroh[:Yukinoroh]]

To make it clear, ascent and descent values are irrelevant in Japanese. Kana and kanji have no ascent or descent. It's a western writing concept. What matters in Japanese is the space between two bases of characters, in this case, 1000 units. It indicates that the characters should be stacked neatly.

Comment 23

[Jonathan Kew [:jfkthame]]

(In reply to Yukinoroh from comment #22)

To make it clear, ascent and descent values are irrelevant in Japanese. Kana and kanji have no ascent or descent.

They may seem irrelevant to Japanese, but they are relevant to OpenType fonts: the relation between the ascent and descent values provided in the font file will determine how the glyphs are positioned relative to other scripts (such as Latin, but any others as well) when they are mixed within a line.

They also contribute to the default line spacing that is expected to be used for the font, as described in the OpenType specification:

sTypoAscender

The typographic ascender for this font. This field should be combined with the sTypoDescender and sTypoLineGap values to determine default line spacing.

(and similarly for descender and lineGap).

Software that is specifically designed for Japanese might be ignoring some or all of these values in the fonts, and imposing its own idea of what line spacing "should" be. But the OpenType specification makes it clear that the default line spacing should be the combination of ascender, descender, and lineGap, which is what browsers are doing.

I don't have access to a broad range of "professional" Japanese OpenType fonts to compare behaviors and metrics (this issue doesn't seem to appear in widely-available fonts such as Source Han Serif, etc), but if it's affecting users widely, maybe we can implement some kind of hack to work around it (e.g. ignoring the lineGap value completely if it is equal to the em size).

But the real fault remains with the fonts, which are misusing the OpenType format. And even if we hack around this in Firefox, those fonts will still behave just as poorly in other applications that simply implement what the OpenType spec says.

Comment 24

[Yukinoroh[:Yukinoroh]]

I don't think users will want to patch the fonts, because it is not easy. FontForge, for example, in its current version, breaks the vertical metrics when generating OpenType CID fonts. You need to rely on external programs to post-patch them. Not easy.

I've done some testing with userContent.css. A 1.25em line-height is what feels the most comfortable, but there's nothing in the font data that defines that. Yet, enabling that value breaks some website elements, like buttons on the Amazon website, as the get their height from before userContent.css is applied, and as a result the text gets clogged at the top of them.

In the options font selection box, there's a minimum font size option, why not adding a maximum line height option there?
Always best to give users all the control.

Comment 25

[Yukinoroh[:Yukinoroh]]

I don't think Firefox is going to force all major Japanese font vendors to change their standards. Firefox has very minimal market share in Japan. Should I understand it's better to downgrade or go elsewhere? I can't seem to find a workaround only using userContent.css - it breaks the alignment of text in all anchor elements.