LibreOffice 3.3.x and 3.4.1 ignore settings like paper tray from the "File" -> "Print" dialog.
Whatever the system default paper tray may be will be used, regardless of settings in said dialog or under the Page layout in for example Writer.
Since we use laserjets with multiple trays for various paper types this essentially means we can not upgrade past the initial LibreOffice release where this critical feature still worked.
We had this problem on Windows Vista and Windows 7 (both 64-bit) where both systems worked flawless with an older version of LibreOffice.
We can't handle such "nothing works" reports, so here we will will limit investigations to the paper tray problem.
I can not confirm that as a general problem. I checked with my OKIPAGE14ex:
a) If I select "Manual tray" in printer dialog the printer will not print from cassette tray and will wait until I provide paper to the manual try
b) If I select "cassette tray" in printer dialog the printer will immediately print from cassette.
Did you check whether you problem has already been reported?
May I ask you to read hints on <http://wiki.documentfoundation.org/BugReport> carefully?
- Attach a sample document
- Attach screenshots with comments (you can add information using LibO DRAW
and then attach your screenshot with comments as PDF) if necessary
- Contribute a step by step instruction containing every key press and every
mouse click how to reproduce your problem
- add information
-- what exactly is unexpected
-- and why do you believe it's unexpected
-- concerning your PC
-- exact printer and driver information
-- concerning your LibO localization (UI language)
–- Libo settings that might be related to your problems (Tools - Options -
Everything print related)
-- how you launch LibO and how you opened the sample document
-- everything else crossing your mind after you read a.m. URL
Can you please file Bug reports with status UNCONFIRMED if your are not absolutely sure that you contributed all required background information and that the problem will be reproducible with information you can provide?
Forgot to mention:
NOT reproducible with "LibreOffice 3.4.1 - WIN7 Home Premium (64bit) German UI [OOO340m1 (Build:103)]"
Reproduced at another company near us which uses LibreOffice as well.
Both locations use a HP Color Laserjet 2600n using the latest drivers from HP for Windows 7 64-bit Dutch.
The build of LO we have now is LibreOffice 3.4.1 OOO340m1 (Build:103).
When I select the manual feed, the printer uses the manual feed. However, when I select tray 2 or tray 3, always tray 3 (system default) used.
Since the driver also supports the paper type selection, we normally select letterhead or plain to select trays and this does not work either.
Since the print dialog from LO does not show the "Unspecified" paper type, it might be the case that the paper type is always overruling the tray selection and LO simply does not provide the paper type selection to the driver while printing.
Note that the same procedure works fine from Notepad and that the only program which has issues selecting the correct paper input is LibreOffice.
Because of this, I do not believe that this is a problem in Windows or in the driver as multiple systems, with multiple versions of Windows and now not only with us, have the exact same issue.
I will attach a list of screenshots next to demonstrate the exact settings and results.
Created attachment 49174 [details]
Screenshots showing all steps and settings used for demonstrating this issue
Testing in Notepad confirmed that specifying the paper type overrules the tray selection. As an observation, this might mean that the bug is not that LO 3.4.1 handles the tray selection incorrectly but rather that it does not pass the paper type selection properly.
As LO does not offer the "Unspecified" paper type, the user can not use the tray selection anyway.
Regardless, I have attached a PDF showing all the steps used for default printing and it simply does not work as intended.
Created attachment 49175 [details]
Screenshot of the printer settings for Notepad where another paper type is available to enable the paper tray selection
This shows the Notepad printer panel which has by default another paper type which allows the use of the manual tray selection.
Without this, the user can not specify a paper tray manually.
As LibreOffice seems to ignore the actual paper type selection during printing, this effectively disables any form of tray selection resulting in the use of the system default for every print job.
There seems to be one exception: selecting the manual paper tray overrules all settings and remains functional.
We found a work-around to enable paper *tray* selection without using paper
By setting the system default paper type to "Unspecified", LibreOffice still
does not overrule this by the user specified paper type in the LO printing
panel. However, since the paper *tray* is set correctly by LibreOffice, we can
now use manual tray selection to switch.
I have adjusted the title of the bug accordingly: LO does not set the paper
type correctly during printing.
As an additional issue: it does not allow the selection of the "Unspecified"
paper type. So even when this gets fixed, it still requires this paper type to
be able to manually set the paper trays when required.
I hope I have been able to clarify things, let me know if more information is
*** Bug 41687 has been marked as a duplicate of this bug. ***
[This is an automated message.]
This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it
started right out as NEW without ever being explicitly confirmed. The bug is
changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back
to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases.
Details on how to test the 3.5.0 beta1 can be found at:
more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
I witnessed the same problem when switching from openoffice (Debian stable) to libreoffice (debian stable with backports).
I have written a BASIC macro that works perfectly in our office and in the office where my wife works, with the following code:
DIM oDoc AS Object
oDoc = ThisComponent
REM Set backgroundImage-option in DocumentSettings to False
DIM oSettings AS Object
oSettings = oDoc.createInstance("com.sun.star.text.DocumentSettings")
oSettings.PrintPageBackground = bBg1
REM choose a certain printer
DIM mPrinterOpts(3) AS NEW com.sun.star.beans.PropertyValue
mPrinterOpts(0).Name = "Name"
mPrinterOpts(0).Value = "MFC8880DN"
mPrinterOpts(1).Name = "PaperFormat"
mPrinterOpts(1).Value = com.sun.star.view.PaperFormat.A4
mPrinterOpts(2).Name = "PaperOrientation"
mPrinterOpts(2).Value = com.sun.star.view.PaperOrientation.PORTRAIT
oDoc.Printer = mPrinterOpts()
REM set Papertray in Styles
DIM oStyle AS Object
DIM sPageStyle AS String
sPageStyle = oDoc.CurrentController.getViewCursor().PageStyleName
ostyle = oDoc.StyleFamilies.getByName("PageStyles").getByName(sPageStyle)
oStyle.PrinterPaperTray = sTray
REM Set printOptions
DIM mPrintOpts(3) AS NEW com.sun.star.beans.PropertyValue
mPrintOpts(0).Name = "CopyCount"
mPrintOpts(0).Value = 1
mPrintOpts(1).Name = "Collate"
mPrintOpts(1).Value = True
mPrintOpts(2).Name = "Pages"
mPrintOpts(2).Value = sPageNr
mPrintOpts(3).Name = "Wait"
mPrintOpts(3).Value = True
This worked perfectly with Openoffice.org v3.2.1. When I upgraded to LibreOffice in backports (first v3.3, now v 3.4.3 OOO340m1 build 302), this stopped working.
printing complete documents to tray 1 WORKS
printing complete documents to tray 2 WORKS
printing the first page to tray 1 and following pages to tray 2 DOES NOT WORK.
Maybe this is related to the bug at hand, and it might even help solving this bug (and my problem ;-)) - to that end, I will be crossposting this info to bug #43932
Thanks for bugreport
Please, verify: in last version of LibreOffice still reproducible?
I'm very sorry, but I have two different linux distributions (Debian and Arch), and none of them is offering the latest version in the repo's. I'm stuck at 3.4.3 and 3.4.5 respectively.
If you're implying that 3.5 has changes in the (linux) printsystem, than I will try to install 3.5 on my arch laptop (libO 3.5 is in the testing repo until the first point-release)
Thanks for reply
> If you're implying that 3.5 has changes in the (linux) printsystem
No. It is better to wait some time
may be related problem:
Bug 42657 - PRINTING: LibreOffice won't save Printer Settings per Document.
Bug 43932 - PRINTING: Paper tray setting not accepted from "File -> Print...
Bug 44275 - Letter-size landscape 2-column Laser PRINTING bug
Dear bug submitter!
Due to the fact, that there are a lot of NEEDINFO bugs with no answer within the last six months, we close all of these bugs.
To keep this message short, more infos are available @ https://wiki.documentfoundation.org/QA/NeedinfoClosure#Statement
Thanks for understanding and hopefully updating your bug, so that everything is prepared for developers to fix your problem.