New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 74077 link

Starred by 12 users

Issue metadata

Status: Fixed
Owner:
User never visited
Closed: Mar 2011
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

sans-serif and serif fonts should have separate UI settings

Project Member Reported by js...@chromium.org, Feb 24 2011

Issue description

We used to have serif, sans-serif and fixed font selection UIs. 
Now, we have only standard and fixed. 

I'm aware that this is what IE and Safari do, but I don't think that's not consistent with what CSS specifies and we don't have to follow them.  For this very reason, Firefox (and Mozilla and Netscape before that) have serif and sans-serif and fixed (at one point, Mozilla also exposed fantasy and cursive in the UI). We decided to do the same for Chrome. 

sans-serif and serif distinction is important in CSS font selection and we need to allow users to set them separately. Two other CSS generic families (fantasy and cursive) are much less widely used by web page authors. So, we don't need a separate UI. 

However, serif and sans-serif generic families are frequently used by web authors at the end of font-family list and we need to let users easily select what those two CSS generic families correspond to. 


Without this recent change, we'd not have  bug 73845 . 

I'm sorry I didn't notice this change sooner. 


 

Comment 1 by js...@chromium.org, Feb 24 2011

In addition, for ChromeOS, we've tried to have at least two sets of fonts (serif and sans-serif) for as many scripts/languages as possible because the distinction between two CSS generic families is important. 
 

Comment 2 by csilv@chromium.org, Feb 24 2011

Repeated from  issue 72313 :

The decision to consolidate the serif and sans-serif font setting was intentional as a way of simplifying our settings.  Safari also has the same standard/fixed font settings.  The bug that is causing the sans-serif font to not be set will be fixed, but I don't believe we should go back to the separate settings.  But if you disagree, could you please clarify so the UI leads can make a decision?

cc: jhawkins, ainslie

Comment 3 by csilv@chromium.org, Feb 24 2011

Repeated from  issue 72313 :

The decision to consolidate the serif and sans-serif font setting was intentional as a way of simplifying our settings.  Safari also has the same standard/fixed font settings.  The bug that is causing the sans-serif font to not be set will be fixed, but I don't believe we should go back to the separate settings.

cc: jhawkins, ainslie

Comment 4 by js...@chromium.org, Feb 24 2011

With the current UI, a user does not have an *easy* way [1] to control what font is used for the two sections below : 

A. 
<div style="font-family: serif;">blah blah....</div>
<div style="font-family:times new roman, serif;">blah... </div>

B.
<div style="font-family: sans-serif;">blah blah....</div>
<div style="font-family: arial, sans-serif;">bla.... </div>

And, a lot of web page authors specify CSS generic families as shown above. 

[1] A user may edit Preference file directly, but that's not for everybody. 

Comment 5 by tony@chromium.org, Feb 24 2011

I think we implemented this wrong.  Here's a test page:
  http://ponderer.org/tests/font-family.html

In Safari and in IE, changing the font in settings shouldn't change the first two blocks.  It should only change the last block.

In Chrome, changing the font in settings changes the first block and the last block.

Comment 6 by csilv@chromium.org, Feb 24 2011

Tony,

Yes, as I indicated in my comment, this is a known bug that will be fixed today.  This will make Chrome's behavior consistent with Safari and IE.

Comment 7 by tony@chromium.org, Feb 24 2011

If it matches Safari & IE's behavior, I think that addresses jshin's concern.  jshin, is that correct?

Comment 8 by kochi@chromium.org, Feb 25 2011

Adding reference to other bugs:
http://crosbug.com/12311 (original bug filed only for ChromeOS)
 http://crbug.com/73842 
 http://crbug.com/73845  (duplicate of 73842)

Let's use this entry for consolidated discussion.

Comment 9 by bashi@chromium.org, Feb 25 2011

Comment 10 by kochi@chromium.org, Feb 25 2011

I just wanted to add my viewpoint from Japanese language user to what Jungshik
said:

- Japanese people has pretty clear distinction between serif (Mincho) and sans-serif
  (Gothic).  Sometimes sans-serif is used for emphasis in serif text.
- In the old days, as display resolution was low and anti-alias technology was not
  used (due to memory, CPU or graphics performance), sans-serif was preferred for
  web fonts because minute shape of Japanese serif fonts could not be clearly
  rendered, but it is not true for modern browser environment, including smart
  phones.
- For IE/Mac users, they have decent fonts by default, so they don't have to tweak
  fonts (almost). But for Linux users, they don't have good quality free Japanese
  font until IPA fonts were released.  So they tend to tweak their fonts.

At the bottom line, I don't support the idea of regarding 'serif' and 'sans-serif'
as same and use the same font for serif/sans-serif.

