Closed Bug 94327 Opened 24 years ago Closed 24 years ago

When there are multiple fonts with different foundry names but the same family name moz should pick the best fit based on width, weight and available size

Categories

(Core :: Internationalization, enhancement, P2)

Product:
Core
Component:
Internationalization
Platform:
x86
HP-UX
Type:
enhancement

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla0.9.7

People

(Reporter: BarrettLndstrm, Assigned: roland.mainz)

References

Details

(Keywords: fonts, intl)

Attachments

(6 files, 6 obsolete files)

Text from previous bug with all the "naughty" bits removed :-)
16.87 KB, text/plain
Details
screenshot with ugly scaled bitmap iso8859-9 fonts
52.11 KB, image/jpeg
Details
CNN.com before the checkin: looks OK on Linux
63.06 KB, image/gif
Details
CNN.com after the checkin: Does not look OK on Linux. Hard to read
72.04 KB, image/gif
Details
Same patch as attachment 60105 but added a rule to avoid banning outline scaled fonts
31.82 KB, patch
Details | Diff | Splinter Review
3-in-one screenshot showing font rendering improvement on Linux
44.99 KB, image/gif
Details
Re-creating bug to get rid of security issues. Will post info from original bug, with confidential material edited out, as an attachment.
Keywords: intl
QA Contact: andreasb → ylong
Barrett Lindstrom : Is this bug important to the product you want to ship? Mark it as P2.
Priority: -- → P2
Yes, this is one that our hpux customers are concerned about.
*** Bug 91145 has been marked as a duplicate of this bug. ***
At present we create a foundry-family node table that separates the fonts into foundry/family/registry/encoding (FFRE) groups. When CSS specs a font generally just the family name is specified. However, the current font code only looks in the first FFRE for a given font even if a better size or style is available from a different foundry. To fix this problem I think we need to create a separate */family/registry/encoding (FRE) node table. This table would sort all the fonts of a given family/registry/encoding but any foundry into nodes. This FRE table would make all the fonts with a given family available rather than just the fonts in the first FFRE with that family name. The would also mean non-scaled fonts from a different foundry would be available as well. This would be far preferrable to bitmap scaling which is done on occasion even when non-scaled fonts from a different FFRE are available.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Target Milestone: Future → mozilla0.9.4
Target Milestone: mozilla0.9.4 → mozilla0.9.5
This code adds an AFRE (Any_foundry-Family-Registry-Encoding) node list. This node list merges all the fonts with the same family-registry-encoding but any foundry name into one group. The font list order is honored: the first font of a given weight/width/slant/size is used. Any subsequent font of the same weight/width/slant/size is ignored in the AFRE (but of course it is remembered in the FFRE list). When looking for a font and the foundry is not specified the code looks in the AFRE node list. Typically only fonts specified by user preferences have a foundry name. Katakai: would you kindly review this? thanks
I believe this should fix the most common cases where we bitmap scale instead of using a font from a different foundry, bug 87664
rbs: fyi, this is a font bug with a patch which may or may not affect your code
Keywords: fonts
> rbs: fyi, this is a font bug with a patch which may or may not affect > your code I assume this refers to bug 99010. I strongly doubt that this will have any functional effect on that code since this exists in a layer below those changes. Bit rot, of course, is a different problem.
bstell: Wanna try to fix bug 93771 ("Mozilla uses low-resolution bitmap fonts on high resolution X11 displays") here ?
Roland: This implements an important bit that is needed for bug 93771 but that bug needs other items as well. Some of those additional items still need to be thought out. I would prefer to get this part in and solve this customer's issue while we try to figure out the full solution for bug 93771.
Should I file the port to Xlib now or after your patch has been r='ed ?
Blocks: 93771
Roland: If it is not too hard go ahead and attach an xlib version. It will have to be redone if Katakai suggests changes but if not we can move directly to asking for sr=.
Xlib version follows once my new build from tip finishes (~14hours)...
Comment on attachment 50063 [details] [diff] [review] Xlib version of the patch for 2001-09-19-08-trunk One minor detail: -- snip -- +#ifdef FIX_ME // where is this defined !? + size->mMap = nsnull; +#endif /* FIX_ME */ -- snip -- Is |mMap| an artifact left over from bug 95518 ?
Attachment #50063 - Attachment is obsolete: true
> + size->mMap = nsnull; bitrot
Blocks: 99509
Any idea when this patch will "land" ?
I need more one day for verifying the patch, sorry.
r=katakai Sorry for late. I've reviewed the codes and have tested the following steps in japanese locale. The patch could get proper sizes of fonts. 1. prepare 2 font patch A, B A contains outline fonts, family name = gothic but foundary = dummy B contains bitmap fonts, 12, 14, 16, 18, 20, 24 points size family name = gothic but foundary = sun 2. set +fp B, then set +fp A A becomes a top directory of fontpath 3. start Mozilla and browse the example page that contains "face=gothic" Without Brian's patch, characters are displayed in outline fonts because TryFamily() returns the first matched font. With Brian's patch, characters are displayed by using bitmap fonts in fontpath B when the size is available. Good.
Requesting sr= ...
Keywords: patch, review
The changes look ok to me with one exception: FFREName will be a dangling pointer since the temporary PromiseFlatCString goes out of scope almost immediately: @@ -3472,7 +3548,9 @@ nsFontXlib* nsFontMetricsXlib::TryNodes(nsAWritableCString &aFFREName, PRUnichar aChar) { - nsCStringKey key(PromiseFlatCString(aFFREName).get()); + const char *FFREName = PromiseFlatCString(aFFREName).get(); + nsCStringKey key(FFREName); + PRBool anyFoundry = (FFREName[0] == '*'); Fix that and you can have sr=kin@netscape.com. If there are any objections from any of the X Font gurus listed on the AssignedTo/Cc list speak up now. :-) I also assume you tested enough to make sure there were no bad affects to onscreen rendering.
How about this: @@ -3472,7 +3548,9 @@ nsFontXlib* nsFontMetricsXlib::TryNodes(nsAWritableCString &aFFREName, PRUnichar aChar) { nsCStringKey key(PromiseFlatCString(aFFREName).get()); + PRBool anyFoundry = (PromiseFlatCString(aFFREName).get()[0] == '*');
It's better to flatten once. The string docs suggest doing things this way: const nsPromiseFlatString& flat = PromiseFlatString(aFFREName); nsCStringKey key(flat.get()); PRBool anyFoundry = (flat.get()[0] == '*'); Should we be checking the length before we go indexing into the string?
thanks. The working model for a FFRE is <foundry>-<family>-<registry>-<encoding> so the minimum length is 7.
checked in
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
we probably want to back this out for 0.9.5
Blocks: 87664, 102623, 102940
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 103159
backed out.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
When the fix was in, it seemed to have had an effect in bug 103159.
Another side-effect I found when the fix was in is that badly-scaled fonts are mysteriously used to render US-ASCII part of US-ASCII + CJK or other multi-script texts. These fonts are also used for pure-US-ASCII pages (such as http://bugzilla.mozilla.org for which I'm gonna attach a screenshot) when View|Character Coding is set to almost anything other than Western. I font-traced and found that those badly-scaled fonts are all in iso8859-9 encodings. Note that iso8859-9 encoded fonts are as good as iso8859-1 encoded fonts to cover US-ASCII part in terms of glyph coverage. When non-Western encoding is selected, font-trace included the following: ...snip.... bitmap (non-scaled) font: -adobe-helvetica-medium-o-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 bitmap (non-scaled) font: -adobe-helvetica-medium-r-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 bitmap (non-scaled) font: -adobe-times-bold-i-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 bitmap (non-scaled) font: -adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 bitmap (non-scaled) font: -adobe-times-medium-i-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 bitmap (non-scaled) font: -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9, nsFontMetricsGTK.cpp 3224 loaded -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9 returns -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9 loaded -adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9 returns -adobe-times-bold-r-normal--17-120-100-100-p-0-iso8859-9 .... snip.... At first I was puzzled by the existence of these fonts at 17px because 'xlsfonts | grep iso8859-9 | grep 17' yielded nothing on my Linux box(RH 7.1). xlsfonts uses XListFonts() used by nsFontMetricsGTK.cpp to get the list of fonts. However, nsFontMetricsGTK.cpp found these fonts at 17px (unscaled and bitmap) while xlsfonts does not. As a last resort, I tried 'xlsfonts -fn -adobe-times-*-*-*--*-*-*-*-*-*-iso8859-9' and the result does include -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9 There is NO 17 px bitmap font in iso8859-9 on my system, but somehow XListFonts comes up with it. I was wondering if this is a bug on X11 library on my system when I realized that averageWidth field is 0. I don't yet understand why XListFonts() comes up with this (non-zero pixelSize and pointSize and zero averageWidth). What's clear to me, though, is that these fonts have to be skipped in a loop in GetFontNames(). They're not unscaled-bitmap fonts (they look really ugly when used because they're scaled). Moreover, 'genuinely scaled' counterparts (with all three fields, pixelSize, pointSize, and averageWidth zero) are returned by XFontLists() so that skipping these strange cases don't get bitmap scaled fonts out of consideration. In case of iso8859-1 encoded fonts, there are actually unscaled bitmap fonts at 17px (with non-zero pixelSize,pointSize and averagewidth) so that these weired cases (with zero averageWidth and nonzero pixelSize and pointSize) can be safely skipped in iso8859-1 case as well. I'm going to attach a patch to address this issue. It may not be a very good idea to attach this patch here because the problem I described above was lying around in GetFontNames() without Brian's patch. His patch only moved it up to the surface.
With both Brian's patch and my patch (attachment 53094 [details] [diff] [review]), it seems like example pages in bug 103159 are rendered fine, but I'm not sure because I don't know how the sample URL given in that bug is supposed to be rendered. (at least, two tables in the page have the same widths and fit well with the rest of the page to my eyes). rbs, can you test it with both Brian's fix and attachment 53094 [details] [diff] [review] in?
Fonts are about 95% reasonable and about 5% chaos. I am somewhat uncomfortable hardcoding in cases like this. + // skip 'mysterious' and 'spurious' cases like + // -adobe-times-medium-r-normal--17-120-100-100-p-0-iso8859-9 + if (pixelSize[0] != '0' || pointSize[0] != 0 ) + continue; Perhaps we need to add font banning before we can enable AFRE.
need font banning first. see bug 104075
Status: REOPENED → ASSIGNED
Depends on: 104075
Target Milestone: mozilla0.9.6 → mozilla0.9.7
--> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
Linux font problem. give to shanjian for research. Change the milestone by your judgement. take your time.
Assignee: ftang → shanjian
Target Milestone: mozilla0.9.7 → mozilla0.9.9
shanjian: Why milestone 0.9.9 ? We have a working patch - and the "font banning code"(=bug 104075) is ready within a few days (depends on how fast I can get reviews) ... ... I still vote for 0.9.7 as target milestone ...
I have no objection if we can get it for 097. I reset target just because I have too many issue on my plate for 097. It is good to know things are in progress. I can take a look of 104075 tomorrow to see if I can give you a review. I have to focus on another issue today.
Status: NEW → ASSIGNED
shanjian wrote: > I have no objection if we can get it for 097. I reset target just because I > have too many issue on my plate for 097. bstell, wanna steal this bug from shanjian ? :) > It is good to know things are in progress. :-) > I can take a look of 104075 tomorrow to see if I can give you a review. I have > to focus on another issue today. Thanks! Note that the patch in bug 104075 is Xlib-toolkit only, e.g. you have to build with "configure --enable-toolkit=xlib" ...
Blocks: 93207
Stealing this from shanjian. I just want to make it sure that we do not miss the 0.9.7 train ...
Assignee: shanjian → Roland.Mainz
Status: ASSIGNED → NEW
Severity: normal → enhancement
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.9 → mozilla0.9.7
Comment on attachment 53094 [details] [diff] [review] a patch to skip fonts with zero av.width and nonzero pixel/point size This workaround breaks Xprint "printer buildin fonts" for some reason... Printing on a 300DPI PS printer gives me the follwoing list of fonts which are banned by the code - but AFAIK some of them should not be banned: -- snip -- xxlib_find_handle: 'xprint' entry 0 xxlib_register_handle: new entry 'xprint' a7d6f8 attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--0-0-1200-1200-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--0-0-1200-1200-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--0-0-1200-1200-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--0-0-1200-1200-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--0-0-0-0-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--0-0-0-0-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--0-0-0-0-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--0-0-0-0-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--0-0-75-75-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--0-0-75-75-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--0-0-75-75-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--0-0-75-75-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-i-normal--0-0-100-100-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-bold-r-normal--0-0-100-100-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-i-normal--0-0-100-100-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--50-120-300-300-p-0-iso8859-1' attempt to ban (possible) printer-buildin font '-adobe-times-medium-r-normal--0-0-100-100-p-0-iso8859-1' XpuCheckSupported: XpGetOneAttribute(job-attributes-supported) returned 'job-name job-owner notification-profile xp-spooler-command-options ' -- snip --
Updated patch, includes attachment 49307 [details] [diff] [review], attachment 50067 [details] [diff] [review] and attachment 53094 [details] [diff] [review] (except that I disabled it when the destination is a printer)
Attachment #49307 - Attachment is obsolete: true
Attachment #50067 - Attachment is obsolete: true
Attachment #53094 - Attachment is obsolete: true
jst: Wanna give me an rs= for the new patch, please ?
- Fix the messed up indentation in NodeAddScalable(). - In NodeAddSize(), fix the next-line argument indentation in the method declaration, and this code leaks |copy| if new nsFontGTKNorma() return null (i.e. out of memory). - Loose the empty string argument to the nsCAutoString constructor at: + nsCAutoString nodeName(""); and use Assign() in stead of Append() when you know the string is empty (just below the above line): + if (aAnyFoundry) + nodeName.Append('*'); + else + nodeName.Append(foundry); same thing at line ~3400. - No error checking after PR_smprintf() at the end of NodeAddScalable() (two occurances). rs=jst with that fixed...
Attachment #60062 - Attachment is obsolete: true
bstell: Wanna check this "in", please ?
Checked in... Followups are... - bug 104075 ("need X font banning") Which adds a way to ban fonts via (user-editable) prefs and - bug 103159 ("sorting fonts by foundry names cause font size of css ignored in some cases") We have to check whether attachment 53094 [details] [diff] [review] really fixes this ...
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Fonts on linux now look like shit. I used to have these fonts set: Fonts for: Western Proportional: Serif Serif: monotype-arial-iso8859-1 Sans-serif: monotype-arial-iso8859-1 Fantasy: adobe-courier-iso8859-1 Monospace: monotype-courier new-iso-8859-1 Starting up moz after rebuilding CVS with this checkin, all my fonts were reset to native linux font adobe-courier. All font selections have become truncated down to nearly none, and it is impossible to select for instance truetype fonts - they are no longer an option.
The checkin also causes truetype fonts to be ignored in CSS on pages. Moz doens't seem to be able to display TT fonts on linux anymore. Backing out the two checkins fixed the problem. I suggest this whole patch is backed out from the main tree untill the bugs are sorted out.
Patch has been backed out.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
dark@c2i.net: OK, looks that the font ban was to "tight". But... what is wrong with attachment 60139 [details] (screenshot after "checkin"). Can you point out where do you see the "bad" fonts ?! ---- I'll rework the font ban part and add a rule that it does not reject outline scaled fonts ...
Status: REOPENED → ASSIGNED
Roland Mainz: All fonts are bad there. I find the difference pretty striking. Adobe-Helvetica is used instead of Verdana, Arial and more - all over the page. Adobe helvetica is a much narrower font, and with less spacing between fonts. Readability is lower than with for instance a typical good webfont like Verdana, which is used a lot on the page (if available)
R.K.Aa: Wanna try the new patch, please ?
Am at work without Mozilla. Back home in 3h 15m. Will test patch first thing.
> But... what is wrong with attachment 60139 [details] (screenshot after "checkin"). > Can you point out where do you see the "bad" fonts ?! It might be that his display is a bit blurry in which case the slight reduction in font size (now that the correct size is available) causes the text to be much harder to read. In bug 102199 I have people asking that moz go back to buggy behavior because now that it uses the *requested* size (requested by the html) they find it hard to read. > I'll rework the font ban part and add a rule that it does not reject outline > scaled fonts ... Careful, the urw fonts which support scalable fonts are very ugly.
I started reading the first attachment in this bug.. silly me.. If attachment 45076 [details] is correct, the HPUX font setup creates faulty fonts.dir files (or equivalent), as shown by the quoted setup for the font Arial Black. (Initial xlsfonts output in attachment id=45076 added as "Submitter_Text(Added 010710)") I don't know the X font system all that well, but the X Window System User Guide, Motif 1.2 Edition, does not mentioned "black" as a weight. Only medium, bold and demibold. All "arial black" fonts are weight medium, which for some reason seem to get truncated when "black" fills its placeholder - but it's still not a valid weight. However: "black" as a weight in the X font system is not the real issue here. The issue is that the Arial Black setup above explicitly tells X that Arial Black *IS* Arial. If the person wished otherwise, and wanted to tell X about a separate font called "Arial Black", he/she should use the real font name INCLUDING the space. I believe the issue would have been identical had the font been called "arial white" - someone with access to Fontmonger might want to test that. By adding a separator after Arial, X is told that "here ends the name". And in other words that all fonts arial are arial, and any "Arial Black" effectively does not exists anymore. In comment from "************ marketing(Added 010718 by) *********** a few "workarounds" are suggested, but the most obvious thing to try is not mentioned: simply correcting the extra "-" in fonts.dir/scale files - or whatever files HPUX X server fetches its info from. And should it choke on the space, there's still the fonts.alias left to correct for it all, where fonts can be completely protected by quotes. I really don't like the idea of Mozilla suddenly trashing my font options because of what appearantly is a bug in HPUX X server. Before fonts on Linux are lobotomized for good, can affected persons try the approach above? (Removing the extranous "-" between "arial" and "black", and replace it with a space.) I have never seen X mistake Arial for Arial Black on Linux. Below is the setup ttmkfdir makes on XFree86 3.3.6 as well as 4.01 for the particular font in fonts.dir, followed by how xlsfont sees that font. $ grep Black fonts.dir ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-adobe-standard ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ascii-0 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-fcd8859-15 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp437 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp850 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp852 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-ibm-cp866 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-1 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-10 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-15 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-2 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-3 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-4 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-5 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-7 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-iso8859-9 ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-koi8-r ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-koi8-ru ariblk.ttf -monotype-Arial Black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251 $ xlsfonts |grep black -bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-1 -bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-2 -bitstream-charter-black-i-normal--0-0-0-0-p-0-iso8859-9 -bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-1 -bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-2 -bitstream-charter-black-r-normal--0-0-0-0-p-0-iso8859-9 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-adobe-standard -monotype-arial black-medium-r-normal--0-0-0-0-p-0-adobe-standard -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ascii-0 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ascii-0 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-fcd8859-15 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-fcd8859-15 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp437 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp437 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp850 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp850 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp852 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp852 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp866 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-ibm-cp866 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-1 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-1 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-10 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-10 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-15 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-15 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-2 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-2 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-3 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-3 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-4 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-4 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-5 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-5 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-7 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-7 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-9 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-iso8859-9 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-r -monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-r -monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-ru -monotype-arial black-medium-r-normal--0-0-0-0-p-0-koi8-ru -monotype-arial black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251 -monotype-arial black-medium-r-normal--0-0-0-0-p-0-microsoft-cp1251 -monotype-arial black-medium-r-normal--10-100-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--10-100-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--11-110-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--11-110-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--12-120-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--12-120-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--13-130-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--13-130-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--14-140-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--14-140-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--15-150-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--15-150-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--18-180-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--18-180-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--24-240-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--24-240-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--6-60-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--6-60-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--7-70-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--7-70-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--8-80-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--8-80-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--9-90-100-100-p-0-iso8859-1 -monotype-arial black-medium-r-normal--9-90-100-100-p-0-iso8859-1 [dark@localhost TrueType]$ (additional sizes due to a fonts.alias) (Ok.. i'll test that patch..)
My display is not blurry. If you don't see that the fonts in use are very different in those two screenshots, we have a problem. The slight reduction in size is not the issue. Adobe Helvetica is simply a "cramped" font with little space between characters, compared to the rounder and spacier verdana, which is widely accknowledged for it's good onscreen readability. When Verdana is the first suggested font in the CSS of a page, i would much prefer that to having Helvetica displayed. Helvetica is not a particular good webfont.
Applied patch - so far so good. Haven't discovered anything missing yet. -TrueType fonts are back in preferences -CNN.com is intact. TT fonts visible, appearing as in attachment 60138 [details] -MSN.com appears to have fonts one number larger than it used to (?) (Doesn't hurt (!) - they were a number too small. May not be due to this patch at all - comparing to a month old screenshot.)
R.K.Aa: Thanks! Please r= the new patch that we can check in it again ...
RKA wrote: > My display is not blurry. If you don't see that the fonts in use are very > different in those two screenshots, we have a problem. etc. etc. No no, _now_ I see the difference. I simply did not compared the type of the used fonts, I only looked at the screen dump and thougth "WTF, what should be wrong with this screenshot ?! I can read the text... and it looks good for me...").
r=R.K.Aa
The weight black is correctly recognized by moz as a bold weight. The problem this bug is addressing is that the font search code stops at the first "arial" group and does not try other arial groups from different foundries. The first arial group only has the arial font in a black weight and from that group moz picks the best choice "in that group" ignoring all other groups with that fontname. Using the name "arial black" would be another solution to "this particular font problem" but the problem shows up in other areas such as forcing bitmap scaling because the first font group of a given name has limited sizes even though there are other groups available with closer sizes. The HP issue is only part of a larger problem: for a given "fontname" moz only looks in the first "foundry-fontname" group and ignores fonts in other "foundry-fontname" groups Is verdana the first font in the CSS for attachment 60138 [details] and attachment 60138 [details]?
fixed-on-trunk
Status: ASSIGNED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
>The weight black is correctly recognized by moz as a bold weight. Wrong, I believe. Arial Black is not bold. It's "medium" and comes in that weight only. Another sample of a "medium only" but "fat" looking font from The Monotype Corporation is Impact. >Using the name "arial black" would be another solution to "this particular >font problem" It would be the CORRECT solution. The fonts name is 'Arial Black', not 'Arial'. >Is verdana the first font in the CSS for attachment 60138 [details] and attachment 60138 [details]? Can't swear if it's the first in the CSS - no font is explicity stated in ".cnnMainT2Area", but it obviously inherits Verdana from somewhere since it's Verdana displaying.
the HP bug had this list of fonts (see attachment 45076 [details]) $ xlsfonts -fn "*arial*" -mono-arial-black-r-normal--0-0-0-0-p-0-hp-roman8 -mono-arial-black-r-normal--0-0-0-0-p-0-hp-roman8 -mono-arial-black-r-normal--0-0-0-0-p-0-iso8859-1 -mono-arial-black-r-normal--0-0-0-0-p-0-iso8859-1 ... For whatever reason it is named "arial" not "arial black" and is being used everywhere a medium weight arial font is requested because the font code only looked at the first arial. > It would be the CORRECT solution. The fonts name is 'Arial Black', not > 'Arial'. Do you see the code parsing the space as a field separator? The macro that finds the field does not stop on spaces http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#3467 3467 #define FIND_FIELD(var) \ 3468 char* var = p; \ 3469 while ((*p) && ((*p) != '-')) { \ 3470 p++; \ 3471 } \ 3472 if (*p) { \ 3473 *p++ = 0; \ 3474 } \ 3475 else { \ 3476 continue; \ 3477 } http://lxr.mozilla.org/seamonkey/source/gfx/src/gtk/nsFontMetricsGTK.cpp#3495 3493 FIND_FIELD(foundry); 3494 // XXX What to do about the many Applix fonts that start with "ax"? 3495 FIND_FIELD(familyName); 3496 FIND_FIELD(weightName); 3497 FIND_FIELD(slant); 3498 FIND_FIELD(setWidth); 3499 FIND_FIELD(addStyle); If you do find it separating on a space then kindly file a bug. > > Is verdana the first font in the CSS for attachment 60138 [details] and > > attachment 60138 [details]? > Can't swear if it's the first in the CSS - no font is explicity stated in > ".cnnMainT2Area", but it obviously inherits Verdana from somewhere since > it's Verdana displaying. We need to be careful here. If we don't know what is specified we cannot determine the "correct" behavior.
I'm simply saying that Moz should not "guess" how an X fontserver might be misconfigured. The missing whitespace is NOT a concern of Mozilla's of course - moz simply interprets what its told - which is the right thing. I'll drop the "black" weight for now, but it's wildly incorrect. This bug was oh-so-next-to-bogus when filed, but as you say: There are other considerations where other foundries may have a better and more scaleable version of a requested font. So don't misunderstand me: I'm *pleased* with the outcome of this fix. Attaching a screenshot I believe demonstrates the improvement on Linux very well. Assembled from 3 screenshots of same page at different times, from http://jigsaw.w3.org/css-validator/ top: before antialiasing of bitmap fonts middle: after antialiasing of bitmap fonts ("adobe-times" is still used) bottom: after THIS fix: ("monotype-times new roman" is used)
I'm lying: the 3'rd sample is using -urw-times instead of adobe-times !
The 1st is a bitmap scaled (up) font (very ugly) The 2nd is an anti-aliased bitmap scaled (aasb) (up) font the anti-jagging is the rounding of the corners. aasb, bug 90813, helps alot at smaller sizes. At larger sizes the aasb glyphs are "somewhat" better but still not great. The 3rd is a outline scaled (non anti aliased) and is good looking (yeah)
On linux redhat 7.0. Build 2001120512 has completely destabilised my font sizes. Fonts now display too big. Accessing my fonts lists gives me only 8859-3 fonts, but I don't know how long this situation has pertained, because I have had no cause to modify my font settings for many months. I reverted through a number of previous builds which I had on hand, and am now on 2001120206, but the instability remains. My prefs.js has only user_pref("font.default", "sans-serif"); user_pref("font.language.group", "[object Window]"); user_pref("font.name.cursive.x-western", "2rebels-cairo-iso8859-1"); user_pref("font.name.fantasy.x-western", "2rebels-cairo-iso8859-1"); user_pref("font.name.monospace.x-western", "monotype-courier new-iso8859-15"); user_pref("font.name.sans-serif.x-western", "monotype-arial-iso8859-15"); user_pref("font.name.serif.x-western", "monotype-times new roman-iso8859-15"); user_pref("intl.font_charset", "iso-8859-1"); user_pref("intl.font_spec_list", "monotype-courier_new-0-scale-fixed-iso-8859-15 ,monotype-arial-0-scale-prop-iso-8859-15,monotype-andale mono-0-noscale-fixed-ko i8-r,monotype-andale mono-0-noscale-prop-koi8-r,monotype-andale mono-0-noscale-f ixed-x-user-defined,ult1mo-alexandria-0-noscale-prop-x-user-defined,nsPseudoFont -courier-100-noscale-fixed-UTF-8,nsPseudoFont-times-120-noscale-prop-UTF-8,isas- fangsong ti-120-noscale-fixed-gb_2312-80,isas-fangsong ti-120-noscale-prop-gb_23 12-80,daewoo-gothic-0-noscale-fixed-ks_c_5601-1987,daewoo-gothic-0-noscale-prop- ks_c_5601-1987,misc-fixed-120-noscale-fixed-jis_x0201,misc-fixed-120-noscale-pro p-jis_x0201,admas-fidel-120-noscale-fixed-jis_x0208-1983,admas-fidel-120-noscale -prop-jis_x0208-1983,cbs-song-120-noscale-fixed-x-cns11643-2,cbs-song-120-noscal e-prop-x-cns11643-2,cbs-song-120-noscale-fixed-x-cns11643-1,cbs-song-120-noscale -prop-x-cns11643-1,monotype-andale mono-0-noscale-fixed-iso-8859-9,bitstream-ame ricana-0-noscale-prop-iso-8859-9,monotype-andale mono-0-noscale-fixed-iso-8859-7 ,monotype-andale mono-0-noscale-prop-iso-8859-7,monotype-andale mono-0-noscale-f ixed-iso-8859-5,monotype-andale mono-0-noscale-prop-iso-8859-5,monotype-andale m ono-0-noscale-fixed-iso-8859-2,ult1mo-alexandria-0-noscale-prop-iso-8859-2,monot ype-courier_new-0-scale-fixed-iso-8859-1,monotype-arial-0-scale-prop-iso-8859-1, "); that contain the word "font". What surprises me is that I cannot recover my previous font setup. What has changed, and how can I revert it?
Brian, could you please verify this bug instead of me? Thanks! Change QA contact to Brian.
QA Contact: ylong → bstell
A further comment on this. linux redhat 7.0 with XFree86 4.1.0 My proportional fonts (san-serif) are now stuffed, but my mono-spaced font still appears to be at the original size (from memory, 13pt for proportional and 12pt for mono. BTW, where are such values defined?) In the months that I have been using Mozilla, the most obvious attraction of the product was its font handling. After the miseries of Netscape 4.7..., fonts Just Worked. I could set font sizes without agonies, and the full set of my fonts seemed to be available. These changes are like 4.7 deja vu. It now Just Doesn't Work. I would be very grateful if someone could tell me how to get back to the previous stable font situation while this stuff is sorted out.
pbwest@powerup.com.au: Could you please open a seperate bug for this (and assign it to me or bstell), please ? I'd like to treat this one as "fixed" and hunt your problems using a seperate bug...
In the months that I have been using Mozilla, the most obvious attraction of the product was its font handling. After the miseries of Netscape 4.7..., fonts Just Worked. I could set font sizes without agonies, and the full set of my fonts seemed to be available. Peter: Erik van der Poel, myself, Roland, rbs, and other have put a lot of work in to this and we are glad to hear your positive comments. There is still lots of things to be improved so the code is still changing. Bumps in the road do happen and we apologize for the current difficulty. We ask for your patience and help as we fix this. Roland: I would recommend that you ask him to make a minimal html page that demonstrates the problem, set the environment variable NS_FONT_DEBUG=1D (see nsFontMetricsGTK.cpp for the values and printfs), do a minimal run "./mozilla html:///dirs/filename.html", and then attach the html and moz's output to this bug. (I like the output attached rather than insert inline since they tend to be longish and it makes scanning the bug hard for new people.) (I added these to the font search code since every system tends to have different fonts and it was often hard to debug problems since I could not reproduce the setup.)
The font prefs are horked at the moment (bug 108939) and this is complicating tracking font problems. There is a similar default font-size mystery on the Mac at bug 111673.
pbwest: did you ever open a separate bug for this? it's been driving me insane since the fix for this bug went in a few weeks ago. an example url in which the fonts have changed for the worse is this: http://html.satelliterecords.com/HOUSE.HTM if i decrement the font size on this page once (via ctrl -) everything is back to normal, and incrementing the size makes it readable, but too large. sorry for the spam here, i'm just wondering if the appropriate bug has been filed yet...
Ian Wehrman: I raised bug 113814, which was marked as a duplicate of 108939. I tried the URL you mentioned, and had no problems with it (linux redhat 7.0; XFree86 4.1.0) on build within the past two days. The page shows up initially at a compact but readable size; Ctrl - reduces the font to an uncomfortable size, and Ctrl + then restores it to the original size.
When determining proper behavior the question should always be: Is moz following the html/css as closely as possible? Past behavior is at best a crude indicator. This is why it is critical to know what font sizes are being requested.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: