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
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.
*** Bug 116686 has been marked as a duplicate of this bug. ***
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.
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?
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.
Adding the UX team with regards to comment 3 and setting to UNCONFIRMED until a decision has been taken...
Taking Stuart's comment 1 for resolving as WF. Admittedly, users expect PDF editing where we refuse that.
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'?
(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.
(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.
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
(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 :(.
(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 <...>.
*** Bug 126532 has been marked as a duplicate of this bug. ***
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.
Thanks for this information. I really appreciate the information that you have provided. https://www.omegle.fyi/ https://www.chatrandom.one/ https://www.bazoocam.fyi/
I have encountered a similar issue with Libre office before and it is a fixable issue. <a href="https://www.loonyheads.com/digital-marketing-company-kerala/">Best digital marketing agency in Kerala</a>. hope you are also able to fix it