semi-transparent elements are printed to PDF as blurry, low-resolution image fallbacks




7 years ago
7 years ago


(Reporter: Ilja Sekler, Assigned: roc)




Firefox Tracking Flags

(blocking2.0 final+)


(Whiteboard: [softblocker], URL)


(4 attachments, 1 obsolete attachment)



7 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv: Gecko/20101013 Ubuntu/10.10 (maverick) Firefox/3.6.11
Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b9pre) Gecko/20100101 Firefox/4.0b9pre

Elements with opacity < 1 are printed with blurry (text almost illegible) image fallbacks, when using in-tree cairo. In builds using system cairo 1.10, these elements are just blank (but fallback images are there, one can drag'n'drop them from evince, though they are blank).

The last good nightly build dates from 2011-01-02, so one of the numerous checkins in <> (Bug 363861, Bug 593604 or Bug 602757) might have caused the regression.

Reproducible: Always

Steps to Reproduce:
1. Print the $URL to a PDF file

Actual Results:  
Semi-transparent elements (class .posted) are printed with blurry image fallbacks (in-tree cairo), the text in these elements is almost illegible and the size of the resulting PDF file is huge.

Expected Results:  
The text in semi-transparent elements is not mangled to a low-resolution bitmap, remains clear and legible.

This bug doesn't happen if the semi-transparent element has <body> as a direct ancestor.

Comment 1

7 years ago
Created attachment 502254 [details]
good PDF with 2011-01-02 nightly

Comment 2

7 years ago
Created attachment 502255 [details]
bad PDF with 2011-01-08 nightly


7 years ago
Keywords: regression
Assignee: nobody → roc
blocking2.0: --- → ?
Created attachment 502459 [details] [diff] [review]

This fixes it.
Attachment #502459 - Flags: review?(jmuizelaar)
Created attachment 502460 [details] [diff] [review]
fix v2

Oops, fix comment.
Attachment #502459 - Attachment is obsolete: true
Attachment #502460 - Flags: review?(jmuizelaar)
Attachment #502459 - Flags: review?(jmuizelaar)
Whiteboard: [needs review]
Attachment #502460 - Flags: review?(jmuizelaar) → review+
Marking as ASSIGNED since, well, there's already a proposed patch.
Ever confirmed: true
blocking2.0: ? → final+
Keywords: checkin-needed
Whiteboard: [needs review] → [needs landing]
Whiteboard: [needs landing] → [needs landing][softblocker]

Comment 6

7 years ago
Thank you very much for the fix. Is unselectable text in areas with transparency in the "good PDF" file a limitation of PDF format or a gecko/cairo bug?

I filed this bug only about PDF keeping <> in the back of my mind, PS still remains the default output format and the results of printing <> to a physical printer look as poor as the "bad PDF". Any chance to review and land <> soon?
Karl's working on that review, but he's been taking holiday days so it'll be maybe a week more.

IIRC when I opened my test PDF in evince I could select the text.

Comment 8

7 years ago
Created attachment 503316 [details]
Transparent parts of PDF not selectable

Screenshot of Evince 2.32.0 with Attachment <> on Ubuntu 10.10 after hitting Ctrl+A: parts of the PDF with transparency ("Posted by:") are not selected. Text in these parts does not appear in the output of pdftotext as well.
Please file a new bug for that.

Comment 10

7 years ago
(In reply to comment #9)
> Please file a new bug for that.

Filed bug 625852.
Last Resolved: 7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Whiteboard: [needs landing][softblocker] → [softblocker]
You need to log in before you can comment on or make changes to this bug.