Download it now!
Bug 125932 - Print/Export should close cells first
Summary: Print/Export should close cells first
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
6.2.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Calc-UX Print Cell-Edit-Mode File-Export
  Show dependency treegraph
 
Reported: 2019-06-14 20:18 UTC by Todd
Modified: 2019-06-28 14:42 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Todd 2019-06-14 20:18:29 UTC
Request for Enhancement:

LibreOffice-6.2.4-Linux_x86-64_rpm.tar.gz

If you add something to a cell and don't press enter or click off the cell to save the cell, then you print, print will not pick up what is in the unsaved cell.  

This is an "inconvenience to the user".  I have twice now tried to figure out what the missing entry was in front of the bank teller on my deport slips.  NOT FUN!

What I would see is something that would either

1) force a save if the print button was pressed (as does the "save" button), or

2) not allow you to print, as does Excel 2007.  A "save your cell first" note would cut down on the confusion with this method, or

3) something cleaver that the programmer likes better.

Many thanks,
-T
Comment 1 V Stuart Foote 2019-06-15 14:10:12 UTC
Hmm can not confirm this on Windows builds, can already "print" with unsaved cells.

On Windows all the print actions--preview, print, preview in web browser--all pick up the cell/formula content from an 'unsaved' edit. Returning from that dialog will have triggered the save-needed actions (toolbar icon change, status bar icon change).

But, the Export actions (to PDF, JPEG, PNG, XHTML) drop the unsaved cell content.

So, guess could make a distinction between Export and Print depending on os/DE. 

=-testing-=
Windows 10 Home 64-bit en-US with
Version: 6.2.4.2 (x64)
Build ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
CPU threads: 4; OS: Windows 10.0; UI render: default; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 2 Todd 2019-06-16 05:09:54 UTC
I had initially though this was a bug, so I reported it over on

Bug 125895 - Calc: print does not print unsaved cell

Maybe there is something in the verbage over there that helps with this RFE

It would also be nice if every OS and export all acted the same
Comment 3 V Stuart Foote 2019-06-16 13:37:51 UTC
@Eike, should there be consistent handling here of uncommitted cells--i.e. 'no save' => no Print, no Export; or conversely 'save not needed' => will Print, will Export?  

Seeing split capability as now, i.e. 'no save' will Print but won't Export, suggests things currently follow different paths. 

Should be consistent, right? But then which action: 'notify a save required, and enforce' before any Print or Export; or 'allow' Print or Export including unsaved cell entries.
Comment 4 Eike Rathke 2019-06-19 11:33:20 UTC
Seems some (print, export) do not close cell input before action, but others (save, saveas, print preview) do i.e. one ends up with the so far edited content being committed to the document. My take is that also print and export should close the pending cell input.
Comment 5 Heiko Tietze 2019-06-19 12:15:18 UTC
So issue accepted as a bug, removing UX.
Comment 6 Xisco Faulí 2019-06-28 14:42:31 UTC
I checked in 

Version: 4.1.0.0.alpha1+
Build ID: 8d8f9dd80abf4e1eb08eee9763ea38f2b15f02b

and it gives an error if I try to export to PDF while editing a cell