Persona is no longer an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 30910 - Pref for minimum font size
: Pref for minimum font size
[have fix][p-icab][p-konqueror][p-omn...
: access, fonts, helpwanted
Product: Core
Classification: Components
Component: CSS Parsing and Computation (show other bugs)
: Trunk
: All All
: P3 enhancement (vote)
: mozilla0.9.5
Assigned To: rbs
: Hixie (not reading bugmail)
: Jet Villegas (:jet)
: 49195 56440 60179 82944 91233 (view as bug list)
Depends on: 84398
Blocks: 96535
  Show dependency treegraph
Reported: 2000-03-07 15:11 PST by Akkana Peck
Modified: 2002-06-29 09:08 PDT (History)
29 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Akkana Peck 2000-03-07 15:11:31 PST
Unix users could really use a pref for "don't ever show me a font smaller than"
a given size (px, pt or mm; pt or mm is probably better than px).  There are a
lot of pages and mail messages that are just unreadable on linux.

I heard a rumour that there's already such a pref for Mac; it should be xp (even
on Windows, I'd use that pref, but it's on Linux that I really need it).
Comment 1 Pierre Saslawsky 2000-03-07 16:12:56 PST
I thought that Todd's proposal (see bug 18136) would fix that but after running 
with the new algorithm for 2 weeks, it appears that we are still having cases 
where pages are unreadable because of small fonts.

The first thing to do is, of course, investigate these cases and see what the 
problem is exactly. But before we go any further, I'm cc'ing and asking the folks 
from bug 18136 what they think about Akkana's request. I'm supporting it since 
it's more or less what we are doing in Todd's system with the smallest sizes 

Basically, it comes down to the issue of giving more control to the designer vs. 
the end-user and I usually am on the end-user side. In the real world, have you 
ever wished the small prints at the bottom of a contract to be legible without 
having to resort to a magnifier glass? If we consider in the virtual world that 
the magnifier glass is changing the medium font size, that's what that system 
would allow to avoid.

Note: what Akkana is refering to is for now a Mac-only temporary hack that wasn't 
supposed to be advertised outside Mac developers. It's just a boolean in MaxGFX 
that limits the font size to 9+. The plan was to remove it once the font size 
mess was completely fixed.
Comment 2 Pierre Saslawsky 2000-04-17 20:28:01 PDT
M17. We still need to investigate some font size issues, for instance the
"FULL STORY" link below the main image on
Comment 3 Pierre Saslawsky 2000-06-12 04:04:17 PDT
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another known 
resource will be working on this bug, or if it blocks your work in some way -- 
please attach your concern to the bug for reconsideration. 

Comment 4 Henri Sivonen (:hsivonen) (not reading bugmail or doing reviews until 2016-10-27) 2000-06-12 15:49:34 PDT
See also bug 31961. I think using px as the unit is the least ambiguous way to go.
Comment 5 Akkana Peck 2000-07-19 11:56:56 PDT
Adding helpwanted keyword.  I'm seeing a large number of pages (including our
own documentation pages!) which look fine in 4.7, but which are unreadable in
mozilla (unless I zoom the font, but then I lose my defaults since I have to
zoom back on the next page I load).
Comment 6 Pierre Saslawsky 2000-07-20 01:52:40 PDT
Akkana, are you seeing this on Unix only? Could you give me a specific URL?
Comment 7 Akkana Peck 2000-07-20 11:44:02 PDT
Here's a Netscape-internal URL for preliminary help pages, which are readable in
4.x but very hard to read in mozilla:

An external site (one of many) I was having trouble with yesterday was anything

Part of the problem may be that I suspect that the "Always use my fonts" pref
may not be working -- I'm seeing an awful lot of documents showing up in ratty
fonts that look like scaled unscalable fonts, and resizing doesn't help because
even when I make the font bigger, it never turns into a font that's very
readable.  How is that pref supposed to work, and how would I test whether it's
working?  It definitely shows me lots of pages that have a font that looks
nothing like my helvetica default.
Comment 8 Jason Eager 2000-08-05 04:33:08 PDT
Adding myself to cc. Konqueror has this.
Comment 9 R.K.Aa. 2000-08-16 11:51:08 PDT
*** Bug 49195 has been marked as a duplicate of this bug. ***
Comment 10 Karl Ove Hufthammer 2000-10-03 10:36:03 PDT
Nominating for Mozilla 1.2. Pages using unreadble fonts are *very* annoying.
Comment 11 Erik van der Poel 2000-10-03 11:53:54 PDT
Note that on Unix, Mozilla supports the following pref:

  user_pref("font.min-size.variable.x-western", 16);

