After enabling true-type font display, Mozilla prefers to render pages using the BOLD version of a font, rather than the appropriate non-bold version. Here is a listing of my unix.js additions, followed by my fonts directory: === unix.js === pref("font.FreeType2.enable", true); pref("font.directory.truetype.1", "/m1/homes/bcrowder/fonts"); === unix.js === === ~/fonts === -rw-r--r-- 1 bcrowder users 105468 Mar 12 10:41 andalemo.ttf -rw-r--r-- 1 bcrowder users 286620 Mar 12 10:41 arialbd.ttf -rw-r--r-- 1 bcrowder users 224692 Mar 12 10:41 arialbi.ttf -rw-r--r-- 1 bcrowder users 206132 Mar 12 10:41 ariali.ttf -rw-r--r-- 1 bcrowder users 275572 Mar 12 10:41 arial.ttf -rw-r--r-- 1 bcrowder users 117028 Mar 12 10:41 ariblk.ttf -rw-r--r-- 1 bcrowder users 111476 Mar 12 10:41 comicbd.ttf -rw-r--r-- 1 bcrowder users 126364 Mar 12 10:41 comic.ttf -rw-r--r-- 1 bcrowder users 311508 Mar 12 10:41 courbd.ttf -rw-r--r-- 1 bcrowder users 234788 Mar 12 10:41 courbi.ttf -rw-r--r-- 1 bcrowder users 244156 Mar 12 10:41 couri.ttf -rw-r--r-- 1 bcrowder users 302688 Mar 12 10:41 cour.ttf -rw-r--r-- 1 bcrowder users 139584 Mar 12 10:41 georgiab.ttf -rw-r--r-- 1 bcrowder users 156668 Mar 12 10:41 georgiai.ttf -rw-r--r-- 1 bcrowder users 142964 Mar 12 10:41 georgia.ttf -rw-r--r-- 1 bcrowder users 158796 Mar 12 10:41 georgiaz.ttf -rw-r--r-- 1 bcrowder users 136076 Mar 12 10:41 impact.ttf -rw-r--r-- 1 bcrowder users 333900 Mar 12 10:41 timesbd.ttf -rw-r--r-- 1 bcrowder users 238612 Mar 12 10:41 timesbi.ttf -rw-r--r-- 1 bcrowder users 247092 Mar 12 10:41 timesi.ttf -rw-r--r-- 1 bcrowder users 330412 Mar 12 10:41 times.ttf -rw-r--r-- 1 bcrowder users 123828 Mar 12 10:41 trebucbd.ttf -rw-r--r-- 1 bcrowder users 131188 Mar 12 10:41 trebucbi.ttf -rw-r--r-- 1 bcrowder users 139288 Mar 12 10:41 trebucit.ttf -rw-r--r-- 1 bcrowder users 126796 Mar 12 10:41 trebuc.ttf -rw-r--r-- 1 bcrowder users 136032 Mar 12 10:41 verdanab.ttf -rw-r--r-- 1 bcrowder users 154264 Mar 12 10:41 verdanai.ttf -rw-r--r-- 1 bcrowder users 139640 Mar 12 10:41 verdana.ttf -rw-r--r-- 1 bcrowder users 153324 Mar 12 10:41 verdanaz.ttf -rw-r--r-- 1 bcrowder users 118752 Mar 12 10:41 webdings.ttf === ~/fonts === These are all fonts from the MicroSoft truetype fonts package, when I moved *i.tff and *b.tff files away from this folder, the bold/italic rendering stopped (reverting to X11 fonts to render bold and italic text on pages that actually required it).

What order does your fonts.dir list the fonts in? ttmkfdir is buggy and lists the fonts in "reverse" order in that file by default. See, eg, http://www.paulandlesley.org/linux/xfree4_tt.html#NON-PACKAGED-FONTS-FILES, section 4.2.2

The existence/nonexistance and ordering of fonts.dir does not have any effect on this behavior. I've played with several different variations of fonts.dir and finally tested the feature entirely without it. No change.

In that case, confirming... we likely have the same problem as ttmkfdir..

Would having my fonts directory help at all?

Here's some additional information I've managed to gather. At first I thought it was some localisation issue as the sort order in ls changes between LC_COLLATE=C and LC_COLLATE=fi_FI (for example). It didn't fix this one, though. However, making symbolic links as follows works for me: 1_Georgia.ttf -> Georgia.ttf 2_Georgia.ttf -> Georgia_Bold.ttf 3_Georgia.ttf -> Georgia_Bold_Italic.ttf 4_Georgia.ttf -> Georgia_Italic.ttf The links are in a different directory from the actual fonts and that directory with the links is then configured for mozilla. Interestingly, if you use 0_Georgia.ttf, it will not be the first one... Hope this helps. I hate this bug :)

You can set NS_FONT_DEBUG=3 (or maybe 7) in the environment before starting mozilla and see if anything interesting shows up.

These fonts are not related to X fonts so ttmkfdir will not have any effect. I'm guessing these fonts have the same internal font name. Could you attach the font summary? (If you have write permission it will be in the font dir and named ".mozilla_font_summary.ndb". If you do not have write permission it will be in "$HOME/.mozilla/fontsummaries/" with a name like "tt_font.d0302.i1234.ndb")

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

I probably have the same fonts and they all have different internal names. Mozilla loads the correct verdana but it renders it quite fat. See the upcoming screen shot, particularly the last part.

"Just a test" is in Verdana, the url bar is in Andale Mono. Obviously, this is not a property of a particular font. I have FreeType 2.0.8 installed. The last part is the same set of fonts via an XFree86 3.3.6 xfs patched with FreeType1 support.

> Mozilla loads the correct verdana but it renders it quite fat. I assume you mean that moz loads verdana but the bold not the regular weight. When it comes to rendering moz does not try and adjust the weight. Moz simply gets the pixels from FreeType2 which renders the outlines specified in the font. > ... "Just a test" is in Verdana, the url bar is in Andale Mono. > Obviously, this is not a property of a particular font. I assume you mean it is not the property of a particular font family (or face). It is very likely that a bold font is being selected. Hence, it is likely that it is a property of the particular font. To see what a given font should look like use a reference display program such as 'ftstring' in the FreeType2 demos. > The last part is the same set of fonts via an XFree86 3.3.6 xfs patched > with FreeType1 support. FreeType1 renders *quite* differently from FreeType2. There has been an on going discussion about this. Many people feel that FreeType1 produces much more attractive glyphs than FreeType2. The FreeType developers have recently released 2.0.9 and say that the glyphs now look much better. Also note that being from xfs it is not anti aliased.

this needs to be fixed for 1.0

> I assume you mean that moz loads verdana but the bold not the regular > weight. No, mozilla claims it's loading the correct file. > I assume you mean it is not the property of a particular font > family (or face). It is very likely that a bold font is being > selected. Hence, it is likely that it is a property of the particular > font. I was unclear. While there are a set of Verdana ttf files, there is only one Andale Mono. That's why it's not font dependent. > FreeType1 renders *quite* differently from FreeType2. There has been > an on going discussion about this. Many people feel that FreeType1 > produces much more attractive glyphs than FreeType2. No doubt. Lots of people use/used this font server and I'm sure they will be displeased if mozilla doesn't come close to it. > The FreeType developers have recently released 2.0.9 and say that the > glyphs now look much better. I'll build it later today and let you know. > Also note that being from xfs it is not anti aliased. Which is why I ran tests with antialias.min bumped up.

> > Many people feel that FreeType1 > > produces much more attractive glyphs than FreeType2. > > No doubt. Lots of people use/used this font server and I'm sure they > will be displeased if mozilla doesn't come close to it. Unfortunately, FreeType1 is no longer supported so moz cannot use it. Lets hope that the supported version gets better. For FreeType2 glyph rendering issues see bug 114885.

Since upgrading to the debian package of 0.9.9 with freetype, antialiasing, and the mstt core fonts, italic style on text seems to no longer be honored. My default font is verdana, and it looks gorgeous, except that on /. I can no longer tell the difference between quoted text (usually handled using <em>) and unquoted. This is a pain ;). Is that this bug, or a different one?

-> nsbeta1

The font info is kept in a hash so later call can share it. The hash key was based on the family name but that is not unique for bold/italic. Now use file name (and add face index for ttc)

nsbeta1+

Comment on attachment 74448 [details] [diff] [review] patch; make the hash key unique /r=yokoyam Thanks brian for explaining the patch for me.

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

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

> I can no longer tell the difference between quoted text (usually > handled using <em>) and unquoted. This is a pain ;). Is that this bug, or a > different one? It should be this bug. Stuart: could you try attachment 74448 [details] [diff] [review] and see if it fixes this for you?

Just recompiled mozilla with Brian Stell's patch (http://bugzilla.mozilla.org/showattachment.cgi?attach_id=74448) applied; Italics, regular and bold aa fonts now work correctly on my X 4.2.0 system.

thanks

Just want to add my bit: Patched my mozilla yesterday and I can now see bold/italics/etc perfectly and have not had any problems.

thanks

Is the patch approved? I would like to have it, but can't compile from sources for some reasons and I don't have time to investigate so I would like to download some binaries that include the patch. Does anyone know where I could get them?

Sorry for the delay, this bug is waiting on super-review and then checkin approval It is a fair amount of work to make experimental binaries available. I believe experimental binaries are made when the patch seems risky. Since the patch is not very risky (even if the problem is really annoying) I doubt an experimental binary will be made. The process of review/super-review/approval does slow the process somewhat but the more important thing is that it does lead to a better end product which of course is our highest priority. Hopefully, we can get this fixed in in a few days.

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

Comment on attachment 74448 [details] [diff] [review] patch; make the hash key unique sr=rbs + char buf[20]; + sprintf(buf, "/%d", nsFT2FontCatalog::GetFaceIndex(aFce)); + key_str.Append(buf); nit (a bit more elegant): key_str.Append('/'); key_str.AppendInt(nsFT2FontCatalog::GetFaceIndex(aFce));

Comment on attachment 74448 [details] [diff] [review] patch; make the hash key unique a=scc

checked in

Tested with nightly build "Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020322". Works beautifully now. Thanks :)

Same for me with the Debian 0.9.9-2 build which incorporates this patch :)

Verified it has been fixed on 03-25 trunk build / RH7.2. However, the problem still exists when I login as root but not my self, it might related to bug 131260. I'm marking one as verified here. Will see if still a problem with above case after bug 131260.