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).

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 already. 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.

M17. We still need to investigate some font size issues, for instance the "FULL STORY" link below the main image on http://cnn.com/

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.

See also bug 31961. I think using px as the unit is the least ambiguous way to go.

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).

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

Here's a Netscape-internal URL for preliminary help pages, which are readable in 4.x but very hard to read in mozilla: http://twain.mcom.com/client/infodsgn/browser/onlinehelp/browserhelp/navtop.html An external site (one of many) I was having trouble with yesterday was anything under healthcentral.com. 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.

Adding myself to cc. Konqueror has this.

*** Bug 49195 has been marked as a duplicate of this bug. ***

Nominating for Mozilla 1.2. Pages using unreadble fonts are *very* annoying.

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.

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 ifdef?

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.

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

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

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

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.

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

This has regressed -- it doesn't work on Unix any more either. For an example, see http://cal-parks.ca.gov/.

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.)

Brian, please take a look at this. Something has changed in the language group stuff, and I think it needs to be fixed.

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);

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.

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).

it needs to be fixed.

OK, we find <HTML LANG="ENG"> in the following document: http://cal-parks.ca.gov/ This is using a 3-letter language code. There is a new RFC on this: http://www.ietf.org/rfc/rfc3066.txt?number=3066 It points to the language code authority: http://lcweb.loc.gov/standards/iso639-2/ 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: http://lxr.mozilla.org/seamonkey/source/intl/locale/src/langGroups.properties So, we need to add the 3-letter codes to that table.

We also need to fix http://lxr.mozilla.org/seamonkey/source/intl/locale/src/nsLanguageAtomService.c pp and its callers so that when LookupLanguage() fails, it falls back to LookupCharSet().

> 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: http://www.w3.org/International/O-HTML-tags.html >.

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 situations. 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...

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: http://php.net/ 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.

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

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.

Taking the bug as it is covered by what I am doing over at bug 84398.

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.

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

> 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.

No sure what is happening with OS/2. But the prefs are supposed to work on all platforms. 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.

(build 0.9.2 on GNU/Linux i386) I added the following 3 lines to preferences.js but the small text at http://www.standaard.be 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?

-> 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, thanks.

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.

Temporary experimental self-extracting executable: ftp://ftp.maths.uq.edu.au/pub/rbs/mozilla-win32-font.exe (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("font.default.x-western.-moz-fixed.name", "Courier New"); user_pref("font.default.x-western.-moz-variable.name", "Times New Roman"); user_pref("font.default.x-western.cursive.name", "Flemish Script BT"); user_pref("font.default.x-western.monospace.name", "Courier New"); user_pref("font.default.x-western.sans-serif.name", "Arial"); user_pref("font.default.x-western.serif.name", "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.

Another Milestone shift... Hopefully should be over soon.

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.

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.

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?

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.

> 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 up.)

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...

I'll take a look again, especially at the Mac port, when the topembed frenzy stops.

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)

s/bug 61833/bug 61883/

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?

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?

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.

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.

VERIFIED FIXED with 2002-03-28-08. The pref is font.minimum-size and it has a UI now too.