There is no UI to edit this pref, but you can use a text editor to edit the
prefs file.
Comment 12 Akkana Peck 2000-10-04 11:48:09 PDT
This ROCKS!  Thank you, Erik!  This will make the web a much more hospitable place.
Comment 13 Matthew Paul Thomas 2000-10-04 16:25:39 PDT
Would making that pref apply to all platforms involve more than getting rid of an 
Comment 14 Erik van der Poel 2000-10-04 16:29:40 PDT
Yes. The code is under mozilla/gfx/src/gtk. It was originally written to solve
an East Asian problem, but it was written to be general, so that other languages
could also set a min size.
Comment 15 R.K.Aa. 2000-10-13 08:56:00 PDT
*** Bug 56440 has been marked as a duplicate of this bug. ***
Comment 16 R.K.Aa. 2000-10-13 08:57:19 PDT
*** Bug 56440 has been marked as a duplicate of this bug. ***
Comment 17 Jason Eager 2000-11-12 15:15:57 PST
Asking if we can bump this up to mozilla1.0?
Comment 18 Akkana Peck 2000-11-13 11:44:33 PST
The pref is working fine on linux.  The remaining issues, I guess, are (1)
getting it on windows and mac, and (2) exposing it in the pref ui.  Priority for
these depends on what priority we put on accessibility to sight impaired users.
Comment 19 Mark Olson 2001-01-08 20:18:27 PST
*** Bug 60179 has been marked as a duplicate of this bug. ***
Comment 20 Akkana Peck 2001-02-08 10:35:28 PST
This has regressed -- it doesn't work on Unix any more either.  For an example,
Comment 21 Akkana Peck 2001-02-08 10:47:39 PST
I take that back.  It's just that I had to set 
user_pref("font.min-size.variable.", 14);
in addition to the
user_pref("font.min-size.variable.x-western", 14);
that had previously been working.
(The first one seems like a null pref name -- is that intentional? -- but it's
what the code looks for in this page, and it works.)
Comment 22 Erik van der Poel 2001-02-08 10:58:05 PST
Brian, please take a look at this. Something has changed in the language group
stuff, and I think it needs to be fixed.
Comment 23 kill this account 2001-02-19 19:40:54 PST
I see that at nsFontMetrics.cpp line 854 langGroup is a empty string
hence the pref name is "font.min-size.variable." which fails to find
a pref because the langGroup is missing.

    844   if (mLangGroup) {
    845     nsCAutoString name("font.min-size.");
    846     if (mGeneric->Equals("monospace")) {
    847       name.Append("fixed");
    848     }
    849     else {
    850       name.Append("variable");
    851     }
    852     name.Append(char('.'));
    853     const PRUnichar* langGroup = nsnull;
    854     mLangGroup->GetUnicode(&langGroup);
    855     name.AppendWithConversion(langGroup);
    856     PRInt32 minimum = 0;
    857     res = gPref->GetIntPref(name.GetBuffer(), &minimum);
    858     printf("get %s\n", name.GetBuffer());
    859     if (NS_FAILED(res)) {
    860       gPref->GetDefaultIntPref(name.GetBuffer(), &minimum);
    861     }
    862     if (minimum < 0) {
    863       minimum = 0;
    864     }
    865     if (mPixelSize < minimum) {
    866       mPixelSize = minimum;
    867     }
    868   }

Akkana, could you try adding the following line to you unix.js:

 pref("font.min-size.variable.", 24);

Comment 24 kill this account 2001-02-19 19:42:21 PST
I'm guessing the site when down because as part of the debug process stopped the
browser mid page load and then I killed the browser instead of letting it finish
the page load.
Comment 25 Akkana Peck 2001-02-20 11:07:46 PST
In my comment of 2001-02-08 10:47 I did that (after inspecting the code to see
what it was looking for) and it worked.  It is a fine workaround, and all that
remains is the question of whether it's really intentional to use null pref
names like that (and whether that will always be supported by the pref code).
Comment 26 kill this account 2001-02-20 11:21:11 PST
it needs to be fixed.
Comment 27 Erik van der Poel 2001-02-20 13:07:22 PST
OK, we find <HTML LANG="ENG"> in the following document:

