Bug 103947 - LibreOffice Draw can not save as (replace) the opening pdf to itself, Must Rename.
Summary: LibreOffice Draw can not save as (replace) the opening pdf to itself, Must Re...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
Version:
(earliest affected)
5.0.4.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:6.3.0
Keywords:
: 116686 126532 (view as bug list)
Depends on:
Blocks: PDF-Export
  Show dependency treegraph
 
Reported: 2016-11-16 01:45 UTC by Harsono Ng
Modified: 2020-03-14 23:17 UTC (History)
11 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 Harsono Ng 2016-11-16 01:45:21 UTC
Description:
I use Libre Office Draw to open .PDF file directly for editing.
the problem is each time i need 'save as' different .PDF's name when 'export as pdf' and delete the original file then rename the edited file back to the name

I can't save as pdf directly to the same file's name itself
the error is: "Error saving the documents ~file name~ : Write Error. The file could not been written"  

I wish somebody could fix this problem for LibreOffice.

note: 
others pdf editor just able to save as and replace, 
but I am prefer using Libre cause it has better feature in editing, just this problem is annoying.

Steps to Reproduce:
0.open pdf file directly into LibreOffice Draw
1.click the 'save as pdf directly' button
2.directly click save with the same file name.
3.error appear 

Actual Results:  
"Error saving the documents ~file name~ : Write Error. The file could not been written"  

Expected Results:
the file is saved successfully


Reproducible: Always

User Profile Reset: No , but
try re install with latest version direct download from website

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:49.0) Gecko/20100101 Firefox/49.0
Comment 1 V Stuart Foote 2016-11-16 08:00:26 UTC
LibreOffice is not a PDF editor, you risk corruption of your PDF by treating it as such. We will not position it as such--WONTFIX

A few comments:

1. LibreOffice does not edit a PDF "directly", rather it is read by filter--an old filter will render elements of the PDF as Draw objects placed on pages of a Draw document (or into document pages of a Writer or Impress document if that filter configuration is picked). 

At 5.3.0 a new filter will treat the PDF as an image and insert the first page of the PDF as an image into Writer, Calc or Impress document.

2. All save/save-as or export from LibreOffice is likewise filter based. 

The internal document is written by filter and saved to a ODF format used for the module that opened the PDF.  

The option to Export from a module to PDF is a different filter than used for PDF import.

The OS and LibreOffice hold lock on the "opened" PDF--that is safest, but as you note is not the most convenient. But as LibreOffice is _not_ a PDF editor this is appropriate.
Comment 2 V Stuart Foote 2018-03-29 00:40:53 UTC
*** Bug 116686 has been marked as a duplicate of this bug. ***
Comment 3 Adrien 2018-03-29 03:39:15 UTC
Coming here from Bug 116686 https://bugs.documentfoundation.org/show_bug.cgi?id=116686:

I've yet to encounter any such corruption, either using export, or using the Print to functionality, but I understand why this was marked as WONTFIX, but then the bug isn't the lack of functionality (for very good reasons), but a poor UX handling of the situation.

A user should not be thrown an error without explanation or have to figure out options on their own. If you don't want people editing PDF's with LO, then don't allow them to edit PDF's with LO. Why is that functionality there at all? Why isn't the PDF imported as read only? What's the point?

Why not warn the user they'll have to export as a different file name, or how doing this at all risks the corruption you speak of?

This bug should be re-opened, at least with respect to how the error is handled with the user.
Comment 4 V Stuart Foote 2018-03-29 12:57:52 UTC
IMHO our avoidance of overwrite handling is correct, LibreOffice is not a PDF editor. Status quo since we merged the old Sun/Oracle PDF Import extension--and the WONTFIX is correct, but for UX do we need to hold users hands tighter?

Miklos, Stephan, David your thoughts on what we tell folks?
Comment 5 m.a.riosv 2018-03-30 09:35:29 UTC
Pherhaps opening pdfs as read only, this gives the already implmented choice, to open as read only or a copy, with the second option the pdf is unlocked, so it can be overwritten exporting as pdf.
Comment 6 Xisco Faulí 2018-04-03 11:54:50 UTC
Adding the UX team with regards to comment 3 and setting to UNCONFIRMED until a decision has been taken...
Comment 7 Heiko Tietze 2018-04-09 09:40:34 UTC
Taking Stuart's comment 1 for resolving as WF. Admittedly, users expect PDF editing where we refuse that.
Comment 8 Adrien 2018-04-09 15:06:33 UTC
The bug is that you *do* allow it, not refuse it.

