Closed Bug 46415 Opened 24 years ago Closed 2 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: 19 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: 19 years ago → 2 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.