This is using a 3-letter language code. There is a new RFC on this:

It points to the language code authority:

Here we find that "eng" is indeed a valid code. The RFC says that the codes are
case-insensitive, so "ENG" is valid too. However, we do not support the
3-letter codes yet:

So, we need to add the 3-letter codes to that table.
Comment 28 Erik van der Poel 2001-02-20 13:13:59 PST
We also need to fix

and its callers so that when LookupLanguage() fails, it falls back to
Comment 29 Karl Ove Hufthammer 2001-02-21 08:19:21 PST
> Here we find that "eng" is indeed a valid code.

But *not* for HTML, or XML. The HTML 4 and XML specifications reference RFC
1766, not RFC 3066. Note that *future* versions of XML (future version of HTML
will be XML-based XHTML) probably *will* use RFC 3066. But for now, you can't
use three letter language codes in HTML documents. See <URL: >.
Comment 30 Erik van der Poel 2001-02-21 09:28:38 PST
Yes, that thought did cross my mind as I wrote my previous comments, but I
didn't think it was all that important. There are other examples of standards
that evolve over time, and specs that reference those, with the intent of
keeping up with those evolving standards. Note, for example, that HTML 4
specifically allows for the evolution of ISO 10646. Note also that RFC 1766
itself specifically allows for the evolution of ISO 639.

So, I think it's quite reasonable to use 3-letter language codes in any
version of HTML, and it's quite reasonable for Mozilla to support them too.
At the moment, Mozilla only uses them to select an appropriate font in some

The alternative, not so palatable to me, is to have Mozilla implement 2-letter
language codes for some versions of HTML and XML, and both 2- and 3-letter
language codes for other versions. This would be pretty messy to implement,
and possibly not worth the trouble.

They used to say "be conservative in what you send, liberal in what you accept"
but now of course we've learned that being too liberal in what we accept leads
to the "tag soup" (broken HTML) that we currently have on the Web.

But is this language code stuff really in the same league?
Comment 31 sairuh (rarely reading bugmail) 2001-02-21 11:06:28 PST
any chance we could get this fixed before moz1.2, eg, moz0.9 or moz1.0...?
clearing milestone to renominate...
Comment 32 James Green 2001-05-07 05:55:32 PDT
Opera (Linux) has a preference for this, specified in px, and set at 10 pages
are perfectly readable here. A URL which exposes this problem in Mozilla:

which renders much small text apparently around 6px (perceived) which makes
various parts of the pages unreadable for me.

Nominating for 0.9.2, 1.0. I don't see it being considered for 0.9.1 since I see
many other more important bugs being thrown back already.
Comment 33 Alex 2001-05-27 11:49:25 PDT
*** Bug 82944 has been marked as a duplicate of this bug. ***
Comment 34 Alex 2001-05-27 11:54:14 PDT
I also like to mention another browser that supports this feature: OmniWeb on
Mac OS X.

Considering how much this bug could improve usability for some people, and
perhaps take some worry away from some web designers who worry about whether
their font size might be too small for some people (at least people using
Mozilla or Netscape 6.xx), I think we get this working for Mozilla 1.0.
Comment 35 Matthew Paul Thomas 2001-05-30 01:01:14 PDT
Jason, James, Alex: If you want this RFE to be implemented, then implement it, 
or find someone who can. Spamming Bugzilla with comments about which other 
browsers support a feature generally won't achieve anything except for annoying 
people, especially when the person who the bug is assigned to is on holiday and 
can't hear you.
Comment 36 rbs 2001-06-17 05:33:06 PDT
Taking the bug as it is covered by what I am doing over at bug 84398.
Comment 37 rbs 2001-06-18 19:18:12 PDT
Got this working in a XP manner over at bug 84398. It is a very handy feature
indeed. I implemented it in a way such that if doesn't affect the chrome. So a
user can bump the min-size without worrying about the XUL menus and such. For
example, it zooms a tiny sidebar content without messing the tabs.
Comment 38 Pierre Saslawsky 2001-07-18 13:25:53 PDT
*** Bug 91233 has been marked as a duplicate of this bug. ***
Comment 39 Felix Miata 2001-07-22 14:07:41 PDT
> Note that on Unix, Mozilla supports the following pref:

