530419 - Correct monospace font setting on Mac (change it from "Apple LiGothic" to "Courier")

Status: RESOLVED DUPLICATE of bug 599289

(Core :: Graphics, defect)

Description

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Test page

The pref to change is font.name.monospace.zh-TW in modules/libpref/src/init/all.js line 1899. Test page attached. Screenshots and patch to come.

The logic to change it to Courier is like what we do on Windows in bug 88579 - these chars will be used in font listed in pref "font.name-list.monospace.zh-TW".

Tim

Comment 1

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Current setting - Apple LiGothic, which is not really a monospace font.

Comment 2

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Proposed setting - Courier

Comment 3

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Attachment: Proposed pref change.

Comment 4

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to comment #0)
Been a bad night with alcohol, let me rephrase what this bug is really about:

During offline discussion yesterday, we discovered that setting "font-family: monospace" doesn't really makes Firefox shows monospace font when lang="zh-TW". (attachment 413931 [details])

The default pref that affects the behavior is "font.name.monospace.zh-TW" on every Mac profile.

The solution is to change the pref from "Apple LiGothic" to "Courier", which is a latin-alphabet font that is truly monospace. For non-latin characters (e.g., Chinese), Firefox would make use of the pref "font.name-list.monospace.zh-TW", which is still "Apple LiGothic". Since Chinese characters is always "monospace" (they are squares), we simply choose a font that goes well side by side with Courier, which LiGothic does. The same idea goes way back as in bug 88579.

We would like to ship this change as soon as possible. Perhaps in Firefox 3.6 and Firefox Mobile.


Tim

Comment 5

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Change the component selection. Still not sure if it's correct though.

Comment 6

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

I think your testcase is invalid; that is, the English text is clearly not lang="zh-TW".  If you mark your English text as English and your Chinese text as Chinese, you should get the desired behavior with the current set of prefs.

Comment 7

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to comment #6)
> I think your testcase is invalid; that is, the English text is clearly not
> lang="zh-TW".  If you mark your English text as English and your Chinese text
> as Chinese, you should get the desired behavior with the current set of prefs.

The sole purpose of "lang" property is to represent the natural language of the paragraph/HTML tag in question, which results Firefox rendering the part of the page with pre-set font designated to that language.

monospace-ed Latin alphabets should stay in monospace whatever language it belongs, whether the author of webpage set the correct "lang" property or not. 

Have you read comment 4?


Tim

Comment 8

[John Daggett (:jtd)]

So what you're saying Tim is that because there isn't a Chinese font with monospace Latin glyphs availabe on OS X (similar to Osaka Mono for Japanese), Courier should be used instead?

Comment 9

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to comment #8)
> So what you're saying Tim is that because there isn't a Chinese font with
> monospace Latin glyphs availabe on OS X (similar to Osaka Mono for Japanese),
> Courier should be used instead?

Not exactly, let's wait for our Mac user who discovered the bug to response :)

However the benefit of using Courier is somewhat similar to bug 88579 - we want Latin alphabets look the same without regard to the "lang" property, whether is "en-US" or "zh-TW". It would be disastrous to render a perfectly English webpage with Latin alphabets in Chinese font just because it doesn't specify the "lang" property and the default is zh-TW.

Comment 10

[philippe (part-time)]

(In reply to comment #8)
> So what you're saying Tim is that because there isn't a Chinese font with
> monospace Latin glyphs availabe on OS X (similar to Osaka Mono for Japanese),
> Courier should be used instead?

That is more or less what Safari does, afaict.
(someone had a surprise with Gecko's behaviour when viewing source on a page, in bug 538916).

Comment 11

[Irvin (MozTW)]

As I know, there is NO Trad. Chinese fonts with mono latin characters bundled in the Mac OS X 10.4 ~ 10.6. Most people will have MingLiU installed by MS office or copried from windows, but it's as ugly as is. 

I'd no idea what font safari will use in such situation, I'll check it later. 

We can choose MingLiU as default monospace chinese font, of course, only a small number of people don't have it. But it's not logical to have a page rendered by MingLiU and other page represended by Courier, which have different "lang" property but had same english content, especially consider how the thin glyph of MingLiU incompatible with the default chinese font Apple LiGothic, and I cannot came into another chinese fonts, which has mono latin letters and available to most of the chinese mac users.

I'll stand for the decision to correct font.name.monospace.zh-TW to Courier.

Here is the list of typefaces included with Mac OS X from Wikipedia
http://en.wikipedia.org/wiki/List_of_typefaces_included_with_Mac_OS_X

Comment 12

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

(In reply to comment #10)
> That is more or less what Safari does, afaict.
> (someone had a surprise with Gecko's behaviour when viewing source on a page,
> in bug 538916).

As far as I can tell (Trac's search sucks, and there's no mxr for WebKit, but I poked around for quite a while), WebKit only sets one global set of fonts (Times, Helvetica, and Courier) and then puts you at the mercy of fallback for handling any glyphs of other scripts/languages not included in those 3 global fonts.  (I say mercy because font fallback sucks; WebKit ends up with Hiragino Kaku Gothic ProN, a font designed for Japanese[1], for zh-TW/zh-Hant monospace, instead of one designed for Traditional Chinese.)

Gecko, on the other hand, sets one set of fonts per langGroup.

So the different behavior in WebKit is because WebKit behaves differently: it says "All monospace is Courier. Oh, here's some Traditional characters; Courier has no glyphs for them.  FontFallback, find me a font with this glyph.  What's that you say, FontFallback? Hiragino Kaku Gothic ProN?  Got it; these monospace Traditional characters are now displayed in Hiragino Kaku Gothic ProN".  

Gecko says "this is monospace, but what language is it? Ah, it's zh-TW/zh-Hant, so monospace means Apple LiGothic.  All these glyphs are present in this font, so no need to look for another font to handle any of them".

I still think Gecko's current behavior is right, based on the way that Gecko is designed to work.

[1] http://support.apple.com/kb/HT1538

Comment 13

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to comment #12)
> Gecko says "this is monospace, but what language is it? Ah, it's zh-TW/zh-Hant,
> so monospace means Apple LiGothic.  All these glyphs are present in this font,
> so no need to look for another font to handle any of them".

You seem to missing the point. Gecko's behavior is correct only if Apple LiGothic is truly a monospace font for zh-TW/zh-Hant. BUT IT IS NOT. It's an sans-serif font, and per comment 11, font like "Osaka Mono" for zh-TW/Hunt, i.e. a zh-TW/Hunt font with monospaced Latin glyphs, DOES NOT EXIST AT ALL.

Therefore, whether you like it or not, we must put font fall back list to work - set Courier as the monospace font, and Apple LiGothic as the fall back.

Webkit font fall back sucks. I know. Yet you already know we are talking about a complete differently way to utilize font fall back, so what's the problem here?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(In reply to comment #13)
> Therefore, whether you like it or not, we must put font fall back list to work
> - set Courier as the monospace font, and Apple LiGothic as the fall back.

I believe Gecko supports having a list of fonts as the default font, for at least some contexts in which we use the preference:  see the font.name-list.* preferences.  (Also, I note the patch doesn't change font.name-list.monospace.zh-TW .  Should it?  I don't remember the details of the contexts in which the two are used.  However, I'd think that if we have a font.name-list.* pref we *could* ignore the font.name.* pref; if that's not what we're doing I think it's worth filing bugs so that we can do that.)

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

(In reply to comment #14)
> I believe Gecko supports having a list of fonts as the default font, for at
> least some contexts in which we use the preference:  see the font.name-list.*
> preferences.  (Also, I note the patch doesn't change
> font.name-list.monospace.zh-TW .  Should it?  I don't remember the details of
> the contexts in which the two are used.  However, I'd think that if we have a
> font.name-list.* pref we *could* ignore the font.name.* pref; if that's not
> what we're doing I think it's worth filing bugs so that we can do that.)

The patch shouldn't change font.name-list.monospace.zh-TW because it's already the second choice of our font fall back list. (font.name.* being the first)

IMO font.name.* shouldn't be ignored because it's the only pref that user could set via Font Preference panel. What I would suggest as a feature is to make that panel to control the entire set of the font fall back list - since in zh-TW most of the time we rely setting a second font contain Chinese glyphs to properly show both Latin alphabet and Chinese glyphs - but that's a bit too complicated and locale-specific, maybe it's not worthy to do.

Comment 16

[John Daggett (:jtd)]

The patch/change here was superceded by the larger set of changes for bug 599289.