148690 - RFE: For Xprint force use of outline scaleable fonts if possible

Status: RESOLVED FIXED

(Core Graveyard :: Printing: Xprint, enhancement)

Description

[Roland Mainz]

RFE: Xprint module should force the use of outline scaleable fonts if possible

Comment 1

[Roland Mainz]

Taking myself...

Comment 2

[Roland Mainz]

Attachment: Patch for 2002-05-31-08-trunk

This patch forces the use of outline scaled fonts (or printer-builtin fonts)
unless there is no other font available.

Comment 3

[Roland Mainz]

BTW: This patch "obsoletes" the hack fix for bug 88554 ("Xprint module should
avoid using GFX fonts unless there is no other option", see see |#ifdef
XPRINT_FONT_HACK| in mozilla/gfx/src/xprint/nsDeviceContextXP.cpp) + bug 116158
("Enhance the workaround for bug 88554") and may even be a fix for bug 93771
("Mozilla uses low-resolution bitmap fonts on high resolution X11 displays") on
Xprint devices.

Comment 4

[Roland Mainz]

Attachment: New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)

Comment 5

[Roland Mainz]

Requesting r=/sr= ...

----

The patch now "avoids" non-outline scaleable fonts on Xprint devices unless
there are no other fonts available for this encoding.

I know we are loosing the ability to address bitmap fonts via the CSS spec but
that was _excactly_ the problem what caused bug 88554 and all the DUPlicates for
this issue (the bitmap fonts are not _banned_, the patch just avoids that locale
prefs or CSS specs cause that we print always with bitmap fonts).
I am confident that we do not want to print bitmap fonts all the time when there
are better-quality (scaleable!) fonts available
Scaleable fonts are _not_ affected by this patch and are addressable via CSS and
locale prefs as usual... :)

Risk control:
The patch adds a new pref which which enables the feature by default for Xprint
devices (it's disabled by default on normal (framebuffer) Xservers, e.g. does
not affect the users unless they print with Xprint) but allows to disable the
code if something goes wrong.

I've tested the patch with the print regression tests, MathML sample pages and
the examples from bug 88554 &co. (e.g.
http://www.fbi.gov/congress/congress99/freehct2.htm , http://www.cnn.com/ etc.)
and they all printed fine without bitmap fonts even when you offer tons of them.

Comment 6

[Shanjian Li]

Comment on attachment 86073 [details] [diff] [review]
New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)

It make sense. r=shanjian

Comment 7

[kill this account]

Changed the title from:

  RFE: Force use of outline scaleable fonts if possible

to:

  RFE: for XPrint force use of outline scaleable fonts if possible

Roland: Could you describe how this global only affect print display and
not screen display:

+#ifdef USE_XPRINT
+  if (nsFontMetricsXlib::mPrinterMode) {
+    gForceOutlineScaledFonts = PR_TRUE;
+  }
+#endif /* USE_XPRINT */

Comment 8

[Roland Mainz]

Brian Stell wrote:
> Changed the title from:
>  RFE: Force use of outline scaleable fonts if possible
> to:
>
>  RFE: for XPrint force use of outline scaleable fonts if possible

s/XPrint/Xprint/ :)

> Roland: Could you describe how this global only affect print display and
> not screen display:
>
> +#ifdef USE_XPRINT
> +  if (nsFontMetricsXlib::mPrinterMode) {
> +    gForceOutlineScaledFonts = PR_TRUE;
> +  }
> +#endif /* USE_XPRINT */

1. |static| variables are only per object file, e.g. having two |static| vars
with the same name in different object files does not cause any problems - they
are  all seperate (look above and below the declaration of that var - there are
tons of those vars which have the same name and datatype as in other modules).
Don't worry... :)
2. [not the case here but listed for completeness:] global variables are (in
Mozilla) per XPCOM module, having two global vars in two seperate modules cannot
cause problems.
3. [not the case here but listed for completeness:] The only known problem in
mozilla is when we have C++ class names in different modules with the same name
- this will cause a build failure in StaticBuilds on some platforms.

Comment 9

[kill this account]

Okay, I was not thinking about a cross module build issue but I'm glad to hear
we do not have a problem.

I was curious what effect gForceOutlineScaledFonts would have if 
nsFontMetricsXlib::mPrinterMode = PR_FALSE.

Comment 10

[Roland Mainz]

Brian Stell wrote:
> I was curious what effect gForceOutlineScaledFonts would have if 
> nsFontMetricsXlib::mPrinterMode = PR_FALSE.

Well, then the code should behave like on normal displays unless you set the
"font.x11.force_outline_scaled_fonts" prefs to TRUE (this feature may be very
valuable for (non-Xprint) high-resolution displays (you can get 200 DPI displays
for less than 10000 euro and even "affordable" 300 DPI displays are available
today :))

Comment 11

[Roland Mainz]

Requesting sr= ...

Comment 12

[Johnny Stenback (:jst)]

Comment on attachment 86073 [details] [diff] [review]
New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)

sr=jst

Comment 13

[Roland Mainz]

Requesting a{1.1alpha}= ...

Comment 14

[Roland Mainz]

Requesting a{1.0.1_branch}= ...

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

Comment on attachment 86073 [details] [diff] [review]
New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)

please check into the 1.0.1 branch ASAP. once landed remove the 
mozilla1.0.1+ keyword and add the fixed1.0.1 keyword

Comment 16

[Simon Montagu :smontagu]

Checked in to trunk for Roland

Comment 17

[Roland Mainz]

Requesting a= for 1.0.1-branch...

Comment 18

[Randell Jesup [:jesup] (needinfo me)]

refresh of a= for 1.0 branch

Comment 19

[Simon Montagu :smontagu]

Checked in to branch

Comment 20

[Roland Mainz]

Filed bug 168043 ("Remove some obsolete code from the PostScript and Xprint
print modules") to get the obsolete code in |#ifdef XPRINT_FONT_HACK ... #endif|
removed.