Closed Bug 194500 Opened 22 years ago Closed 16 years ago

Fonts too small in menus and group pane and subject pane

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INCOMPLETE

People

(Reporter: 3.14, Unassigned)

References

Details

Attachments

(5 files)

Screenshot showing the problem
48.81 KB, image/png
Details
screenshot with small xft font
81.88 KB, image/png
Details
about:buildconfig
1.41 KB, text/html
Details
screenshot - xft 1.4 on XFT SuSE 9.0 system
192.39 KB, image/png
Details
screenshot - non-xft 1.7 on same XFT SuSE 9.0 system as attachment 149532
81.43 KB, image/png
Details 
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.

pi

    
    

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

    
    

    
  
No, that setting has no effect for this problem.

pi

    
    

    
  
Are you using an xft build?

    
    

    
  
I am usuing this version, no idea how it was compiled:
http://ftp.mozilla.org/pub/mozilla/releases/mozilla1.3b/Red_Hat_7x_RPMS/RPMS/i386/

pi

    
    

    
  
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?

    
    

    
  
Yes, same for both themes.

pi

    
    

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

pi

    
    

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

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

    
    

    
  
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.

pi

    
    

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

Are you possibly using a dual-monitor setup?

    
    

    
  
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.

pi

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
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.

pi

    
    

    
  
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.

    
    

    
  

      
      
      
      

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

pi

    
    

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

    
    

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

pi

    
    

    
  
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.

    
    

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

    
    

    
  
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.

    
    

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

    
    

    
  
Hi,

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

regards
Hadmut

    
    

    
  
Hi, 

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.

regards
Hadmut

    
    

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


    
    

    
  
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
helvetica-medium-12.

    
    

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

    
    

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

pi

    
    

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

    
    

    
  
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:
http://bugzilla.mozilla.org/show_bug.cgi?id=206748#c1
http://bugzilla.mozilla.org/show_bug.cgi?id=206975#c14
http://bugzilla.mozilla.org/show_bug.cgi?id=238962#c4

See also: bug 18454 & bug 172768

    
    

    
  
I use the precompiled version
(http://ftp.mozilla.org/pub/mozilla.org/mozilla/releases/mozilla1.7rc2/mozilla-win32-1.7rc2-installer.exe).
I don't see anything about xft there:

Build platform
target
i686-pc-linux-gnu

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
-I/usr/X11R6/include

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"
EndSection

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

pi

    
    

    
  
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.

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

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

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

    
    

    
  
mozilla.org does not provide xft builds of the 1.7x series. You can build your
own if you can't find some other source: http://www.mozilla.org/build/unix.html

    
    

    
  
I don't have time to build my own version. Anyhow I made the change to
/etc/X11/XF86Config-4.

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.

pi

    
    

    
  


  
note besides the larger chrome text that the page font rendering is superior to
the mozilla.org non-xft 1.7 build in attachment following

    
    

    
  


  
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

    
  
Assignee: asa → general
QA Contact: asa → general

    
    

    
  
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.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: