Printing under Linux does not work at all after the last Cairo merge. Depending on the printer being used you either get an error pop-up or a blank page printed. Hg bisect identified this check-in as the regressor: The first bad revision is: changeset: 41305:f236632a9747 user: Jeff Muizelaar <jmuizelaar@mozilla.com> date: Mon Apr 05 22:28:54 2010 -0400 summary: Bug 542605. Update cairo to 12d521df8acc483b2daa844d4f05dc2fe2765ba6. r=vlad,jwatt,bas

Mandriva-linux-2010.1-Cooker-86_64 Printer/printing works fine

What is not working for me is printing to a several different model HP printers using recent trunk nightlies via cups under fedora 12.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.3a5pre) Gecko/20100503 Minefield/3.7a5pre I am able to print lots of pages, but not all. I haven't tested whether this regressed at the same point yet. I've also had some sites print the first page only, so I've had to print to PDF, and then print that to get all of the pages. Need to do some more testing to get some more concrete facts about which pages fail and in which builds. Print preview also give me this, but I don't think it's related: Trying to position a sizeless window; caller should have called sizeToContent() or sizeTo(). See bug 75649. TEST-INFO ExitPrintPreview: mPrintEngine=0xae106200, GetIsPrinting()=0 Oh, and when I say some pages don't print, I mean that nothing happens (not an error or a blank page like in comment 0). I guess that makes this a fairly useless comment about a possibly completely unrelated issue... I'll work on the regression range, then at least it might match this bug. This is on Gentoo with CUPS 1.3.11-r1

Also, wasn't the checkin from comment 0 backed out? And then not checked in again until the 26th or so?

Right. This should have gotten better after Jeff backed out the Cairo update - the final landing happened much later. If that's not the case, maybe the backout didn't take properly?

The date identified by hg bisect is the date int he patch not the date it was pushed. The actual check-in identified was: jmuizelaar@mozilla.com Mon Apr 26 07:41:22 2010 -0700 f236632a9747 Jeff Muizelaar — Bug 542605. Update cairo to 12d521df8acc483b2daa844d4f05dc2fe2765ba6. r=vlad,jwatt,bas Reland after fixing quartz related clipping bug and a bunch of other ones

Could you attach the PostScript output for a page that won't print. There is a cairo patch more recent than the 12d521df merge that may help: http://cgit.freedesktop.org/cairo/commit/?id=42b5cac7668625c9761113ff72b47af5cfd10377

this page does not print http://www.wg9s.com/

The bug page you are looking at does not print.

