Closed
Bug 130438
Opened 22 years ago
Closed 22 years ago
[ps] printing messes up italics and ems
Categories
(Core :: Printing: Output, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: pretzalz, Assigned: zhayupeng)
References
Details
Attachments
(3 files)
326 bytes,
text/html
|
Details | |
5.27 KB,
application/postscript
|
Details | |
581 bytes,
patch
|
dcone
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
I made a simplified test case: http://techhouse.brown.edu/~pretzalz/test.html which has the source: <html> <head> </head> <body style="font-family: Georgia, serif;"> This page has <i>italics</i> and <em>emphasis</em>. </body> </html> When I try to print this page, I get a console error "NO FONT WAS FOUND" which appears twice and the following output: http://techhouse.brown.edu/~pretzalz/mozilla.ps . The words italics and emphasis are slightly larger and bolder(though this might just be my perception of them being larger), but they aren't like how they are displayed in the browser or in print preview(though print preview has messed up spacing, the words are still cursive). When Georgia is removed from the body style, printing works correctly. Expected result: Page is printed as it is displayed in the browser. Actual result: Italic and Emphasized words are printed in a completely different style. I did a xlsfonts | grep -i georgia and confirmed that there is indeed no such font called Georgia on my system so mozilla should use the secondary font 'serif' to print just as it does to display the page. I am using a CVS build from yesterday.
Comment 2•22 years ago
|
||
does it still happen on RC1?
![]() |
||
Comment 3•22 years ago
|
||
![]() |
||
Comment 4•22 years ago
|
||
I see <em> and <i> not printing italic at all (and neither does font-style:italic).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: printing messes up italics and ems when primary Font family is unknown → printing messes up italics and ems
Comment 5•22 years ago
|
||
Reporter: Does this PostScript job print OK for you ?
Reporter | ||
Comment 6•22 years ago
|
||
It works, but since I can't get Xprt to work it isn't very helpful, but I guess that is more my problem than Mozilla's.
Comment 7•22 years ago
|
||
Travis Crump wrote:
> It works, but since I can't get Xprt to work it isn't very helpful, but I
> guess that is more my problem than Mozilla's.
Which specific problem do you have with Xprt ?
Updated•22 years ago
|
Summary: printing messes up italics and ems → [ps] printing messes up italics and ems
Comment 8•22 years ago
|
||
This bug still exits in Mozilla1.0
![]() |
||
Comment 11•22 years ago
|
||
Comment on attachment 96801 [details] [diff] [review] patch sr=bzbarsky. nice find... This code sucks in another cute way; for "font-family: foo, sans-serif;" it will do a substitution of "Times New Roman" for "foo" and ignore the generic font family... nsAFMObject::CheckBasicFonts() needs to look at gSubstituteMap, not just at gSubstituteFonts... and it should consider using EnumerateFamilies on the nsFont instead of the RFind it does now... do we have a bug on fixing this function to generally work?
Attachment #96801 -
Flags: superreview+
Comment 12•22 years ago
|
||
Comment on attachment 96801 [details] [diff] [review] patch Yes, this is correct.. I forgot to update these indexes when I fixed the font table. r=dcone
Attachment #96801 -
Flags: review+
Assignee | ||
Comment 13•22 years ago
|
||
checked in trunk
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•