Closed Bug 130438 Opened 22 years ago Closed 22 years ago

[ps] printing messes up italics and ems

Categories

(Core :: Printing: Output, defect)

Product:
Core
Component:
Printing: Output
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: pretzalz, Assigned: zhayupeng)

References

Details

Attachments

(3 files)

Testcase
326 bytes, text/html
Details
Testcase (attachment 80152) printed with 2002-05-08-08-trunk + Xprint module (300 DPI, DIN A4)
5.27 KB, application/postscript
Details
patch
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.
Boris, any ideas on this one?
does it still happen on RC1?
Attached file Testcase — 

    
    

    
  
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

    
    

    
  


  
Reporter:
Does this PostScript job print OK for you ?

    
    

    
  
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.

    
    

    
  
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 ?

    
  
Summary: printing messes up italics and ems → [ps] printing messes up italics and ems

    
    

    
  
This bug still exits in Mozilla1.0

    
  
Blocks: 157675

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch
        — 
          — Splinter Review
      

    


  
correct the index of font

    
    

    
  
=>
Assignee: rods → pete.zha

    
    

    
  
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 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+

    
    

    
  
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.