Unify pref font choices for various Latin script-using languages

RESOLVED FIXED in mozilla34

Status

()

Core
Layout
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: hsivonen, Assigned: smontagu)

Tracking

(Blocks: 1 bug)

Trunk
mozilla34
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(5 attachments, 2 obsolete attachments)

(Not sure if this should be a back end bug or a front end bug. Filing as a back end bug to get this triaged by layout engineers.)

Steps to reproduce:
 1) Use an en-US build.
 2) Under Preferences: Content: Fonts & Colors: Advanced change the font selections for serif and sans-serif fonts (i.e. change them for the default "Western" pref group)
 3) Navigate to http://www.w3.org/TR/CSS21/
 4) Look at the list of editors

Actual results:
Tantek's name is rendered in a font that's different from the font used for the names of the other editors.

Expected results:
Expected Tantek's name to be rendered in the same font as Bert's, Hixie's and Howcome's names.

Additional info:
Bert's name is marked up with lang="nl", Tantek's as lang="tr", Hixie's as lang="en" and Howcome's as lang="no". Our font pref taxonomy was created back in the days when Latin fonts had 8-bit repertoires and there were typically different fonts for Western European, Central European, Baltic and Turkish. nl, en and no are considered "Western" but tr is Turkish and, thus, is governed by a different font pref. These days, the kind of fonts one would reasonably use as the fonts that CSS generic serif and sans-serif map to tend to have glyphs for Western European, Central European, Baltic and Turkish use. More and more, Latin fonts even cover IPA-inspired African glyphs (presumably governed by our "Other languages" pref) and if one were a reader of an African language that uses rare Latin extensions, one would probably be sure to choose a font that has those extensions.

It would make sense for the fonts settings for all Latin uses to be governed by one pref view (at least by default). It's pretty annoying to have to make consistent pref changes for multiple legacy-oriented pref groups in order to get consistent outcomes across all Latin script-using languages.

(It wouldn't hurt to have a UI shortcut for syncing even Greek and Cyrillic with the Latin prefs considering that the size considerations are the same and more and more often the sort of high-quality fonts one would use cover Greek and Cyrillic in addition to Latin.)
Summary: Unify settings for various Latin fonts → Unify font settings for various Latin script-using languages
(Assignee)

Updated

6 years ago
Whiteboard: dupeme

Comment 1

6 years ago
Depending upon the platform, there's no guarantee that the default font for Latin will have coverage for Cyrillic and Greek.  And the prefs are set so that users whose main script is one or the other can opt for a different default font.

I'm sure there's room to consolidate some of these, the Turkish/Latin case for example.

Updated

6 years ago
Summary: Unify font settings for various Latin script-using languages → Unify pref font choices for various Latin script-using languages
(In reply to John Daggett (:jtd) from comment #1)
> Depending upon the platform, there's no guarantee that the default font for
> Latin will have coverage for Cyrillic and Greek.  And the prefs are set so
> that users whose main script is one or the other can opt for a different
> default font.

I didn't mean to suggest taking away the ability to set Cyrillic and Greek fonts separately from the Latin font. However, it would be convenient to have a way to synchronize them in one UI action. But that parenthetical remark was off-topic for this bug anyway.

> I'm sure there's room to consolidate some of these, the Turkish/Latin case
> for example.

If we had a unified pref for all Latin, we could even use it for all *-Latn such as  Romaji tagged as lang="ja-Latn".
This sounds a lot like what I had in mind with bug 556237.
(In reply to Jonathan Kew (:jfkthame) from comment #3)
> This sounds a lot like what I had in mind with bug 556237.

Yes, I agree. And the interface would have to support (or have the ability to support) all 160 or so scripts, not just the common Latn, Cyrl, and Grek ones.
Duplicate of this bug: 792575
Duplicate of this bug: 192636
Bug 192636 comment 17 indicates that this has been a problem for Wikipedia. :-(
(Assignee)

Comment 8

4 years ago
Created attachment 8463967 [details] [diff] [review]
Patch 1: merge x-baltic with x-western

After writing bug 485179 I decided to put my code where my mouth was and fix this.
Assignee: nobody → smontagu
Attachment #8463967 - Flags: review?(jfkthame)
(Assignee)

Comment 9

4 years ago
Created attachment 8463968 [details] [diff] [review]
Patch 2: merge x-central-euro with x-western
Attachment #8463968 - Flags: review?(jfkthame)
(Assignee)

Comment 10

4 years ago
Created attachment 8463975 [details] [diff] [review]
Patch 3: merge tr with x-western

Note that this patch doesn't touch nsGkAtomList.h, because nsGkAtoms::tr is used elsewhere (as a matter of fact it's used both for the <tr> element and the tr language tag, which seems to me like a bug waiting to happen :( )
Attachment #8463975 - Flags: review?(jfkthame)
(Assignee)

Comment 11

4 years ago
In theory I'd like to change "x-western" to "Latn" as well, but that would effectively reset the font pref for anybody who has already set it -- or do we have a way to migrate prefs in that kind of situation?
I wonder whether you should add one more patch to this series: to change the UI string for font.langGroup.latin1 in fonts.dtd (as displayed in the Font preferences dialog) from "Western" to "Latin", to better reflect the newly-extended scope of the preferences it's referring to. WDYT? We'd want to change the entity name, too, so as to alert localizers.

(Perhaps we'd need to say "Latin script", so as not to mislead people into thinking it's specific to the Latin language.)
(In reply to Simon Montagu :smontagu from comment #11)
> In theory I'd like to change "x-western" to "Latn" as well, but that would
> effectively reset the font pref for anybody who has already set it -- or do
> we have a way to migrate prefs in that kind of situation?

We could write a fragment of JS code that's executed on first run after an update, and moves the old prefs to their new names - e.g. see function BG__migrateUI() in components/nsBrowserGlue.js.

Not sure whether it's worth it here, or if we should just leave this as a somewhat obsolete internal name that normal users won't see.
> BG__migrateUI() in components/nsBrowserGlue.js.

sorry, that's  browser/components/nsBrowserGlue.js
(In reply to Jonathan Kew (:jfkthame) from comment #12)
> I wonder whether you should add one more patch to this series: to change the
> UI string for font.langGroup.latin1 in fonts.dtd (as displayed in the Font
> preferences dialog) from "Western" to "Latin", to better reflect the
> newly-extended scope of the preferences it's referring to. WDYT? We'd want
> to change the entity name, too, so as to alert localizers.

Yes, I agree. The list is primarily of scripts now (with a few language holdouts), and "Western" is not a script (nor is it a language, for that matter).

> (Perhaps we'd need to say "Latin script", so as not to mislead people into
> thinking it's specific to the Latin language.)

We don't do that for, e.g., Arabic, do we? I don't think it'll confuse too many people.

(In reply to Simon Montagu :smontagu from comment #11)
> In theory I'd like to change "x-western" to "Latn" as well, but that would
> effectively reset the font pref for anybody who has already set it -- or do
> we have a way to migrate prefs in that kind of situation?

We'll already be resetting the font pref for anyone who cares about 'x-baltic', 'x-central-euro', or 'tr', so I think we could take the hit on 'x-western', as well. (Are the defaults any different among them?)
Comment on attachment 8463967 [details] [diff] [review]
Patch 1: merge x-baltic with x-western

Review of attachment 8463967 [details] [diff] [review]:
-----------------------------------------------------------------

::: gfx/thebes/nsUnicodeRange.cpp
@@ +41,5 @@
>  };
>  
>  /**********************************************************************
>   * Unicode subranges as defined in unicode 3.0
> + * x-western, x-central-euro, tr  -> latin 

Please drop the trailing space while you're touching this.
Attachment #8463967 - Flags: review?(jfkthame) → review+
Attachment #8463968 - Flags: review?(jfkthame) → review+
Attachment #8463975 - Flags: review?(jfkthame) → review+
I suggest also:
 1) Removing the comment about Vietnamese in https://mxr.mozilla.org/mozilla-central/source/intl/locale/langGroups.properties#186 . Clearly, we aren't going to introduce a language group for Vietnamese at this point.
 2) Changing the UI string in the pref pane from "Western" to "Latin".
(Assignee)

Comment 18

4 years ago
(In reply to Henri Sivonen (:hsivonen) from comment #17)
> I suggest also:
>  1) Removing the comment about Vietnamese in
> https://mxr.mozilla.org/mozilla-central/source/intl/locale/langGroups.
> properties#186 . Clearly, we aren't going to introduce a language group for
> Vietnamese at this point.

Yes, thanks for the pointer, there are quite a few comments in langGroups.properties that have become irrelevant and can be removed.

>  2) Changing the UI string in the pref pane from "Western" to "Latin".

There seems to be a consensus on this. Personally I'm not sure how clear "Latin" will be to users. What does everybody think about "Roman" as an alternative?

Most other browsers don't seem to have an equivalent of this pref pane. IE has "Latin based" as one option; I'm not sure which languages it covers.
(In reply to Simon Montagu :smontagu from comment #18)
> >  2) Changing the UI string in the pref pane from "Western" to "Latin".
> 
> There seems to be a consensus on this. Personally I'm not sure how clear
> "Latin" will be to users. What does everybody think about "Roman" as an
> alternative?

I'm a bit concerned about this, too, although I do think we need to change it from "Western" to something that better reflects the extended scope of the setting.

IMO, "Latin [script/alphabet/based]" is probably better than "Roman [ditto]", which I think is a less widely recognized term; it's known from font names like "Times New Roman", of course, but that's perceived as part of the name of the typeface design rather than of the writing system it's implementing.

(FWIW, I notice that wikipedia's article is titled "Latin script"; looking up "Roman script" redirects there.)
(In reply to Simon Montagu :smontagu from comment #18)
> >  2) Changing the UI string in the pref pane from "Western" to "Latin".
> 
> There seems to be a consensus on this. Personally I'm not sure how clear
> "Latin" will be to users. What does everybody think about "Roman" as an
> alternative?

I still think unadorned "Latin" is the best, as that is the standard name of the script and no other scripts have a disambiguator attached, even if they might otherwise potentially benefit from one.

(In reply to Jonathan Kew (:jfkthame) from comment #19)
> I'm a bit concerned about this, too, although I do think we need to change
> it from "Western" to something that better reflects the extended scope of
> the setting.
> 
> IMO, "Latin [script/alphabet/based]" is probably better than "Roman
> [ditto]", which I think is a less widely recognized term; it's known from
> font names like "Times New Roman", of course, but that's perceived as part
> of the name of the typeface design rather than of the writing system it's
> implementing.

I actually think "Roman" is the more recognized of the two; but I am not in favor of using it, as that is not the standard name.

The menu contains other strings that refer to scripts and not languages (even though they share a name with one)—e.g. Arabic, Hebrew—but we don't modify them to include "script". I really think the audience for this is small enough as it is.

> (FWIW, I notice that wikipedia's article is titled "Latin script"; looking
> up "Roman script" redirects there.)

Yeah, but Wikipedia has standardized article titles to "X script" and "Y language", so I'm not sure that's the best metric to use.
AFAICT, the convention is to use "Roman" when referring to numbers (of the "MMXIV" type) and "Latin" when referring to letters.

I can't think of any succinct (fitting in the UI label) way to help people who are insufficiently educated to realize that this sort of letters that their language is written with are called "Latin" letters beyond
 1) making sure that "Latin" is preselected when opening the UI in a browser whose UI locale uses the Latin script.
 2) changing the "Other Languages" label to "Other writing systems" to avoid suggesting that the items in the menu are *languages*, since the items are actually *scripts* aka. "writing systems".

So I think the en-US UI string should be simply "Latin", since it's the right adjective to be in the same category as Cyrillic and Devanagari.
(Assignee)

Comment 22

4 years ago
Created attachment 8466912 [details] [diff] [review]
patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog
Attachment #8466912 - Flags: review?(jfkthame)
(Assignee)

Updated

4 years ago
Attachment #8466914 - Flags: review?(jfkthame)
(Assignee)

Comment 24

4 years ago
Created attachment 8466915 [details] [diff] [review]
patch 5: delete obsoleted comments in langGroups.properties and assign x-western to a few unassigned languages that use Latin script

I thought this was going to be a comment-only change, but I ended up uncommenting a couple of language assignments as well
Attachment #8466915 - Flags: review?(jfkthame)
(Assignee)

Updated

4 years ago
Attachment #8466914 - Attachment is obsolete: true
Attachment #8466914 - Flags: review?(jfkthame)
Comment on attachment 8466912 [details] [diff] [review]
patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog

Review of attachment 8466912 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/components/preferences/fonts.xul
@@ +70,5 @@
>              <menuitem value="x-telu"          label="&font.langGroup.telugu;"/>
>              <menuitem value="th"              label="&font.langGroup.thai;"/>
>              <menuitem value="x-tibt"          label="&font.langGroup.tibetan;"/>
>              <menuitem value="x-cans"          label="&font.langGroup.canadian;"/>
> +            <menuitem value="x-western"       label="&font.langGroup.latin;"/>

Now that we're calling this "Latin" rather than "Western", it should move up to come between Korean and Malayalam in the list.
Comment on attachment 8466915 [details] [diff] [review]
patch 5: delete obsoleted comments in langGroups.properties and assign x-western to a few unassigned languages that use Latin script

Review of attachment 8466915 [details] [diff] [review]:
-----------------------------------------------------------------

Looks fine to me.

What about s/x-western/x-latn/g or something like that, or is it not worth the disruption?
Attachment #8466915 - Flags: review?(jfkthame) → review+
(In reply to Simon Montagu :smontagu from comment #24)
> I thought this was going to be a comment-only change, but I ended up
> uncommenting a couple of language assignments as well

Nice. Filed bug 1048153 as a follow-up.
(Assignee)

Comment 28

4 years ago
(In reply to Jonathan Kew (:jfkthame) from comment #25)
> Comment on attachment 8466912 [details] [diff] [review]
> > +            <menuitem value="x-western"       label="&font.langGroup.latin;"/>
> 
> Now that we're calling this "Latin" rather than "Western", it should move up
> to come between Korean and Malayalam in the list.

Oops, I thought that we sorted the list on the fly -- I've now reopened bug 54746.
(Assignee)

Comment 29

4 years ago
Created attachment 8467044 [details] [diff] [review]
patch 4: change "Western" to "Latin" and "Other Languages" to "Other Writing Systems" in the font preferences dialog
Attachment #8467044 - Flags: review?(jfkthame)
(Assignee)

Updated

4 years ago
Attachment #8466912 - Attachment is obsolete: true
Attachment #8466912 - Flags: review?(jfkthame)
Attachment #8467044 - Flags: review?(jfkthame) → review+
https://hg.mozilla.org/mozilla-central/rev/f0ae82398d23
https://hg.mozilla.org/mozilla-central/rev/2a9dfb605be4
https://hg.mozilla.org/mozilla-central/rev/13b41d588e0c
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla34
Also these two changesets, which landed with an incorrect bug number (750622):
> https://hg.mozilla.org/mozilla-central/rev/3d88e3845d62
> https://hg.mozilla.org/mozilla-central/rev/0b923ab187d3
(In reply to Jonathan Kew (:jfkthame) from comment #26)
> What about s/x-western/x-latn/g or something like that, or is it not worth
> the disruption?

If we're gonna change it, we might as well go full 'Latn' (or at least 'latn').

(See also bug 1048153 comment 1.)
Whiteboard: dupeme

Updated

3 years ago
Depends on: 1140720
Depends on: 1147311

Updated

2 years ago
Blocks: 1303529
You need to log in before you can comment on or make changes to this bug.