394412 - Error attempting to print from Trunk build of Seamonkey

Status: RESOLVED FIXED

(Core :: Printing: Output, defect)

Description

[Andy Willis (abwillis)]

I don't know if this is caused by Thebes or by the Seamonkey change on toolkit but on Trunk builds when I attempt to print I get the error:
"An unknown error occurred while printing."
As I think it is probably Thebes related I am adding it to the Thebes metabug.
I tried a new profile to make sure it wasn't some bug from my migrated profile but I get the same error.  Print preview gives the same error.  I tried 3 installed printers (all PS).

Comment 1

[Peter Weilbacher]

Yes, I'm pretty sure that this is a cairo problem. I only checked in non-functional stubs for the printer functions to get it to compile. I wanted to take a closer look once we have really solved the on-screen functionality.

Comment 2

[Peter Weilbacher]

Just took a quick look again, only to the point to find the stubs again.

They are the five functions (GetSurfaceForPrinter, Begin/EndDocument,
and Begin/EndPage) listed here:
http://mxr.mozilla.org/seamonkey/source/widget/src/os2/nsDeviceContextSpecOS2.h#99

On Windows they are listed here:
http://mxr.mozilla.org/seamonkey/source/widget/src/windows/nsDeviceContextSpecWin.h#56
bug actually only one of them is implemented, here:
http://mxr.mozilla.org/seamonkey/source/widget/src/windows/nsDeviceContextSpecWin.cpp#515

That doesn't really look difficult (especially since I don't think we can set our output type to PDF yet, which is what 80% of that implementation is about).

Comment 3

[Peter Weilbacher]

Attachment: First try, PDF works

OK, it turns out that I got the PDF bit to work earlier. We don't have a UI to set the printing to PDF and the respective filename, so for now this patch just hardcodes that it prints to moz_print.pdf on the Desktop. This happens whatever printer is selected.
Print preview also work, but printing (to PDF) from the preview doesn't put anything in the file, don't know yet why that is.

I guess I should really split up the patch in two parts: enabling the PDF surface, and getting the printing enabled.

Comment 4

[Peter Weilbacher]

Comment on attachment 289249 [details] [diff] [review]
First try, PDF works

Well, this patch was rubbish. I forgot some files and left garbage in the ones that I did add...

Will post a new one soon.

Comment 5

[Andy Willis (abwillis)]

I must have missed hitting commit before... my builds with this attachment 289249 [details] [diff] [review] mostly created the pdf file on the desktop (some printers didn't seem to do anything).  I also was able to create .ps files if I selected create file.

Comment 6

[Peter Weilbacher]

Attachment: [checked in] cleaned up patch

This still doesn't work but it should be clean enough to check in. Will do that in a minute.

I don't know why I had the impression that printing to PDF wouldn't work. I now installed the PrintPDF extension in Firefox and it does it's job (mostly). (Got it from https://addons.mozilla.org/en-US/firefox/addon/5971 and then had to edit its install.rdf to include a line for OS2.)

Comment 7

[Peter Weilbacher]

Attachment: paging functions

This adds the functions to do paging of the surface, i.e. tell the printer driver when to start and end the document and when to start a new page.

To compile, this also needs nsOS2Uni.* copied from widget/src/os2 to gfx\thebes\src and added nsOS2Uni.cpp to CPPSRCS in gfx\thebes\src\Makefile.in. Adding similar functions in widget/src/os2/nsDeviceContextSpecOS2.cpp doesn't seem to work, although I don't understand why not.

Comment 8

[Peter Weilbacher]

OK, that printing still doesn't work with that patch seems to be a problem with the units involved. I compute the size of the cairo surface in pixels and as such it still appears in nsPageFrame::Reflow(). Typical values for a print to the Apple PS driver are 5100x6600 pixels. But the margins (which are 0.5 inch by default) appear in AppUnits (whatever these units are they seems to be 720 twips / 0.24 = 3000) and so there is no room left for the content!

Comment 9

[Peter Weilbacher]

Attachment: [checked in] forgotten scaling

Oh, of course. I forgot to scale our pixels to AppUnits in nsThebesDeviceContext::CalcPrintingSize(). The code was already there in the first version of the patch. ;-) Will check this in soon.

With this patch and the previous one I can print fine, but only to a low resolution printer like the one from FaxPrint. Even a 300dpi OMNI driver doesn't work, it crashes in PMGPI after a few seconds of trying to print the first page (and the debugger isn't able to catch the crash or it doesn't show a call stack so I don't know where that happens, but probably somewhere in cairo).

Comment 10

[Peter Weilbacher]

Attachment: [checked in] pagination implementation in widget

OK, so this works after all, and then we don't need to move nsOS2Uni.*.

It feels a bit weird to have a HDC as class member variable that isn't cleared in this class (but instead in gfxOS2Surface) but I don't see a way around that currently.

Comment 11

[Peter Weilbacher]

Comment on attachment 301186 [details] [diff] [review]
[checked in] forgotten scaling

checked in to trunk

Comment 12

[Peter Weilbacher]

Comment on attachment 301189 [details] [diff] [review]
[checked in] pagination implementation in widget

Checked this fix into trunk, too.

Comment 13

[Peter Weilbacher]

OK, so print preview and printing itself now work in principle and this error has gone away, so this is fixed.

Print preview still gives huge scrollbars but that is bug 378272. I'll file a follow-up bug about the RAM and spool-file size issue.

Comment 14

[Peter Weilbacher]

Btw, the driver I was referring to in comment 9 isn't from FaxPrint but from PMFax (and while writing FaxPrint I was actually thinking of _FaxView_).