Issue 118127

http://openoffice.org/bugzilla/show_bug.cgi?id=92003


I have a ethernet TCP/IP connected laser printer with more than one paper tray, running OO 3.3.0 M20 on OSX 10.6.7.  It appears that OO always sends some sort of command to my printer that it should be using 8.5 x 11 " paper.  Changing the paper size in a given document only changes the distance between the margins to an appropriate size, but the printer never gets a command to print, or that it should be printing, on an alternative size paper. 

I've seen some confusing inquiries on this issue, so I'm going to post a comparison to the printing behavior of TextEdit, a standard Mac text editing application that can handle .rtf documents (but not much else).

(1) In a given document opened in OO Writer, a paper size other than "Letter" can be chosen at Format --> Page.  Once an alternative paper size is selected, the page size as presented in the editing window and in page preview pane shows the changes in paper size appropriately on the computer screen.  See attached Example-OO.odt set to page size 6.44" w x 8.56" h.  So far so good.

     (a)  OO Writer printing to multipurpose tray.

          1.  When printing the 6.44" w x 8.56" h .odt document to the multipurpose tray which is loaded with letter size 8.5" w x 11" h paper, the OO prints as in the FIRST page of Example-OO-a.pdf, with the correct line width, however on the wrong size paper and with everything placed arbitrarily on the left hand side.  No printer error is thrown for printing on the wrong size paper, as my printer should do and as my printer does using TextEdit.

          2.   When printing the 6.44" w x 8.56" h .odt document to the multipurpose tray which is loaded with correct size 6.44" w x 8.56" paper, the OO prints as in the SECOND page of Example-OO-a.pdf, with the correct line width, however with text running off the left side of the paper because my multipurpose tray paper guides require the paper be loaded in the center of tray.  After this page prints, the printer detects that the paper it printed on is nominal 6.44" w x 8.56" paper, and then printer throws the error "Load tray 1 letter 8.5 x 11" ".  e.g. the printer THINKS the paper size should have been 8.5 x 11" even when OO should have communicated to the printer / printer drivers / OS that it should be expecting 6.44" w x 8.56" paper.  Loading another piece of 6.44" w x 8.56" repeats the print and throws the same error, ad infinitum, until an 8.5 x 11" piece of paper is loaded and then the printer is satisfied.

     (b)  OO Writer printing to standard tray.

          1.  When printing the 6.44" w x 8.56" h .odt document to the standard tray which is loaded with letter size 8.5" w x 11" h paper, OO prints as in the FIRST page of Example-OO-b.pdf.  This is basically the same behavior as in 1a1 above.  Again, no printer error is thrown for printing on the wrong size paper, as my printer should and as my printer does using TextEdit.

          2.   When printing the 6.44" w x 8.56" h .odt document to the standard tray which is loaded with correct size 6.44" w x 8.56" paper.  Apparently, my printer in this instance was able to detect that nominal 6.44" w x 8.56" paper is loaded in the standard tray I guess because of the paper guides.  Nothing prints at all.  The printer throws the error "Load Tray 2 Letter - 8.5 x 11" ".  e.g. the printer THINKS the paper size should have been 8.5 x 11" even when OO should have communicated to the drivers / OS that it should be expecting 6.44" w x 8.56" paper.

(2)  Contrast that with the output from the TextEdit printing pretty much the same page in .rtf format.  Use the file Example-TE.rtf which is already set to page size 6.44" w x 8.56" h.  Print from the TextEdit application (deselect Format --> Wrap to Window in the TextEdit application to make the appearance of the document clearer).

     (a)  TextEdit printing to multipurpose tray.

          1.  When printing the 6.44" w x 8.56" h .rtf document with TextEdit to the multipurpose tray which is loaded with letter size 8.5" w x 11" h paper, TextEdit prints as in the FIRST page of Example-TE-a.pdf.  Everything is the right size and centered nicely for my printer; however, the printer detects that it has printed on the incorrect size paper and throws the error "Load Tray 1 6.4 x 8.6 " ".  Loading the correct size paper reprints exactly as it should.

          2.   When printing the 6.44" w x 8.56" h .rtf document with TextEdit to the multipurpose tray which is loaded with correct size 6.44" w x 8.56" paper, TextEdit prints as in the SECOND page of Example-TE-a.pdf.  Perfect!  No errors thrown by printer, as it was expecting 6.44" w x 8.56" paper and it received 6.44" w x 8.56" paper.

     (b1+2)  TextEdit printing to standard tray.  This behaves essentially the same as in 2(a) above, with results shown in Example-TE-b.pdf.  Print is centered and no errors are thrown for wrong size paper when the 6.44" w x 8.56" paper is loaded in the standard tray.

As an experiment, I also tried to change the default paper size in the "Print & Fax" control panel under OS X "System Preferences."  Since 6.44 x 8.56" is not a standard paper size, I had to add a user-defined paper size from a "Page Setup" dialog in another application (not OO).  Interestingly, when printing Example-OO.odt from OO under these circumstances to the multipurpose tray, the output was as in Example-OO-x.pdf, indicating that OO still tries to print to 8.5 x 11, even when the default paper size and OO document paper size instruct it otherwise.

In short, I think there is a problem with OO interfacing the with OS X API.  My best guess is that it is over-riding the OS X default paper size setting in control panels with its own, and it's NOT over-riding the OS X default paper size with the paper size specified in the actual OO Writer document.  I think the correct behavior should be that OO uses the OS X default paper size setting as the default size for new OO documents, then if there is a user change to the document paper size in OO, then when printing, there must be part of the OS X printing API that receives the specific paper size of the document being printed from OO, and which then send this paper size on to the printer.  I do no think this is a problem with my particular printer or the printer setup, as everything works as it is supposed to with TextEdit.  I think, somehow, OO Writer is not sending the actual page size of the document being printed to the drivers / OSX, it is simply reformatting the text as if it were on the correct size document, then embedding this in a standard 8.5 x 11 " document before sending it to the printer.

But I could be wrong.  At any rate, it seems screwed up.