Closed Bug 381330 Opened 17 years ago Closed 17 years ago

Investigate improvements for system font handling

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
OS/2
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mozilla, Assigned: mozilla)

References

Details

Attachments

(4 files, 2 obsolete files)

fix system font units (checked in)
6.23 KB, patch
Details | Diff | Splinter Review
use font name to determine styles (checked in)
5.47 KB, patch
Details | Diff | Splinter Review
Use font resolution instead of screen resolution (checked in)
1.54 KB, patch
Details | Diff | Splinter Review
Replace WarpSans with Workplace Sans, v2 (checked in)
6.79 KB, patch
Details | Diff | Splinter Review 
Now with bug 371504 checked in, Thebes builds display system fonts using cairo (via gfxFont::Draw). This seems to have the side effect that not all system fonts are displayed correctly, problematic are especially fonts that are not available as TrueType (or Type1?) fonts, most notably WarpSans.

So, either we have to find a way to get Fontconfig+Freetype to work with those fonts (which is probably difficult) or draw the text that uses system fonts using OS/2 GPI (urgs!).

If none of this works, we would have to require that users use TrueType (or Type1) fonts as system fonts... :-(
Blocks: 381331
Dave, I would like this bug to be about system fonts (those that are not used by the webpages, they are handled differently in the code), to I will reply to your comment on bug 381333 here. ;-)

There are some things I would like you to try.

- Reset your system config to what it was before you tried to get
  readable fonts.

- In the mzfntcfgft package you can uncomment #define MATCH_DEBUG in
  src/fontconfig.c (around line 427). That will enable output of the
  full list of fonts that Fontconfig sees.
- Recompile the package.

- Add a
     #define DEBUG_thebes
  somewhere at the beginning of gfx/thebes/src/gfxOS2Fonts.cpp and
  recompile in $(OBJDIR)/gfx/thebes/src. (I hope you are not using
  a static build).
  This will enable extra debugging output.
- Then set the app so that no webpage is loaded on startup. Just
  to reduce complexity.

Start the app, redirecting output to a file. There will be lots of output, especially with the full font list coming out several times. I'm mostly interested in the lines that contain
     CairoFontFace(): create it for
and the three following ones and the font list. If you ZIP it up it should still be possible to attach it to this bug or send it to me.


If you have the show-glyphs-afew.c test that I sent to the cairo list some days ago you could modify that to use "WarpSans" instead of "Bitstream Vera Sans" and with the help of the abovementioned debug version of mzfntcfgft try to see what font is really selected for your setup. For me it is Helvetica.
Handling system fonts has become easier, we can now ignore strikeout and others following bug 377717.
I built last night, possibly after that bug checkin... the timing would be close.  I have WorkplaceSans because I am using ft2lib with pmshell.  It looked good with Mozilla but the menu bar font size was tiny... I have good vision and I could barely make out the words, it *might* have been as much as 6 point but maybe as small as 4 but considering the size the it was quite clear.
see bug 366664, we need to redesign the font handling in XP level.
masayuki: thanks for the hint. I wanted to test that on OS/2, too. I hope to find time and adapt our code before you check that in.

abwillis: yes, I think there is a problem with units (px vs pt or something like that). Will try to debug what is going on.
(replying to comment #1)
Ok, must be my stupid weekend, replying to wrong bug and realized I had forgot
to copy mzfntcfg.dll to the bin directory :)
Anyways without mzfntcfg.dll Firefox surprisingly runs with the output talked
about earlier. Debug output in total (no font list) is this
gfxOS2Font[0x2054c600]::CairoFontFace(): create it for WarpSans, 16.000000
  input=WarpSans,400,0,16.000000
  fcPattern=WarpSans,80,0,16.000000
  fcMatch=LotusWP Int A,80,0,16.000000
gfxOS2Font[0x209d8ae0]::CairoFontFace(): create it for WarpSans, 16.000000
  input=WarpSans,400,0,16.000000
  fcPattern=WarpSans,80,0,16.000000
  fcMatch=LotusWP Int A,80,0,16.000000
gfxOS2Font[0x20b3d1a0]::CairoFontFace(): create it for WarpSans, 9.000000
  input=WarpSans,400,0,9.000000
  fcPattern=WarpSans,80,0,9.000000
  fcMatch=LotusWP Int A,80,0,9.000000
