http://openoffice.org/bugzilla/show_bug.cgi?id=118127
Issue Type: DEFECT
Summary: (Mac) Non-standard page size in OO not passed-on to
printer
Classification: Application
Product: Word processor
Version: OOo 3.3
Platform: Macintosh
OS/Version: Mac OS X
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: printing
AssignedTo: [email protected]
ReportedBy: [email protected]
QAContact: [email protected]
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.
--
Configure bugmail: http://openoffice.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
---------------------------------------------------------------------
Please do not reply to this automatically generated notification
from Bugzilla. Please log into the website and enter your comments.
---------------------------------------------------------------------
--
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help
--
-----------------------------------------------------------------
To unsubscribe send email to [email protected]
For additional commands send email to [email protected]
with Subject: help
