I think this has carried over from the Openoffice days.

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

[Reproducible] with "LibreOffice 3.3.0 RC3 - WIN7  Home Premium (64bit) German UI  [OOO330m19 (build 5 / tag 3.3.0.3)]". Selection "Only selected sheets" in print dialog does not work for print from print preview.


@Kohei:
One for you?

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

Also have same problem! Windows XP.
Also, problem is when that happen I cannot print selection.
Not really sure how to reproduce it, but happens to me quite offten, maybe once a week. First it goes on spree with printing 16 pages from all sheets, then when I try to print just SELECTION it won't print it, always all sheets.

I can confirm this for multiple machines here, running on XP
LibreOffice 3.3.2 OOO330m19 (Build:202) tag libreoffice-3.3.2.2

Before finding this bug-report, I found email from 11 Nov 2010, describing the same bug in LibreOffice 3.3.0:
http://listarchives.libreoffice.org/www/users/msg00346.html

With many sheets, this can be a bit annoying  :-)

Closing the print preview _before_ printing makes it print only the selected sheet.

Unfortunately it's not easy to fix this one, since this is due to a design flow rather than a simple bug.  The information about which tabs are selected is not available during print preview since it's stored in Calc's view shell.  During print preview, however, the view shell is not Calc's but preview's own view shell, which doesn't store the tab selection info, hence by default chooses to print all sheets.

And this is not a regression but rather a long standing problem.  I'll remove this from the list of blockers.

Pointer for future investigation.  In ScModelObj::FillRenderMarkData(), we try to get a hold of the ScTabViewShell instance and eventually ScMarkData in order to get tab selection data.  And because the view shell is not ScTabViewShell during print preview but rather ScPreviewShell, the returned pointer is NULL, hence the code doesn't un-select the tabs that are not selected.

A possible solution is to store this selected state with ScTable itself rather than ScMarkData and pull that information from ScTable.  Since ScTable also stores tab color data, it makes sense to also store the selected state alongside it as well.

Hi, My last comment crossed your comment, I was going to sugest at least grey-ing the option when defaulting to "all sheets". (when the pointer is null)

Your solution sounds very good. I don't know if ScMarkData is used by anything. maybe it could be stored in both, if only the user can select/unselect tabs.

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

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

Hi,

Same problem here in a company where i try to migrate to libreoffice 3.4.3 from Office 2003.

This is a BIG problem because in company environment, we use many sheets in the same file. And 90% of employees go to the "Print preview" and print.. and this is a normal behavior.

Just 30min ago, the big boss wanted print the current sheet (1 page) BUT 16 pages are printed because the file have 16 sheets! and that happen also with all others employees..

This point is a BLOCKER in my case and in a company that may be want to migrate to libreoffice. Is a really good product, but that kind of bug can be a trigger to go to a microsoft solution.

Please put a higher priority of this bug and try to fix this for 3.4.4.

Thanks in advance,
Michael

(In reply to comment #8)
> Pointer for future investigation.  In ScModelObj::FillRenderMarkData(), we try
> to get a hold of the ScTabViewShell instance and eventually ScMarkData in order
> to get tab selection data.  And because the view shell is not ScTabViewShell
> during print preview but rather ScPreviewShell, the returned pointer is NULL,
> hence the code doesn't un-select the tabs that are not selected.

Would   pDocShell->GetBestViewShell()   help in any way?

(In reply to comment #13)

> Would   pDocShell->GetBestViewShell()   help in any way?

I may have tried that one in my last attempt.  But it's worth double-checking it to be sure.

> Would   pDocShell->GetBestViewShell()   help in any way?

I tried (in version3.5), but it didn't help.

(In reply to comment #14)
> (In reply to comment #13)
> 
> > Would   pDocShell->GetBestViewShell()   help in any way?
> 
> I may have tried that one in my last attempt.  But it's worth double-checking
> it to be sure.

Actually, during print preview, it's ScPreviewShell that's the view shell, but we need access to ScTabViewShell which holds access to ScMarkData.  GetBestViewShell() only returns if the view shell is ScTabViewShell, and returns NULL during print preview mode.

So, I still stand by my original assessment in comment #8.  Given the circumstance that's the best way to fix this since that would only move the storage location without introducing yet another layer of complexity.

I changed my mind.  I'll devise a different solution.

Ok. The basic printing issue as originally reported is now resolved on master.  Right now I'm trying to fix the inconsistency in the pages in the print preview mode.

(In reply to comment #18)
> Ok. The basic printing issue as originally reported is now resolved on master. 
> Right now I'm trying to fix the inconsistency in the pages in the print preview
> mode.

Fixed that as well.  Now the print preview should show the correct sheet(s) based on the printing options and selected sheet(s).

Also fixed the minor issue where ending the print preview mode cleared all selected sheets but the current.  This concludes my work on this bug.

Actually I did a little more than what was asked for.  Anyway, Calc's print preview should be a lot more usable now.

I believe this one missed the boat for beta 0, but it should be in beta 1.

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