Reproduced the same problem on Mandriva 2008 (x64), LibreOffice 3.4.4 (340m1 Build:402).

*** Bug 44138 has been marked as a duplicate of this bug. ***

Regression due to original report

@Ivan:
Might be UI related, may be not ... . Can you shed light on the dark?
Please feel free to reassign (or reset Assignee to default) if it’s not your area or if provided information is not sufficient. Please set Status to ASSIGNED if you accept this Bug.

It seems the set-tray-feature actually works, just need to update the UI... I'll take a look.

Same problem with LibreOffice 3.4.5 OOO340m1 (Build:502) on Ubuntu 10.04 x64

the problem still exists with libreoffice 3.4.5 on ubuntu 11.10 64bit.

Hum, I'm sorry, I didn't succeed with fixing...

My feeble attempt to fix:
http://nabble.documentfoundation.org/REVIEW-fdo-43932-try-to-fix-paper-tray-settings-td3657361.html

Reset Assignee to default.

- same problem on 3.4.3 on ubuntu 11.04
- it always uses the thefault printer from cups print server
- version 3.3.4 is working with multiple paper trays

This bug also affects 3.5.0 RC2.

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 #39220

we also tested with 3.5 RC2.
paper tray is also not working.

I cant write a fix, so its not possible to help that much.
only if you have to test something, im able to test if its working.

now I have to migrate our 250 computers to OpenOffice!!!!
we need du update form 3.3.x because of other fixes and we cant, because our 60 printer would stop printing from multiple paper trays.

if i can help something, let me know now!!!

tnx

chris -- which is scripting migration to OO ... sniff

Same problem with LibreOffice 3.4.5 OOO340m1 (Build:502)
on Ubuntu 11.10 (GNU/Linux 3.0.0-16-generic i686) 32bit

(In reply to comment #11)

> now I have to migrate our 250 computers to OpenOffice!!!!
> we need du update form 3.3.x because of other fixes and we cant, because our 60
> printer would stop printing from multiple paper trays.

@ chris,

you can change the paper tray setting in "File -> Printer Settings..."

@ Samuel

That is no solution if you use a letterhead and you need to print every first page to tray X and every next page to tray Y. In an office environment this is unacceptable.

> you can change the paper tray setting in "File -> Printer Settings..."

@samuel
tnx for reply, yes i also found that hint at redhat bugzilla.

sadly we cant handle it that way.
letterhead, internal documentation, we are a school with 250 employee,
teachers are not that flexible :-)

they want a solution, comming wendsday i have to push the software rollout of 
open office.

tnx anyway

chris

PS: hopefully we will migrate back to LibreO this year

"LibreOffice 3.5.0 German UI/Locale [Build-ID: 7e68ba2-a744ebf-1f241b7-c506db1-7d53735] on German WIN7 Home Premium (64bit) prints to the correct OKI 14ex tray and settings from Print dialog will not be lost. So it indeed seems to be LINUX related.

Version due to comment 8
<http://wiki.documentfoundation.org/BugReport_Details#Version>

I can't see any particular BASIC problem here.

This one will not block anything. But IMHO a 3.5 Most Annoying one.

@All:
Really limited to WRITER or also visible with CALC, DRAW, ...?

(In reply to comment #16)

> I can't see any particular BASIC problem here.
> 
> This one will not block anything. But IMHO a 3.5 Most Annoying one.

I'm the one that pasted the BASIC-macro, so I should add that the pasted macro worked in openoffice perfectly (print page 1 to tray2 and consequent pages to tray1), but since I made the switch to libreoffice v3.3 and later 3.4, the problem surfaced.

I added this information because it rules out the possibility that it is a GUI-problem. The cause is to be sought underneath.

> @All:
> Really limited to WRITER or also visible with CALC, DRAW, ...?

I have tried it just now (in v3.4.4) and both CALC and DRAW are also not able to print to tray2 when selected in the CTRL+P print-dialog > properties of printer.

@change from 'blocker' to 'critical':
I'm not happy with this change, because it costs me money: letterhead-paper doesn't come cheap and for every printed page of a letter consisting of more than 1 page, I have to throw away a letterhead-page that is not printed correctly.

I agree that only affects printers with more than one tray, and thus rules out most consumers and even a lot of (small) businesses.

Due to Comment 17 I modify Component.

I have nothing further to add, other than that I just migrated 15 schools to LO (using debian squeeze-backport packages), and because a handfull of their 70+ printers sees activ use of different trays for different papers, I now need to downgrade to Openoffice 3.2 because of this bug. 

I tried the 3.5 deb-packages downloaded directly from openoffice.org, and the problem is there also.

(In reply to comment #19)
Thank you for your testimony and posting your result in testing LO 3.5. I hope this shows that a significant portion of the LO-targeted audience is affected by this bug.

This shows that the regression was hit from OOo3.2 -> LO3.3 and that all LO-releases are affected.

<http://wiki.documentfoundation.org/BugReport_Details#Version>

David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=6d4cca9c22c52b5a7742adc47ebf1a2930e29764

fix setting of paper tray from print dialog (fdo#43932)

fixed in master, requested review for 3.5 and 3.4

David Tardon committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=504aead0573befc744a00b8b1d68e3ebbaca8c47

Revert "fix setting of paper tray from print dialog (fdo#43932)"

DT, Thank you for your work on this. I was contemplating building libreoffice from GIT with the patch you submitted yesterday. Since I have never built anything myself, I was happy to see that there is an AUR-package to build LO from GIT.

Since you reverted the patch, I presume no testing is needed at this moment, but I will keep a close look on this and try a patch when available.

(In reply to comment #25)
> Since you reverted the patch, I presume no testing is needed at this moment,
> but I will keep a close look on this and try a patch when available.

Yes. And when there is a patch, you often can find a build to test it here:
http://dev-builds.libreoffice.org/daily/

Isn't this a duplicate of bug #49149 ?

(In reply to comment #27)
> Isn't this a duplicate of bug #49149 ?

If both reports describe the same bug, then it should be the other way around. The numbering of the bugreports should have given that away :)

Works in version 3.6.0.4 (Build ID: 932b512).

seeing as samuel originally reported this problem and now it works in version 3.6.0.4 for him it's apparently resolved now

Created attachment 72818 [details]
set correct paper tray in UI

This was fixed in 38f8241859cdef4dd7c3098e365947dd5b64f78c by David Tardon, but unfortunately this bug wasn't referenced in the commit message (unlike his previous attempt which he had to reverse), so it never had the chance to appear in this bug report and to get into later 3.5.x releases, its only resolved in 3.6 releases.
http://cgit.freedesktop.org/libreoffice/core/commit/?id=38f8241859cdef4dd7c3098e365947dd5b64f78c

I've applied that commit as a patch without change against Ubuntu 12.04 LTS's version 3.5 build which they call 3.5.4-0ubuntu1.1 and was able to build, run, and see this bug is resolved. (launchpad bug #994388). Didn't notice any regressions with some brief testing, and the patch appears to be a limited in it's scope.

I'm now going to deploy that particular build to real users in a 10 desk office running Ubuntu 12.04 where this bug has been of concern and see if they notice any regressions due to this fix being applied.

I believe this bug was still present in 3.5.7. I will confirm, and try this patch against against an unadulterated LibreOffice 3.5.7 when I get the chance, particularly if interest is expressed.