Fonts too small in menus and group pane and subject pane



17 years ago
11 years ago


(Reporter: 3.14, Unassigned)



Firefox Tracking Flags

(Not tracked)



(5 attachments)



17 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3b) Gecko/20030212 (i.e., 1.3b release)

After installing the RH7 RPMs (previously using self compiled trunk from
20030117) several displays are very small and hence hard to read. This includes:
all pull-down menus, bookmarks (personal toolbar), group pane, subject pane,
header pane in MailNews.

There seems to be no option to which let's me change it. Sorry, no clue which
component this is.


Comment 1

17 years ago

Comment 2

17 years ago
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021203 not that this
matters when looking at png files instead of the real thing.
You should try changing the Minimum Font size option.  I don't use pop mail but
I think that setting the min font size in the browser effects all mozilla

Comment 3

17 years ago
No, that setting has no effect for this problem.

Are you using an xft build?

Comment 5

17 years ago
I am usuing this version, no idea how it was compiled:

Does this happen with a non-RPM build (just a regular .tar.gz nightly)?
OK.  Is this a problem with the Modern theme too?  Or just Classic?

Comment 9

17 years ago
Yes, same for both themes.


Comment 10

17 years ago
Since I am not able to find it: Which font setting would be responsible for the
size in the header pane?

Your GTK theme, if any, could be...

Failing that, it would be the Mozilla themes themselves....

Comment 12

17 years ago
No idea about GTK theme. Anyway, I am using KDE 3.0.3, but the same problem
happens with failsafe.

It sounds strange that I cannot change the font size in content areas from
within Mozilla.

That's the UI, not content areas... typically the UI font is set by the OS.

Are you possibly using a dual-monitor setup?

Comment 14

17 years ago
Why is it UI to display the names of folders and newsgroups, of subjects, and of
header entries?

No, I don't use a dual-monitor setup.

It's UI because Mozilla has the "last word" in what it looks like.  Content
would be web pages and such, where the author has said "last word" (in both
cases the user should be able to override it, but the mechanisms are different).

So nothing changed about your system and the fonts just became a lot smaller? 
Any chance you can narrow down the date range when the problem first appeared?

Comment 16

17 years ago
Try manually setting the font size in the browser and this time make sure that
you uncheck the dialog box for "allow documents to use other fonts".  I forgot
that option last time I suggested you to do this.  I know for a fact that this
works for the browser, but again I dont have mail installed.  If this doesnt
work then try changing the font types.  I have all the fonts set up for
helvetica (also gnome default) using proportional size 12, monospace 12 and min
font size 10.  It got rid of my problems with fonts in the browser and it should
work for mail.

Comment 17

17 years ago
Re comment 15: I was running self-compiled Mozilla from source 20030117. Without
any other change, the RH7 RPMs of the release were installed. From the same
login I restarted Mozilla and it showed the problem.

Re comment 16: Changing the fonts for what? Western? Unicode? Unchecking the box
for Western does not change anything and would be very bad for reading web pages.

I am having the same problem with the mozilla-1.3b-0_xft rpm.
Normally I use Galeon with this build, but I once started
Mozilla and I got the following (attached). No matter
what I do, the menu fonts remain small.

Comment 20

17 years ago
Posted file about:buildconfig
Problem is still there in Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a)
Gecko/2003031714 (built from source 03/16/03 14:01:00).

Does setting the font.uifont.pointheight preference to something like "15" help?
 Is it already set in your prefs.js?

Comment 22

17 years ago
Boris, you are a genius! You really seem to know every single line of the code.

No, it was not in my prefs.js. about:config did display a value of 10. Changing
it has the effect you'd expect. Great!

Should we mark this WFM now or look for the reason of the bad default (which
seemd to be a regression)?

Actually, I just saw a post about that pref on n.p.m.unix.... ;)

The only place it's set is build/package/rpm/SOURCES/mozilla-1.2.1-xft-prefs.js;
no idea why it would affect non-xft builds.

Chris, any idea what's up?
Woops.  I don't think I should have included that patch for the RH7 builds since
they don't use Xft.

Comment 25

17 years ago
*** Bug 197916 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
I also encountered this bug with the provisional help from Boris Zharsky,
I fixed it, for now, on my system.  The real problem is that the
default for the menus in most applications on my system - out-of-the box RH 7.3
- is 12-point Helvetica.  So to match that I went to about:config and set
the font to 12-point Helvetica.  The current setting, 10-point "sans",
appears to just be wrong.  There appears to be no "sans" font and it substitutes
Times-Roman.  BTW, I installed from the file mozilla-1.3-0_rh7.i386.rpm and
I am using Gnome with a configuration very close to default.

Meanwhile I encountered another problem.  If I try to change the settings in
about:config in the presence of more than one "user profile", the changes seem
to do nothing.  Even if I have only one profile, the changes only work if I quit
Mozilla and come back in again.  The user profile system is extremely confusing
in general and I think that it should be abolished.

Comment 27

16 years ago
*** Bug 200113 has been marked as a duplicate of this bug. ***

Comment 28

16 years ago

I just tried the font.uifont.pointheight hint, since
I have the same problem with 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030327 Debian/1.3-4

but neither is font.uifont.pointheight set nor does setting it cause
any difference...


Comment 29

16 years ago

I just found that it depends on the screen resolution (dpi):
If I do start the XFree86 server with -dpi 75, the menu fonts
become very small. If I use -dpi 100, they do look well. 
It seems that they are bigger than just the 75/100 ratio.