>  user_pref("font.min-size.variable.", 14);
>  user_pref("font.min-size.variable.x-western", 16);

> There is no UI to edit this pref, but you can use a text editor to edit the
> prefs file.

Is the 14/16 point size? Pixel size? It has no current impact placed in 
2001062912 for OS/2. We need this on all platforms, not just *nix, doze & Mac.

Is there an equivalent to this pref for the various 4.X Netscape flavors? 
Doesn't work for OS/2 2001062912.
Comment 40 rbs 2001-07-22 19:42:00 PDT
No sure what is happening with OS/2. But the prefs are supposed to work on all 

The values are interpreted as pixels or points depending on the "unit":
user_pref("font.size.unit", "px") -> pixels [default, i.e., when no unit pref]
user_pref("font.size.unit", "pt") -> points

I need testers for the various font changes that have been requested: support
for min-size on all platforms (this bug), ability to set different font-sizes
for each generic font family, ability to set multiple default fonts, etc. The
code is now sitting in the FONT_20011307_BRANCH -- see my latest comments in
bug 74186 for information about checking out the branch and a link to the bonsai
listing of checkins there so far. The branch build is what I have been using for
my browsing for testing purposes, including adding these comments.
Comment 41 wing-tung Leung 2001-07-23 10:34:38 PDT
(build 0.9.2 on GNU/Linux i386)

I added the following 3 lines to preferences.js but the small text at does not seem to grow larger.

user_pref("font.size.unit", "pt")
user_pref("font.min-size.variable.", 20)
user_pref("font.min-size.variable.x-western", 20)

Am I missing something important here?
Comment 42 rbs 2001-07-23 12:15:21 PDT
-> unix.js or prefs.js
Note that this will also explode your chrome: big toolbars, big menus, 
huge sidebar tabs, etc. It was a temporary hack for some other problem.

BTW, this bug is not about that unix-only hack anymore. What is needed is a XP 
solution to control the content, leaving your chrome untouched. I have a patch 
that is already doing what is required in a clean way -- from the Style System. 
For illustration, the patch can zoom the content in-between two sidebar tabs 
without changing the tabs. Could folks please grab the branch and test this 
accessibility-friendly new way instead of the old hack that will be going away, 
Comment 43 rbs 2001-07-23 23:18:16 PDT
Milestone shift... Need interested folks to try out the branch that has the fix.
It may be too late for changes like this soon. See bug 74186.
Comment 44 rbs 2001-07-31 00:14:21 PDT
Temporary experimental self-extracting executable:
(need the new expected font prefs keys! See bug 74186):

//for this bug: set 10px as the minimum allowable font-size
user_pref("font.current.x-western.min-size", 10);
//for bug 61883 
user_pref("", "Courier New");
user_pref("", "Times New Roman");
user_pref("", "Flemish Script BT");
user_pref("", "Courier New");
user_pref("", "Arial");
user_pref("", "Times New Roman, Georgia");
//uncomment this and set different generic fonts & values to try out bug 74186
//user_pref("font.current.x-western.cursive.size-adjust", "0.55");

The fix for this bug (and related) is far from being the kind of casual
one-liner fix. Some major changes were needed. Give the build a try, thanks.
Comment 45 rbs 2001-08-22 04:24:26 PDT
Another Milestone shift... Hopefully should be over soon.
Comment 46 kill this account 2001-08-23 15:37:23 PDT
This bug is not related to bug 96535 "Font sizes too large for Japanese UI".
There already is a pref (no UI) for minimum Japanese size. The pref is
currently set large (16 px). I had set it smaller (10 px) but because the
limited default Japanese fonts available on Redhat 6.2 was we ended up with
a variety of cases where Japanese text overlapped because the fill-in glyphs 
were a lot bigger than the desired size. 

The large minimum Japanese font size would be fixed by bug 95721 
"[Get] actual string height" which would eliminate the text overlap or 
bug 90813 "anti-alias bitmap scaled fonts to make them less ugly" which
would allow us to make the glyphs the correct size.

