Pref for minimum font size

VERIFIED FIXED in mozilla0.9.5



19 years ago
17 years ago


(Reporter: akkzilla, Assigned: rbs)


({access, fonts, helpwanted})

access, fonts, helpwanted
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [have fix][p-icab][p-konqueror][p-omniweb][p-opera], URL)



19 years ago
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).


19 years ago
Keywords: pp

Comment 1

19 years ago
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.
Keywords: fonts
OS: Linux → All
Hardware: PC → All

Comment 2

19 years ago
M17. We still need to investigate some font size issues, for instance the
"FULL STORY" link below the main image on
Target Milestone: --- → M17

Comment 3

19 years ago
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. 

Target Milestone: M17 → Future
See also bug 31961. I think using px as the unit is the least ambiguous way to go.

Comment 5

19 years ago
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).
Keywords: helpwanted

Comment 6

19 years ago
Akkana, are you seeing this on Unix only? Could you give me a specific URL?

Comment 7

19 years ago
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

19 years ago
Adding myself to cc. Konqueror has this.

Comment 9

19 years ago
*** Bug 49195 has been marked as a duplicate of this bug. ***
Nominating for Mozilla 1.2. Pages using unreadble fonts are *very* annoying.
Keywords: mozilla1.2

Comment 11

19 years ago
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.


19 years ago
Summary: pref: "don't ever show me a font smaller than this" → Pref for minimum font size

Comment 12

19 years ago
This ROCKS!  Thank you, Erik!  This will make the web a much more hospitable place.
Would making that pref apply to all platforms involve more than getting rid of an 

Comment 14

19 years ago
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

19 years ago
*** Bug 56440 has been marked as a duplicate of this bug. ***

Comment 16

19 years ago
*** Bug 56440 has been marked as a duplicate of this bug. ***

Comment 17

19 years ago
Asking if we can bump this up to mozilla1.0?

Comment 18

19 years ago
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.
Keywords: access

Comment 19

19 years ago
*** Bug 60179 has been marked as a duplicate of this bug. ***

Comment 20

18 years ago
This has regressed -- it doesn't work on Unix any more either.  For an example,

Comment 21

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
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

18 years ago
it needs to be fixed.

Comment 27

18 years ago
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

18 years ago
We also need to fix

and its callers so that when LookupLanguage() fails, it falls back to
> 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

18 years ago
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?
any chance we could get this fixed before moz1.2, eg, moz0.9 or moz1.0...?
clearing milestone to renominate...
Keywords: pp
Target Milestone: Future → ---

Comment 32

18 years ago
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.
Keywords: mozilla0.9.2, mozilla1.0

Comment 33

18 years ago
*** Bug 82944 has been marked as a duplicate of this bug. ***

Comment 34

18 years ago
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.
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.
Severity: normal → enhancement
Component: Compositor → Style System
QA Contact: petersen → ian
Whiteboard: [p-icab][p-konqueror][p-omniweb][p-opera]


18 years ago
Depends on: 84398

Comment 36

18 years ago
Taking the bug as it is covered by what I am doing over at bug 84398.
Assignee: pierre → rbs
Target Milestone: --- → mozilla0.9.3

Comment 37

18 years ago
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.
Whiteboard: [p-icab][p-konqueror][p-omniweb][p-opera] → [have fix][p-icab][p-konqueror][p-omniweb][p-opera]


18 years ago

Comment 38

18 years ago
*** Bug 91233 has been marked as a duplicate of this bug. ***

Comment 39

18 years ago
> 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

18 years ago
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

18 years ago
(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

18 years ago
-> 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

18 years ago
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4

Comment 44

18 years ago
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

18 years ago
Another Milestone shift... Hopefully should be over soon.
Target Milestone: mozilla0.9.4 → mozilla0.9.5


18 years ago
Blocks: 96535

Comment 46

18 years ago
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.
No longer blocks: 96535

Comment 47

18 years ago
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.


18 years ago
Blocks: 96535

Comment 48

18 years ago
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

18 years ago
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

18 years ago
> 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

18 years ago
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

18 years ago
I'll take a look again, especially at the Mac port, when the topembed frenzy 

Comment 53

18 years ago
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)
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 54

18 years ago
s/bug 61833/bug 61883/

Comment 55

18 years ago
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

18 years ago
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.

Is there a bug number for a UI to set minimum font sizes?

Comment 58

18 years ago
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

18 years ago
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

17 years ago
VERIFIED FIXED with 2002-03-28-08. The pref is font.minimum-size and it has a UI
now too.
You need to log in before you can comment on or make changes to this bug.