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

RESOLVED FIXED in mozilla1.0.1

Status

Core Graveyard
Printing: Xprint
--
enhancement
RESOLVED FIXED
16 years ago
9 years ago

People

(Reporter: Roland Mainz, Assigned: Roland Mainz)

Tracking

Trunk
mozilla1.0.1
All
Linux
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

16 years ago
RFE: Xprint module should force the use of outline scaleable fonts if possible
(Assignee)

Comment 1

16 years ago
Taking myself...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
(Assignee)

Updated

16 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1alpha
(Assignee)

Comment 2

16 years ago
Created attachment 85989 [details] [diff] [review]
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.
(Assignee)

Comment 3

16 years ago
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.
(Assignee)

Comment 4

16 years ago
Created attachment 86073 [details] [diff] [review]
New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)
Attachment #85989 - Attachment is obsolete: true
(Assignee)

Comment 5

16 years ago
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.
Keywords: patch, review

Comment 6

16 years ago
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
Attachment #86073 - Flags: review+

Comment 7

16 years ago
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 */
Summary: RFE: Force use of outline scaleable fonts if possible → RFE: for XPrint force use of outline scaleable fonts if possible
(Assignee)

Comment 8

16 years ago
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.
Summary: RFE: for XPrint force use of outline scaleable fonts if possible → RFE: For Xprint force use of outline scaleable fonts if possible

Comment 9

16 years ago
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.
(Assignee)

Comment 10

16 years ago
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 :))
(Assignee)

Comment 11

16 years ago
Requesting sr= ...
Comment on attachment 86073 [details] [diff] [review]
New patch for 2002-05-31-08-trunk (for both GTK+ and Xlib gfx)

sr=jst
Attachment #86073 - Flags: superreview+
(Assignee)

Comment 13

16 years ago
Requesting a{1.1alpha}= ...
Keywords: approval
(Assignee)

Comment 14

16 years ago
Requesting a{1.0.1_branch}= ...
Keywords: mozilla1.0.1
Target Milestone: mozilla1.1alpha → mozilla1.0.1

Updated

16 years ago
Keywords: mozilla1.0.1 → mozilla1.0.1-
(Assignee)

Updated

16 years ago
Blocks: 149768
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
Attachment #86073 - Flags: approval+

Updated

16 years ago
Keywords: mozilla1.0.1- → mozilla1.0.1+
Checked in to trunk for Roland
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
(Assignee)

Updated

16 years ago
Keywords: mozilla1.0.1
(Assignee)

Comment 17

16 years ago
Requesting a= for 1.0.1-branch...
refresh of a= for 1.0 branch
Keywords: approval, mozilla1.0.1, review
Checked in to branch
Keywords: fixed1.0.1

Updated

16 years ago
Keywords: mozilla1.0.1+
(Assignee)

Comment 20

15 years ago
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.
Blocks: 168043
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.