Closed Bug 68865 Opened 24 years ago Closed 23 years ago

Mozilla Postscript output is 5x to 20x size of IE output

Categories

(Core :: Printing: Output, defect)

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

Tracking

()

Status:
RESOLVED INVALID
Milestone:
mozilla1.0.1

People

(Reporter: dclose, Assigned: dcone)

References

(
URL
)

Details

(Whiteboard: want for mozilla1.0.1) 

Printing to HP Postscript printer (8100 PS), either through spool or to file,
generates huge files which take excessively long to send to printer. With 0.7,
this URL produced nearly 4MB while IE generated only about 10KB. With nightly
build from Feb 13, difference is smaller but still outrageous.
Reporterdo you have a testcase we can use to test this?
This may be due to an image output.  We are outputing ascii.. they may be doing 
some sort of binary output.. I am not sure.. just a guess
*** Bug 70639 has been marked as a duplicate of this bug. ***
Anyone able to reproduce?
Keywords: qawanted
Marking NEW based on duplication.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Future
*** Bug 80528 has been marked as a duplicate of this bug. ***
1. Can anyone please attach a PostScript output from IE, please ?
2. Is this a Win32 or cross-platform issue (unix) ?

Misc: 
- QA=roland.mainz@informatik.med.uni-giessen.de
- Setting target_milestone to mozilla1.0.1 - is this OK ?
URL: www.stratasource.com → http://www.stratasource.com
Keywords: qawanted
QA Contact: sujay → Roland.Mainz
Whiteboard: want for mozilla1.0.1
Target Milestone: Future → mozilla1.0.1
I think this is not a PostScript Issue as much as an ImageLib issue.  The images  
can be very large.. since we can use the native size of the original image. This 
Would make our output slower depending on the page.  The Postscript output can 
show exactly how large this can be.. and this issue is much worse on Postscript 
platforms such as Linux.
IE PostScript output was attached to bug 70639, marked as a duplicate of this one.
I compared the file size using the HP colorlaser PS output.  The Mozilla file 
was basically a little over 2x the size.  I counted the number of images in both 
files.. and the mozilla file had 78 images and the explorer file had 40 images.  
Not sure what the extra images are from yet.. but I bet mozilla uses images for 
things that Expolorer does not.. and this may give us our file size difference.
Mozilla has many more images than Explorer.. depending on the page.  The PS 
seems fine, just more images per page.  I will mark this as not a bug, since its 
just the way we lay out our HTML
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → INVALID
Note that my experience is that files are much more than 2x, sometimes 20x. This
may be just the way Moz works, but it can be a serious problem. The result is
that shared printers take much longer for Moz print jobs, causing irritation
from other users. That could work against Mozilla.
I agree, but the native layout module uses this method, which means printing 
uses this method.  I have not run across a 20x test case, but the test cases I 
used .. were 2x.  Again this was because of the images.  The PS was not any 
different that of Explorer.  I did want to run experiments and find out exactly 
which elements we use to layout are so big and I (or anyone who is interested) 
can test by printing one element at a time and finding out what elements use all 
the images. Then a bug can be filed.  Also.. native images can contribute to 
this since we no longer print images at the screen resolution but at the 
resolution of the native image.
*** Bug 93997 has been marked as a duplicate of this bug. ***
*** Bug 93344 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.