GIF image print quality is not readable for humans or scanners

VERIFIED DUPLICATE of bug 64460

Status

()

Core
Printing: Output
VERIFIED DUPLICATE of bug 64460
17 years ago
17 years ago

People

(Reporter: K. Burke, Assigned: dcone (gone))

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
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 pnunn@netscape.com 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

17 years ago
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..
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 2

17 years ago
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 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 3

17 years ago
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

17 years ago
Created attachment 22353 [details]
original gif label

Comment 5

17 years ago
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

17 years ago
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.

Updated

17 years ago
Depends on: 64460

Comment 7

17 years ago
Created attachment 22354 [details]
minimum html with gif

Comment 8

17 years ago
Created attachment 22355 [details]
oiginal html with gif (sent by KBurke)

Comment 9

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

Comment 10

17 years ago
verif
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.