93771 - Mozilla uses low-resolution bitmap fonts on high resolution X11 displays

Status: RESOLVED INVALID

(Core :: Layout, defect)

Description

[Roland Mainz]

[more or less a replacement for bug 92918]
Mozilla uses low-resolution fonts on high resolution X11 displays, e.g. on a
300DPI X11 display Mozilla uses a 90DPI bitmap fonts even if there a is
scaleable font (or bitmap font with matching or higher resolution) available
which would fit "better" on that display.
This results in a very _bad_ font quality.

Comment 1

[Roland Mainz]

It should be avoided (if possible [1]) that fonts are used which have a lower
resolution than the current display (scaling high-resolution fonts "down" isn't
that bad... far better than a "scale-up" of bitmap fonts).

[1]=Bitmap fonts should _not_ be disabled complely if their resolution does not
"match"... this would kill support for charsets where the system does not have
much fonts installed for... like Japanese on a plain Solaris 7 installation.
Those fonts should simple be "treated" as last option - use them if every other
option fails...

Comment 2

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

layout

Comment 3

[kill this account]

I'd like to suggest we change the title of this bug to:

  XPrint: should use outline scaled fonts when avail

Once the in bug 94327 is in we will have combined all the fonts of a given 
Any_foundry/Family/Registry/Encoding (AFRE) together. This means that if any
of these font is an outline scaled font if will be in that set (bug 74889).

The non-Xprint code (at least the GTK version) Erik combined the fonts into 
FFRE (Foundry/Family/Registry/Encoding) sets so users could select a Helvetica
font from Adobe instead of URW because the URW bitmap fonts were jaggy.

I would hope that at 300 DPI all the outline scaled fonts look good so my
first suggestion would be to try this:

  Xprint should always look in the AFRE for fonts

  Xprint should select an outlined scaled font if available (see
PickASizeAndLoad)

Comment 4

[Roland Mainz]

> I'd like to suggest we change the title of this bug to:
> 
>   XPrint: should use outline scaled fonts when avail

IMHO _no_ because this a generic X11 issue. There are already 200DPI color
monitors available - and grayscale monitors are available for 300DPI and more.
We really should avoid 75DPI bitmap fonts on 300 DPI displays if there are
"better" fonts available.

Xprint just get's "hit" more often because the higher DPI values are more
"common" on this type of output device.

> Once the in bug 94327 is in we will have combined all the fonts of a given 
> Any_foundry/Family/Registry/Encoding (AFRE) together. This means that if any
> of these font is an outline scaled font if will be in that set (bug 74889).
> 
> The non-Xprint code (at least the GTK version) Erik combined the fonts into 
> FFRE (Foundry/Family/Registry/Encoding) sets so users could select a Helvetica
> font from Adobe instead of URW because the URW bitmap fonts were jaggy.
> 
> I would hope that at 300 DPI all the outline scaled fonts look good so my
> first suggestion would be to try this:
> 
>   Xprint should always look in the AFRE for fonts
> 
>   Xprint should select an outlined scaled font if available (see
> PickASizeAndLoad)

Uhm... the Xprint module uses Xlib gfx fontmetrics code which is AFAIK in "sync"
with GTK+ fontmetrics code.
I'd like to handle the Xprint stuff just like any other X11 stuff... AFAIK there
is no need to add exceptions (except the workaround for this bug :-)

BTW: s/XPrint/Xprint/ ... :-)

Comment 5

[karnaze (gone)]

reassigning to ftang.

Comment 6

[Frank Tang]

x11 stuff. reassign to bstell

Comment 7

[Roland Mainz]

Example debug output printing http://www.cnn.com/ via Xprint module (300DPI
printer) + XPRINT_FONT_HACK in mozilla/gfx/src/xlib/nsFontMetricsXlib.cpp
disabled:
-- snip --
nsFontMetricsXlib::Init == 'serif'
nsFontXlib::LoadFont: '-adobe-times-medium-r-normal--57-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
=== cannot get lang group for x-cns-11643-2
=== cannot get lang group for x-cns-11643-3
=== cannot get lang group for x-cns-11643-4
=== cannot get lang group for x-cns-11643-5
=== cannot get lang group for x-cns-11643-6
=== cannot get lang group for x-cns-11643-7
=== cannot get lang group for ISO-8859-3
=== cannot get lang group for jis_0201
=== cannot get lang group for jis_0212-1990
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-medium-r-normal-sans-39-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-bold-r-normal-sans-39-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'Georgia,sans-serif,serif'
nsFontXlib::LoadFont: '-adobe-helvetica-medium-r-normal--42-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-medium-r-normal-sans-35-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,arial,sans-serif,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--35-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-medium-r-normal-sans-57-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'arial,helvetica,sans-serif,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--78-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'arial,helvetica,sans-serif,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--57-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-medium-r-normal-sans-43-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-bold-r-normal-sans-43-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'Arial,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--43-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontMetricsXlib::Init == 'Verdana,Arial,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--39-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-bold-r-normal-sans-57-*-*-*-m-*-iso8859-1'
nsFontMetricsXlib::Init == 'Arial,serif'
nsFontXlib::LoadFont: '-monotype-arial-bold-r-normal--53-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'arial,helvetica,sans-serif,serif'
nsFontMetricsXlib::Init == 'arial,helvetica,sans-serif,serif'
nsFontXlib::LoadFont: '-monotype-arial-regular-r-normal--43-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'arial,helvetica,sans-serif,serif'
nsFontXlib::LoadFont: '-monotype-arial-regular-r-normal--35-*-*-*-p-*-iso8859-1'
nsFontMetricsXlib::Init == 'verdana,"Lucida Sans Typewriter",helvetica,serif'
nsFontXlib::LoadFont: '-b&h-lucida sans
typewriter-bold-r-normal-sans-35-*-*-*-m-*-iso8859-1'
-- snip --

The result of this is that most of the text is rendered with 75DPI/100DPI
"Lucida Sans Typewriter" fonts on a 300DPI device... ;-(

One (simple) solution would be to make a 2-pass font lookup step:
1. Try to find a font but ignore any fonts which have a resolution lower than
the device's resolution
2. If [1] did not find any matching fonts then try again without that
restriction.

Comment 8

[kill this account]

is the XPrint system using the actual pixels or does it do some scaling
behind the scene?

Comment 9

[Roland Mainz]

> is the XPrint system using the actual pixels or does it do some scaling
> behind the scene?

Nope, Xprint does not do any scaling (except for images rendered via
XPutImage(), see |XpSetImageResolution()|. But this does not affect fonts,
_only_ images).

Comment 10

[kill this account]

Roland: could you discuss the actual differences between:

 1) a 24 pixel font rendered at 75 DPI

 2) a 24 pixel font rendered at 100 DPI

 3) a 24 pixel font rendered at 300 DPI

Comment 11

[kill this account]

--> ftang

Comment 12

[Frank Tang]

bulk move NEW FUTURE bug to ASSIGN

Comment 13

[Roland Mainz]

Attachment: Patch which will never really work

This patch does not work properly - but it looks how things should work.
1. Get rid of all the workarounds/hacks to cure the syptoms of _this_ bug.
2. Ban lowres fonts unless there is no other font available (for example - when
there is no other font in this charset then we have to pick this one)

However - this patch is far too simple.
AFAIK we need two lists - one list of fonts which fit into the resolution (or
are scaleable) and a 2nd list of all "lowres" fonts which do not match our
resolution requirements.
The first list is searched always - and the 2nd list is only searched if we did
not find anything in the first list.

Comment 14

[Roland Mainz]

Comment on attachment 82013 [details] [diff] [review]
Patch which will never really work

I forgot to comment that the patch uses a hardcoded DPI value of "300" (instead
of asking the Xserver for it's DPI value) ...

Comment 15

[Roland Mainz]

Brian Stell wrote:
> Roland: could you discuss the actual differences between:
> 1) a 24 pixel font rendered at 75 DPI
> 2) a 24 pixel font rendered at 100 DPI
> 3) a 24 pixel font rendered at 300 DPI

All these fonts are 24pixels in height but may use different fonts as source.
(Assuming the Xserver runns at 300 DPI:)
[1] may come from /usr/openwin/lib/X11/fonts/75dpi/  (=bitmap font)
[2] may come from /usr/openwin/lib/X11/fonts/100dpi/ (=bitmap font)
[3] may be a outline scaleable font (or a printer-builtin font if the display is
on Xprt)

Comment 16

[Boris Zbarsky [:bzbarsky]]

To Roland.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

I do not expect this is an issue anymore as the way we do fonts is completely different now.

Comment 18

[ran]

I want to see bug report