(In reply to comment #7) > Could you attach the PostScript output for a page that won't print. > > There is a cairo patch more recent than the 12d521df merge that may help: > > http://cgit.freedesktop.org/cairo/commit/?id=42b5cac7668625c9761113ff72b47af5cfd10377 The patch referenced here does not help.

(In reply to comment #12) > Created an attachment (id=443243) [details] > postscript same file but with 20100426 nightly Oops. I should have mentioned this is the postscript from printing the same file, but with a build from before the Cairo landing and therefore prints successfully.

Both PS files work for me on Ubuntu 10.04. I tested with both "lpr" (goes through CUPS filtering) and "lpr -l" (sends PS directly to the printer). It sounds similar to this bug: https://bugs.freedesktop.org/show_bug.cgi?id=27491 Can you try reducing your test case to find out what it is on the page that triggers the failure.

(In reply to comment #15) > Both PS files work for me on Ubuntu 10.04. I tested with both "lpr" (goes > through CUPS filtering) and "lpr -l" (sends PS directly to the printer). > > It sounds similar to this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=27491 > > Can you try reducing your test case to find out what it is on the page that > triggers the failure. That is the same patch that I said I tested in comment #13 that did not seem to help. I suppose I can try again.

(In reply to comment #16) > That is the same patch that I said I tested in comment #13 that did not seem to > help. I suppose I can try again. The patch helped but it did not fix cairo bug 27491. I don't have a solution for 27491 as I can not reproduce the problem and the test case is too large to be able to take a guess at what the problem might be. This bug may or may be the same bug as 27491.

OK. This is NOT the same issue as Cairo bug 27491 as the patch for that does not help here. I can print straight text files. I can print gif images. I cannot print gif images with a transparent background.

Postscript file created by printing using 20070426 nightly (before cairo update landing) This both prints correctly and displays correctly in Document viewer.

Created using current trunk. This neither prints nor displays correctly in Document Viewer. The fact that it does not display in document viewer would seem to rule out an issue with printer definitions or drivers.

(In reply to comment #17) > (In reply to comment #16) > > That is the same patch that I said I tested in comment #13 that did not seem to > > help. I suppose I can try again. > > The patch helped but it did not fix cairo bug 27491. I don't have a solution > for 27491 as I can not reproduce the problem and the test case is too large to > be able to take a guess at what the problem might be. > > This bug may or may be the same bug as 27491. OK so these postscript files were created by loading this url: http://www.wg9s.com/images/valid-html401.gif and then doing a File print. Using the current trunk the generated postscript does not display using Document Viewer 2.28.2.

(In reply to comment #20) > Created an attachment (id=443497) [details] > postscript from printing same iamge using current trunk > Applying the following change to this file seems to fix it. I am not saying this is the correct fix, just that doing this makes it print and display in DOcument Viewer. --- bad.ps 2010-05-04 19:36:11.489221072 -0400 +++ test.ps 2010-05-05 07:36:24.438334910 -0400 @@ -1058,13 +1058,12 @@ 62o9r,`I(J$Hq25)?cW(_aF'W%I':WgQnt/g1BRV*""5gSTJ6N3.>%%?JrhR9YUG*r-j!3l !^In1+<U^321nCbKeQAZ-uoP7RHX<m"ZP<@pYZ+Vi<"5_IP9`15NI8hjaLS!IW+CuJ*;?Bl $f8iI]r'd^[-Eqm=*sPJnQH^E$bWG-N[BnIi':-2tR/YoD_nas'PMMDtnfpq1!nis,[#+^\ `N,qZ#INJ*6b9!;r?[JO(Dt=@=2F#)5HQYdedE+VTXM@Spg7?8WU\7O-<jr,t@NO\''E!bi (?:F$ZI,f6@iVGJS'M<(s>*/Hj%%gM&kTn'ja:siNiGPrkR9;YX%eG<rEUs,hfWlOD@<jYW )=)6@`"bt!+Z<;"pHUXg^CURGaf)(0@j`@Sg8S$gh*X4rp8L-7lp'1DH^gSp!>XfeML;m\B \@cuT+X<4DV3:(rb%Wc(:8a<@"U^)UUf92)I7C,7X4D'/gAQcHA[C*-G2%GbkB4DnDg0t8# 7#t#ic04uIRbcNbN<kkh#<(!V:4^PHJO%jB=6L^GC/0G#D^:UJ:I~> -Q Q Q showpage %%Trailer %%EOF

(In reply to comment #10) > Created an attachment (id=443228) [details] > postscritp file of http://www.wg9s.com Applying the same "fix" to this postcript corrects the issue with this file as well.

(In reply to comment #22) > Applying the following change to this file seems to fix it. I am not saying > this is the correct fix, just that doing this makes it print and display in > DOcument Viewer. Your close :). There is a missing 'Q' before the image when the clip path is reset. I have been testing a patch to fix this.

Should be fixed with this patch: http://cgit.freedesktop.org/cairo/commit/?id=fa937913e06bc295750538be45aa83eb42332fb4

This is most-likely NOT the correct fix as I really don't understand this code., therefore I have also not assigned the bug to me. However, this has restored the ability to print for me. Oddly, this required a clobber to be effective, so there must be a dependency issue in the build system as well.

With this workaround patch I am able to also print http://news.bbc.uk.co/, which was the testpage for https://bugs.freedesktop.org/show_bug.cgi?id=27491, without the need to install the patch attached to that bug. So, perhaps this patch is closer to correct than I first thought.

Have you tried the patch in comment 25?

(In reply to comment #28) > Have you tried the patch in comment 25? I noticed that and did a new build using that. It works like a champ. Somehow I missed that comment earlier. Also you can ignore my comment about dependency issues (it never made any sense anyway). I figured out how i had screwed up. I do both 64 and 32-bit Linux builds and had stupidly done a depend 64-bit build to add the patch, and then tested using the 32-bit build.

It t]seems like somehow we need to come up with a non-error-tolerant postscript parser with good reporting on what the error condition is that we can use to somehow build into the test infrastructure for printing so that issues such as this would somehow result in a test failure that would have enough information in the failure message to easily figure out the issue.

OK so for people who are trying to use Firefox trunk nightlies, but can't print, I wanted to let you know that I do produce and make publicly available at http://www.wg9s.com/mozilla/firefox/ builds on sort of a regular at around the same time as official nightly builds. I don;t always have time to do this every day especially if I have difficulty in merging my pending patches with the trunk. Anyway these builds include this fix but also have a bunch of pending MathML and sometimes SVG SMIL patches included as well. The build is what I run myself. I just make it available to to others who might want to be testing something close to current nightlies that can also print.

OK, so is the fix in comment #25 sufficient to cover all of the issues or is the earlier patch required as well? I ask, only because I cannot reproduce any reported issues if I just include the comment #25 patch.

The cairo update in bug 562746 will include the fix in comment #25.

Does it make any sense to try to get the 2 patches form here into the next alpha if the cairo landing can't make it so that Linux printing will work in the Alpha?

We need to get the cairo update into beta 2. In the mean time, this should be relnoted.

Could we possibly take the upstream patches mentioned in comment #25 and comment #7 as they seem to be sufficient to fix the Linux printing issue without requiring the entire cairo update. It would seem to be un-optimal to release a beta with printing broken in a major platform.

Oh. I guess that is what i already said in comment 34. What would have been more useful to add is that hose 2 patches can be added without breaking windows builds.

I really don't think you should release a beta on a tier 1 platform when printing does not work. Beta builds are intended to be used by a wider range of users and to gain more feedback than you get from nightly and alpha builds. If printing doesn't work, people won't use it regularly and you'll get less feedback.

I went forward and pushed these changes ahead of the cairo update: http://hg.mozilla.org/mozilla-central/rev/2a8e821c0e80 http://hg.mozilla.org/mozilla-central/rev/75e1aec716c0

This made it in to beta 1, so removing relnote request.