64930 - GIF image print quality is not readable for humans or scanners

Status: VERIFIED DUPLICATE of bug 64460

(Core :: Printing: Output, defect)

Description

[K. Burke]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT)
BuildID:    Mozilla/5.0 (Windows; U; WinNT4.0; en-US; m18) Gecko/20001108 
Netscape6/6.0

UPS Internet Shipping allows customers to print labels to attach to their 
packages that will be read by both delivery drivers and barcode scanners.  The 
generated label is a GIF image embedded on an HTML page, which the customer is 
to print on an HP Laserjet.  The label printed by Netscape 6 is not readable, 
but it is in Communicator 4.7 and IE 5.

Reproducible: Always
Steps to Reproduce:
1. Sign on to the testing URL above using the Netscape account.
2. Drop down a name from the address book.
3. Enter 1 for the weight of the package.
4. Click the "Ship Now" graphical button.
5. On the "Complete Shipment" page check the "Label 1" box
6. Click the "View/Print" graphical button
7. Print the label in the pop-up window on an HP Laserjet.  Compare to printing 
the same page in IE or Communicator 4.75

Actual Results:  Printed label not readable.

Expected Results:  Print like Netscape Communicator 4.75 or Internet Explorer 5.

The closest similar bug I could find is:
http://bugzilla.mozilla.org/show_bug.cgi?id=27962,
specifically the comments of [e-mail] on 2000-02-23 11:22.
I think we are getting "displayscreen resolution printing" rather than "printer 
scaling".

The linear barcode on the label is scannable, but the 2-D barcode is not.  
Additionally the text in the GIF does not print well enough to expect drivers 
and recipients to read it.  The labels will have to pass internal certification 
for the browser to be supported.

Comment 1

[shrirang khanzode]

confirming bug , cc:bijals. This is one feature for future releases.Bug 64460 is 
open for a similar problem. Maybe this shud b a duplicate of that, but I will 
wait..

Comment 2

[dcone (gone)]

This depends on and is a duplicate of 64460.  I made a reference to that 
problem.

*** This bug has been marked as a duplicate of 64460 ***

Comment 3

[dcone (gone)]

I could use the original gif that is sent to the browser.  This might not be a 
resolution thing, but a color palette thing.. we could be changing this into GIF 
that has a different color palette.  I need to know the original size of this 
gif and the printed dimensions. 

Comment 4

[shrirang khanzode]

Attachment: original gif label

Comment 5

[shrirang khanzode]

Karl Burke's comments from email :

Don & Shrirang,

We were originally given Chris Saari as a contact at Netscape, but I didn't
get in touch with Chris yesterday because the bug was quickly marked as a
DUP.

Attached below are 3 files: (1) a minimum HTML page referencing the GIF (2)
the original HTML page referencing the GIF and (3) a GIF label.

The URL I put in the bug is a test system.  We have created a login account
for you with ID=netscape PASS=netscape.  We've been having trouble with the
back end systems this week, but hopefully after you log in you can click on
the "SHIP" icon in the top menu and follow the steps I put in the bug.

I would like to mention that the problem appears more drastically for us
than http://www.news.com referenced in
http://bugzilla.mozilla.org/show_bug.cgi?id=64460.  I believe this is
because we take a large GIF (1400 x 800) and display it in an <IMG> tag with
attributes of 686 x 392.  I'm still trying to find out why we do this, since
the person that wrote the label generator is no longer at UPS.

Comment 6

[shrirang khanzode]

Don's email :

I believe that the large image is needed to get the resolution when printed you
need for scanning.
The image is read in and scaled to the size you want on the screen (72 DPI).
Netscape 4.x would reload and rescale the image for
the printout and you would get a nice image.  Netscape 6.0 uses the image in
memory which has been scaled already.. so when you
go to a high res device you are printing a low res version of the image.
For a printer..those extra bits really help the resolution since a laserwriter
is at least 300 dpi..
The image should be reloaded in that case.  We did it this way because
some sites use very large images and we were running into memory problems and it
was taking huge amounts of time to print.  Some images were 10 meg or greater..
which when reloaded can really take a huge amount of time to load.. and when the
printer driver rips these images.. can be 4x larger for the printer driver.
I believe that is the reason...
Other possibilities or contributing factors might be the color conversion of the
gif to our internal format. We might be loosing color information from
this conversion (getting and antialiased version) which would be really bad.

Comment 7

[shrirang khanzode]

Attachment: minimum html with gif

Comment 8

[shrirang khanzode]

Attachment: oiginal html with gif (sent by KBurke)

Comment 9

[shrirang khanzode]

pls save all 3 attachments posted  here locally and view(print)

Comment 10

[shrirang khanzode]

verif