Bug 32826 - Printing in Preview mode causes all sheets to be printed
Summary: Printing in Preview mode causes all sheets to be printed
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
3.3.0 RC2
Hardware: x86 (IA32) All
: medium minor
Assignee: Kohei Yoshida
URL:
Whiteboard: target:3.5
Keywords:
: 33104 33522 38131 38156 45985 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-01-04 10:06 UTC by John Ervin
Modified: 2015-05-29 09:14 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
It happened with this test spreadsheet. Seems reproducible (6.50 KB, application/vnd.ms-excel)
2011-01-04 10:06 UTC, John Ervin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Ervin 2011-01-04 10:06:51 UTC
Created attachment 41632 [details]
It happened with this test spreadsheet.  Seems reproducible

I have a document with multiple sheets.  If I view the sheet that I'm working on in Preview mode and hit the printer icon, all sheets are printed.  If I close preview, returning to the sheet in question, hit the same print icon, then it correctly (IMHO) prints only the sheet that is up.

Happens on both my Ubuntu 10.10 Laptop and my Windows 7 desktop

LibreOffice 3.3.0 
OOO330m18 (Build:4)
tag libreoffice-3.3.0.2
Comment 1 John Ervin 2011-01-04 10:08:14 UTC
I think this has carried over from the Openoffice days.
Comment 2 Rainer Bielefeld Retired 2011-01-15 00:02:32 UTC
*** Bug 33104 has been marked as a duplicate of this bug. ***
Comment 3 Rainer Bielefeld Retired 2011-01-15 00:25:34 UTC
[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?
Comment 4 Rainer Bielefeld Retired 2011-04-04 22:02:46 UTC
*** Bug 33522 has been marked as a duplicate of this bug. ***
Comment 5 Mikeyy - L10n HR 2011-04-29 13:54:24 UTC
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.
Comment 6 Jaap Stolk 2011-05-16 03:54:20 UTC
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.
Comment 7 Kohei Yoshida 2011-05-20 22:55:00 UTC
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.
Comment 8 Kohei Yoshida 2011-05-20 22:59:55 UTC
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.
Comment 9 Jaap Stolk 2011-05-20 23:26:17 UTC
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.
Comment 10 Rainer Bielefeld Retired 2011-06-09 22:00:05 UTC
*** Bug 38131 has been marked as a duplicate of this bug. ***
Comment 11 Olivier Hallot 2011-06-10 12:16:59 UTC
*** Bug 38156 has been marked as a duplicate of this bug. ***
Comment 12 MichaelB 2011-10-04 07:08:58 UTC
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
Comment 13 Eike Rathke 2011-10-25 10:20:49 UTC
(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?
Comment 14 Kohei Yoshida 2011-10-25 10:45:57 UTC
(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.
Comment 15 Winfried Donkers 2011-11-11 02:47:30 UTC
> Would   pDocShell->GetBestViewShell()   help in any way?

I tried (in version3.5), but it didn't help.
Comment 16 Kohei Yoshida 2011-11-22 15:35:22 UTC
(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.
Comment 17 Kohei Yoshida 2011-11-28 15:15:04 UTC
I changed my mind.  I'll devise a different solution.
Comment 18 Kohei Yoshida 2011-11-28 21:06:32 UTC
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.
Comment 19 Kohei Yoshida 2011-11-28 21:34:50 UTC
(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).
Comment 20 Kohei Yoshida 2011-11-28 21:54:53 UTC
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.
Comment 21 Rainer Bielefeld Retired 2012-02-13 06:04:34 UTC
*** Bug 45985 has been marked as a duplicate of this bug. ***