Last Comment Bug 37685 - [PRE] Need support for printing preformatted plain text
: [PRE] Need support for printing preformatted plain text
Status: VERIFIED FIXED
[eapp]
: helpwanted, topembed+
Product: Core
Classification: Components
Component: Printing: Output (show other bugs)
: Trunk
: x86 Linux
: P3 normal with 4 votes (vote)
: mozilla1.0
Assigned To: dcone (gone)
: sujay
: Jet Villegas (:jet)
Mentors:
http://www.mozilla.org/quality/browse...
: 55246 61475 74187 74678 77079 98515 98967 102136 111575 113572 120185 129679 (view as bug list)
Depends on:
Blocks: 64841 advocacybugs 104166 125136
  Show dependency treegraph
 
Reported: 2000-04-30 20:36 PDT by salwan.searty
Modified: 2002-03-14 06:44 PST (History)
26 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
make nsAFMObject::CreateSubstituteFont smarter (3.85 KB, patch)
2001-11-24 06:43 PST, James Henstridge
dcone: review+
attinasi: superreview+
Details | Diff | Splinter Review
Test case for UNIX printing bugs (2.80 KB, text/html)
2001-11-27 15:22 PST, Eric Vaandering (no email)
no flags Details
PNG file converted from postscript output with mozilla 0.9.6 (29.14 KB, image/png)
2001-11-27 15:28 PST, Eric Vaandering (no email)
no flags Details
Eric's test case with my patch applied (still not correct) (88.23 KB, image/png)
2001-11-29 17:39 PST, James Henstridge
no flags Details
Patch to fix all the problems with the overlapping text (4.94 KB, patch)
2002-02-26 15:11 PST, dcone (gone)
rods: review+
attinasi: superreview+
roc: approval+
Details | Diff | Splinter Review

Description salwan.searty 2000-04-30 20:36:15 PDT
When the <pre></pre> tag is used around some text in html, the text should look 
courier-like. In Mozilla, preformatted plain text renders properly on the 
screen, but looks more Times-like when printed on paper.
Comment 1 Frank Tang 2000-05-01 12:10:55 PDT
salwang.searty- Are you referred to English page, or Chinese page ? Can you 
attach some URL so we can try ?
Comment 2 salwan.searty 2000-05-02 10:50:21 PDT
I'm referring to English pages. I've included an URL. Look at the last line on 
that test page. In Windows 98 and NT4, the text prints properly. I've only seen 
this problem on Linux.
Comment 3 yueheng.xu 2000-05-02 12:32:59 PDT
This is a ASCII printing ssue, not i18n issue
Comment 4 dcone (gone) 2000-06-05 07:19:13 PDT
This bug has been marked future because we have determined that it is not 
critical for netscape 6.0.  If you feel this is an error, or if it blocks your 
work in some way -- please attach your concern to the bug for reconsideration.
Comment 5 Tobias Burnus 2000-09-10 09:59:57 PDT
Can you please reconsider! It makes printing in some cases impossible. The
problem seems to be that in gfx/src/ps/nsAFMObject.cpp

PRInt16
nsAFMObject::CreateSubstituteFont(const nsFont &aFontName)

simply uses Times_Roman.

Suggests keywords:
-- 4xp -- (this works in NS 4.x, Helvetica/sans-serif doesn't, but this is only
a small change, when Courier works)
-- helpme --
-- nsbeta3 -- Since this is rather serious!
Comment 6 Eric Vaandering (no email) 2000-09-15 16:51:17 PDT
I have to agree with Tobias on this issue. Printed computer code (esp. FORTRAN,
don't laugh) is nearly useless in a variable width font.
Comment 7 Tobias Burnus 2000-10-05 07:55:53 PDT
Suggest relnotesRTM since this should be in the release notes (and won't
unfortunally fixed by RTM it seems). Suggest furthermore mozilla0.9/mozilla1.0.
If you have hope (and time!) to fix this before, I wouldn't mind a rtm!
Comment 8 Andreas Franke (gone) 2001-01-07 06:56:52 PST
Nominating for nsbeta1 and mozilla0.9 (per Tobias Burnus).
Comment 9 Akkana Peck 2001-01-08 10:57:29 PST
I'm seeing this, too, filed bug 64318 which seems to be the same problem
(there's a test case attached to that bug).
Comment 10 shrirang khanzode 2001-01-31 20:13:53 PST
spam : changing qa to sujay (new qa contact for Printing)
Comment 11 Kevin McCluskey (gone) 2001-04-26 17:13:18 PDT
*** Bug 77079 has been marked as a duplicate of this bug. ***
Comment 12 Kevin McCluskey (gone) 2001-05-02 10:40:40 PDT
*** Bug 74678 has been marked as a duplicate of this bug. ***
Comment 13 stephend@netscape.com (gone - use stephen.donner@gmail.com instead) 2001-05-20 12:18:43 PDT
*** Bug 74187 has been marked as a duplicate of this bug. ***
Comment 14 Roland Mainz 2001-06-12 06:30:58 PDT
Has this been fixed in PostScript module ? 
Xprint module (2001-06-10-08-trunk + patch from bug 57820) prints the testcase
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=24128) correctly
(except bug 85414)...
Comment 15 Leston Buell 2001-06-14 22:29:26 PDT
I'm putting these comments here because bug 74187 (incorrect font for printing
message body) was duped to this bug. The message body now prints in what is
probably the correct font.

...but the message header prints in a much larger font. The headers should print
in the smaller font, as the message body. I imagine that this problem calls for
opening a new bug.
Comment 16 Akkana Peck 2001-06-26 15:40:00 PDT
I just tried printing the URL of this bug with a 6/25 build, and the last line
(which is preformatted) still printed out in variable-width.  The message
headers look fine.
Comment 17 dcone (gone) 2001-08-29 14:11:39 PDT
this is a linux bug, so I am taking off the topemed since embed is a Windows 
project.
Comment 18 dcone (gone) 2001-08-29 14:14:08 PDT
*** Bug 61475 has been marked as a duplicate of this bug. ***
Comment 19 Boris Zbarsky [:bz] (still a bit busy) 2001-09-06 10:08:26 PDT
*** Bug 98515 has been marked as a duplicate of this bug. ***
Comment 20 Boris Zbarsky [:bz] (still a bit busy) 2001-09-09 09:11:49 PDT
*** Bug 98967 has been marked as a duplicate of this bug. ***
Comment 21 Boris Zbarsky [:bz] (still a bit busy) 2001-09-28 09:42:29 PDT
*** Bug 102136 has been marked as a duplicate of this bug. ***
Comment 22 Asa Dotzler [:asa] 2001-10-12 17:29:31 PDT
0.9.5 is out the door. bumping TM up by one.
Comment 23 Hrvoje Niksic 2001-10-25 16:44:03 PDT
It seems that this has been moved to 0.9.9.  What's up with this?  I find that
this bug makes accepting Mozilla much harder in an office environment; Netscape
4 apparently handled this well, and this is extremely important when printing
source code or other ASCII-heavy stuff.

I don't know what's involved in fixing this, so please don't take this the wrong
way.  I would just really appreciate if it were possible to fix this sooner
rather than later.  It's not unimportant.
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2001-11-23 09:15:39 PST
*** Bug 111575 has been marked as a duplicate of this bug. ***
Comment 25 James Henstridge 2001-11-23 19:11:02 PST
Is there any reason for the code in nsPostScriptObj::setscriptfont to ignore the
aFontIndex argument?  The code sets postscriptFont from aFontIndex, then goes
ahead and sets it to something else entirely (either Times for normal/italic
style, and Helvetica for oblique styles).

Is that code in there for i18n reasons?

By the way, printed text mail messages look horrible at the moment -- see the
attachment on bug 111575.  Even though setscriptfont is ignoring the passed font
index, the page is layed out with the metrics of the passed font index.
Comment 26 James Henstridge 2001-11-24 06:43:48 PST
Created attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

This patch changes nsAFMObject::CreateSubstituteFont so it returns a better
match for fonts such as "sans serif", "serif" and "monospace" (and for unknown
fonts, at least attempts to display things as bold or italic).

I also changed nsPostScriptObj::setscriptfont to actually respect the font
index passed to it (if it is a valid index), rather than ignoring it.

This seems to get things to render a bit better (makes text mail messages print
okay, which was what I was originally interested in).

Any chance that this can be checked in before mozilla 0.9.9? :)
Comment 27 Reinout van Schouwen 2001-11-26 11:44:43 PST
I don't know why it doesn't show up here, but bug 55246 has been marked as a
duplicate of this bug. *But* it was targeted for 0.9.7! I sure hope this can be
fixed soon...
Comment 28 Akkana Peck 2001-11-26 15:44:49 PST
*** Bug 55246 has been marked as a duplicate of this bug. ***
Comment 29 Moses Lei 2001-11-27 15:00:53 PST
I think we should reopen 55246 and make this bug depend on that one.

If we don't do that, however, I suggest a change of summary to match the larger
issue brought up in 55246, "On Unix all fonts print as Times (postscript module)"

A few points worth bringing over from that bug:
1) All fonts, whether they are PRE, sans serif, symbol, or a non-Western
European font, will print as Times.
2) This results in big internationalization problems, since Times doesn't have
the necessary international glyphs.

Also, a new point:
3) It appears that on-screen metrics are used to place the printed elements.
This results in overlap when changing from Normal to Bold or Italic and back,
because Times/Times Bold/Times Italic don't have the same metrics as the
on-screen fonts. (If someone needs to see what I'm talking about, I can try to
scan something in...)

I suggest that this bug be bumped up to mozilla 0.9.7 and given priority P2.
Comment 30 Eric Vaandering (no email) 2001-11-27 15:22:16 PST
Created attachment 59410 [details]
Test case for UNIX printing bugs

Attaching test case HTML showing printing problems being discussed. PNG file of
PS output will come next.
Comment 31 Eric Vaandering (no email) 2001-11-27 15:28:25 PST
Created attachment 59413 [details]
PNG file converted from postscript output with mozilla 0.9.6

This is the PNG version of the Postscript output.

Possibly relevant details: 

mozilla version 0.9.6
Redhat (i386) version 6.1

As you can see, printing on linux is quite broken. This is probably my single
biggest complaint since there is no workaround (short of taking screenshots,
which I have resorted to.)

I fully agree with upping the priority to get this bug fixed.
Comment 32 James Henstridge 2001-11-29 17:39:07 PST
Created attachment 59788 [details]
Eric's test case with my patch applied (still not correct)

I tried out Eric's test case with my patch, and created a PNG from the
postscript output.  As you can see, with my patch, it still doesn't quite work.


The correct fonts are being used, but the wrong font metrics are being used to
position the text :(  I guess this needs a bit more thought.
Comment 33 Boris Zbarsky [:bz] (still a bit busy) 2001-12-05 07:55:52 PST
*** Bug 113572 has been marked as a duplicate of this bug. ***
Comment 34 R.K.Aa. 2002-01-15 17:03:39 PST
*** Bug 120185 has been marked as a duplicate of this bug. ***
Comment 35 Eric Vaandering (no email) 2002-01-30 16:20:41 PST
Please don't let this sit until mozilla 1.1, which as far as I can tell means
"Forever."

This bug and bug 55246 (which was duped to this) make mozilla look really,
really bad. I often times can't get a a usable printout out of mozilla for this
reason, which is a major pain.

Please reconsider at least trying to fix this right after 1.0. (I realize this
isn't an API issue, so its not important for 1.0).

Comment 36 James Henstridge 2002-01-31 01:06:56 PST
I agree with Eric's comment above.  It makes printing of web pages and mail
messages close to useless on Unix systems.

I had a go at fixing it a few months back, but my patch must have been fixing
the wrong stage of the code.  Is there anyone who understands the code who could
post some pointers on where to look, so the problem could be fixed?
Comment 37 Akkana Peck 2002-01-31 11:35:32 PST
I generally have to fire up NS4 when I need to print something and want it to
come out readable, due to this and related bugs.  :-(
Comment 38 Toby Haynes 2002-02-01 15:39:20 PST
This has to be viewed as BASE functionality. Being unable to print in a
non-proportional font is daft. Last time I tried to hack the postscript produced
by mozilla to replace the proportional fonts with monospaced one, it looked like
this would only require using the correct font metrics and the correct
monospaced font for this all to work fine. I don't understand why this one keeps
getting kicked out further and further down the release list. Not having it in
Mozilla 1.0 is a disaster.
Comment 39 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-02-12 17:02:03 PST
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Comment 40 Bob Clary [:bc:] 2002-02-13 16:05:41 PST
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Comment 41 Kevin McCluskey (gone) 2002-02-14 13:26:03 PST
Marking nsbeta1+
Comment 42 dcone (gone) 2002-02-25 14:43:40 PST
Comment on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

r=dcone
Comment 43 dcone (gone) 2002-02-25 14:46:26 PST
I tested that patch.. and it aligned all the text.  I would like to check this 
in.. are there any objections.. I can not find anything wrong with how the 
output looks, it looks like all the columns were aligned.  I went over that 
patch and it looks like everything is correct.
Comment 44 Kevin McCluskey (gone) 2002-02-25 17:36:08 PST
topembed+
Comment 45 James Henstridge 2002-02-25 18:35:41 PST
The patch still has some alignment issues with the font metrics (as can be seen
in the last attachment).  However it is an improvement over what is currently in
place, as it will choose Courier for "monospace" (and helvetica for "sans serif").

Applying the patch should make things work a bit better, but unless some other
part of the printing code has changed since I did the patch that makes the font
metrics work correctly, I wouldn't consider the issue fixed yet.
Comment 46 dcone (gone) 2002-02-26 10:39:44 PST
All the <pre> tag stuff looks good on my machine.. even the line is to long tag.  
I think I will get an sr.. check this in.. and then the other issues are covered 
by other bugs.   I think all the <pre> stuff looks good.  There may be other 
issues with underlines and such.. I have bugs for those.
Comment 47 Marc Attinasi 2002-02-26 10:55:28 PST
Comment on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

sr=attinasi
Comment 48 dcone (gone) 2002-02-26 15:11:52 PST
Created attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text
Comment 49 Marc Attinasi 2002-02-26 16:26:03 PST
Comment on attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

this looks great - but, could you comment the NS_IS_BOLD macro and why you
picked the number 401 please? Also, please mark the old patch obsolete. Thanks.
Comment 50 James Henstridge 2002-02-26 17:12:09 PST
the NS_IS_BOLD macro is from my original patch.  I actually swiped it from
nsPostScriptObj.cpp, where it doesn't have a comment:
  http://lxr.mozilla.org/seamonkey/source/gfx/src/ps/nsPostScriptObj.cpp#75

In the standard CSS model, a weight of 400 is normal.  So the macro says weight
greater than normal should be treated as bold (and anything less than or equal
to normal should be normal).

It is great that this is getting fixed!
Comment 51 rods (gone) 2002-02-26 18:11:39 PST
Comment on attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

r=rods
Comment 52 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-02-27 09:30:05 PST
Comment on attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

a=roc+moz for 0.9.9
Comment 53 dcone (gone) 2002-02-28 07:31:27 PST
fixed.
Comment 54 sujay 2002-03-04 15:15:37 PST
Salwan, is this fixed for you now? please verify..thanks.
Comment 55 Toby Haynes 2002-03-07 14:37:37 PST
Yea! 

Printing in vastly improved in general with mixes of fonts. And my html manuals
no longer look as though the typesetter had a bad day. Great stuff! Thanks.
Comment 56 Boris Zbarsky [:bz] (still a bit busy) 2002-03-08 10:06:13 PST
*** Bug 129679 has been marked as a duplicate of this bug. ***
Comment 57 sujay 2002-03-08 12:25:00 PST
marking verified per Toby's comments...thanks for feedback

REOPEN if this bug is not fixed for anyone.
Comment 58 Al Peak 2002-03-13 14:32:20 PST
Printing is vastly improved with the latest patch, especially preformatted text
and mixed font faces.  But we aren't quite there yet.  I'm still getting
overlapping text for bold and italic print under Linux, as reported in
[duplicate] bug 55246.  Should we reopen this one, that one, or create a new bug?
Comment 59 sujay 2002-03-13 14:50:24 PST
Alen, please file a new bug on the new issue you see...
Comment 60 dcone (gone) 2002-03-14 06:44:09 PST
There are still open bugs for overlapping text.. but the bugs associated with 
the <pre> were fixed in this bug. 

another bug that deals with this is.. which is still open
http://bugzilla.mozilla.org/show_bug.cgi?id=117434

Note You need to log in before you can comment on or make changes to this bug.