1307678 - Title of latest recommendation of language.chinadaily.com.cn is cut

Status: NEW

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

Description

[Eric Tsai (no more review request accepted)]

Attachment: Comparision of Firefox and Chrome

According to https://webcompat.com/issues/2974

Step to reproduce:
1. Visit http://language.chinadaily.com.cn/
2. See title of "lastest recommendation" column on the right (please refer to the attachment)
3. The title is cut in Firefox 50, Mac OS X, but not in Chrome.

heycam guess this issue is related to (a) firefox choosing a different fallback font for chinese than safari and chrome do, and (b) something funny about line layout when we have a fallback font

Karl's comment in the other issue https://webcompat.com/issues/2975 guess it's similar with this bug.

Comment 1

[Eric Tsai (no more review request accepted)]

Hi jfkthame, heycam said you could say whether our choice of fallback font on macOS is correct / desirable, could you have time for this?

Comment 2

[Cameron McCormack (:heycam)]

Attachment: reduced test

Here's a reduced test for the issue.  The specific fonts involved probably make this problem evident only on macOS.

Comment 3

[Cameron McCormack (:heycam)]

Attachment: reduced test

Comment 4

[Jonathan Kew [:jfkthame]]

One thing I notice is that http://language.chinadaily.com.cn/ doesn't seem to have a lang attribute (e.g. on the root element), so it looks like the Chinese text is actually getting a default Japanese font. Adding lang="zh-CN" should cause it to use our Chinese font prefs rather than Japanese during fallback, which seems like it's probably more appropriate for the site. (Though the result with no lang attribute present may also depend on the OS locale, I think...)

That won't solve the clipping problem, though; or at least it doesn't solve it for me on OS X 10.10.

In general, it's unwise to specify a line-height that is equal to the font-size, as is done here; text often requires a bit more vertical space than the nominal font size if it's to be comfortably read.

The actual clipping in this case occurs, I suspect, because of the presence of Helvetica in some of the font prefs; the Mac's Helvetica has unusually tight vertical metrics, and when this ends up being the font we use as a basis for the baseline position (the content called for font-family:"微软雅黑", but that's a Windows font not present on the Mac, so we hit a fallback path...) we get an ascent that isn't quite sufficient for a lot of the Asian fonts.

It might be worth specifying Arial instead of Helvetica as the default sans-serif font in the Chinese prefs, I suspect; it tends to have vertical metrics that work better together with other fallbacks.

Comment 5

[Cameron McCormack (:heycam)]

Thanks, Jonathan.  Interestingly, Chrome is selecting a Chinese fallback font (Songti TC).  I wonder what heuristics it's using for that.

Can you explain how it is that Helvetica influences the baseline position?  It does seem strange to me that when you have text whose glyphs come entirely from this one fallback font, that some other fallback font in the prefs is what decides how the line is positioned.  (Maybe it is that the decision needs to be made before we've selected the fonts to use for all the glyphs?)

I tried twiddling various font.name* prefs to change Helvetica to Arial but didn't manage to avoid the clipping.  What specific prefs would need to change?

Comment 6

[Jonathan Kew [:jfkthame]]

(In reply to Cameron McCormack (:heycam) from comment #5)
> Thanks, Jonathan.  Interestingly, Chrome is selecting a Chinese fallback
> font (Songti TC).  I wonder what heuristics it's using for that.

I wonder if it's simply a question of picking Chinese before Japanese for untagged CJK text? (What would Chrome pick for a Japanese page that lacks any lang tag?)

It's also possible they're doing smarter things such as doing language-recognition heuristics on the actual content -- in most cases, given more than a few characters of CJK, it's usually possible to infer whether the content is actually Chinese or Japanese. Or in the absence of lang tags, they could do things like "if it's a .cn domain, it's more likely Chinese, whereas .jp is likely Japanese", etc, to pick a default.

> 
> Can you explain how it is that Helvetica influences the baseline position? 
> It does seem strange to me that when you have text whose glyphs come
> entirely from this one fallback font, that some other fallback font in the
> prefs is what decides how the line is positioned.  (Maybe it is that the
> decision needs to be made before we've selected the fonts to use for all the
> glyphs?)

I think there's an issue whereby the metrics of the first available font in the list (whether or not it ends up being used for the actual characters present) will provide line metrics. And in this case, the *only* font explicitly listed is one that's not present; but we append a default font internally so as to have -something- available.

> 
> I tried twiddling various font.name* prefs to change Helvetica to Arial but
> didn't manage to avoid the clipping.  What specific prefs would need to
> change?

Hmm, actually, changing those only becomes useful after you add the proper lang attribute to the document: if I add lang="zh-CN" to the root element, then changing Helvetica to Arial in font.name.sans-serif.zh-CN seems to fix the clipping.

With no lang attribute, however, the default we append to the font list (which then provides line metrics) is probably font.name.serif.x-western, assuming an en-US browser with default settings. So in that case, what may help is to change font.name.serif.x-western from Times to Times New Roman (which has a similar effect on metrics to the Helvetica/Arial change for sans-serif fonts).

I'm not sure whether that would be a good idea in general, but it seems to "fix" this particular example. I do think the site should add a lang attribute, though; and once they do that, the relevant font pref to consider will be a Chinese one rather than a Western one.

Comment 7

[Xidorn Quan [:xidorn] UTC+10]

I guess we can at least do some smarter things like choosing default fallback according to ccTLD? Also do we currently do fallback according to user's language preference?

Comment 8

[Firefox Bug Husbandry Bot]

Migrating Webcompat whiteboard priorities to project flags. See bug 1547409.

Comment 9

[Firefox Bug Husbandry Bot]

See bug 1547409. Migrating whiteboard priority tags to program flags.