Bug 34303 - VistaFilePickerImpl () - PDF export location is not the path of the original file but a different folder (last used for save/export/..) workaround comment 47
Summary: VistaFilePickerImpl () - PDF export location is not the path of the original ...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: All Windows (All)
: high normal
Assignee: Not Assigned
URL:
Whiteboard: target:6.5.0 target:6.4.0.1
Keywords: filter:pdf
: 48152 51149 66996 67000 67222 69880 71968 100881 101750 119968 (view as bug list)
Depends on: 114484 43021
Blocks: LO-File-Dialog PDF-Export-File-Dialog
  Show dependency treegraph
 
Reported: 2011-02-15 09:38 UTC by thePanz
Modified: 2020-05-05 19:07 UTC (History)
25 users (show)

See Also:
Crash report or crash signature:


Attachments
attachment-10306-0.html (1.79 KB, text/html)
2014-05-26 09:28 UTC, Posy
Details
attachment-10306-1.dat (1 bytes, multipart/alternative)
2014-05-26 09:28 UTC, Posy
Details
klaus_w_posner.vcf (147 bytes, text/x-vcard)
2014-05-26 09:28 UTC, Posy
Details

Note You need to log in before you can comment on or make changes to this bug.
Description thePanz 2011-02-15 09:38:13 UTC
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.
Comment 1 Bogdan Stăncescu 2011-12-13 15:35:24 UTC Comment hidden (me-too)
Comment 2 Björn Michaelsen 2011-12-23 11:44:59 UTC Comment hidden (obsolete)
Comment 3 Hein Zelle 2011-12-29 04:09:34 UTC
Confirmed for libreoffice 3.5.0beta2, linux32, ubuntu 10.04
Comment 4 Hein Zelle 2011-12-29 04:19:47 UTC
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.
Comment 5 Hein Zelle 2011-12-29 04:21:52 UTC
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.
Comment 6 thePanz 2011-12-29 04:37:16 UTC
I completely agree with Hein Zelle.. I'll test LibOO 3.5Beta2 soon
Comment 7 Bogdan Stăncescu 2013-03-01 22:00:13 UTC Comment hidden (no-value)
Comment 8 ign_christian 2013-07-18 04:11:51 UTC
*** Bug 51149 has been marked as a duplicate of this bug. ***
Comment 9 ign_christian 2013-07-18 04:13:08 UTC
*** Bug 48152 has been marked as a duplicate of this bug. ***
Comment 10 ign_christian 2013-07-18 04:13:49 UTC
*** Bug 66996 has been marked as a duplicate of this bug. ***
Comment 11 bfoman (inactive) 2013-07-23 16:05:07 UTC
*** Bug 67222 has been marked as a duplicate of this bug. ***
Comment 12 Cor Nouws 2013-07-23 16:40:49 UTC
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...
Comment 13 ign_christian 2013-09-28 02:17:38 UTC
*** Bug 67000 has been marked as a duplicate of this bug. ***
Comment 14 Mike Kaganski 2013-09-28 05:34:00 UTC
(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.
Comment 15 Mike Kaganski 2013-09-28 09:12:36 UTC
*** Bug 69880 has been marked as a duplicate of this bug. ***
Comment 16 bfoman (inactive) 2013-11-24 18:37:32 UTC
*** Bug 71968 has been marked as a duplicate of this bug. ***
Comment 17 csongor 2013-11-25 02:27:37 UTC
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.
Comment 18 Cor Nouws 2013-11-25 22:01:38 UTC
(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 ..
Comment 19 Alexander Mueller 2014-05-26 07:32:10 UTC
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.
Comment 20 Posy 2014-05-26 09:28:48 UTC
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.
Comment 21 Posy 2014-05-26 09:28:49 UTC
Created attachment 99852 [details]
attachment-10306-1.dat
Comment 22 Posy 2014-05-26 09:28:49 UTC
Created attachment 99853 [details]
klaus_w_posner.vcf
Comment 23 csongor 2014-05-26 11:33:51 UTC
- 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.
Comment 24 Cor Nouws 2014-06-22 15:08:30 UTC
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.
Comment 25 Kevin Suo 2014-08-01 09:28:29 UTC Comment hidden (obsolete)
Comment 26 Kevin Suo 2014-08-15 03:00:10 UTC Comment hidden (obsolete)
Comment 27 Kevin Suo 2014-08-15 03:02:19 UTC Comment hidden (obsolete)
Comment 28 Kevin Suo 2014-08-15 03:04:36 UTC Comment hidden (obsolete)
Comment 29 pavel.lastovicka 2015-01-07 16:59:12 UTC
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.
Comment 30 Stephan Bergmann 2015-01-14 16:45:19 UTC
(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.
Comment 31 QA Administrators 2016-01-17 20:03:18 UTC Comment hidden (obsolete)
Comment 32 Bogdan Stăncescu 2016-01-20 12:26:53 UTC
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).
Comment 33 Klaus Langguth 2016-01-21 10:55:47 UTC
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
Comment 34 Klaus Langguth 2016-01-21 10:58:39 UTC
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
Comment 35 Stephan van den Akker 2016-03-11 18:23:20 UTC
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.
Comment 36 Adolfo Jayme Barrientos 2016-07-12 21:56:09 UTC
*** Bug 100881 has been marked as a duplicate of this bug. ***
Comment 37 Cor Nouws 2016-08-27 09:46:35 UTC
*** Bug 101750 has been marked as a duplicate of this bug. ***
Comment 38 rominafk 2016-09-23 16:55:04 UTC
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
Comment 39 Dale 2017-04-11 03:12:45 UTC
The problem still persists and it is still frustrating.
Version 5.3.1.2
Win 7 (x64)
Comment 40 John A. Paravantis 2017-08-09 12:30:35 UTC
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.
Comment 41 muso 2018-02-16 19:32:35 UTC
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.
Comment 42 Cor Nouws 2018-05-03 10:05:52 UTC
@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.
Comment 43 jane 2018-07-25 17:00:40 UTC
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.
Comment 44 putt1ck 2018-09-08 05:10:59 UTC
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
Comment 45 Stephen 2018-09-18 06:53:19 UTC Comment hidden (me-too)
Comment 46 Cor Nouws 2018-09-18 11:54:04 UTC
(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?
Comment 47 V Stuart Foote 2018-09-18 13:27:46 UTC
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.
Comment 48 Stephen 2018-09-19 09:03:36 UTC
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.
Comment 49 Dieter 2018-09-19 09:23:20 UTC
*** Bug 119968 has been marked as a duplicate of this bug. ***
Comment 50 Kaue 2018-10-01 01:04:23 UTC
(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.
Comment 51 wpeaton4 2019-08-14 17:22:22 UTC
This issue persists in Windows up through 2019-08-14 and ver 6.1.5.2
Comment 52 Xisco Faulí 2019-12-03 10:19:45 UTC
Changing priority to 'high' since the number of duplicates is higher than 5 or the number of people in CC higher than 20
Comment 53 Oliver Brinzing 2020-01-12 08:08:49 UTC
(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
Comment 54 Timur 2020-01-12 09:25:21 UTC
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.
Comment 55 V Stuart Foote 2020-01-12 14:31:47 UTC
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