305558 - image at left overlaps text when printed

Status: RESOLVED INCOMPLETE

(Core :: Printing: Output, defect)

Description

[Dave Yost]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050811 Camino/0.9a2+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050811 Camino/0.9a2+

image at left overlaps text when printed

Reproducible: Always

Steps to Reproduce:
1. Go to URL
2. Print
3.

Actual Results:  
attached PDF

Expected Results:  
as seen on the screen.

Comment 1

[Dave Yost]

Attachment: Clicked Preview from the Print dialog and saved the resulting PDF

(application/pdf should be in the "select from list:" pop-up here.)

Comment 2

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

It doesn't in Camino if you uncheck "Shrink to Fit Page Width", but it does
(with it checked or unchecked) in DeerPark.  

I'm guessing this has something to do with screen vs print dpi, as the image is
so much "larger" in print.

->Core:Printing

I assume this is true on the trunk as well as the branch, but I only have 1.8
branch builds atm.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Minimal testcase on the bug would help. Please don't mark core layout bugs (which is what this is) NEW without such a testcase....

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: bg image for "testcase"

Comment 5

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Attachment: partial testcase

bz: apologies about the NEW change; it must have slipped my mind when moving.

Here is a "testcase" that works when "Print Background Images" (obviously) and "Shrink To Fit Page Width" are checked.  When "Shrink to Fit" is not checked, it seems to work some of the time and not others, which for the life of me I can't understand.  Layout is not my forté; apologies again, but I hope this helps some.

Comment 6

[Boris Zbarsky [:bzbarsky]]

So the problem is that the blockquote margin "px" and the background image "px" end up different sizes?  That should most likely be fixed by bug 177805.

Comment 7

[verdy_p]

Comment on attachment 205199 [details]
bg image for "testcase"

Could the bug server return the correct MIME type for the image, i.e. the one that it already reports in the header (image/gif) instead of returning this incorrect HTTP header:

Content-Type:text/html; charset=iso-8859-1

This causes the browser to have to guess the effective MIME type given that this is definitely not a valid HTML document.

A complete transaction is:

 Request URL:https://bugzilla.mozilla.org/attachment.cgi?id=205199
 Request Method:GET
 Status Code:302 Found

Request Headers:

 Accept:application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
 Referer:https://bugzilla.mozilla.org/attachment.cgi?id=205199&action=edit
 User-Agent:Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.2 (KHTML, like Gecko) Chrome/6.0.453.1 Safari/534.2
 Query String Parameters
 id:205199

Response Headers:

 Connection:Keep-Alive
 Content-Length:247
 Content-Type:text/html; charset=iso-8859-1
 Date:Tue, 20 Jul 2010 00:43:03 GMT
 Keep-Alive:timeout=300, max=999
 Location:https://bug305558.bugzilla.mozilla.org/attachment.cgi?id=205199
 Server:Apache
 Strict-transport-security:max-age=2629744; includeSubDomains

(Yes the query was performed within Chrome and not Firefox, but there's no reason why the server should not return the correct MIME type that it already knows on this Bugzilla Attachment Details for Bug)

Or at least the HTML containing the reference of the image displayed in the generated IFRAME could specify the MIME type as an attribute:

  <img type="image/gif" src="http://bugzilla.../attachment.cgi?id=..." />

that it has already used in the same generated HTML code in the header.

but for demonstrating bugs with HTML pages stored in Bugzilla attachments referencing images also in Bugzilla attachments, the MIME type should be correct (and if not, it should be editable by editing the attachment properties to the MIME type expected, waiting for a validation if ever an "unsafe" type like "application/binary" is manually specified)

Comment 8

[verdy_p]

In fact the bug comes from the fact that the HTML attachment in the example does not use the correct URL for the image....

Comment 9

[Boris Zbarsky [:bzbarsky]]

The attachment uses the correct url (which happens to point to a redirect at the moment, but that's an implementation detail of bugzilla which has changed before and may change again).  The type of the 302 response body is correctly sent as text/html; that response body is in fact an HTML document, as you would know if you had bothered to look at it.  The post-redirect 200 response body is an image and sent as image/gif.

Now can you please stop spamming this bug?

Comment 10

[Mihai Morar, (:MihaiMorar)]

The page mentioned in the URL is no longer available. Can you provide please another page that is still causing this issue?

Comment 11

[Mihai Morar, (:MihaiMorar)]

I am closing this as beng invalid due to lack of activity.

Comment 12

[Boris Zbarsky [:bzbarsky]]

INCOMPLETE, not INVALID.

That said, did you test the testcase attached to this bug?

Comment 13

[Mihai Morar, (:MihaiMorar)]

It worked fine while tested using partial testcase. Sorry for delay Boris but I was in PTO for 2 weeks.