The default bug view has changed. See this FAQ.

[PRE] Need support for printing preformatted plain text

VERIFIED FIXED in mozilla1.0

Status

()

Core
Printing: Output
P3
normal
VERIFIED FIXED
17 years ago
15 years ago

People

(Reporter: salwan.searty, Assigned: dcone (gone))

Tracking

({helpwanted, topembed+})

Trunk
mozilla1.0
x86
Linux
helpwanted, topembed+
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [eapp], URL)

Attachments

(4 attachments, 1 obsolete attachment)

(Reporter)

Description

17 years ago
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

17 years ago
salwang.searty- Are you referred to English page, or Chinese page ? Can you 
attach some URL so we can try ?
(Reporter)

Comment 2

17 years ago
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

17 years ago
This is a ASCII printing ssue, not i18n issue
Assignee: yueheng.xu → dcone
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → M20
(Assignee)

Comment 4

17 years ago
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

Comment 5

17 years ago
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.

Comment 7

17 years ago
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

16 years ago
Nominating for nsbeta1 and mozilla0.9 (per Tobias Burnus).
Keywords: mozilla0.9, nsbeta1

Comment 9

16 years ago
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

16 years ago
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay

Updated

16 years ago
Depends on: 64841

Updated

16 years ago
No longer depends on: 64841

Updated

16 years ago
Blocks: 64841

Updated

16 years ago
Target Milestone: Future → mozilla0.9.1
*** Bug 77079 has been marked as a duplicate of this bug. ***

Updated

16 years ago
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. ***

Updated

16 years ago
Target Milestone: mozilla0.9.2 → mozilla0.9.3

Comment 14

16 years ago
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

16 years ago
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

16 years ago
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

Updated

16 years ago
Keywords: topembed
(Assignee)

Comment 17

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

Comment 18

16 years ago
*** Bug 61475 has been marked as a duplicate of this bug. ***
(Assignee)

Updated

16 years ago
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. ***

Updated

16 years ago
Blocks: 92997

Updated

16 years ago
No longer blocks: 92997
Summary: [PRE ]Need support for printing preformatted plain text → [PRE] Need support for printing preformatted plain text

Updated

16 years ago
Blocks: 92997
*** Bug 102136 has been marked as a duplicate of this bug. ***

Updated

16 years ago
Blocks: 104166

Comment 22

16 years ago
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.9

Comment 23

16 years ago
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. ***

Comment 25

16 years ago
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

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

Comment 27

16 years ago
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

16 years ago
*** Bug 55246 has been marked as a duplicate of this bug. ***

Comment 29

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

16 years ago
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.
*** Bug 113572 has been marked as a duplicate of this bug. ***

Comment 34

15 years ago
*** Bug 120185 has been marked as a duplicate of this bug. ***

Updated

15 years ago
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).

Comment 36

15 years ago
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

15 years ago
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

15 years ago
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.

Updated

15 years ago
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 → ---
Blocks: 125136

Updated

15 years ago
Target Milestone: --- → mozilla1.0

Comment 40

15 years ago
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+
(Assignee)

Comment 42

15 years ago
Comment on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

r=dcone
Attachment #59044 - Flags: review+
(Assignee)

Comment 43

15 years ago
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.

Updated

15 years ago
Keywords: topembed
topembed+
Keywords: topembed → topembed+

Comment 45

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

Comment 46

15 years ago
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

15 years ago
Comment on attachment 59044 [details] [diff] [review]
make nsAFMObject::CreateSubstituteFont smarter

sr=attinasi
Attachment #59044 - Flags: superreview+
(Assignee)

Comment 48

15 years ago
Created attachment 71565 [details] [diff] [review]
Patch to fix all the problems with the overlapping text

Comment 49

15 years ago
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+

Comment 50

15 years ago
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!
(Assignee)

Updated

15 years ago
Attachment #59044 - Attachment is obsolete: true

Comment 51

15 years ago
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+
Keywords: mozilla0.9.9+
(Assignee)

Comment 53

15 years ago
fixed.
Status: ASSIGNED → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED

Comment 54

15 years ago
Salwan, is this fixed for you now? please verify..thanks.

Comment 55

15 years ago
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. ***

Comment 57

15 years ago
marking verified per Toby's comments...thanks for feedback

REOPEN if this bug is not fixed for anyone.
Status: RESOLVED → VERIFIED

Comment 58

15 years ago
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

15 years ago
Alen, please file a new bug on the new issue you see...
(Assignee)

Comment 60

15 years ago
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.