27378 - fonts look bad, blocky, jaggy in some configurations

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[Erik van der Poel]

Currently, we are only using the font family (e.g. "times") for font selection.
We should also use the foundry (e.g. "adobe"), since there are multiple versions
of times, and some of them are bad (e.g. urw).

Comment 1

[Erik van der Poel]

We may be able to look at the FONT_TYPE property to see if it's TrueType, in
which case we may want to use that font. We need to check whether this trick
is reliable.

Comment 2

[John G. Myers]

Instead of looking for "TrueType", I suggest you look for the known-ugly font 
types.  That way, a future beautiful font technology that can't use the TrueType 
trademark isn't excluded.

Comment 3

[Erik van der Poel]

-mdk-helvetica-* fonts are also ugly (Mandrake). We need to default to
adobe-helvetica, so we need the foundry (adobe) to be supported.

Comment 4

[Erik van der Poel]

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

Comment 5

[Erik van der Poel]

Target M16, after Beta 1 branch.

Comment 6

[Jungshik Shin]

In addition to foundry and font family, it might be necessary
to list font encoding in some cases. For instance, currently
Mozilla makes usee of at least two font encodings to
render Korean, ksc5601.1987-0 and johab(sh) and they have
different repertoire of characters and drastically different
quality(anyway, both have their own merits). With spread of ISO10646-1
encoded fonts(as distributed by XFree86 4.0) and support of them
by Mozilla, this could be the case not only of Korean but also
of other languages/scripts/encodings.

and 

Comment 7

[msanz]

need this fixed in beta2

Comment 8

[leger]

Putting on [nsbeta2+] radar.  But MUST complete work by 05/16 please.

Comment 9

[Erik van der Poel]

Fixed by adding support for the foundry field. Fonts are now selected by
foundry, family, charset registry and charset encoding.

Comment 10

[Chris Petersen]

Erik,

Is there a test case I can run to verify this fix or is this a code fix issue.

Comment 11

[Erik van der Poel]

Hi Chris, if you use a Unix machine that has both adobe-times and urw-times
installed, you *might* see the ugly urw fonts on the screen. It depends on the
hash order (in the old Mozilla, before my fix). After the fix, it does not use
the hash order, it uses the XListFonts order (xlsfonts -u). So I guess you might
be able to see the bug with an old build, and then see it go away with a new
build. Does this help?

Comment 12

[Chris Petersen]

Thanks for info. I will take a look at this.

Comment 13

[Chris Petersen]

Fixed in the May 31 Linux build (2000053108).

Comment 14

[Jungshik Shin]

Yet another field might be necessary to differntiate between fonts like
the following:

-misc-fixed-medium-r-normal-ja-13-120-75-75-c-120-iso10646-1
-misc-fixed-medium-r-normal-ja-18-120-100-100-c-180-iso10646-1
-misc-fixed-medium-r-normal-ko-0-0-100-100-c-0-iso10646-1
-misc-fixed-medium-r-normal-ko-18-120-100-100-c-180-iso10646-1

These fonts are shipped by default in XF86 4.0.x and everything is identical
except for the 'additional-style' field which is empty for most X11 fonts.
Do I have to file a new bug for this? 

Jungshik Shin

Comment 15

[Erik van der Poel]

Brian, please take a look at the previous comment in this bug report.

Comment 16

[kill this account]

I opened a bug, 71484, to look into the 10646 fonts with language tag