Closed Bug 382570 Opened 17 years ago Closed 17 years ago

Wrong Fonts (Serif) used in Suiterunner Program and MailNews

Categories

(SeaMonkey :: General, defect)

x86
Windows XP
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: tobias, Unassigned)

References

Details

(Keywords: regression)

Attachments

(4 files)

Using Suiterunner Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a5pre) Gecko/2007053022 SeaMonkey/2.0a1pre

the Program-Fonts are set to Serif-Fonts (Times New Roman I think?), but Suiterunner should use the System default (or set System Default), here MS Sans Serif. 

Older Suiterunner Builds from tpol are using the System Default, this happen first with Builds from WINNT 5.2 sea-win32-tbox Clbr VM-release Box.
Keywords: regression
Did you use th zip or installer build?
I have used the *.zip-Builds, formerly XPFE-zip, than the official Suiterunner-Trunk-Builds.  

I prefer the *.zip Builds, it was much easier to change the Build for testing.
Hmm, now I have tried the 2007060310-Tinderbox-Installer-Build, and there is no difference, Programm-Fonts are Serif. 
I also see this with my self compiled Linux build from cvs.

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007060301 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre

As you can see at my screenshot, it seems to be exactly the same font as at Tobias' screenshot.
Tobias says, he thinks the font is "Times New Roman". I also have this font here installed on Linux, but I'm not really sure if it's that font.

Actually I only see it when using a migrated profile (created with SM 1.x, using the migrator from bug 329744). 

When creating a new profile with the suiterunner-SeaMonkey a non-serif font is used correctly.
(In reply to comment #4)
[...]
> Actually I only see it when using a migrated profile (created with SM 1.x,
> using the migrator from bug 329744). 
> 
> When creating a new profile with the suiterunner-SeaMonkey a non-serif font is
> used correctly.
> 

I have tested this while choosing "Don't import anything" from Profile-Migrator, and I get the wrong Fonts too. So I also get the wrong Font when I only create an new Profile without importing old Stuff. 

Next, I have reactivated tpol-Build 2007052023 and created an new Profile with that. The used Fonts are like expected "Sans Serif", but when I use this Profile with Suiterunner-Build 2007060400, the used Fonts are "Serif" again. 

Additionally, when I startup an SeaMonkey-Suiterunner-Trunk-Build and the Profile-Migrator comes up, the Migrator will show the wrong Serif-Fonts too. 
(In reply to comment #5)
> (In reply to comment #4)
> [...]
> > Actually I only see it when using a migrated profile (created with SM 1.x,
> > using the migrator from bug 329744). 
> > 
> > When creating a new profile with the suiterunner-SeaMonkey a non-serif font is
> > used correctly.
> > 
> 
> I have tested this while choosing "Don't import anything" from
> Profile-Migrator, and I get the wrong Fonts too. So I also get the wrong Font
> when I only create an new Profile without importing old Stuff. 

If choosing "Don't import anything" no new profile is created here. I am lead to the default (imported) profile. And I still get the wrong fonts there.

If I start SM with "seamonkey -profilemanager" I can create a new profile that does have the correct sansserif fonts. 

> Additionally, when I startup an SeaMonkey-Suiterunner-Trunk-Build and the
> Profile-Migrator comes up, the Migrator will show the wrong Serif-Fonts too. 

If I start SM with "seamonkey -migration" the migration wizard comes up with correct sansserif fonts.
The big difference between the last tpol build (that will get overwritten soon with a new one) and current builds is that with adding the installer, we also made zip builds be generated from a package list instead of just packing up the files in dist/bin

There's a possibility that we're not yet packaging all files we should package.
Tobias: Can you download the build from http://www.mcsmurf.de/mozilla/suiterunner-bin.zip, extract it somewhere and test if you also get the wrong fonts with that build? This is a standard suiterunner build, just with everything in bin/ packaged (instead of a script only packaging some files, though that should work, too)...
Thanks for your work Frank, I have tested this Build and the wrong Fonts still live on with it. :(

I have investigated a little more and found out, that I get the wrong Serife Fonts, when I use an Windows-User-Profile where the System-Fonts are set all to "MS Sans Serif". 
Using another Windows-User-Profile with default settings (dosn't matter if I choose XP-Style or Classic-Windows-Style) so that "Tahoma" was set as default Screen-Font, I get the expectet "Sans Serif"-Font in Suiterunner too. 

But changing back the Windows-Screen-Fonts back to "MS Sans Serif" will bring back the Serif-Font in Suiterunner. Same on my second Machine using Win2k, I have set the System-Screen-Font to MS Sans Serif there too. 

As I remember "MS Sans Serif" was not fit for UTF-8, probably this will cause the wrong Serif-Font in Suiterunner. 

But now I wonder, why I get the Sans Serif Fonts in older tpol Builds using this Settings with MS Sans Serif as default Screen Font in Windows. 
I also did some further testing with my self compiled 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/2007060721 Mnenhy/0.7.5.0 SeaMonkey/2.0a1pre 
with a completely new profile created by using suiterunner's  profilemanger.

At first I got the correct nonserif fonts both on UI and on the content windows.

Then I just changed the fontsize for Western/Monospace from the standard 12 to 14.

The effect was kind of weird: Many formerly nonserif fonts on the websites changed to Monospace 14. After a restart of SM also the GUI's font changed to be Monospace 14.

See the screenshot for details: 
-on bonsai I usually don't get monospace fonts
-see the input search field on google
-see the monospace ui on both browser window and prefpanel
If you just delete all font.name.* prefs everthing changes back to normal.
This also explains why I first only saw this bug with an old migrated profile. That profile has several font.name.* prefs.
Further tests show me, that a
 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a6pre) Gecko/20070610 Minefield/3.0a6pre
also has these problems. After changing a font at Edit ->Prefs ->Content ->Fonts&Colors this font will also be used for the GUI.

However I could not find a FF related bug. But bugzilla-searches are still a kind of magic for me. ;-) Please perform some searches yourself.
(In reply to comment #11)
> If you just delete all font.name.* prefs everthing changes back to normal.
> This also explains why I first only saw this bug with an old migrated profile.
> That profile has several font.name.* prefs.
> 

Sorry, but where I can delete the "font.name.*" prefs? I can see them via about:config, but can't delete them there. And there are now "font.name.*" prefs in the user.js, so I couldn't find them at an editorable place. 

Using Tahoma as default Screen/System Font in Windows is quite a mess, MS Sans Serif was much better as Screen-UI-Font in my opinion. 
(In reply to comment #13)
> (In reply to comment #11)
> > If you just delete all font.name.* prefs everthing changes back to normal.

> Sorry, but where I can delete the "font.name.*" prefs?

I edited the prefs.js directly (while SeaMonkey was closed of course).
Urgh, of course I meant the "prefs.js", not user.js. Add my actual prefs.js as attachment, there are no prefs for "fonts.name.*" in it.
(In reply to comment #15)
> Created an attachment (id=267950) [details]
> prefs.js from actual SeaMonkey-Suiterunner
> 
> Urgh, of course I meant the "prefs.js", not user.js. Add my actual prefs.js as
> attachment, there are no prefs for "fonts.name.*" in it. 

I can see
user_pref("font.name.fantasy.x-western", "Albertus MT Lt");
in this.

Try to delete this and I think your fonts will change back to "normal".
Thanks for have a look, I've got some headache today. 

But deleting this line in my prefs.js has no effect for the UI-Font. 

I have tried to check the Diffs in some Files from old 2007052023-tpol-Build to the new SeaMonkey-Trunk-Builds, but at moment I haven't found anything specific. 

Also I have tried to copy the files existing in old tpol-Build but not new Trunk-Build into the right directories from the Trunk-Build, but this helps not, so I don't know if there was a File missing in the Trunk-Package. 

Did someone know were the Settings to import/read for Windows-System-Default-Screenfonts are?
OK, from our discussions on IRC, the Windows and Linux builds might show the same symptoms, but it's two different underlying problems, as the font selection happens in a platform-specific way.

Windows has regressed to not support Bitmap fonts, that's known and this is bug 324706 - as this bug has originally been filed on Windows, setting this dependency here.

The Linux issue is not that clear, but should be dealt with in a separate, new bug.
Depends on: 324706
Filed bug 385258 for the Linux symptoms.
This issue was fixed with the patch from Bug 324706, so I mark this Bug as resolved=fixed now, hope thats the right solution.

Sorry for my delay in testing and reporting to Bugzilla. 
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: