Closed Bug 37685 Opened 24 years ago Closed 22 years ago

[PRE] Need support for printing preformatted plain text

Categories

(Core :: Printing: Output, defect, P3)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.0

People

(Reporter: salwan.searty, Assigned: dcone)

References

(
URL
)

Details

(Keywords: helpwanted, topembed+, Whiteboard: [eapp])

Attachments

(4 files, 1 obsolete file)

Test case for UNIX printing bugs
2.80 KB, text/html
Details
PNG file converted from postscript output with mozilla 0.9.6
29.14 KB, image/png
Details
Eric's test case with my patch applied (still not correct)
88.23 KB, image/png
Details
Patch to fix all the problems with the overlapping text
4.94 KB, patch
rods
: review+
attinasi
: superreview+
roc
: approval+
Details | Diff | Splinter Review 
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.
salwang.searty- Are you referred to English page, or Chinese page ? Can you 
attach some URL so we can try ?

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.
URL: http://www.mozilla.org/quality/browse...
This is a ASCII printing ssue, not i18n issue
Assignee: yueheng.xu → dcone
Status: NEW → ASSIGNED
Target Milestone: --- → M20
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.
Target Milestone: M20 → Future
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!
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.

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!

Nominating for nsbeta1 and mozilla0.9 (per Tobias Burnus).
Keywords: mozilla0.9, nsbeta1
I'm seeing this, too, filed bug 64318 which seems to be the same problem
(there's a test case attached to that bug).
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Depends on: 64841
No longer depends on: 64841
Blocks: 64841
Target Milestone: Future → mozilla0.9.1
*** Bug 77079 has been marked as a duplicate of this bug. ***
Keywords: helpwanted
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 74678 has been marked as a duplicate of this bug. ***
*** Bug 74187 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.2 → mozilla0.9.3
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)...
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.
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.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Keywords: topembed
this is a linux bug, so I am taking off the topemed since embed is a Windows 
project.
Keywords: topembed
Summary: Need support for printing preformatted plain text → [PRE ]Need support for printing preformatted plain text
*** Bug 61475 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 98515 has been marked as a duplicate of this bug. ***
*** Bug 98967 has been marked as a duplicate of this bug. ***
Blocks: advocacybugs
No longer blocks: advocacybugs
Summary: [PRE ]Need support for printing preformatted plain text → [PRE] Need support for printing preformatted plain text
Blocks: advocacybugs
*** Bug 102136 has been marked as a duplicate of this bug. ***
Blocks: 104166
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Target Milestone: mozilla0.9.6 → mozilla0.9.9
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.

*** Bug 111575 has been marked as a duplicate of this bug. ***
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.
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? :)
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...
*** Bug 55246 has been marked as a duplicate of this bug. ***
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.
Attaching test case HTML showing printing problems being discussed. PNG file of
PS output will come next.
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.
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.
*** Bug 113572 has been marked as a duplicate of this bug. ***
*** Bug 120185 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla0.9.9 → mozilla1.1
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).


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?
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.  :-(
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.
Whiteboard: [eapp]
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.
Keywords: nsbeta1+
Target Milestone: mozilla1.1 → ---
Target Milestone: --- → mozilla1.0
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.
Keywords: nsbeta1+ → nsbeta1
Marking nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Comment on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

r=dcone
Attachment #59044 - Flags: review+
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.
Keywords: topembed
topembed+
Keywords: topembed → topembed+
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.
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 on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

sr=attinasi
Attachment #59044 - Flags: superreview+
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.
Attachment #71565 - Flags: superreview+
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!
Attachment #59044 - Attachment is obsolete: true
Comment on attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

r=rods
Attachment #71565 - Flags: review+
Comment on attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

a=roc+moz for 0.9.9
Attachment #71565 - Flags: approval+
fixed.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Salwan, is this fixed for you now? please verify..thanks.
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.
*** Bug 129679 has been marked as a duplicate of this bug. ***
marking verified per Toby's comments...thanks for feedback

REOPEN if this bug is not fixed for anyone.
Status: RESOLVED → VERIFIED
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?
Alen, please file a new bug on the new issue you see...
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
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: