2.80 KB, text/html
29.14 KB, image/png
88.23 KB, image/png
4.94 KB, patch
rods (gone): review+
Marc Attinasi: superreview+
|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.
This is a ASCII printing ssue, not i18n issue
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.
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).
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)
*** Bug 77079 has been marked as a duplicate of this bug. ***
*** Bug 74678 has been marked as a duplicate of this bug. ***
*** Bug 74187 has been marked as a duplicate of this bug. ***
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.
this is a linux bug, so I am taking off the topemed since embed is a Windows project.
*** Bug 61475 has been marked as a duplicate of this bug. ***
*** Bug 98515 has been marked as a duplicate of this bug. ***
*** Bug 98967 has been marked as a duplicate of this bug. ***
*** Bug 102136 has been marked as a duplicate of this bug. ***
0.9.5 is out the door. bumping TM up by one.
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.
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? :)
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.
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.
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. ***
*** Bug 120185 has been marked as a duplicate of this bug. ***
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.
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.
16 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.
Comment on attachment 59044 [details] [diff] [review] make nsAFMObject::CreateSubstituteFont smarter r=dcone
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.
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
Created attachment 71565 [details] [diff] [review] Patch to fix all the problems with the overlapping text
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.
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 on attachment 71565 [details] [diff] [review] Patch to fix all the problems with the overlapping text r=rods
Comment on attachment 71565 [details] [diff] [review] Patch to fix all the problems with the overlapping text a=roc+moz for 0.9.9
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.
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