Should nevertheless be configurable.


Comment 30

16 years ago
This bug is KDE only, right? If it had "KDE" in the summary it would be easier to
find. And bug 140751 should probably depend on this.

My workaround is this (needs Gnome installed too and may depend on a particular
Xft setup): Before starting Mozilla, start /usr/bin/gnome-font-properties . You
can close it immediately or use it to set your Mozilla font properties (Mozilla
takes most of its settings, including antialiasing).

Comment 31

16 years ago
I had this same problem with mozilla-1.3b RH7 RPMs and later. This is with RH7.1
and Gnome-1.4.0. I solved it by enabling the Gnome Control Center -> Theme
Selector -> User Font checkbox, and setting the font selector underneath it to

Comment 32

16 years ago
running "gnome-font-properties" worked for me.  I need to run every time I boot
and before I run mozilla.  I'm suprised there isn't more activity in this bug...
 The last few major releases have had this problem.  I'm running KDE on Suse 9,
but had the same problem with recent builds on Suse 8.2.  The menu displays in a
very small font (which font depends on which one I have chosen in my font
properties in mozilla) unless I run "gnome-font-properties" before I start up

Comment 33

15 years ago
After upgrading from Woody to Sarge I now have the problem again. Setting
font.uifont.pointheight has no effect.

I am using 1.7RC2 (the Linux installer).

Sounds like you should contact your OS vendor, if the OS upgrade broke things.

Comment 35

15 years ago
Reporter, am I correct to assume in Sarge you are using an XFT-enabled Mozilla?
 (see about:buildconfig to find out if you don't know) If so, ensure that
Mozilla is seeing an appropriate DPI:

/etc/X11/XF86Config (normally, I don't know if Sarge is different) ->
Section "Monitor" ->
DisplaySize ###mmwidth ###mmheight

controls DPI in xfs, the legacy method of X font service.

/etc/X11/Xresources (in all distros I've tried, I don't know about Sarge) ->
Xft.dpi: ###

controls DPI in fontconfig/XFT, the modern method of font service.

Systems that use both font services (all current distros AFAIK) will have
inconsistent results among various apps if these two DPIs are not identical.
Find out your actual DPI under xfs using 'xdpyinfo | grep resolution' or in KDE
'kinfocenter' -> X-server. Adjust it if necessary to suit your personal taste by
changing DisplaySize. Once you're happy with the xfs DPI, use its value for Xft.dpi.

For addtional info on the effect of DPI, or for additional tweaking of the UI
fonts in Moz, see the following:

See also: bug 18454 & bug 172768

Comment 36

15 years ago
I use the precompiled version
I don't see anything about xft there:

Build platform

Build tools
Compiler 	Version 	Compiler flags
gcc 	gcc version 3.2.3 	-Wall -W -Wno-unused -Wpointer-arith -Wcast-align
-Wno-long-long -pedantic -pthread -pipe
c++ 	gcc version 3.2.3 	-fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe

Configure arguments
--disable-tests --enable-extensions=default,irc --without-system-nspr
--without-system-jpeg --without-system-zlib --without-system-png
--without-system-mng --disable-debug '--enable-optimize=-O2 -g' --enable-crypto

So that means I don't have an XFT-enabled Mozilla right?

Anyhow, before the upgrade I was also using those compiled builds.

/etc/X11/XF86Config-4 does not have DisplaySize, but something like this:
Section "Monitor"
        Identifier      "Monitor"
        HorizSync       30-92
        VertRefresh     50-85
        Option          "DPMS"

Section "Screen"
        Identifier      "Default Screen"
        Device          "Graphikkarte"
        Monitor         "Monitor"
        DefaultDepth    16
        SubSection "Display"
                Depth           1
                Modes           "1024x768"
[etc. for different depths]


Comment 37

15 years ago
That link you pasted in is for a Win32 build, not any help to this bug. Your
about:buildconfig report shows you're using a standard non-xft build, which is
highly likely not the best choice for Sarge, because Sarge probably is XFT enabled.

Section "Monitor"
        Identifier      "Monitor"
        HorizSync       30-92
        VertRefresh     50-85
        Option          "DPMS"

Section "Monitor"
        Identifier      "Monitor"
        DisplaySize      269 202 # 096 DPI @ 1024x768
        HorizSync       30-92
        VertRefresh     50-85
        Option          "DPMS"

and then run 'xdpyinfo | grep resolution'. Also read the links in comment 35.

Comment 39

15 years ago does not provide xft builds of the 1.7x series. You can build your
own if you can't find some other source:

Comment 40

15 years ago
I don't have time to build my own version. Anyhow I made the change to

xdpyinfo | grep resolution now gives:
resolution:    96x96 dots per inch
(before it was 81x81 I believe). Does not change anything, though. But that was
expected, I understand.


Comment 41

15 years ago
note besides the larger chrome text that the page font rendering is superior to
the non-xft 1.7 build in attachment following

Comment 42

15 years ago
note besides the smaller chrome text that the page font rendering is inferior
to the xft 1.4 build shipped with the OS
Product: Browser → Seamonkey


14 years ago
Assignee: asa → general
QA Contact: asa → general

Comment 43

14 years ago
is this bug still a problem?
also, gtk2/xft builds of Mozilla 1.7.x are available in the contrib subdirectory.
No reply to comment #43 after 2½ years. No dependencies. Resolving INCOMPLETE.
Closed: 11 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.