Closed
Bug 148690
Opened 22 years ago
Closed 22 years ago
RFE: For Xprint force use of outline scaleable fonts if possible
Categories
(Core Graveyard :: Printing: Xprint, enhancement)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.0.1
People
(Reporter: roland.mainz, Assigned: roland.mainz)
References
Details
Attachments
(1 file, 1 obsolete file)
7.90 KB,
patch
|
shanjian
:
review+
jst
:
superreview+
jesup
:
approval+
|
Details | Diff | Splinter Review |
RFE: Xprint module should force the use of outline scaleable fonts if possible
Assignee | ||
Comment 1•22 years ago
|
||
Taking myself...
Assignee: katakai → Roland.Mainz
QA Contact: Roland.Mainz → katakai
Assignee | ||
Updated•22 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1alpha
Assignee | ||
Comment 2•22 years ago
|
||
This patch forces the use of outline scaled fonts (or printer-builtin fonts) unless there is no other font available.
Assignee | ||
Comment 3•22 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•22 years ago
|
||
Attachment #85989 -
Attachment is obsolete: true
Assignee | ||
Comment 5•22 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.
Comment 6•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
Requesting sr= ...
Comment 12•22 years ago
|
||
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 14•22 years ago
|
||
Requesting a{1.0.1_branch}= ...
Keywords: mozilla1.0.1
Target Milestone: mozilla1.1alpha → mozilla1.0.1
Updated•22 years ago
|
Keywords: mozilla1.0.1 → mozilla1.0.1-
Assignee | ||
Updated•22 years ago
|
Blocks: xprint_machv
Comment 15•22 years ago
|
||
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•22 years ago
|
Keywords: mozilla1.0.1- → mozilla1.0.1+
Comment 16•22 years ago
|
||
Checked in to trunk for Roland
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Assignee | ||
Updated•22 years ago
|
Keywords: mozilla1.0.1
Assignee | ||
Comment 17•22 years ago
|
||
Requesting a= for 1.0.1-branch...
Updated•22 years ago
|
Keywords: mozilla1.0.1+
Assignee | ||
Comment 20•22 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
Updated•16 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•