Bug 125435 - LibreOffice PDF export regression -- edit file properties before saving/exporting doesn't work correctly and the PDF isn't opened automatically after export
Summary: LibreOffice PDF export regression -- edit file properties before saving/expor...
Status: RESOLVED DUPLICATE of bug 120343
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Printing and PDF export (show other bugs)
Version:
(earliest affected)
6.2.3.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:pdf
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2019-05-21 20:11 UTC by João Paulo
Modified: 2019-06-07 02:53 UTC (History)
1 user (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 João Paulo 2019-05-21 20:11:07 UTC
Description:
On Windows 10, version 1809, 64 bits, running LibreOffice 6.2.3.2 (x64), build ID aecc05fe267cc68dde00352a451aa867b3b546ac, do the following:

* Configure LibreOffice to edit file properties before saving (Menu Tools, Options, Load/Save, General, enable "Edit document properties before saving").

* Export any saved or unsaved document as a PDF file named as a new file (i.e., create a new PDF file instead of overwriting an old one).

* LibreOffice opens an error message box saying (translated from PT-BR):

"Error saving document <name of document without file extension>:
General error.
General input/output error."

* The PDF file isn't automatically opened (Menu File, Export As, Export As PDF, enable the "View PDF after export").

* Besides the error, the user still can edit the file properties and they will be saved on the exported PDF (tested with Title, Subject and Keywords fields, not tested with Custom Properties as they don't appear on SumatraPDF or Evince Document Viewer).

* If the exported PDF file already exists (i.e., the user chooses to overwrite an old PDF file), there is no error shown and the PDF files is automatically opened if the setting to "View PDF after export" is enabled.

I think this is due to the file properties being opened for the PDF file **before** the file is created.

There is no __confirmed__ data loss (I didn't test with Adobe Reader or other PDF viewers which could show custom properties), but this is is annoying.

Steps to Reproduce:
1. Configure LibreOffice to edit file properties before saving (Menu Tools, Options, Load/Save, General, enable "Edit document properties before saving").

2. (Optional) Configure LibreOffice to open the PDF file after export (Menu File, Export As, Export As PDF, enable the "View PDF after export").

3. Export any saved or unsaved document as a PDF file named as a new file (i.e., create a new PDF file instead of overwriting an old one).

4. LibreOffice opens an error message box saying (translated from PT-BR):

"Error saving document <name of document without file extension>:
General error.
General input/output error."

5.a) If Step 2. was completed: The PDF file isn't automatically opened.

5.b) With or without Step 2. completed: If the exported PDF file already exists (i.e., the user chooses to overwrite an old PDF file), there is no error shown and the PDF files is automatically opened if the setting to "View PDF after export" is enabled.

6. Besides the error, the user still can edit the file properties and they will be saved on the exported PDF (tested with Title, Subject and Keywords fields, not tested with Custom Properties as they don't appear on SumatraPDF or Evince Document Viewer).

Actual Results:
Actual results: There is no __confirmed__ data loss (I didn't test with Adobe Reader or other PDF viewers which could show custom properties), but this is is annoying.

Expected Results:
Expected results:

1. No error shown when exporting PDF if editing properties before saving file was enabled.

2. Automatically open the PDF file if view PDF after export was enabled.


Reproducible: Always


User Profile Reset: No



Additional Info:
I marked version 6.2.3.2 release as the earliest version affected because I didn't test on earlier versions. I think it's a regression from version  6.1.5.2, as it was the latest I had before upgrading to 6.2.x line.
Comment 1 João Paulo 2019-05-22 21:18:14 UTC
Sorry the first post was somewhat convoluted. The lines starting with "*" are redundant and incomplete compared to the Steps to reproduce (the numbered lines).
Comment 2 Xisco Faulí 2019-06-06 07:38:54 UTC
Thanks for reporting this issue.
It looks like a duplicate of bug 120343

*** This bug has been marked as a duplicate of bug 120343 ***