Thus, I am removing the "blocks bug 96535" setting.
Comment 47 rbs 2001-08-23 16:21:14 PDT
The reason I added the dependency is because the way the min-size is handled
currently affects the Japanese UI. When I land my changes that have a proper
handling of the min-size (so that the min-size separates the chrome from the
content), the Japanese UI bug 96535 is going to be fixed too. You could still
set the Japanese min-size, but it won't affect the chrome anymore.
Comment 48 kill this account 2001-08-28 14:02:37 PDT
So, since you are changing the way the code works shall we plan on assigning
to you any chrome related font size bugs, including Japanese ones?
Comment 49 rbs 2001-08-28 14:57:03 PDT
Not like that :-) Wow, bstell, I will collapse under bugs if I dare :-)
But of course, I take responsibility for addressing issues that may be caused
by my patch. BTW, I don't anticipate issues in this particular area since the 
patch is purposely _avoiding_ the chrome. I was only able to experiment to see 
the effect of the font's min-size if it was let to impact the chrome on Win32, 
and it was unbearable. I had hoped that you or other interested folks could try 
my patch on the various Linux flavors which they have access to. Otherwise, it 
is just a wait'n see.
Comment 50 kill this account 2001-08-30 16:21:41 PDT
> I had hoped that you or other interested folks could try my patch on the 
> various Linux flavors which they have access to. 

Are you talking about the patches the ones in bug 74186?

(I'm happy to see you doing so much even if I am having a hard time keeping
Comment 51 rbs 2001-08-30 17:48:49 PDT
Yep, that's the patch(es)... Bug 74186 "Unable to choose different size for 
serif and sans-serif fonts". It is because of that bug that I became interested 
in this one. It is closely interwined with this one. Indeed, right over there, 
to fix bug 74186 in the Style System, I am seeing the font-sizes that are about 
to be set for these 'serif', 'sans-serif' (and anything else for that matter);
I am seeing for whom the fonts are intended (chrome or content); I am seeing the 
user's preferred font's min-size. Thus I could apply the cut-off as appropriate 
-- leaving the chrome alone, and honoring the CSS notion of "computed value" vs. 
"actual value". As a result, the fix for this bug in a proper, long-lasting way. 
But that part is the XP part, and elements of my patches affect the GFX ports 
which I don't have access to, and so I can only rely on others to try things out 
to get checkin approval, otherwise I am just stuck. Need help, thanks...
Comment 52 Pierre Saslawsky 2001-08-30 19:30:34 PDT
I'll take a look again, especially at the Mac port, when the topembed frenzy 
Comment 53 rbs 2001-09-27 22:34:10 PDT
Back-end landed as part of my font changes in bug 99010. The front-end aspect is
part of bug 61833. But those wishing to have a go can set:

user_pref("font.minimum-size.x-western", 40);

(applicable to all platforms)
Comment 54 rbs 2001-09-27 22:35:26 PDT
s/bug 61833/bug 61883/
Comment 55 Akkana Peck 2001-09-28 10:30:03 PDT
I need to update the customizing document, so I want to make sure I understand
the new prefs.  The preference name has changed from min-size to minimum-size?
The previous prefs were names like "font.min-size.variable.x-western", so should
I change the customizing document (and my prefs) to reflect the new prefs names?
 Has the size distinction between variable and fixed gone away?
Comment 56 rbs 2001-09-28 11:17:36 PDT
The previous prefs are still there (maybe not for too long -- depending on how 
the new one goes...). Unlike the previous prefs, the new one has the advantage 
that it doesn't affect the chrome and it is the one that will be hooked to the 
UI. In the meantine where all the prefs are still supported, whichever is 
greater will win on Unix.

And yes, with the new pref, it is the same cut-off for all fonts. The initial 
plan was to make a distinction between the different generic fonts, but feedback 
from UI people deemed that it would be overkill. Also, re: the previous prefs, 
it doesn't seem that people really bother to set different values there.

Comment 57 Eric Vaandering (no email) 2002-01-02 07:53:58 PST
Is there a bug number for a UI to set minimum font sizes?
Comment 58 Akkana Peck 2002-01-02 12:21:40 PST
I thought there was, but I can't find one.  There definitely should be (I've
watched more than one user give up on mozilla because of that lack).  Please
file one and cc me.
Comment 59 rbs 2002-01-02 12:43:59 PST
It might be worth to reopen bug 110342 to hook the pref for the minimum size on
the UI rather than waiting forever on the mammoth bug 61883.
Comment 60 André Dahlqvist 2002-03-29 02:45:42 PST
VERIFIED FIXED with 2002-03-28-08. The pref is font.minimum-size and it has a UI
now too.

Note You need to log in before you can comment on or make changes to this bug.