157667 - font.minimum-size vs. font.min-size

Status: RESOLVED INVALID

(SeaMonkey :: Preferences, defect)

Description

[Masaki Katakai]

There are two preferences which defines min font size,

font.minimum-size.ja

font.min-size.variable.ja
font.min-size.fixed.ja

Which should we use? Preference Dialog stores the value
as font.minimum-size.<lang>. However, it does not change
UI font size.

We still have to define font.min-size... to define minmum
size of UI fonts.

Comment 1

[kill this account]

font.minimum-size.<lang> seems to be from layout not the X windows code.

rbs: would you care to comment on the difference between these?

Comment 2

[rbs]

font.minimum-size.<lang>: this works as expected - i.e., it establishes a
minimum threshold so that users don't suffer from poorly designed web sites.
Often people design their pages and only test them on IE Windows, and when
Mozilla Unix users visit such pages, they appear unreadadbly small to them. Some
IE-centric pages appear unreadably small on Mozilla Windows too, BTW, and the
pref fixes that.

The pref is also a cross-platfrom pref that helps accessibility in general
(e.g., people with special visual needs or with non-conventional monitors).
Hence it has a persistent effect (unlike the zoom which is transient).

===
font.min-size.<lang> is a Unix-only pref that predates font.minimum-size.<lang>.
I have already suggested to remove this pref altogether (and thus any code that
refers to it).

userChrome.css is usually the centralized location that is advertised for
specific changes to the chrome, and so Japanese distributions can bump the
font-size of their UI there -- although it seems to me that this isn't necessary
since the default font used in the UI is probably already matching with the
user's preferred font inherited from their desktop. That's why I don't find the
old pref of significant value now that the new pref is there.

In the meantine where both prefs are still supported, the winner (on Unix) is
whichever is greater between the two.

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

Mass reassign of my non-Firefox bugs to [e-mail]

Comment 4

[Oliver Schoett]

> the winner (on Unix) is whichever is greater between the two.

This is not what the bug report says:

> font.minimum-size.<lang> [...] does not change UI font size.
                                      ***

I am seeing the same problem on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2pre) Gecko/20070127 SeaMonkey/1.1

My font.minimum-size.<lang> hat been set to 13 in the prefs dialog for the languages x-unicode, x-user-def, and x-western; my font.min-size values are set by default to 10 for a handful of Asian languages.

Browsing http://digg.com/view/all, I get a body text that is clearly too small.  The DOM  Inspector shows the computed style of the HTML element to be 13px (OK), and the computed style of the directly enclosed BODY element to be 10.7333px (BAD).  Presumably this is due to the CSS rule

body, td, th, textarea, input, select, h2, h3, h4, h5, h6 {
	font: 83%/1.4 arial, helvetica, sans-serif;
}

in http://digg.com/css/15/global.css

Of course, this is bad web site design, but the point here is that the minimum font size setting should allow me to protect myself from such nonsense.

Comment 5

[Oliver Schoett]

Work-around for my problems reported in Comment #4: start SeaMonkey with the environment setting MOZ_DISABLE_PANGO=1

This is about SeaMonkey 1.1 compiled from source in Gentoo x86 Linux; I gathered the solution from the thread

   news://news.mozilla.org:119/mozilla.dev.apps.seamonkey
   PuppyOS: SeaMonkey updated to version 1.1

Comment 6

[Serge Gautherie (:sgautherie)]

(Filter "spam" on 'prefs-nobody-20080612'.)

Comment 7

[Phoenix]

font.minimum-size is the only one left for now thus making this bug obsolete, so closing it.