Closed
Bug 37685
Opened 24 years ago
Closed 23 years ago
[PRE] Need support for printing preformatted plain text
Categories
(Core :: Printing: Output, defect, P3)
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: salwan.searty, Assigned: dcone)
References
()
Details
(Keywords: helpwanted, topembed+, Whiteboard: [eapp])
Attachments
(4 files, 1 obsolete file)
2.80 KB,
text/html
|
Details | |
29.14 KB,
image/png
|
Details | |
88.23 KB,
image/png
|
Details | |
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.
Comment 1•24 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•24 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.
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Assignee | ||
Comment 4•24 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•24 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!
Comment 6•24 years ago
|
||
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•24 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•24 years ago
|
||
Nominating for nsbeta1 and mozilla0.9 (per Tobias Burnus).
Keywords: mozilla0.9,
nsbeta1
Comment 9•24 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•24 years ago
|
||
spam : changing qa to sujay (new qa contact for Printing)
QA Contact: shrir → sujay
Updated•23 years ago
|
Target Milestone: Future → mozilla0.9.1
Comment 11•23 years ago
|
||
*** Bug 77079 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Keywords: helpwanted
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 12•23 years ago
|
||
*** Bug 74678 has been marked as a duplicate of this bug. ***
*** Bug 74187 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Comment 14•23 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•23 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•23 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.
Updated•23 years ago
|
Target Milestone: mozilla0.9.3 → mozilla0.9.4
Assignee | ||
Comment 17•23 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•23 years ago
|
||
*** Bug 61475 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•23 years ago
|
Target Milestone: mozilla0.9.4 → mozilla0.9.5
Comment 19•23 years ago
|
||
*** Bug 98515 has been marked as a duplicate of this bug. ***
Comment 20•23 years ago
|
||
*** Bug 98967 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Blocks: advocacybugs
Updated•23 years ago
|
No longer blocks: advocacybugs
Summary: [PRE ]Need support for printing preformatted plain text → [PRE] Need support for printing preformatted plain text
Updated•23 years ago
|
Blocks: advocacybugs
Comment 21•23 years ago
|
||
*** Bug 102136 has been marked as a duplicate of this bug. ***
Comment 22•23 years ago
|
||
0.9.5 is out the door. bumping TM up by one.
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Updated•23 years ago
|
Target Milestone: mozilla0.9.6 → mozilla0.9.9
Comment 23•23 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.
Comment 24•23 years ago
|
||
*** Bug 111575 has been marked as a duplicate of this bug. ***
Comment 25•23 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•23 years ago
|
||
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•23 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•23 years ago
|
||
*** Bug 55246 has been marked as a duplicate of this bug. ***
Comment 29•23 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.
Comment 30•23 years ago
|
||
Attaching test case HTML showing printing problems being discussed. PNG file of PS output will come next.
Comment 31•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
*** Bug 113572 has been marked as a duplicate of this bug. ***
Comment 34•23 years ago
|
||
*** Bug 120185 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
Target Milestone: mozilla0.9.9 → mozilla1.1
Comment 35•23 years ago
|
||
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•23 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•23 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•23 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•23 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 → ---
Updated•23 years ago
|
Target Milestone: --- → mozilla1.0
Comment 40•23 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.
Assignee | ||
Comment 42•23 years ago
|
||
Comment on attachment 59044 [details] [diff] [review] make nsAFMObject::CreateSubstituteFont smarter r=dcone
Attachment #59044 -
Flags: review+
Assignee | ||
Comment 43•23 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.
Comment 45•23 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•23 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•23 years ago
|
||
Comment on attachment 59044 [details] [diff] [review] make nsAFMObject::CreateSubstituteFont smarter sr=attinasi
Attachment #59044 -
Flags: superreview+
Assignee | ||
Comment 48•23 years ago
|
||
Comment 49•23 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•23 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•23 years ago
|
Attachment #59044 -
Attachment is obsolete: true
Comment 51•23 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•23 years ago
|
||
fixed.
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Comment 54•22 years ago
|
||
Salwan, is this fixed for you now? please verify..thanks.
Comment 55•22 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.
Comment 56•22 years ago
|
||
*** Bug 129679 has been marked as a duplicate of this bug. ***
Comment 57•22 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•22 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•22 years ago
|
||
Alen, please file a new bug on the new issue you see...
Assignee | ||
Comment 60•22 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.
Description
•