Right now, a user can open a PDF with LO and Draw will open it with the ability to change and even export it. The only thing (to the user) that it can't do is overwrite on export and instead offers a non-helpful error message.

If you don't want to be a PDF editor - fine, no arguments there. But then only open PDF's as read-only. Remove the code that allows the user to make changes and de-activate the save and export functions in that case.

A regular user is going to sensibly understand that being able to open a PDF and make changes and then save those changes is thus 'editing' the PDF. (call it export or whatever you like, that is *irrelevant* to the user) A user would have a reasonable question that if LO is not a PDF editor, why is the functionality there?

The cause of this bug report being filed was precisely because this is mishandled - that is what needs to be fixed. Had the PDF been only opened read-only, there would have no occasion to file the bug. Do I need to file a separate bug for that, or is that too just going to be closed as 'wontfix'?
Comment 9 Heiko Tietze 2018-04-09 15:13:32 UTC
(In reply to Adrien from comment #8)
> Do I need to file a separate bug for that, or is that too 
> just going to be closed as 'wontfix'?

While I can follow your arguments the decision was made (don't know the reasons). Removing save capabilities also means you cannot export a text document as PDF.

You can reopen the ticket, I will not touch this status since input from UX has been given. As open source it's up to the developers to implement a feature. But be aware that QA has the final word about open tickets.
Comment 10 Adrien 2018-04-09 15:20:48 UTC
(In reply to Heiko Tietze from comment #9)
> (In reply to Adrien from comment #8)
> > Do I need to file a separate bug for that, or is that too 
> > just going to be closed as 'wontfix'?
> 
> While I can follow your arguments the decision was made (don't know the
> reasons). Removing save capabilities also means you cannot export a text
> document as PDF.
> 
> You can reopen the ticket, I will not touch this status since input from UX
> has been given. As open source it's up to the developers to implement a
> feature. But be aware that QA has the final word about open tickets.

Thank you, I appreciate the (very quick!) reply.
Comment 11 Aron Budea 2019-02-07 13:22:07 UTC
Seems like this is fixed now by Caolán's commit.

https://gerrit.libreoffice.org/plugins/gitiles/core/+/6a58859bf24c949e2531fffe5e999bcc868414c8%5E!
author		Caolán McNamara <caolanm@redhat.com>	Thu Feb 07 10:29:45 2019 +0000
committer	Caolán McNamara <caolanm@redhat.com>	Thu Feb 07 13:28:53 2019 +0100

Resolves: rhbz#1673198 cannot overwrite open file with export
Comment 12 Aron Budea 2019-02-07 13:25:09 UTC
(In reply to Aron Budea from comment #11)
> https://gerrit.libreoffice.org/plugins/gitiles/core/+/
> 6a58859bf24c949e2531fffe5e999bcc868414c8%5E!
Of course BZ fails to pick up the ending ! as part of the URL :(.
Comment 13 Stephan Bergmann 2019-02-07 13:28:31 UTC
(In reply to Aron Budea from comment #12)
> Of course BZ fails to pick up the ending ! as part of the URL :(.

It can only use some heuristics to determine what part of free text should or should not be part of a URL.  Help it along by enclosing URLs in <...>.
Comment 14 V Stuart Foote 2019-07-25 12:16:49 UTC
*** Bug 126532 has been marked as a duplicate of this bug. ***
Comment 15 Felipe 2020-03-14 23:17:59 UTC
Hi! My first time here, I think.

The following workaround works for me with Windows 10, LO Writer Version 6.4.1.2 (x64) Build ID: 4d224e95b98b138af42a64d84056446d09082932.

After I open the hybrid pdf file with LO Writer and do some edits, I just save (Ctrl-S, no Export) to a temporary odt file in the same folder as the original hybrid pdf file (and with the same file name, except the extension). I can save (Crl-S) any time I want.

At the end of the editing session, I Export (Directly) to (hybrid) PDF, and Windows does not complain that the file is being used by another application!

Finally I can also delete the temporary odt file (since the pdf file has it embedded).

This has the the added advantage for me that a Dropbox link to the hybrid pdf file keeps working.