Last Comment Bug 432575 - OS/2 fontconfig issues compared to ft2lib
: OS/2 fontconfig issues compared to ft2lib
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Graphics (show other bugs)
: Trunk
: x86 OS/2
: -- major (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 439187 439190 439193 439194 439195
Blocks: 371503
  Show dependency treegraph
 
Reported: 2008-05-06 21:19 PDT by Steve Wendt
Modified: 2011-12-12 13:43 PST (History)
9 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
sm119 menus, for comparison (9.05 KB, image/jpeg)
2008-05-06 21:30 PDT, Steve Wendt
no flags Details
sm20a1 menus (10.46 KB, image/jpeg)
2008-05-06 21:42 PDT, Steve Wendt
no flags Details
sm119 font prefs, for comparison (44.27 KB, image/jpeg)
2008-05-06 21:42 PDT, Steve Wendt
no flags Details
sm20a1 font prefs (41.24 KB, image/jpeg)
2008-05-06 21:51 PDT, Steve Wendt
no flags Details
sm119 mailnews, for comparison (37.46 KB, image/jpeg)
2008-05-06 21:52 PDT, Steve Wendt
no flags Details
sm20a1 mailnews (37.90 KB, image/jpeg)
2008-05-06 21:56 PDT, Steve Wendt
no flags Details
sm119 bugzilla text, for comparison (9.27 KB, image/jpeg)
2008-05-06 21:57 PDT, Steve Wendt
no flags Details
sm20a1 bugzilla text (9.49 KB, image/jpeg)
2008-05-06 21:59 PDT, Steve Wendt
no flags Details
sm119 os2.jp, for comparison (42.59 KB, image/jpeg)
2008-05-06 22:00 PDT, Steve Wendt
no flags Details
sm20a1 os2.jp (40.62 KB, image/jpeg)
2008-05-06 22:03 PDT, Steve Wendt
no flags Details
sm119 Warpzilla newsbits, for comparison (30.08 KB, image/jpeg)
2008-05-06 22:09 PDT, Steve Wendt
no flags Details
sm20a1 Warpzilla newsbits (31.69 KB, image/jpeg)
2008-05-06 22:10 PDT, Steve Wendt
no flags Details
sm20a1 bugzilla flags (8.06 KB, image/jpeg)
2008-05-06 22:13 PDT, Steve Wendt
no flags Details
output of fonts_test (font listing) (7.09 KB, text/plain)
2008-05-06 22:15 PDT, Steve Wendt
no flags Details
screenshot - 120 DPI & 10pt system menu fonts (128.71 KB, image/png)
2008-05-07 11:55 PDT, Felix Miata
no flags Details
antialiasing/emboldening options (35.60 KB, image/png)
2008-05-09 14:22 PDT, Peter Weilbacher
no flags Details
MailNews screenshots with and without embolden (51.46 KB, image/png)
2008-05-09 16:49 PDT, Peter Weilbacher
no flags Details
Thebes Test DLL (444.04 KB, application/zip)
2008-05-09 18:16 PDT, Peter Weilbacher
no flags Details
sm119 vs test thebes (full hinting) (63.73 KB, image/png)
2008-05-10 00:29 PDT, Steve Wendt
no flags Details
sm119 mailnews vs thebes test vs no anti-aliasing (98.25 KB, image/png)
2008-05-10 00:32 PDT, Steve Wendt
no flags Details
sm119 status line vs thebes test (2.46 KB, image/png)
2008-05-10 00:33 PDT, Steve Wendt
no flags Details
add hinting and environment variables (3.74 KB, patch)
2008-05-25 14:17 PDT, Peter Weilbacher
no flags Details | Diff | Splinter Review
add hinting and antialiasing prefs [checked in] (4.32 KB, patch)
2008-05-28 05:35 PDT, Peter Weilbacher
no flags Details | Diff | Splinter Review
portion of MathML test page (9.91 KB, image/png)
2008-05-31 17:15 PDT, Steve Wendt
no flags Details
comparison of 9pt vs 10pt (85.69 KB, image/png)
2008-06-03 21:24 PDT, Steve Wendt
no flags Details
Bugzilla form fields with old wpsu font (32.29 KB, image/png)
2010-06-23 22:18 PDT, Steve Wendt
no flags Details
Bugzilla form fields with new wpsu font (30.92 KB, image/png)
2010-06-23 22:19 PDT, Steve Wendt
no flags Details

Description Steve Wendt 2008-05-06 21:19:44 PDT
The rendering of fonts is suboptimal in trunk builds, as compared to ft2lib in Seamonkey 1.1.x.  Screen captures will illustrate the points.
Comment 1 Steve Wendt 2008-05-06 21:30:51 PDT
Created attachment 319712 [details]
sm119 menus, for comparison
Comment 2 Steve Wendt 2008-05-06 21:42:23 PDT
Created attachment 319713 [details]
sm20a1 menus

The text in the menus is smaller and fuzzier; you can't make out the letter 'i' very well in File, Edit, View, etc.  On the plus side, the underlines for the accelerator keys stands out better.
Comment 3 Steve Wendt 2008-05-06 21:42:56 PDT
Created attachment 319714 [details]
sm119 font prefs, for comparison
Comment 4 Steve Wendt 2008-05-06 21:51:03 PDT
Created attachment 319715 [details]
sm20a1 font prefs

As in the menus, the text is smaller and fuzzier; the text is gray instead of black (due to anti-aliasing?) making it harder to read.  This is WorkPlace Sans rather than WarpSans, but I don't think that is the issue.

The "serif" and "sans-serif" selections are how the profile migrator converted from "Tms Rmn" and "Helv."  These two and WarpSans are not supported by the OS/2 fontconfig, since they are not TrueType, but I believe these settings are getting mapped to "Times New Roman" and "Helvetica."
Comment 5 Steve Wendt 2008-05-06 21:52:25 PDT
Created attachment 319716 [details]
sm119 mailnews, for comparison
Comment 6 Steve Wendt 2008-05-06 21:56:26 PDT
Created attachment 319718 [details]
sm20a1 mailnews

Like the prefs tree, the folder tree is too gray and fuzzy.  The captions under the icons, such as 'Get Msgs' are too small and fuzzy.  The heading 'Seamonkey Mail - Local Folders' looks really weird, as do the sub-headings 'Accounts' and 'Advanced Features.'
Comment 7 Steve Wendt 2008-05-06 21:57:24 PDT
Created attachment 319719 [details]
sm119 bugzilla text, for comparison
Comment 8 Steve Wendt 2008-05-06 21:59:36 PDT
Created attachment 319720 [details]
sm20a1 bugzilla text

Note how the 'RESOLVED FIXED' text looks blocky.
Comment 9 Steve Wendt 2008-05-06 22:00:45 PDT
Created attachment 319721 [details]
sm119 os2.jp, for comparison
Comment 10 Steve Wendt 2008-05-06 22:03:35 PDT
Created attachment 319722 [details]
sm20a1 os2.jp

Note how the line-spacing is doubled.  'OS2.jp' is smaller and non-bold.  The Japanese characters are less distinct (fuzziness?).
Comment 11 Steve Wendt 2008-05-06 22:09:33 PDT
Created attachment 319723 [details]
sm119 Warpzilla newsbits, for comparison
Comment 12 Steve Wendt 2008-05-06 22:10:40 PDT
Created attachment 319724 [details]
sm20a1 Warpzilla newsbits

The text looks bigger, bolder, and blockier here.  Perhaps the same as the bugzilla text example.
Comment 13 Steve Wendt 2008-05-06 22:13:27 PDT
Created attachment 319725 [details]
sm20a1 bugzilla flags

The hyphens in the bugzilla flags are some weird character.
Comment 14 Steve Wendt 2008-05-06 22:15:55 PDT
Created attachment 319726 [details]
output of fonts_test (font listing)
Comment 15 Steve Wendt 2008-05-06 22:18:25 PDT
Font settings in prefs.js:

user_pref("font.name.cursive.he", "Andale Mono");
user_pref("font.name.cursive.tr", "Andale Mono");
user_pref("font.name.cursive.x-western", "Andale Mono");
user_pref("font.name.fantasy.he", "Andale Mono");
user_pref("font.name.fantasy.tr", "Andale Mono");
user_pref("font.name.fantasy.x-western", "Andale Mono");
user_pref("font.name.sans-serif.x-western", "sans-serif");
user_pref("font.name.serif.x-western", "serif");
Comment 16 Peter Weilbacher 2008-05-07 00:58:44 PDT
Thanks, Steve, for the details. That's a lot of stuff to go through, will try that over the next days.

The most puzzling is why "Times New Roman MT 30" doesn't get picked up for the Bugzilla hyphens.

Not sure that all problems are solvable, though. The OS2.jp case is because Japanese fonts were changed from sans-serif to serif by default to pick up the default OS/2 Unicode fonts. It is unfortunate, that this font has a larger line-height.

The migration as shown in attachment 319714 [details] and attachment 319715 [details] is correct. You obviously never touched the Serif and Sans-Serif settings for Western, and so it just shows the new defaults in the panel. They will get resolved to the same fonts.

P.S.: Next time you make screenshots, it would be nice to use PNG format. JPEG makes fonts fuzzy, so the problematic details don't stand out as clearly.
Comment 17 Steve Wendt 2008-05-07 11:41:35 PDT
(In reply to comment #16)
> The OS2.jp case is because Japanese fonts were changed from sans-serif to 
> serif by default to pick up the default OS/2 Unicode fonts.

I can't read Japanese, so any preferences stated by Japanese users should certainly take precedence.  ;-)

> Next time you make screenshots, it would be nice to use PNG format.

OK, no problem.
Comment 18 Felix Miata 2008-05-07 11:55:31 PDT
Created attachment 319834 [details]
screenshot - 120 DPI & 10pt system menu fonts

Other than the accelerator key underlines, I'm hard pressed to detect any font differences between branch & trunk.

Re: comment 4 there is a Workplace Sans issue, because the default system menu font is WarpSans bold, which branch is using, while Workplace Sans AFAIK does not exist in bold. That leaves trunk to menu with normal weight as long as menu is set to Workplace TTF instead of WarpSans bitmap.
Comment 19 Felix Miata 2008-05-07 11:57:28 PDT
http://fm.no-ip.com/auth/Font/fonts-comps-ecs.html can be used for convenient comparison of common OS/2 fonts.
Comment 20 Peter Weilbacher 2008-05-09 14:22:43 PDT
Created attachment 320273 [details]
antialiasing/emboldening options

My system is set to display menus in 9 WarpSans Bold. From top to bottom in this series of screenshots are the options that I can see:

0. SM 1.1.9 with FT2LIB: fairly good reproduction of the text in OS/2 PM menus, here just for comparison.

1. SM normal trunk build: reproduction soso, fonts are antialiased and the artificial emboldening of Workplace Sans looks a bit different than WarpSans bold.

2. SM trunk without antialiasing: bad display, some characters are unreadable (like 'i') others have funny kinks (like 'b' and 's'). Some other text in the UI is completely unrecognizable.

3. SM trunk without emboldening: looks nice, but not like PM menus.

4. SM trunk without emboldening and without antialiasing: Looks nice, too, but still not like PM menus.

Of the options for trunk I really like 1 best...
Comment 21 Steve Wendt 2008-05-09 15:04:46 PDT
(In reply to comment #20)
> 2. SM trunk without antialiasing: bad display, some characters are unreadable
> (like 'i') others have funny kinks (like 'b' and 's'). Some other text in the
> UI is completely unrecognizable.

This one is definitely no good...

> 3. SM trunk without emboldening: looks nice, but not like PM menus.

This one is a little fuzzy, but not bad.

> 4. SM trunk without emboldening and without antialiasing: Looks nice, too, but
> still not like PM menus.

This one looks best to me.

> Of the options for trunk I really like 1 best...

I'm curious how options 3 and 4 look in other places (text under icons in mail/news, status bar, prefs tree and mail/news folder tree).  Those examples might provide stronger reasons to lean toward a different option.  In the worst case, there could be an environment variable to choose, as suggested in an earlier bug, but it would be nice to just have one good option.  I guess the best option would be a bold version of Workplace Sans, but that may or may not come into existence.
Comment 22 Peter Weilbacher 2008-05-09 16:49:11 PDT
Created attachment 320302 [details]
MailNews screenshots with and without embolden

The non-bold options may look better on first glance but they are unusable, especially because MailNews uses bold font to signify new messages. Well, there are always different indicators, too, but those are less visible. With the bold switched off you can't quickly see any more which folders have new messages or which messages in the message list are unread.

Well, these are screenshot of the MailNews window showing the top level view of a News account. From top to bottom:
- current SM trunk (with embolden and antialias switched on)
- SM trunk without embolden but with antialias
- SM trunk without embolden and without antialias

I don't think this is any better than what we have, Workplace Sans just looks weird at large sizes.
Comment 23 Peter Weilbacher 2008-05-09 18:16:38 PDT
Created attachment 320314 [details]
Thebes Test DLL

OK, I discovered that font hinting could make a difference, too. Setting full hinting mode on seems to help non-bold Workplace Sans but also seems to make webpages a bit worse.

So I made this test version of the Thebes DLL that has full hinting on by default. It also lets you play with the options by setting environment variables. See details in the ReadMe file. It should work with the last available SM trunk nightly.
Comment 24 Steve Wendt 2008-05-10 00:24:38 PDT
(In reply to comment #23)
> So I made this test version of the Thebes DLL that has full hinting on by
> default. It also lets you play with the options by setting environment
> variables. See details in the ReadMe file.

Thanks!

> OK, I discovered that font hinting could make a difference, too. Setting full
> hinting mode on seems to help non-bold Workplace Sans but also seems to make
> webpages a bit worse.

Yes, I can see what you mean.  Comments to follow, with attachments.
Comment 25 Steve Wendt 2008-05-10 00:29:19 PDT
Created attachment 320335 [details]
sm119 vs test thebes (full hinting)

With full hinting, the letter 'e' looks too much like a 'c'
Comment 26 Steve Wendt 2008-05-10 00:32:07 PDT
Created attachment 320336 [details]
sm119 mailnews vs thebes test vs no anti-aliasing

Without anti-aliasing, the text is darker, but it's really ugly.
Comment 27 Steve Wendt 2008-05-10 00:33:25 PDT
Created attachment 320338 [details]
sm119 status line vs thebes test

The text in the status line, menus, and under the icons in mail/news sure looks smaller than before.  Maybe it would help legibility to use a slightly larger size?
Comment 28 Peter Weilbacher 2008-05-14 16:02:20 PDT
(In reply to comment #16)
> The most puzzling is why "Times New Roman MT 30" doesn't get picked up for the
> Bugzilla hyphens.

I debugged this and found out that to my surprise "Times New Roman MT 30" doesn't contain the glyph for that hyphen. But I'm not sure I understand correctly: did the hyphen correctly show up in nightlies before 2008-05-01?

(Still thinking about the hinting/antialiasing issue without any good ideas.)
Comment 29 Peter Weilbacher 2008-05-17 11:21:43 PDT
(In reply to comment #28)
> I debugged this and found out that to my surprise "Times New Roman MT 30"
> doesn't contain the glyph for that hyphen. But I'm not sure I understand
> correctly: did the hyphen correctly show up in nightlies before 2008-05-01?

In my testing it doesn't even show up on the 1.8 branch, unless I set the Unicode font to something else than the default TNR MT 30. The non-breaking hyphen (Unicode decimal 2011) is contained in the DejaVu Unicode fonts as well as the Free* fonts and others. Steve, I don't see any font in your font listing that does contain it.

I could fix that by treating it as a special character and if not found replace it with a normal hyphen. But if I start doing that for one character I will probably soon have to do it for more, so this doesn't seem like a good idea.
Comment 30 Steve Wendt 2008-05-17 16:34:34 PDT
(In reply to comment #29)
> > did the hyphen correctly show up in nightlies before 2008-05-01?

I had not tried earlier nightlies; is there some reason to think there might be a difference?  If so, I can certainly try them.

> In my testing it doesn't even show up on the 1.8 branch
> Steve, I don't see any font in your font listing that does contain it.

Well, it certainly gets displayed properly.  Is there something I can do to determine why?

> I could fix that by treating it as a special character and if not found 
> replace it with a normal hyphen. But if I start doing that for one character 
> I will probably soon have to do it for more, so this doesn't seem like a  
> good idea.

Agreed.
Comment 31 Peter Weilbacher 2008-05-24 12:06:24 PDT
(In reply to comment #30)
> I had not tried earlier nightlies; is there some reason to think there might be
> a difference?  If so, I can certainly try them.

I checked in a patch that sets different default fonts for some languages.

> Well, it certainly gets displayed properly.  Is there something I can do to
> determine why?

Yes, you can download
   http://temp.weilbacher.org/fonts_search_chars.zip
and then run the contained program like this:
   fonts_search_chars.exe 8209
That should give you a list of fonts that contain that hyphen, in case I overlooked one.


I found a way to modify FreeType's emboldening routine so that it only emboldens horizontally. Looking at WarpSans Bold it seems to me that this is similar to what is done at least for that font. Combined with hinting this looks much better than what we currently have. Now I just need to find a way to make hinting non-destructive for Type1 fonts (like "Times New Roman") that don't have hinting instructions (that is why the "e" looks weird in Steve's screenshot of attachment 320335 [details]).
Comment 32 Peter Weilbacher 2008-05-25 14:17:14 PDT
Created attachment 322455 [details] [diff] [review]
add hinting and environment variables

Didn't find a way to disable hinting for Type 1 fonts. I think we should still activate it by default, the characters indeed look a lot sharper!

User switches, as in the test DLL I posted earlier, then make sense. This patch would let it react to
   set MOZ_HINTING=n (where n=0...3, default = 2)
   set MOZ_NO_EMBOLDEN=1
   set MOZ_NO_ANTIALIAS=1

Instead of inventing these environment variables, perhaps it would be more clever to add hidden preferences, like
   gfx.os2.hinting   (integer, 0 to 3, default = 2)
   gfx.os2.antialias (boolean, default = true)
   gfx.os2.embolden  (boolean, default = true)
Then one doesn't need to restart for changes to get active.
Comment 33 Peter Weilbacher 2008-05-25 14:28:56 PDT
The DLL in thebes_test_2008052409.zip implements the aforementioned patch (plus a bit of extra debugging) and the horizontal-only emboldening, for those who want to test it with the latest SeaMonkey nightly.
Comment 34 Felix Miata 2008-05-25 16:05:31 PDT
(In reply to comment #32)
> Instead of inventing these environment variables, perhaps it would be more
> clever to add hidden preferences, like
>    gfx.os2.hinting   (integer, 0 to 3, default = 2)
>    gfx.os2.antialias (boolean, default = true)
>    gfx.os2.embolden  (boolean, default = true)
> Then one doesn't need to restart for changes to get active.
 
And one can have different behavior for different apps and/or profiles, and better compare with/without to make best settings selections.
Comment 35 Steve Wendt 2008-05-25 21:44:08 PDT
(In reply to comment #31)
> That should give you a list of fonts that contain that hyphen, in case I
> overlooked one.

These three, apparently:
Lucida Sans Regular
Lucida Sans Oblique
Workplace Sans Regular

I have a fuzzy recollection of Mike Kaply mentioning once that there was code to find a match for characters in the installed fonts, if the first choice didn't have it (perhaps similar to this test code?).

(In reply to comment #32)
> Instead of inventing these environment variables, perhaps it would be more
> clever to add hidden preferences
> Then one doesn't need to restart for changes to get active.

I like this idea.
Comment 36 Peter Weilbacher 2008-05-26 14:02:47 PDT
(In reply to comment #35)
> These three, apparently:
> Lucida Sans Regular
> Lucida Sans Oblique
> Workplace Sans Regular

And have you configured any of those in the profile where the dash is displayed?

> I have a fuzzy recollection of Mike Kaply mentioning once that there was code
> to find a match for characters in the installed fonts, if the first choice
> didn't have it (perhaps similar to this test code?).

Yes, it tries to replace the character from the Unicode font. That is what I implemented on trunk, too. But in neither case does it search all fonts available on the system, but only those that are configured in Mozilla somehow.
I meant to implement such font matching across _all_ fonts but my first approaches were too slow on pages where many characters were missing. I still plan to implement the Windows and Mac way on OS/2 but that will take time.
Comment 37 Steve Wendt 2008-05-26 19:40:48 PDT
(In reply to comment #36)
> And have you configured any of those in the profile where the dash is
> displayed?

No, all font.* settings are at default; for Unicode that is:
Times New Roman MT 30, Times New Roman WT J, Times New Roman WT SC, Times New Roman WT TC, Times New Roman WT K, Tms Rmn

I don't know how to check if Tms Rmn has that character; copying and pasting into 'E' just gives me a '?' even if the font is set to Lucida Sans.
Comment 38 Peter Weilbacher 2008-05-28 05:35:43 PDT
Created attachment 322762 [details] [diff] [review]
add hinting and antialiasing prefs [checked in]

OK, so this is the patch to use hidden prefs for antialiasing and hinting:

   pref                       type  values  default
   gfx.os2.font.hinting       int   0...3   2
   gfx.os2.font.antialiasing  bool          true

I tested using an option for emboldening, but had twice some really weird effects when switching that option without restarting, like windows which were only partly painted. And I don't really think that there would be much use for it (if you disagree, please convince me :-)).

The hinting and antialiasing options don't cause any problem when switching without restarting, but they only take effect if a font gets used for the first time.

I'll check this in in a minute (to get it into the code for FF3rc2) and over night set off new nightly builds that have this options.
Comment 39 Peter Weilbacher 2008-05-28 05:52:28 PDT
(In reply to comment #37)
> (In reply to comment #36)
> > And have you configured any of those in the profile where the dash is
> > displayed?
> 
> No, all font.* settings are at default; for Unicode that is:
> Times New Roman MT 30, Times New Roman WT J, Times New Roman WT SC, Times New
> Roman WT TC, Times New Roman WT K, Tms Rmn

It actually takes into account all of

Deja Vu Serif, FreeSerif, Times New Roman WT*, Times New Roman MT 30, Gentium, Doulos SIL, TITUS Cyberbit Basic, Bitstream Cyberbit, Charis SIL, Georgia, Tms Rmn and also some unicode sans-serif fonts which you don't have installed. (Take a look at the name.*.x-unicode and name-list.*.x-unicode preferences in greprefs\all.js.)

Perhaps I should add Workplace Sans to font.name-list.sans-serif.x-unicode by default. What happens if you do that?

> I don't know how to check if Tms Rmn has that character; copying and pasting
> into 'E' just gives me a '?' even if the font is set to Lucida Sans.

Perhaps with Alex Taylor's CPMAP program?
Comment 40 Steve Wendt 2008-05-31 17:15:59 PDT
Created attachment 323249 [details]
portion of MathML test page

I also get some junk on the MathML test page; it looks like it should be some white space character?
Comment 41 Steve Wendt 2008-05-31 17:23:31 PDT
(In reply to comment #39)
> Perhaps I should add Workplace Sans to font.name-list.sans-serif.x-
> unicode by default. What happens if you do that?

It doesn't seem to help.  I see that it lists Helv, so that should probably get removed if the list gets updated (unless Helvetica has some useful glyphs in it?).  Lots of the font.name.sans-serif.* entries also point to Helv by default.

> > I don't know how to check if Tms Rmn has that character; copying 
> > into 'E' just gives me a '?' even if the font is set to Lucida Sans.
> 
> Perhaps with Alex Taylor's CPMAP program?

That only seems to show the first 256 ASCII characters, unless there is an option I'm missing.
Comment 42 Steve Wendt 2008-05-31 17:29:45 PDT
(In reply to comment #36)
> > I have a fuzzy recollection of Mike Kaply mentioning once that there 
> > was code to find a match for characters in the installed fonts,
> 
> Yes, it tries to replace the character from the Unicode font.

Is that related to this variable?  Does trunk still do something if this is present? MOZILLA_USE_EXTENDED_FT2LIB=T

Are the DejaVu fonts the ones recommended for UniCode now?  Or is Code 2000 still the recommendation?
Comment 43 Steve Wendt 2008-05-31 17:51:46 PDT
(In reply to comment #41)
> > Perhaps I should add Workplace Sans to font.name-list.sans-serif.x-
> > unicode by default. What happens if you do that?
> 
> It doesn't seem to help.

If I add it to font.name-list.serif.x-unicode, then it makes a difference.  I see that font.default.x-unicode is defaulted to serif (NOT sans-serif).  If I use Code2000 there instead, it fixes both Bugzilla and the MathML test case.

But since these both appear to be Sans Serif fonts, that's probably not a good solution.  Maybe the Deja Vu fonts are a good choice?
Comment 44 Steve Wendt 2008-05-31 18:19:46 PDT
(In reply to comment #43)
> Maybe the Deja Vu fonts are a good choice?

Well, Deja Vu Serif works for MathML, but not Bugzilla.  Gentium seems to work for both - is that what you are using, Peter?
Comment 45 Felix Miata 2008-05-31 18:21:52 PDT
Just an educated guess that if DejaVu doesn't already have the broadest unicode glyph coverage, it won't be long before it does if past rate of development is any indication.
Comment 46 Steve Wendt 2008-05-31 19:51:05 PDT
(In reply to comment #27)
> The text in the status line, menus, and under the icons in mail/news 
> sure looks smaller than before.  Maybe it would help legibility to use a 
> slightly larger size?

Can this be tweaked via usercontent.css?  I can't find WarpSans or Workplace Sans in about:config anywhere...

(In reply to comment #36)
> Yes, it tries to replace the character from the Unicode font.

How about iterating both Serif and Sans Serif, instead of just Serif?
Comment 47 Peter Weilbacher 2008-06-01 10:27:38 PDT
Comment on attachment 322762 [details] [diff] [review]
add hinting and antialiasing prefs [checked in]

This was checked in on 2008-05-28.
Comment 48 Peter Weilbacher 2008-06-01 10:42:45 PDT
(In reply to comment #42)
> Is that related to this variable?  Does trunk still do something if this is
> present? MOZILLA_USE_EXTENDED_FT2LIB=T

No, that variable is obsolete, but it does of course replace characters from the Unicode font(s).

> Are the DejaVu fonts the ones recommended for UniCode now?  Or is Code 2000
> still the recommendation?

I hope I never recommended Code 2000 but DejaVu will be installed with eCS2 and is a good choice (if you don't get worked up about the fact that OS/2 cannot install all of the fonts).

(In reply to comment #46)
> (In reply to comment #27)
> > The text in the status line, menus, and under the icons in mail/news 
> > sure looks smaller than before.  Maybe it would help legibility to use a 
> > slightly larger size?

It should really only depend on the font and the screen resolution (dpi). Well, and what font size you have set for your system.

> Can this be tweaked via usercontent.css?  I can't find WarpSans or Workplace
> Sans in about:config anywhere...

You should be able to reset the CSS properties "font-size" or "font-size-adjust" for menu and/or menuitem (or whatever the DOM Inspector tells you the item is).

All the other comments just underline that I should find time to implement full scale font replacement as is done on Mac and Windows. Some time over the summer maybe. Will take more memory and a page-load hit on pages with lots of weird characters but hopefully not too much if done right.
Comment 49 Steve Wendt 2008-06-03 21:24:15 PDT
Created attachment 323657 [details]
comparison of 9pt vs 10pt

This comparison between the default 9pt and a slight increase to 10pt suggests to me that the default should be changed; Workplace Sans just looks really bad at the smaller size.

In the top portion, note how the 'P' in 'Private' barely has any space inside of the loop.  In the middle and bottom, note how much more legible the text is - you can barely read the 9pt version.  To my eyes, Workplace Sans 10pt looks much closer to WarpSans 9pt in Seamonkey 1.x.

For anyone who wants to try this, it's a single line in userChrome.css:
* { font-size: 10pt !important; }
Comment 50 Steve Wendt 2008-06-03 21:37:21 PDT
Would it be better to open separate bugs for these issues?

1) change default point size for chrome to 10pt
https://bugzilla.mozilla.org/show_bug.cgi?id=432575#c49
https://bugzilla.mozilla.org/attachment.cgi?id=323657

2) implement glyph matching for Unicode characters
references to similar Windows/Linux bugs?
https://bugzilla.mozilla.org/show_bug.cgi?id=432575#c36
https://bugzilla.mozilla.org/attachment.cgi?id=319725

3) Thebes font hinting does bad things to non-hinted fonts
https://bugzilla.mozilla.org/show_bug.cgi?id=432575#c31
https://bugzilla.mozilla.org/attachment.cgi?id=320335
Comment 51 Steve Wendt 2008-06-03 21:53:54 PDT
Another nit with Bugzilla - the form fields seem to also be using Workplace Sans 9pt, while Seamonkey 1.x picked something totally different from WarpSans (at least on my system).  It looks like the CSS file just specifies to use a sans-serif font, but the default for font.name.sans-serif.x-western is Helv, and changing it doesn't help.
Comment 52 Felix Miata 2008-06-22 22:03:03 PDT
My memory isn't good on this, so I looked at:
http://fm.no-ip.com/auth/Font/fonts-forms
http://fm.no-ip.com/auth/Font/fonts-moz
http://fm.no-ip.com/auth/Font/fonts-system
<application dir>\res\forms.css

The best I can remember is that form controls, such as buttons, selects & inputs (but not textareas) by default are supposed to use system fonts rather than fonts specified for web page content in prefs. Looks like FF2 was broken in this regard.
Comment 53 Peter Weilbacher 2009-08-21 15:46:48 PDT
(In reply to comment #50)
> 3) Thebes font hinting does bad things to non-hinted fonts
> https://bugzilla.mozilla.org/show_bug.cgi?id=432575#c31
> https://bugzilla.mozilla.org/attachment.cgi?id=320335

As for the 'e' problem in OS/2's TNR font, I don't think we'll ever get a solution. I finally found the change in FreeType that regressed this character but it was apparently necessary to make many other characters look better (see http://savannah.nongnu.org/bugs/?23669).

When I mentioned the problem to the FreeType guys last year, they suggested to switch from the Type1 hinter to the FT autohinter or turn hinting off altogether. I now finally found a way to do that, using the font name "Times New Roman " (with trailing space) as trigger. But both cases look awful, the chars are very fuzzy, in longer text it really hurts my eyes. So, unless someone of the FT team finds a real solution, which is unlikely, I don't think we'll ever get that fixed. :-(
Comment 54 Peter Weilbacher 2009-08-22 12:25:09 PDT
I had totally forgotten that bug 439193 was there about the TNR 'e' problem. That already had a similar patch to what I did yesterday. But nice to have confirmed that this kind of hack for just TNR is not a solution. ;-)
Comment 55 Peter Weilbacher 2010-04-13 13:50:00 PDT
I'll probably not be able to work on any bugs in the near future.
Comment 56 Steve Wendt 2010-06-23 22:17:29 PDT
(In reply to comment #51)
> Another nit with Bugzilla - the form fields seem to also be using Workplace
> Sans 9pt, while Seamonkey 1.x picked something totally different from 

This looks a lot better with Alex's latest wpsu_bmp test version.
Comment 57 Steve Wendt 2010-06-23 22:18:34 PDT
Created attachment 453656 [details]
Bugzilla form fields with old wpsu font
Comment 58 Steve Wendt 2010-06-23 22:19:03 PDT
Created attachment 453657 [details]
Bugzilla form fields with new wpsu font
Comment 59 Benoit Jacob [:bjacob] (mostly away) 2011-12-02 14:12:40 PST
This bug has been opened for almost 4 years and nothing is being done about it, so I suspect that the reason is a general lack of interest in OS/2. marking as WONTFIX but CCing font people so they get a chance to see it and reopen if needed.
Comment 60 Peter Weilbacher 2011-12-05 00:49:53 PST
I don't know where this sudden run to close all OS/2 bugs by non-OS/2 people comes from. Font people working on non-OS/2 font code can hardly decide what to do with these bugs, so CCing them doesn't help.

This particular bug turned into something of a meta-bug for OS/2 font issues. As most users are basically happy with the current state and all bugs blocking this are resolved now, I guess we can have this one resolved, too. But then it should be FIXED not WONTFIX.
Comment 61 Benoit Jacob [:bjacob] (mostly away) 2011-12-05 05:22:54 PST
(In reply to Peter Weilbacher from comment #60)
> I don't know where this sudden run to close all OS/2 bugs by non-OS/2 people
> comes from. Font people working on non-OS/2 font code can hardly decide what
> to do with these bugs, so CCing them doesn't help.

I can answer that: it comes from the graphics team having frequent "bugkill" sessions (as announced on the dev-planning list) where we try to go over all bugs, retriage them, and close what we can.

When in doubt, we are aggressive in the direction of closing bugs. It's perfectly fine to reopen if the closing was wrong.
Comment 62 Dave Yeo 2011-12-05 20:42:49 PST
The biggest fix was a better replacement for Warpsans (bitmapped font not supported by Freetype), http://users.socis.ca/~ataylo00/creative/fonts/workplace/index.html#wpsu
Also the current repository of mzfntcfgft (OS/2 fontconfig) is https://bitbucket.org/dryeo/mzfntcfgft/overview. There is an issue tracker there.
Comment 63 Joe Drew (not getting mail) 2011-12-12 13:43:06 PST
(In reply to Benoit Jacob [:bjacob] from comment #61)
> (In reply to Peter Weilbacher from comment #60)
> > I don't know where this sudden run to close all OS/2 bugs by non-OS/2 people
> > comes from. Font people working on non-OS/2 font code can hardly decide what
> > to do with these bugs, so CCing them doesn't help.
> 
> I can answer that: it comes from the graphics team having frequent "bugkill"
> sessions (as announced on the dev-planning list) where we try to go over all
> bugs, retriage them, and close what we can.

Also, it was news to many people that the OS/2 port is one of our best non-tier 1 ports. Luckily, most people have been corrected on that front!

More information on BugKill: https://wiki.mozilla.org/Platform/GFX/BugKill

> When in doubt, we are aggressive in the direction of closing bugs. It's
> perfectly fine to reopen if the closing was wrong.

Yes, and our apologies for when we've messed things up on you.

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