From observing Safari's behavior, if I set the default font to 'Times',
Japanese font also changes to serif family one, even though 'Times' doesn't
contain Japanese glyphs.
So Safari seem to infer the font family from the default font and chooses
appropriate font for fallbacks.

Comment 11 by tony@chromium.org, Feb 25 2011

@kochi: Can you make a page demonstrating the fallback you're describing?  What does IE do in that case?
@tony: Your test page demonstrates the issue.
@csilv: The current behavior doesn't follow Safari and IE. In Safari and in IE, the first two blocks of tony's test page are rendered by different fonts even if I change Web page font (IE) / Standard font (Safari). In Chrome, the first two blocks are rendered by the same font when I selected a Standard font from WebUI. 
> this is a known bug that will be fixed today.
No, the problem is not yet fixed at all. Perhaps you misunderstand the issue.
I think VYV03... is saying about the changes in r76141 for  Issue 73842 .
To see what's happening after that change, please see attached screenshot
(Chromium_Build76185.png).

BTW, WebKit have 6 definitions for font types, i.e.:
  WebKitStandardFont, WebKitFixedFont, WebKitSerifFont,
  WebKitSansSerifFont, WebKitCursiveFont, WebKitFantasyFont
(From http://trac.webkit.org/browser/trunk/Source/WebKit/win/WebPreferenceKeysPrivate.h)
And Safari allows users to change only the following two in its Prefs UI.
  WebKitStandardFont, WebKitFixedFont
Attached screenshot (Safari_v503_Win.png) shows how it works at the following pages.
 http://www.mozilla.gr.jp/standards/webtips0007.html#c1_3
 http://ponderer.org/tests/font-family.html

To follow Safari's behavior, the following changes will be required.
 1.Include "webkit.webprefs.standard_font_family" in user's pref_name.
 2.In case user's "standard_font_family" is blank, set it to "serif_font_family"
   or "sans_serif_font_family" (depends on "kWebKitStandardFontIsSerif").
 3.When user changes "Standard font" in the WebUI settings, store that font
   to "webkit.webprefs.standard_font_family" in the Preferences file.
Furthermore, I request to add the following new option:
 Add a button "Advanced..." on the "Fonts and Encoding" overlay, that opens
 new overlay similar to current "Fonts and Encoding" overlay. But it only
 contains font-face chooser for Serif and Sans-Serif (+ Cursive & Fantasy).

What is your opinion?
Safari_v503_Win.png
64.2 KB View Download
Chromium_Build76185.png
42.0 KB View Download

Comment 14 by kochi@chromium.org, Feb 28 2011

Zelidrag, do you have any opinion here?
I think this affects many CJK people (and potentially others), and should be fixed in M11.

Jungshik, would you mind raising the priority to P1?

Comment 15 by tony@chromium.org, Feb 28 2011

Not matching the behavior of Safari is clearly a bug.  I've filed  issue 74434  for matching Safari's behavior.  Whether we have extra options for sans-serif and serif seems like a separate discussion.

@kochi: It sounds like we only need separate sans-serif/serif font selectors for Linux.  It also sounds like now there exists free decent fonts on Linux.  Can we just add these fonts to the default font list for Linux?
@Tony I think we already have the list in ja locale resources.  I'll check how it is decently ordered.

But having serif/sans-serif font selectors for Linux is nice.

Labels: UI-Needed Mstone-13
Status: Assigned

Comment 18 by evan@chromium.org, Mar 2 2011

Being able to specify serif/sans-serif fonts can be important on Linux, where Arial and Times New Roman aren't always available.  On the other hand, if we defaulted to "serif" and "sans serif", that would work for all Linux users at the cost of breaking web pages for users that had Arial available.  (If you have Arial installed, "sans" will still usually map to some other font.)
Labels: -Pri-2 -Mstone-13 Pri-1 Mstone-11
I think we might be over-simplifying too far. The feature should still be useful for people who want to use it. No offense, but most users will never open this setting page, and those that do probably have expectations that we are now failing to meet. I agree generally on keeping UI simple, but this is so buried and is already a niche feature that making it not work for the niche set of users that actually use it seems counter-productive.

Is this something we can get back for M11?
(To be clear, for M11 I mean match Safari, and as for Serif vs Sans-Serif, that would be nice in M11 but if it is too hard I think it's not the end of the world if that's 12. That said, I do not like the idea of shipping something that breaks safari compat to stable.)
Labels: -Mstone-11 Mstone-12
As of r76463, M11 matches both Safari and IE.  Bumping to M12.
I talked to Ben and Glenn, both were OK with adding the option. Alex, any objections?
Ian, to confirm... Ben and Glenn are OK with having the following three settings:

  Standard Font
  Serif Font
  Sans-Serif Font

Is that accurate?

Comment 24 by tony@chromium.org, Mar 2 2011

For reference, here's what the Firefox dialog looks like.  It has Proportional (what we call Standard), Serif, Sans-serif, and Monospace (what we call Fixed-width). This bug is about added Serif and Sans-serif.

If we exposed Serif and Sans-serif, would it be on Linux only?

If it's technically possible, maybe we can have Sans-serif map to Arial, sans-serif.  That is, use Arial if it's available, otherwise use the sans-serif font provided by fontconfig (which the user can define).
Screenshot-Fonts.png
54.4 KB View Download
Is it possible to implement the following behavior?
* If users selected serif fonts, set standard_font_is_serif to true and update serif_font_family.
* If users selected sans-serif fonts, set standard_font_is_serif to false and update sansserif_font_family.
This will bring both a simple UI and a sane CSS font selection at the same time.
@tony: The Firefox setting "Proportional" corresponds to standard_font_is_serif (not standard_font_family).
@comment25

Do you mean the last changed font would be automatically selected as 'standard'?
I don't agree that is sane, too ambiguous for users which font will be used as
standard web font.  It's confusing.

If he/she uses sans-serif as default but just wanted to set serif font to another,
he/she would be surprised.
@ian @csilv (22, 23) 
No objections here. 
Labels: Feature-DOMUI-Options
I know it is offtopic, 
but concerning the over-simplified font setting. 

Does anyone here use any languages other than English?
How can we use the same font for all English, Japanese, Korea and Chinese?

I fount this issue that come up with the same member 3 years ago concerning about this!
http://code.google.com/p/chromium/issues/detail?id=2685

Comment 30 by js...@chromium.org, Mar 15 2011

Sorry about  bug 2685 . I'll work on that in Webkit first. What to do on the UI will come later. 

As for comment 3, I think we need either of the following:

A.  
   - serif
   - sans-serif
   - monospace
   - 'standard' (when no CSS generic is specified) 

B. 
  - serif
  - sans-serif
  - monospace
  - a check box to determine which to use for 'standard', serif or sans-serif. 

B. is what Firefox does  and what Chrome (before removing of serif/sans-serif UI) did except that in case of Chrome, we don't have a checkbox.  

BTW, this is not Linux-specific. This is more about giving users a choice and control. For instance, on Windows, our default setting for CJK locale is old Windows XP because they're common across Windows versions although Vista fonts look much better in general. End-users on Vista or Win 7 may want to change their font settings to use Windows Vista/Win 7 fonts. 

Another example is some users have their favorite fonts downloaded from somewhere (for instance, Koerean users would love to use Naver Nanum fonts - OFL'd high quality fonts), but we can't set them as the default out of the box because those fonts are not available out of the box on Windows/Mac. [1]  Nonetheless, we have to let users make that change if they wish to. 

[1] Newer Linux distros will ship Naver Nanum fonts by default. So, the situation on Linux is better in this case. 


Comment 31 by csilv@chromium.org, Mar 15 2011

Based on previous comments, my plan is to implement option A.  That seems to be the consensus choice from previous comments.  This will be for all platforms.  Note that I intend to use the same ordering as Firefox, which has standard/default first.  So:

- Standard Font
- Serif Font
- Sans-Serif Font
- Monospace Font

Another related change will be a single default font-size preference.  (See  crbug.com/10524 )  So font size preferences:

- Standard Font Size:
- Minimum Font Size:

I expect to have a CL soon.

Comment 32 by csilv@chromium.org, Mar 15 2011

Status: Started
Labels: -UI-Needed
Project Member

Comment 34 by bugdroid1@chromium.org, Mar 17 2011

Summary: sans-serif and serif fonts should have separate UI settings
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=78474

------------------------------------------------------------------------
r78474 | csilv@chromium.org | Wed Mar 16 17:29:53 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/advanced_options_handler.h?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/options/advanced_options.js?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/options/font_settings.js?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/advanced_options_handler.cc?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/options/font_settings.html?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/font_settings_handler.cc?r1=78474&r2=78473&pathrev=78474
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/font_settings_handler.h?r1=78474&r2=78473&pathrev=78474

web-ui settings: Font setting fixes and improvements.
- Add back settings for serif & sans-serif fonts.
- Remove font size setting for monospace fonts.
- As a result of these changes, the default font size now matches the 'Medium' setting.

BUG= 10524 , 74077 , 71482 
TEST=Verify that options in font settings dialog work properly.
Review URL: http://codereview.chromium.org/6672063
------------------------------------------------------------------------

Comment 35 by csilv@chromium.org, Mar 17 2011

Fixed in r78474.

Comment 36 by csilv@chromium.org, Mar 17 2011

Status: Fixed
Cc: jnd@chromium.org a deleted user anan...@chromium.org
 Issue 8847  has been merged into this issue.
Project Member

Comment 38 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 39 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Area-UI -Mstone-12 M-12 Cr-UI
Project Member

Comment 40 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment