Bug 450567 - Printing of a page with tables results in unusably blurry output
Printing of a page with tables results in unusably blurry output
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
9
All Linux
low Severity high
: ---
: ---
Assigned To: Carl Worth
Fedora Extras Quality Assurance
:
: 479450 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-06-09 13:48 EDT by Jonathan Blandford
Modified: 2013-04-02 00:22 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 13:50:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch from bisecting firefox 3 rc2. (4.98 KB, patch)
2008-06-09 13:48 EDT, Carl Worth
no flags Details | Diff
Actual patch this time (rather than HTML view of patch) (743 bytes, patch)
2008-06-09 14:06 EDT, Carl Worth
no flags Details | Diff

  None (edit)
Description Carl Worth 2008-06-09 13:48:09 EDT
I originally wrote up a description of the end-to-end problem, (along
with a minimal test case), here:

        http://cworth.org/cairo/a_chain_of_bugs/

To summarize the three necessary, (and independent) problems pointed
out there:

  1. Firefox uses "fancy" compositing operators to render table borders.

     This results in (small) image fallbacks in PDF output, inside
     a large knockout group.

  2. Poppler uses "fancy" compositing operators to render knockout groups.

     This (with (1)) results in a full-page image fallback in the PostScript
     output, inside a group.

  3. Cairo uses the wrong resolution when rednering a PostScript image inside
     a group.

     This finally, (with (2) and (1)), causes the full-page blurriness.

There's another, higher-level issue (lets call it (4)) which I didn't discuss
in the original blog report. Namely, clicking "print" (on some systems) is
resulting in firefox producing a PDF file which is then converted to a
PostScript file by poppler. I have not yet analyzed an affected system to see
exactly what interaction of firefox and GtkPrint is causing this. But if
this were fixed so that GtkPrint told firefox to simply generate PostScript
output in the first place, then the bug should be eliminated.

So, there are four separate issues there, and fixing any one of them should
eliminate the end-to-end problem of blurry printing.

My first attempt was to fix issue #3. It's in cairo itself, so I'm familiar
with the code. And it's the most clearly *wrong* behavior, (where the other
issues are all perhaps less-than-ideal or non-optimal, but not wrong per se).

My attempts to fix that issue are described here:

        Bug with fallback resolution of groups
        http://lists.cairographics.org/archives/cairo/2008-May/014169.html

It's clear that the solution there will be fairly complex, and likely
error prone. It's worth pursuing in the future. But I think we'll want
a more focused solution for the short term.

So next I turned my attention to issue #1 where I assumed we could come
up with a quick fix. Here's a bug report with initial efforts on that
front:

        Printing on linux should set SIMPLIFY_OPERATORS | DISABLE_SNAPPING
        https://bugzilla.mozilla.org/show_bug.cgi?id=435313

The patch there seems good and correct, (will result in the ADD operator
being replaced with OVER for example), but it's not sufficient. The border-
rendering code uses the CLEAR operator as well and SIMPLIFY_OPERATORS doesn't
change that. So all the same fallbacks are still triggered.

My next approach was a patch to replace the use of CLEAR with "draw with OVER
and with an opaque, white source" inside the border-rendering code when
under the influence of SIMPLIFY_OPERATORS. I didn't get far testing that
patch though, because I first found that in the Firefox 3 rc2 release the
entire buggy behavior seems to be gone already.

I bisected that change down and found a single-line (single-digit in fact!)
commit that changes the behavior:

        http://hg.mozilla.org/mozilla-central/index.cgi/rev/f6f36787bc84

I've also attached the same patch.

So I recommend this patch for a good, short-term fix for the problem.

I've verified that it fixes both my minimal test case and the printing
of a page originally reported, (not publically available).

-Carl

PS. And yes, this is a lot of bug-report verbiage for a single-line
fix. But the other issues are still worth fixing, so I thought it
would be worthwhile to document what I'd done here.
Comment 1 Carl Worth 2008-06-09 13:48:09 EDT
Created attachment 308731 [details]
Patch from bisecting firefox 3 rc2.
Comment 2 Carl Worth 2008-06-09 14:06:51 EDT
Created attachment 308734 [details]
Actual patch this time (rather than HTML view of patch)

Sorry about that. I had attached the output of the webpage displaying the
patch rather than just the patch. This should be a bit more useful I think.

-Carl
Comment 4 Kevin R. Page 2009-01-29 03:37:48 EST
*** Bug 479450 has been marked as a duplicate of this bug. ***
Comment 5 Kevin R. Page 2009-01-29 03:43:50 EST
I believe bug #479450 is a dupe of this one, but would appreciate confirmation.

While Firefox 3.1b would seem to fix the issue, I have a large number of faulty PDFs produced by firefox (the problem only became apparent when I went to print one as they look fine on-screen).

Is there anything that can be done to fix the PDFs?
Comment 6 Kevin R. Page 2009-04-14 19:18:16 EDT
(In reply to comment #0)
> To summarize the three necessary, (and independent) problems pointed
> out there:
[...]
>   3. Cairo uses the wrong resolution when rednering a PostScript image inside
>      a group.

Carl,

So as I understand it fixing (3) would allow the correct (non-blurry) printing of PDFs generated from Firefox under (1) (print to file, as PDF) ?

FF 3.1 seems to have fixed (1), but I still have a large number of PDFs generated by earlier versions. At the moment I don't get usable output when I print them.

I guess what I'd really like to know is whether these PDFs are effectively corrupted forever, and that I need to do some damage limitation to identify and regenerate them where I can.

(The bug is still present in F10, so could you update the bug version? I guess it might be better reassigned to cairo from firefox, too?)
Comment 7 Kevin R. Page 2009-05-19 15:53:55 EDT
I have scoured my hard drives for affected files (searching for files containing "Creator (cairo" seems to work - any reason this would miss any?).

The good news: I can re-print some of them with a newer firefox version (though I'll have to do so soon - some banks etc. only make statements available for a year, and it looks like this bug was introduced ~1 year ago)

The bad news: there are lots of others I can't re-print. I have needed, and will need, to print some of these. They're pages such as "Print a copy for your records" - I normally "print" to PDF and only really print when I need to.

From comment #0 if bugs (2) and (3) were fixed in Cairo these files would print ok - true or false?

It'd be *really* helpful to know so I can better judge when/whether it's worth trying to work around the issue.
Comment 8 Bug Zapper 2009-06-09 21:30:20 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 9 Kevin R. Page 2009-06-11 12:25:37 EDT
Please change component to Cairo and version to F11:

I've tested with Fedora 11 and while printing a print-to-PDF generated by firefox on F11 is fine, printing a print-to-PDF on F11 that was generated by firefox on F10 is still unusably blurry.

Therefore I think firefox has been fixed (1), but bugs (2) and (3) (as per comment #0) in cairo remain.

(I'd still love some wisdom on whether PDFs previously generated are recoverable)
Comment 10 Bug Zapper 2009-07-14 13:50:18 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.