When exporting to PDF the "Save to" dialog point to the latest used directory. It should instead (IMHO) point to the same location of the current opened document. This suggested behavior will save a lot user mouse clicks when using PDF export with multiple document in different folders.
This is an incredibly annoying bug -- I actually registered just to report this one. I suppose most developers don't use this feature on a regular basis, or there would certainly be more interest in fixing this, if there was more dogfooding on this one.
[This is an automated message.] This bug was filed before the changes to Bugzilla on 2011-10-16. Thus it started right out as NEW without ever being explicitly confirmed. The bug is changed to state NEEDINFO for this reason. To move this bug from NEEDINFO back to NEW please check if the bug still persists with the 3.5.0 beta1 or beta2 prereleases. Details on how to test the 3.5.0 beta1 can be found at: http://wiki.documentfoundation.org/QA/BugHunting_Session_3.5.0.-1 more detail on this bulk operation: http://nabble.documentfoundation.org/RFC-Operation-Spamzilla-tp3607474p3607474.html
Confirmed for libreoffice 3.5.0beta2, linux32, ubuntu 10.04
This bug is present in pretty much all "save as" or "file open" dialogs. It's old: already existed in early openoffice.org versions. I'll open a separate bug for different dialogs if that is better - please let me know. Below are a couple of cases that exhibit similar behaviour: LibreOffice remembers the last used directory for a certain action, which is very often the WRONG directory. It would be better, in my opinion, to start from the directory of the current document OR the current working directory when libreoffice was started from the commandline. Alternatively, it would make sense to only remember these folders during a session and forget them when the program is closed. Or, make it optional. Examples (I'm sure there are more): 1) File/open dialogs (for instance: insert picture from file) remember the last directory from which I have inserted a picture. Very often this has nothing to do with the current document. It takes a lot of effort to navigate back to the folder where the current document is. I suggest in this case to use the folder of the currently opened document as a starting point opening new files such as images. Possibly, after this folder has been changed _within the current session_, it could be remembered for the current document. 2) File->Open does a similar thing, but it remembers a DIFFERENT directory than insert->picture->from file. 3) file->save on a new document has a similar problem when started from commandline: go to directory a/b/c, start libreoffice (new document), save -> suggests home directory instead of a/b/c 4*) "File->Save As" DOES show the proper behaviour, starting at the current document's directory. It does not remember the last selected dir, apparently.
That last point (4*) should have read: "File->Save As" DOES show the proper behaviour when saving an existing document with a different name: it starts at the current document's directory.
I completely agree with Hein Zelle.. I'll test LibOO 3.5Beta2 soon
Is there any update on this one? It's been more than two years...
*** Bug 51149 has been marked as a duplicate of this bug. ***
*** Bug 48152 has been marked as a duplicate of this bug. ***
*** Bug 66996 has been marked as a duplicate of this bug. ***
*** Bug 67222 has been marked as a duplicate of this bug. ***
Strange... When I do File > Export as PDF, it does 100% of the times always and since ages give the same path (and name) as the docuent that I export. So.. interesting to find out what is going on in the other situations, reported here...
*** Bug 67000 has been marked as a duplicate of this bug. ***
(In reply to comment #1) > I suppose most developers don't use this feature on a regular > basis, or there would certainly be more interest in fixing this, if there > was more dogfooding on this one. While this request undoubtedly deserves proper attention, and I don't question that there are scenarios where the current behaviour is not optimal, I only want to describe the opposite scenario: when the current state is the desired one. Our organisation produces documentation for customers as PDFs. Each documentation set may consist of tens or hundreds of documents, and they are initially prepared as ODFs in a structured directory tree. When the final PDFs are created, they go to another dedicated output directory (on another server). It would be pain, if we needed to browse there for each document. The best is to browse there once (for first document), and then all subsequent PDFs go there, regardless of the ODF path. This is not restricted to one document, or one LO session. What I want to stress is that this may only be fixed by introducing a new option in settings, because simple change of the way it works, without a choice, will hurt other users.
*** Bug 69880 has been marked as a duplicate of this bug. ***
*** Bug 71968 has been marked as a duplicate of this bug. ***
As I suggested in #71968 (sorry for duplicate) there should be a button on the Export dialog with the following label: "Navigate to document's folder" The dialog should work as it is working now. That is, it should offer by default the folder in which the last pdf was saved. But the mentioned button could save us from navigating to the folder in which the ODT file is. Or, the opposite solution can be also good. It could offer by default the folder in which the ODT file is and a "Navigate to last pdf exporting directory" button could navigate into the folder in which I exported my last pdf file.
(In reply to comment #17) > It could offer by default the > folder in which the ODT file is and a .... Must be a Windows-only issue? For me, File > Export to PDF always gives the location of the actual file ..
For me it depends whether or not there is already a PDF in the target directory. So depending on this sometimes it suggests the same directory as the one the document is residing in; at other times it suggests the directory I last saved a pdf to.
Created attachment 99851 [details] attachment-10306-0.html Am 26.05.2014 09:32, schrieb bugzilla-daemon@freedesktop.org: > > *Comment # 19 <https://bugs.freedesktop.org/show_bug.cgi?id=34303#c19> > on bug 34303 <https://bugs.freedesktop.org/show_bug.cgi?id=34303> from > Alexander Mueller <mailto:xelarellum@web.de> * > For me it depends whether or not there is already a PDF in the target > directory. So depending on this sometimes it suggests the same directory as the > one the document is residing in; at other times it suggests the directory I > last saved a pdf to. > ------------------------------------------------------------------------ > You are receiving this mail because: > > * You are on the CC list for the bug. > I prefere the same directory as the one the document is residing in.
Created attachment 99852 [details] attachment-10306-1.dat
Created attachment 99853 [details] klaus_w_posner.vcf
- In many cases it is very convenient if the previous directory is offered as default, where the last pdf was saved. - In many other cases it's better to have the same directory where the odt (or whatever original file) is. That's why I suggested to offer the last pdf-exporting directory as default (this is the present behaviour) and have a "Navigate to the document's directory" button.
So this is a bug on Windows (I can't check) For comment #14, Mike (and others about the same): I understand the idea. Pls file an enhancement for that.
With version 4.3.0.4, windows XP SP3, I do not reproduce this issue. Export to pdf always save to the original document dir. Maybe this is fixed already? Could someone check? P.S.: I added Klaus Langguth to cc list of this bug. He claimed this same bug behaviour on MAB4.2.
(In reply to comment #25) Please ignore my comment in #25. I reproduce this in Windows 7, LibreOffice 4.3.1.1.
Set version to 4.3.0.4, as there is no 4.3.1.1 in the list. Someone should set it to an earlier version when confirm it's reproducible in that version.
Per bug 71968, set version to 4.0.4.2.
I can confirm this bug. It seems to me the problem is specific for VistaFilePickerImpl. It does not happen on Windows XP neither with internal LibreOffice file picker. Also, this is not specific to PDF. Command File|Export does not set directory to document's directory either.
(In reply to pavel.lastovicka from comment #29) > I can confirm this bug. It seems to me the problem is specific for > VistaFilePickerImpl. It does not happen on Windows XP neither with internal > LibreOffice file picker. > > Also, this is not specific to PDF. Command File|Export does not set > directory to document's directory either. That would suggest a duplicate of bug 37814 (as I would have assumed from the previous comments, too), but I got private mail lately that claims that this export-to-PDF--specific wrong-save-as-dir issue is /not/ solved with recent LO nightlies that /do/ contain a fix for the general wrong-save-as-dir in case of non-ASCII characters bug 37814.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.0.4 or later) https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT: - Update the version field - Reply via email (please reply directly on the bug tracker) - Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-01-17
Confirmed fixed in LibreOffice 4.4.6.3. Steps to reproduce in Windows (on Mac it was fixed a long time ago; not sure about Linux): 1. Create a new folder, thus ensuring you have no previous history pointing to that folder 2. Copy a LibreOffice document to the new folder 3. Open the document from the new folder 4. From the main menu, File -> Export to PDF If the bug was fixed in your version of LibreOffice, then LibreOffice will display the Save file dialog with the new folder opened initially (this is what I found). If the bug was not fixed, LibreOffice will display the Save file dialog with some old folder opened initially (wherever you last exported a PDF file).
Sorry but this bug isnt solved yet. It still does not work. The files opened within LO can not be saved as pdfs in the same folder as the orignial file was. This is very anoying bug as export pdfs is a important feature. It will not work on windows 7 nor on windows 10. Please fix it. Thank you so much Klaus
The bug is still present and it is not solved. Saving pdfs within the same folder of the opened file will not work. LO saves it somewhere else. This is a very anoying bug as pdfs saving is a main feature of LO. We use W7 / W10 home an pro versions. None works. Please fix that Thank you Klaus
This behaviour is already present in Open Office version 3.3.0. Setting the version accordingly (earliest version where the problem occurs). I also experience it on my linux box connected to a windows network.
*** Bug 100881 has been marked as a duplicate of this bug. ***
*** Bug 101750 has been marked as a duplicate of this bug. ***
I have update to last version: --------- Versione: 5.1.5.2 (x64) Thread CPU: 4; Versione SO: Windows 6.19; Versione locale: it-IT (it_IT); -------- but the bug is present yet
The problem still persists and it is still frustrating. Version 5.3.1.2 Win 7 (x64)
Confirmed with LibreOffice 5.4.0.3 x64 in Windows 10 x64. In my opinion, it is a very annoying issue and should be addressed. In the meantime, as a shortcut to addressing this inconvenience, I try to Save As first, copy the path from the top of the Save As dialog box, Cancel, Export to PDF, paste the path at the top of that dialog box, and then save/export the PDF.
This bug is still in LO 6.0.1. It is super annoying because in 99% of the cases one wants the PDF on the same folder than the opened file. Moreover this bug leads to lot of troubles: I work on project A and export a PDF then I work on project B and export. As default export folder is still the one of project A I often accidentally export to that instead of the folder of project B.
@timur: You changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|medium |high Summary|PDF export location is not |PDF export location should |the path of the original |have option in settings to |file but a different folder |set path of the original |(last used for |file, last path used for |save/export/..) |save/export/.. or home | |directory OS|Windows (All) |All As far as I'm aware, there is a problem on Windows. As the previous summary & OS showed. By changing this all in an enhancement effectively, the problem becomes a bit hidden, I'm afraid.
This problem is also occurring on Linux. This is new behavior, probably started with the latest version. Previously, exporting a document to PDF would bring up a file dialogue with the current directory selected. Now it pulls up the home directory EVERY time, regardless of whether or not a PDF was exported to a different directory in the same session. Something changed the original behavior.
I think this is wider than PDF export and a bug that entered around 6.05. I've added a bug report on it https://bugs.documentfoundation.org/show_bug.cgi?id=119754
If this was first reported in 2011, I don't see why it's regarded as 'new.' THis very basic bug still needs fixing. When 'directly exporting' as a pdf, Libraoffice still points to the last saved directory, rather than the one in which the present file is in.
(In reply to jane from comment #43) > This problem is also occurring on Linux. This is new behavior, probably > started with the latest version. Previously, exporting a document to PDF It's still OK for me on Linux. Version: 6.2.0.0.alpha0+ Build ID: 8c20d5d4ad6f3e8c672337e3ba67be45a1ccb7c2 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2018-09-14_02:29:28 Locale: nl-NL (nl_NL.UTF-8); Calc: threaded Versie: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b CPU-threads: 4; Besturingssysteem: Linux 4.15; UI-render: standaard; VCL: gtk2; Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded so there is a situation that triggers this?
The issue here and in all valid duplicates has been Windows os/DE only and is caused by implementation issues in the Windows native VistaFilePickerImpl() module. Toggling "false" the 'UseSystemFileDialog' (now moved to Expert configuration) will launch the native LO dialog which has never mishandled file paths for PDF creation. Recent linux os/DE filemanager specific issues, e.g. bug 119133 and duplicates have had issues with DE integration with file management--those are distinct to this MS Windows os/DE module Restoring to Windows only here, and resetting as bug rather than enhancement.
Would respectfully suggest something similar to the 'always save a backup copy' function in Tools>Options/Load/Save. Suggest having an option to 'Always save a pdf copy next to original.' This would save a lot of clicking and navigating around directories whenever a user wishes to save a pdf version of their text file.
*** Bug 119968 has been marked as a duplicate of this bug. ***
(In reply to Stephen from comment #48) > Would respectfully suggest something similar to the 'always save a backup > copy' function in Tools>Options/Load/Save. Suggest having an option to > 'Always save a pdf copy next to original.' This would save a lot of clicking > and navigating around directories whenever a user wishes to save a pdf > version of their text file. I upvote it.
This issue persists in Windows up through 2019-08-14 and ver 6.1.5.2
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
(In reply to thePanz from comment #0) > When exporting to PDF the "Save to" dialog point to the latest used > directory. It should instead (IMHO) point to the same location of the > current opened document. reproducible with: Version: 6.3.4.2 (x64) Build-ID: 60da17e045e08f1793c57c00ba83cdfce946d0aa CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: but no longer reproducible with: Version: 6.4.0.2 (x64) Build-ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3 CPU-Threads: 4; BS: Windows 10.0 Build 18363; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: "Save to" dialog now points to the same location of the current opened document. https://bugs.documentfoundation.org/show_bug.cgi?id=43021#c58
As Status field explains, Fixed is only with known commit, so if this is resolved it should be marked WorksForMe. For such a long standing bug with many users, it was better just to write observation and call others to test. Please test and if reproducible with 6.4.0.2, feel free to set New again.
Believe this was fixed by Jan-Marek's work on the VistaFilePicker() for bug 43021 master with dev comments https://gerrit.libreoffice.org/c/core/+/83409 back port to 6.4.0.1 https://gerrit.libreoffice.org/c/core/+/83839 But, looks to have result in bug 129886