Closed Bug 194500 Opened 22 years ago Closed 17 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: 17 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: