Closed Bug 46415 Opened 25 years ago Closed 3 years ago

Arial looks much smaller than Helvetica at same size, and is hard to read

Categories

(Core :: Layout: Text and Fonts, defect, P3)

Product:
Core
Component:
Layout: Text and Fonts
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
Future

People

(Reporter: akkzilla, Unassigned)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [nsbeta3-] relnote-user)

Split off from bug 46286: When I view the test case in that bug (see URL for this bug) in mozilla on a vanilla Redhat 6.2 system (standard server, I haven't installed any unusual fonts), the Arial fonts are all significantly smaller than the others, though the size specified is the same. The result of this is that all web pages and mail messages which specify Arial are difficult to read in Mozilla, because the font will be smaller than intended. Perhaps this is just a Redhat bug and can be fixed by downloading a better Arial font, since the one that comes with Redhat is difficult to read even at larger sizes (cc'ing blizzard); but most users won't know how to do that, so we should either figure out the answer and spoon-feed them a solution in our help pages, or work around it by adjusting the sizes so that we use a larger size when Arial is specified. Adjusting the sizes may cause problems on other systems which have a correct Arial font, though. I wonder whether there's any way to tell whether a system has the bad Arial or not?
You should make sure that the X server, any font servers, and Mozilla are on the same page dpi-wise and that they match the screen resolution you use. If you use a font server and can find its config file (/etc/xfs/, maybe), then you can find its font path (called a "catalogue" for some reason) and that should lead you to the Arial font. I use a real truetype font and it works well but almost anything is possible. It may also be useful to use the NS_FONT_DEBUG trick to document what Mozilla is doing.
Nominating for nsbeta3 since it's a dogfood issue for me (too many pages out there use Arial, and I can't read it in mozilla). Though if bug 31816 (use my fonts, overriding document fonts) were fixed, I'd have a workaround.
Keywords: nsbeta3
Just a note that Arial is actually larger than Helvetica on my system, at large sizes quite a bit larger (but that's bug 41552). I think this shows that Linux font support is rather fragile.
If you use xfd to see your Ariel and Helvetica font. Is Ariel smaller than Helvetica ? If the answer is yes, then it is a problem in the font.
Not sure how to test this, since I don't know which arial mozilla is choosing (I seem to have -graphis-grarial, -grinet-greekarial, and -ult1mo-arial installed) and what size it's choosing for any given point/mm size. All three of these, at pretty much all sizes, are awful, though: blotchy and looking like they've been scaled badly. They'd have to be much larger than helvetica to be readable. If it's typical of linux systems to have such bad arial fonts (and this is a vanilla RH6.2 system), I think we should just map arial to helvetica. If we can't do that, let's find out where people can download a better arial font so they can make web pages readable, and get it prominently displayed in the release notes.
Summary: Ariel looks much smaller than Helvetica at same size → Ariel looks much smaller than Helvetica at same size, and is hard to read
The first thing to do is figure out which fonts Mozilla is opening. From a Bash shell say something like: NS_FONT_DEBUG=3 ./mozilla URL &>/tmp/moz.log Close Mozilla as soon as your test page is loaded to keep the log file small. Now say something like: grep ^loaded /tmp/moz.log and you will see which fonts Mozilla actually loaded. Now you should say: xlsfonts -u -fn '-*' >/tmp/fonts.lst which will give you an unsorted list of XLFD names. From the list you can tell if Mozilla is loading the fonts you want. The biggest hurdle now is finding the physical font. You should first say: xset q and look at the font path. If you're using just Redhat's font server then you can say: chkfontpath --list It may be simpler to just say: find / -name fonts.dir and look through the results for your Arial fonts. If there not there, then search through any fonts.alias files. I'll bet the fonts are just aliases for something weird. Almost anything is possible: aliases to URW fonts, truetype fonts converted to a set of bitmap fonts, even Adobe "Arial MT" type1 fonts. There are no Arial fonts in the standard X distribution. I don't know if Redhat supplies some. In any case, please do not map Arial to anything else. One can get real Windows truetype Arial fonts and they work nicely. This really sounds like a system configuration issue rather than a Mozilla bug but you're absolutely correct that there must be a good explanation or many users will get very confused.
The more I think about implementing Mozilla on top of X, the more I believe that we should Just Say No to circumstantial hacks, which have a way of coming back to haunt us later. Instead, we should provide good documentation to help people get rid of all those common but ugly fonts (e.g. ult1mo's arial).
Tenthumbs: thanks for the extensive instructions! It's loading the ult1mo-arial-medium-r-normal--*-*-*-*-p-*-iso8859-2 fonts. chkfontpath --list gave me a list of 31 paths, all under /usr/X11R6/lib/X11 or /usr/share/fonts. Doing a find [path] -name "*rial*" in those two directories turned up /usr/share/fonts/ISO8859-7/Type1/grarial.{afm,pfb} (which are real files, not links) but nothing on ult1mo-arial; finding for ult1mo also turned up nothing. I don't think they're all links to the same font: if I run xfontsel and pin down weight, slant, and pxlsize and switch between the three arials, I see three different fonts (at similar but not identical sizes, and all looking badly rescaled). How would font aliases be stored (i.e. how should I be looking for them)? Should they be symlinked files, or is there a list of aliases somewhere, or what? If we can find out what's up, maybe we can talk to Redhat about the Arial they distribute, and get them to fix it, and then mozilla (and other apps, too) will be usable without the user having to remap anything at all. That would be the best solution. My suggestion of remapping it on the mozilla end was simply because I've had no luck getting information on how to remap it on the system end, and if I can't, then for sure a lot of mozilla/Netscape users won't.
Aliasing is normally done in fonts.alias files in places like /usr/lib/X11/fonts (but the exact directory is vendor-dependent).
I do have aliases for the various arial fonts (all three types), 12 lines in the file /usr/share/fonts/ISO8859-2/Type1/fonts.alias, which typically look like: "-ulT1mo-Arial-bold-i-normal--0-0-0-0-p-0-iso8859-2" "-ulT1mo-Arial-bold-i-normal--0-0-0-0-p-0-adobe-fontspecific" (substituing for bold, i, etc.). which doesn't really clear up my confusion over where these fonts are actually living. Is this where I'd make a change (changing those 12 lines to fonts I found more readable) and where we'd advise other users to make a change if they had the same problem?
Akkana, "man mkfontdir" has useful information but, in typical Unix fashion, there's no way anyone could know about this in advance. Basically, fonts.dir files are the databases that map physical font names to logical XLFD names. Mkfontdir can generate fonts.dir files but it only knows about the basic BFD and PCF fonts. For everything else it just blindly adds the fonts.scale file, if there is one. You either use specialized tools to generate a fonts.scale or you do it by hand. Over time, it was found that ways were needed to 1) provide short names rather than the overlong XLFD names, 2) provide a workaround for apps that assumed their hard-coded fonts existed, and 3) provide a way to equate one font encoding to another. This is what the fonts.alias files are for. It's important to note that XLFD font encodings are representations of the internal structure of a font not mappings in the Unicode sense, although they often coincide, because that's the situation you have. In your case, the ulT1mo-Arial alias says equate all 8859-2 encoding references to adobe-fontspecific ones. The font itself may or may not have all the 8859-2 glyphs but it obviously has the wrong encoding. This is actually a feature. To find the actual font file, use the fonts.alias file to work backwards to the real XLFD name and then the fonts.dir file to the physical name. Now there can be more than one fonts.alias file and they affect all fonts along the font-path but it is important to remember that the X server's font-path is not the same as the X font server's font-path. For a standard Redhat, the font server's config file is /etc/X11/fs/config. If "xset q" says X is using more than just a font server then you'll have to check out those places as well. You can try commenting out the ulT1mo-Arial alias but it may be simpler to just remove that particular directory. Make sure the font server is restarted. I find it disturbing that a 8859-2 font is in a 8859-7 directory. Are you sure you haven't installed some extra package? Erik, I hate to say this but there may actually be a Mozilla bug here. Assuming Akkana defaults to an 8859-1 encoding, should Mozilla have gone for 8859-2? This is similar to bug 42917 and others. I realize it's late in the game to do anything major but it will have to be addressed eventually. I also realize that X fonts are disgustingly difficult to deal with. I'm also glad to see that you're coming around to my way of thinking. You can't prevent people from shooting themselves in the foot; if you try, they just get a bigger gun.
Forgot to add that, if you have 8859-1 fonts, you can try re-ordering the font-path so they come before the others. You may also want to consider splitting up fonts into different directories. One of X's quirks is that it always orders XLFD names in lexicographic order within a directory so sometimes the only way to make the fonts you want come out in the order you want is to use separate directories.
nsbeta3- per i18n bug meeting. This seems a problem of the installed font.
Whiteboard: [nsbeta3-]
Then we'd better release note it, since it makes mozilla unusable for many web pages on Redhat, supposedly one of our supported platforms.
Keywords: relnote
> Erik, I hate to say this but there may actually be a Mozilla bug here. > Assuming Akkana defaults to an 8859-1 encoding, should Mozilla have gone > for 8859-2? Isn't this what we agreed to on mozilla.unix? We said that if the Web page asks for Arial, then Mozilla would start at the top of the font list, and take the first one that matches. The user has ult1mo-arial near the top, so it is chosen. Web pages are often encoded in iso-8859-1, but you can use NCRs (numeric character references) like 〹 to access *any* Unicode character. We convert the incoming iso-8859-1 document and any NCRs into Unicode for internal processing, and then we take it from there in the font engine. If the Web page has specified any language tags, they will be passed down to the font engine. If there are no language tags, a fallback based on the original charset (e.g. iso-8859-1 -> x-western) gets passed down. So we are not guaranteed to even have that info available to us in the font engine currently (since it's just a fallback). I suppose we could open up the discussion again, and then decide to make yet another change of this magnitude, but going back and forth on these issues is pretty tiring, and we should try to make a better decision this time. Also, it's getting late to make big changes, since Beta 3 is coming, and RTM will follow that. Maybe we should just put a stake in the ground, leave Mozilla as it is, and tell all those poor users to get rid of their ugly ult1mo-arial fonts.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Tenthumbs: thanks again for the tutorial! I'm still fuzzy on how a lot of this works, and will keep re-reading your explanation and the various man pages (does O'Reilly or anyone have a good book that explains X fonts? Probably a forlorn hope, but ...) as I try to learn more about this. I'd like to be less clueless on the font issue since I seem to get bitten so often. Anyway, I removed (well, moved somewhere else) my whole /usr/share/fonts/ISO8859-2 directory and restarted the X server (not sure if that part was necessary), and now Arial looks just like Helvetica -- same size, same readability. I'm happy and should be able to use Mozilla to browse to pages with Helvetica now. Is this a reasonable thing to suggest to people in the release notes? Perhaps something like this: <relnote> Linux users: If you find that pages which use "Arial" fonts are difficult to read -- for example, if <font face="arial">this Arial text</font> looks smaller or harder to read than the rest of the text in this paragraph -- try the following: <pre> rm -rf /usr/share/fonts/ISO8859-2 </pre> and then log out of X and log back in again. </relnote> rm -rf seems a little severe ... we could suggest mv'ing it, as I did, but I'm not sure where (I moved mine to /usr/share.fonts.ISO8859-2; /usr/share/fonts.ISO8859-2 might be a better suggestion. Then we would change the suggestion to <relnote> Redhat 6.2 (and perhaps other Linux) users: If you find that pages which use "Arial" fonts are difficult to read -- for example, if <font face="arial">this Arial text</font> looks smaller or harder to read than the rest of the text in this paragraph -- try the following: <pre> mv /usr/share/fonts/ISO8859-2 /usr/share/fonts.ISO8859-2 </pre> and then log out of X and log back in again. <p> You can always undo this, if necessary, with the command: <pre> mv /usr/share/fonts.ISO8859-2 /usr/share/fonts/ISO8859-2 </pre> </relnote> Blizzard: is there anyone at Redhat we could talk to about the awful ISO8859-2 fonts? Perhaps this will be fixed in RH7, or in some downloadable RPM; or by removing some RPM that Redhat installs but which isn't really necessary? (In which case, it would be much better simply to suggest that users use RPM or upgrade to a newer release.)
pbrown@redhat.com and otaylor@redhat.com are probably the best contacts for font related issues. They might have a clue about what you're talking about here. Unfortunately, I don't.
Eric, you're right that the current behavior is what we talked about. Blame me for not realizing that the case where we're looking for a replacement glyph is not the same as the case where we're looking for an entire font. Mozilla might get away with slipping in a single glyph from an ugly font (but bug 42917 shows that people sometimes notice) but rendering an entire page in some ugly font clearly won't work. Mozilla really needs to supply a quantity that describes the urgency of the request; i.e., "I absolutely, positively must have something now" vs. "I need this, but I've got some other things to try so don't get too carried away." Maybe that should be a "quality" or "closeness" of match coefficient; whatever. However, this isn't going to happen now. I agree it's too late for any major changes. All I would deal with is bug 40373. The rest can wait. There is good news; the latest ult1mo packages have dropped the Arial and other clones for legal reasons so this particular problem will slowly disappear. Still, this stuff must be addressed eventually. There's no reason to assume that an X user can control the X server, or its font servers, in any way; the user might not be sufficiently privileged or the servers might be on remote machines. Mozilla needs to operate reasonably well in this kind of environment. I have some ideas. Maybe I'll open another bug. Akkana, you probably should use chkfontpath --delete (or whatever the option is called) to remove font directories or the font server will keep looking for something that's not there. A font section in the release notes is certainly a good idea but it may be hard to describe exactly what to look out for. You and I know about Arial and things like that but I don't thing you can assume all users do. Maybe a reference to a special test page that says something like: "here are some (English) text samples in some of the more common web fonts; if they look bad, there's a problem and here's some ideas." Of course, as you found out, discovering which font is at fault and where it is can be an adventure.
Malte Gell <malte.gell@gmx.de> on mozilla-unix just said: > Lack of true type font support ? Update to XFree86 4.0x (SuSE has > updates for SuSE 6.2-7.0) and use true type fonts with Netscape, looks > very nice now on my machine. I haven't tried yet myself, but that might be better advice to give people, if it works.
Yes, TT fonts are much better but all the useful ones are from Microsoft and I wonder if there are licensing issues; e.g., can they be used on Linux if they are only available as Win32 executables. If you ignore the licenses, they work just fine.
I should add that truetype support has been available in one form or another for Linux for years. If Redhat didn't publicize that fact, that's Redhat's problem.
tenthumbs: The user _should_ generally be in control of the X server, since by definition the X server will be on the user's machine. Of course, if the user uses a remote X font server then that's a different matter.
Akkana: regarding your comment in bug 51920: I wrote how to fix the font-mess on linux here: http://home.c2i.net/dark/linux.html#ttf http://home.c2i.net/dark/linux.html#fuzzy Font handling on linux sux long way - but isn't inrepairable. The "disaster" is how font-handling is pretty much left up to the user, in lack of standards. In addition, Windows and Linux thinks same size font is two wildly different things; Linux is "off by two" - a bug i believe may be in the freetype library. But all can be mended. Figuring out the "Right Way" was the first thing i did after starting to use linux, and it took me 4 months to figure it all out, so go take a look.
Ian Hickson, yes you're right. I get confused a lot by X's arcane architecture. Things like Xnest or Xvfb can confuse matters even more. I disagree that a user can always control an X server. I can set up a system using xdm and normal users will not be able to alter X's settings. My basic point is that Mozilla will, at some time in the future, need to be more clever.
The contents of the relnote for this bug seem very unclear. Can someone clarify? Gerv
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-user
Okay, how about this: Many Linux systems (in particular, Redhat systems) have bad Arial fonts. If you're on a Linux system and many web pages, especially those using the "Arial" font, look unclear, small or are otherwise hard to read, the following links explain two ways you can change your font server to get better Arial fonts: http://home.c2i.net/dark/linux.html#ttf http://home.c2i.net/dark/linux.html#fuzzy Alternately, if that doesn't work, you may be able to fix the problem by renaming or removing /usr/share/fonts/ISO8859-2, e.g. <pre> mv /usr/share/fonts/ISO8859-2 /usr/share/fonts.ISO8859-2 </pre> and then log out of X and log back in again. You can always undo this, if necessary, with the command: <pre> mv /usr/share/fonts.ISO8859-2 /usr/share/fonts/ISO8859-2 </pre>
The proposed relnote is rather specific and following the advice could conceivably cause X not to start. I doubt that's a good idea. I think you want something more general like: "The X windows system uses fonts from many different sources. In an attempt to replicate a common font, like Arial, an installed X font may claim to be something it is not. For example, some Linux distributions come with an Arial font that is of much poorer quality than the real one." "To work around this sort of problem, it is possible to rearrange the X server's font path to either eliminate the directory containing the problem fonts or move the offending font to the end of the font path where it is less likely to be selected. Some Linux distributions offer special tools to manipulate the font path. Redhat, for example, has chkfontpath. Other distributions rely directly on the X server's configuration files." Something like that, anyway.
reassign to bstell and keep it as Future
Assignee: erik → bstell
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
The ugly fonts in RH Linux come from AbiWord. They really need to fix this. See: http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=18855 and http://www.abisource.com/bugzilla/show_bug.cgi?id=1030
I tested the methods you described in here and found that the problem (in my case) is that redhat (I tested 7.0) allows the x font server to scale bitmap fonts, even if it may have a better font, resulting in very hard edged, horrible and hard to read fonts. Redhat actually has a bug in the configuration of xfs (x font server, /etc/X11/config) that has in the list of paths the bitmap fonts with the ´:unscaled´ (that means that it won´t allow them to scale) option and the same without it, causing that when it needs to load a font it may load a scaled bitmap. The release notes should mention this. I think that mozilla may be able to workaround this problem by filtering the fonts that are scaled bitmaps, like you can do with the gnome font selector. (if you have gnome you can load it from Utilities->Font selector) As a side note please correct the subject, it sais Ariel instead of arial.
In the last message I meant ´/etc/X11/fs/config´. A corrected example file follows, the original was the same but with many paths repeated (those that end with ´:unscaled´): # # Default font server configuration file for Red Hat Linux # # allow a max of 10 clients to connect to this font server client-limit = 10 # when a font server reaches its limit, start up a new one clone-self = on # alternate font servers for clients to use #alternate-servers = foo:7101,bar:7102 # where to look for fonts # catalogue = /usr/X11R6/lib/X11/fonts/misc:unscaled, /usr/X11R6/lib/X11/fonts/75dpi:unscaled, /usr/X11R6/lib/X11/fonts/Type1, /usr/X11R6/lib/X11/fonts/Speedo, /usr/share/fonts/default/TrueType # in 12 points, decipoints default-point-size = 120 # 100 x 100 and 75 x 75 default-resolutions = 75,75,100,100 # use lazy loading on 16 bit (usually Asian) fonts deferglyphs = 16 # how to log errors use-syslog = on # don't listen to TCP ports by default for security reasons no-listen = tcp
Agustín, Can you give a code snippet that shows how the gnome Utilities->Font selector determines that a scalable font is a bitmap font?
I can. Assume that mozilla fully parses the xlfd name; then FontScaleType = (pixel_size == 0 ) + (point_size == 0) + (resolution_x == 0 ) + (resolution_y == ); switch (FontScaleType) { case 0: /* bitmap font */ case 4: /* scalable font */ case 2: /* scaled bitmap */ default: /* mutant bogon */ }
Summary: Ariel looks much smaller than Helvetica at same size, and is hard to read → Arial looks much smaller than Helvetica at same size, and is hard to read
This is interesting. Is there a reference that documents this behavior?
Just recently I've been seeing another Redhat Arial related problem: sites that force font face Arial and font size +2 or bigger, and I get these huge blocky letters that have obviously been scaled way up from small 10 or 12 pixel high versions (and now the pixels are 1/2cm squares). I'm not sure whether something changed in mozilla, or on my machine (I installed some fonts for MathML, but can't think of anything else font related that I've changed recently). This is not a readability problem like the too-small Arial that started this bug; it's just ugly.
Documentation? This is Unix. Who need documentation when you have the source code? Seriously, I couldn't find any. I did look at XFree86, Gimp, assorted GTK widgets, Wine, and a few other programs and they all act as I describe. This is some logic here. Bitmap fonts have hardcoded resolution values so the X server (or xfs) offers them in that resolution but a scalable size. You see the scaled bitmaps with a pattern like "0-0-100-100". You should also look at bug 34242. If mozilla stays as it is, then the X server will also offer fonts with a pattern like "12-12-0-0" (where 12 is the default font size; could be a different value). No, I don't know why. You can see all of this behavior from the command line. Compare xlsfonts -u -fn '-*-*-*-*-*-*-*-*-*-*-*-*-*-*' with xlsfonts -u -fn '-*' Akkana: are you seeing this on normal pages or just MathMl pages? Which math fonts did you install? I found it best to use the type1 fonts and ignore TTF fonts unless there's no other choice.
Oops, I never answered Tenthumbs' question. I was seeing the problem on normal pages, not just MathML pages; though oddly, I haven't seen it at all this week, so either there was some temporary change in Mozilla, or I just happened to go to several sites specifying absurdly large font sizes the week I was seeing the problem with large blocky Arial. For MathML I installed Wolfram Type 1 fonts and cmps fonts (at least, I think those are the other fonts I installed for MathML -- not sure how else they would have gotten into my /usr/local/fonts dir). I started with the Wolfram fonts but I found that a lot of the MathML demo pages still didn't display correctly (it was missing integrals or sigma-summations or something).
Akkana: you need the math fonts at <ftp.ams.org//pub/tex/psfonts/amsfonts> as well. Also, make sure that you have the equivalent of the cm fonts from <ftp.ams.org//pub/tex/psfonts/cm>. Do NOT install the beta STIX fonts. They all have iso8859-1 encodings even though they're not. Mozilla will get confused.
Redhat note: I just tested on a machine recently upgraded from RH6.2 to RH7.0, which has had no font changes (I haven't edited the font directory, nor installed any extracurricular fonts) and where rpm -qa | grep -i word | grep -i abi gives nothing, and arial fonts in mozilla are still smaller and blockier than helvetica of the same size. The bad Arial doesn't appear to be AbiWord's fault.
Didja check for "abisuite"?
On a system with chkfontpath installed and xfs as the only source of fonts, I suggest this command for rooting out the troublesome fonts: chkfontpath --list | cut -d: -f 2 | xargs -i find -maxdepth 1 {} - name 'fonts.*' | xargs grep -iH 'arial' This should allow you to zero in on the files which provide the troublesome fonts. On my system I found them all in /usr/share/fonts/ISO8859-2/Type1
--> ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
bulk move NEW FUTURE bug to ASSIGN
Status: NEW → ASSIGNED
*** Bug 116581 has been marked as a duplicate of this bug. ***
If you want to install easily high-quality Arial (and many other) fonts, try http://freshmeat.net/projects/webfonts4linux/
I am using RH 7.2. After copying MS Web fonts and enabled TT in Mozilla Arial still looked way smaller than in Windows. I 've been trying to solve the problem for ages using fonts.alias files for sizes less than 12 (alias everything to 14) and anything else people were mentioning. Nothing really helped until I changed my <b>dpi</b> (dots per inch) settings. I have a resolution of 1280x1024, changed my dpi settings as described in <a HREF=http://www.mozilla.org/unix/dpi.html>http://www.mozilla.org/unix/dpi.html<a> and I am happy mozilla user ever after. I don't know if this is specific RH7.x problem but I recommend linking people to this information.
Another option is to override *all* font settings via CSS. I've created a stylesheet which does this, using only the user's specified font(s) and default font size(s): * http://kmself.home.netcom.com/Download/userContent.css Sample pages w/o & w/ stylesheet: * http://kmself.home.netcom.com/Download/test.html * http://kmself.home.netcom.com/Download/test-css.html See also: http://twiki.iwethey.org/twiki/bin/view/Main/UserContentCSS
Component: GFX → Layout: Fonts and Text
what a hack. I have not touch mozilla code for 2 years. I didn't read these bugs for 2 years. And they are still there. Just close them as won't fix to clean up.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → WONTFIX
Mass Reassign Please excuse the spam
Assignee: ftang → nobody
Mass Re-opening Bugs Frank Tang Closed on Wensday March 02 for no reason, all the spam is his fault feel free to tar and feather him
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Reassigning Franks old bugs to Jungshik Shin for triage - Sorry for spam
Assignee: nobody → jshin1987
Status: REOPENED → NEW
QA Contact: chrispetersen → layout.fonts-and-text

Mass-removing myself from cc; search for 12b9dfe4-ece3-40dc-8d23-60e179f64ac1 or any reasonable part thereof, to mass-delete these notifications (and sorry!)

The bug assignee didn't login in Bugzilla in the last 7 months.
:jfkthame, could you have a look please?
For more information, please visit auto_nag documentation.

Assignee: jshin1987 → nobody
Flags: needinfo?(jfkthame)

This looks like it was related to bitmap font configurations that have long since been superseded; I don't think there's any value in keeping it open. Too much has changed, both in Gecko and in the OS environment, for this to be meaningful any more.

If anyone has remotely similar issues with a current Firefox version and a current Linux system, please file a new issue with the details.

Status: NEW → RESOLVED
Closed: 20 years ago → 3 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.