gfxOS2Font[0x204790e0]::CairoFontFace(): create it for WarpSans, 9.000000
  input=WarpSans,700,0,9.000000
  fcPattern=WarpSans,200,0,9.000000
  fcMatch=Arial Narrow,200,0,9.000000
gfxOS2Font[0x20b5d660]::CairoFontFace(): create it for WarpSans, 9.000000
  input=WarpSans,400,0,9.000000
  fcPattern=WarpSans,80,0,9.000000
  fcMatch=LotusWP Int A,80,0,9.000000

Later I will remove the lotus fonts and see if that makes a difference.

With mzfntcfg.dll I get a crash
Killed by SIGSEGV
pid=0x9304 ppid=0x001e tid=0x0001 slot=0x00cb pri=0x0200 mc=0x0001
I:\MOZILLA\OBJ-FB\DIST\BIN\FIREFOX.EXE
LIBC062 0:0000f38c
cs:eip=005b:155bf38c      ss:esp=0053:0011c0f8      ebp=0011c128
 ds=0053      es=0053      fs=150b      gs=0000     efl=00012246
eax=ffffff00 ebx=ffffffff ecx=ffffffff edx=00000073 edi=00000170 esi=00000170
Process dumping was disabled, use DUMPPROC / PROCDUMP to enable it.

and removing the font list the output I get is

gfxOS2Font[0x2054b2a0]::CairoFontFace(): create it for serif, 16.000000

...
input pattern
  SERIF,80,0,16.000000
best match
  TIMES NEW ROMAN MT 30,REGULAR
  input=serif,400,0,16.000000
  fcPattern=SERIF,80,0,16.000000
  fcMatch=SERIF,80,0,16.000000
gfxOS2Font[0x20a071c0]::CairoFontFace(): create it for serif, 16.000000

full font list
...
input pattern
  SERIF,80,0,16.000000
best match
  TIMES NEW ROMAN MT 30,REGULAR
  input=serif,400,0,16.000000
  fcPattern=SERIF,80,0,16.000000
  fcMatch=SERIF,80,0,16.000000
gfxOS2Font[0x20b87620]::CairoFontFace(): create it for Workplace Sans, 9.000000

full font list
...
input pattern
  WORKPLACE SANS,80,0,9.000000
best match
  WORKPLACE SANS,REGULAR
  input=Workplace Sans,400,0,9.000000
  fcPattern=WORKPLACE SANS,80,0,9.000000
  fcMatch=WORKPLACE SANS,80,0,9.000000
gfxOS2Font[0x205757c0]::CairoFontFace(): create it for WarpSans, 9.000000

full font list
..
input pattern
  WARPSANS,80,0,9.000000
best match



So the crash is happening when trying to match the last WARPSANS.
I'm somewhat surprised about how many fonts I have installed after 10 yrs of
running this install and should prune the list soon.
Ok, I spent a couple of hours pruning my fonts, editing INI files, removing fontconfig caches, and resetting the WPS and could not get away from the crash.
Finally in disgust I created new virgin ver 4 ini files and Seamonkey actually came up in 16 colour VGA goodness <gr> and ran for a minute before crashing (in Seamonkey with a popup.log entry instead of libc062). As I did not feel like reinstalling video drivers ( a bitch last time) etc I reverted back to a back up.
Anyways looking at the log file (virgin ini gives very short font list) the biggest difference is Helvetica. With the virgin INI's all warpsans fall back to Helvetica while now I don't see Helvitica anywhere.
Searching everywhere I can't find Helvetica, just Helv. The Font pallette has Helvetica but Fontfolder does not. Almost seems like Helvetica has disappeared here. Perhaps you can tell me where it is located on your system or/and send me a copy?
This is the easy part and should fix the problem that the menu font is much too small. I use the system's screen DPI to compute the size in pixels. The end result is really close. I see a 1 px difference that is probably unavoidable when using FT/cairo to draw the text and of course it still looks different because of antialiasing...
It also removes the unnecessary intermediate function.
Assignee: nobody → mozilla
Status: NEW → ASSIGNED
Comment on attachment 265989 [details] [diff] [review]
fix system font units (checked in)

OK, checked this patch in.
Attachment #265989 - Attachment description: fix system font units → fix system font units (checked in)
Dave, thanks for the debugging info from your machine. I think it may have been better not to clean out fonts at all. Whatever you are seeing may be seen by many other users in the future, too. Do you still have the full font list corresponding to the info you posted in comment 6? Would like to see that so that I can decide what I need to do to fontconfig to fix stuff (or get Doodle to do it).

I will update the mzfntcfgft package and announce it in the newsgroup, so that the separate DLL isn't needed any more and one cannot forget to copy it.

Helv on my machine comes from \OS2\DLL\HELV.FON while Helvetica is a Type 1 font inside \PSFonts\HELV*.OFB.
Unluckily I don't have the full font list anymore. I did get things working though by changing DEFAULT_SANSSERIF_FONT to DEJAVU SERIF so it was definitely a problem with my install of Helvetica. Whether INI file corruption or a corrupted file I haven't researched.
Here is, for reference, the patch I just checked into trunk. It adds a method to "guess" the font style (bold, italic, oblique) from its name.

Of course this would not detect a font style not present in the name (or present in another language). That's why I also played around with an algorithm using the OS/2 GPI functions to derive the properties as was used in nsDeviceContextOS2. But for the moment I cannot get that to work reliably, for some fonts (including WarpSans) I always get rubbish, even after discussing with people in comp.os.os2.programmer.misc. And one cannot derive the oblique property that way...
(In reply to comment #11)
> Unluckily I don't have the full font list anymore. I did get things working
> though by changing DEFAULT_SANSSERIF_FONT to DEJAVU SERIF so it was definitely
> a problem with my install of Helvetica. Whether INI file corruption or a
> corrupted file I haven't researched.

OK, don't worry. I think I have figured out what is going wrong in Fontconfig, even though I don't know how to fix it. I think it requires quite an overhaul of the current code that Doodle wrote...
Attached image screen shot of bug of related problem (obsolete) — 
I've added a screen shot of font corruption when displaying "http://tinderbox.mozilla.org/showbuilds.cgi?tree=SeaMonkey"
The problem shows up if a Type 1 copy of Helvetica is present on a Windows system.  Other sites are corrupted too, like www.ati.com.  Also see bug 366983.   A fix check-in for this bug seems to correspond to when my problem reappeared again.

070625 trunk build was OK
070627 trunk build is broken -- Both SeaMonkey and Firefox on WinXP Pro - multiple machines.
My apologies...  I appear to be off by a month for the check-in for 381330, but the issue and attachment may still be relevant.
Tom, I am sure that your problem has nothing to do with what this bug is about. This is a pure OS/2 development bug.

You should file a new one for yours (or find one that is marked Windows).
We might have to implement something like bug 327879 (and probably whatever comes out of bug 333126).

But first we need to get FreeType/Fontconfig support for our fonts (like the OS/2 .fon format). Veit thinks that this is doable, see his post in comp.os.os2.programmer.misc.
I found that the menu fonts appeared a big larger on screen than they should. I found that I should be using CAPS_VERTICAL_FONT_RES to derive the effective vertical resolution for fonts instead of using CAPS_VERTICAL_RESOLUTION which is the actual screen resolution. From the old code in gfx/src/os2 I also learned that the stuff with the array isn't really necessary for DevQueryCaps(), so I removed that.
Will check it in one of these days if nobody complains...
Attachment #275342 - Attachment is obsolete: true
Comment on attachment 266434 [details] [diff] [review]
use font name to determine styles (checked in)

This was actually checked in on 2007-05-28.
Attachment #266434 - Attachment description: use font name to determine styles → use font name to determine styles (checked in)
Attachment #278832 - Attachment description: Use font resolution instead of screen resolution → Use font resolution instead of screen resolution (checked in)
OK, part of this was merged into my last patch to bug 381333 but we shouldn't really mix the issues. While it seems feasible to implement support for the OS/2 font file formats into FreeType so that we can directly use them, I won't have time to do that, and nobody else stepped forward to try it.

Helv and Times and nice replacements in Helvetica and Times New Roman, so they are not really problematic. The Fontconfig algorithm actually replaces them automatically. That mainly leaves WarpSans. That is used for the menus in standard OS/2 Warp 4 by default (as WarpSans Bold). We have Alex Taylor's "Workplace Sans" font as a nice replacement for the regular WarpSans variant, and I think we should recommend users to install that if they want Mozilla apps to appear similar to PM apps (OpenOffice already recommends something similar). To get bold we can just tell cairo to artificially embolden "Workplace Sans". And while the appearance is not exactly the same, it comes closer than any other font I have seen (especially better than Helvetica that I got until now).

So, this patch replaces any instance of WarpSans that enters gfxOS2Fonts with Workplace Sans and adds emboldening. As an experiment it also switches off antialiasing for system fonts (not those inside webpages) because normally PM apps don't have antialiased fonts. But this only works with regular "Workplace Sans", the emboldened version would be unreadable without antialiasing. I think we could make this react to an environment variable. The WarpSans -> Workplace Sans replacement should do no harm when Workplace Sans isn't actually installed. Fontconfig would then select Helvetica.

If we agree on this we could add something like

   - <Application> cannot make use of OS/2 fonts like WarpSans and others
     which are not available in Type1 or TrueType format. It is therefore
     recommended to install the "Workplace Sans" font from
        http://www.cs-club.org/~alex/creative/fonts/
     or
        http://hobbes.nmsu.edu/cgi-bin/h-search?key=wpsu_ttf
     which <Application> will use as a replacement.

to the "Known Problems of the OS/2 version" in README.txt. If we go the way to let users decide on antialiasing we would add a new paragraph to the "Other important environment variables" section.
(In reply to comment #20)
> I think we should recommend users to install that if they want Mozilla apps
> to appear similar to PM apps (OpenOffice already recommends something similar).

Workplace Sans is required in OO2 to get numbers on the vertical ruler.  Other than that, it works fine with WarpSans.

> As an experiment it also switches off
> antialiasing for system fonts (not those inside webpages) because normally PM
> apps don't have antialiased fonts. 
> I think we could make this react to an environment variable.

Is there some performance benefit to having it off?  Or does it look strange?

There pretty much has to be some performance hit to having the anti-aliasing on but I couldn't say how much.  Turning it off because other PM apps don't have it isn't really that strong of an argument considering that the Menus don't work like other PM apps (e.g. Click File and move your mouse to edit... in PM apps it behaves for me in a more friendly way of not changing the menu drop down to edit but Mozilla switches from File to Edit).
I just combined https://bugzilla.mozilla.org/attachment.cgi?id=288324 and https://bugzilla.mozilla.org/attachment.cgi?id=288168 and am building now.
If there are speed improvements I don't think they would be noticeable. Especially given the few words that are displayed using the system font (mostly in the UI and on pages with HTML form elements). If antialiasing could be switched off for web page content that would probably have an impact.

No, the argument for disabling antialiasing of system fonts isn't a strong one, it was more an experiment.
OK, this is a clean diff against current trunk (without the bit that switches off antialiasing!) and also includes the additions to the three README.txt files. Someone please check for typos, other improvements welcome, too. :-)
Attachment #288324 - Attachment is obsolete: true
(In reply to comment #24)
> Created an attachment (id=289049) [details]
> Replace WarpSans with Workplace Sans, v2
> 
> OK, this is a clean diff against current trunk (without the bit that switches
> off antialiasing!) and also includes the additions to the three README.txt
> files. Someone please check for typos, other improvements welcome, too. :-)
> 

The patch doesn't apply cleanly after your checkin https://bugzilla.mozilla.org/attachment.cgi?id=289173 for bug381333. However, after manually copying the new lines of this attachment into gfxOS2fonts.cpp it compiles fine. Workplace Sans really looks very nice and I would vote for it as a replacement for WarpSans. I'm seeing still the problem that bold seems not to work (particularly in about:config the bold user-set changes don't show up).
Ah, ok "bold" Workplace Sans works now after installing the new mzfntcfgft package (before I had recompiled it with Peter's patches for fontconfig.c).
OK, are the native English speakers happy with my text for README.txt? Or can someone make it clearer? Otherwise I would check this patch in.
(In reply to comment #27)
> OK, are the native English speakers happy with my text for README.txt?

Looks fine to me.

Comment on attachment 289049 [details] [diff] [review]
Replace WarpSans with Workplace Sans, v2 (checked in)

OK, checked this into trunk.
Attachment #289049 - Attachment description: Replace WarpSans with Workplace Sans, v2 → Replace WarpSans with Workplace Sans, v2 (checked in)
With this I think this bug is resolved.
Status: ASSIGNED → 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: