Bug 39220 - UI: Printer settings for paper *type* from print dialog ignored
Summary: UI: Printer settings for paper *type* from print dialog ignored
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
3.4.1 release
Hardware: x86-64 (AMD64) Windows (All)
: medium major
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 41687 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-07-14 04:46 UTC by Berend Dekens
Modified: 2012-08-31 10:05 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshots showing all steps and settings used for demonstrating this issue (823.42 KB, application/vnd.oasis.opendocument.graphics)
2011-07-16 04:16 UTC, Berend Dekens
Details
Screenshot of the printer settings for Notepad where another paper type is available to enable the paper tray selection (105.00 KB, image/png)
2011-07-16 04:23 UTC, Berend Dekens
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Berend Dekens 2011-07-14 04:46:02 UTC
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.
Comment 1 Rainer Bielefeld Retired 2011-07-15 00:31:50 UTC
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.

@Berend Dekens:
Did you check whether you problem has already been reported?
May I ask you to read  hints on <http://wiki.documentfoundation.org/BugReport> carefully?
Then please:
- 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? 

Thank you!
Comment 2 Rainer Bielefeld Retired 2011-07-15 00:34:57 UTC
Forgot to mention:
NOT reproducible with "LibreOffice 3.4.1  - WIN7  Home Premium (64bit) German UI [OOO340m1 (Build:103)]"
Comment 3 Berend Dekens 2011-07-16 03:59:14 UTC
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.
Comment 4 Berend Dekens 2011-07-16 04:16:48 UTC
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.
Comment 5 Berend Dekens 2011-07-16 04:23:11 UTC
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.
Comment 6 Berend Dekens 2011-07-16 04:31:27 UTC
We found a work-around to enable paper *tray* selection without using paper
*type* selection:

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
required.
Comment 7 Rainer Bielefeld Retired 2011-10-12 10:47:59 UTC
*** Bug 41687 has been marked as a duplicate of this bug. ***
Comment 8 Björn Michaelsen 2011-12-23 12:25:31 UTC
[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:
http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1

more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Comment 9 Vincent Van Houtte 2012-01-30 07:55:52 UTC
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:

[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

	REM Print
	oDoc.Print(mPrintOpts())
[/CODE]

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
Comment 10 sasha.libreoffice 2012-03-01 03:17:48 UTC
Thanks for bugreport
Please, verify: in last version of LibreOffice still reproducible?
Comment 11 Vincent Van Houtte 2012-03-01 04:33:01 UTC
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)
Comment 12 sasha.libreoffice 2012-03-01 04:47:52 UTC
Thanks for reply
> If you're implying that 3.5 has changes in the (linux) printsystem
No. It is better to wait some time
Comment 13 sasha.libreoffice 2012-03-01 05:22:03 UTC
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
Comment 14 Florian Reisinger 2012-08-14 14:01:02 UTC
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.

Yours!

Florian
Comment 15 Florian Reisinger 2012-08-14 14:02:09 UTC
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.

Yours!

Florian
Comment 16 Florian Reisinger 2012-08-14 14:06:48 UTC
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.

Yours!

Florian
Comment 17 Florian Reisinger 2012-08-14 14:08:51 UTC
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.

Yours!

Florian