Description: PDFs are exported to the most recently directory and not to the document's directory. Correct in 25.2.1.2 Wrong in 25.2.2.1 Steps to Reproduce: 1.Click the "export to PDF" toolbar icon Actual Results: The most recently used directory opens Expected Results: The document's directory opens Reproducible: Always User Profile Reset: No Additional Info: I reverted to LO 25.2.1.2 from 25.2.2.1 and the behaviour is correct again.
I can't reproduce. Please detail step by step how the issue is reached. Please test in safe mode, Menu/Help/Restart in Safe Mode
I am also affected at work on Windows. Pressing PDF icon would generate a copy of the document in PDF in the current folder. Now it's anywhere but not the document folder.
On my linux is still ok Version: 25.2.1.1 (X86_64) / LibreOffice Community Build ID: e538fb6403facdfd3db0250c3b3278236c675c2a CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded But I noticed the problem at work, on Windows. I often generate some reports in a certain folder. I open documents, edit, export the PDF (usually the PDF being generated in the same folder), then I send all the PDF from the active folder to clients. Now I have to choose each time the correct folder for the exported PDF.
I would bibisect this, but it is Windows only. I can't.
I came back to 24.8 on Windows but I have the same problem. Could be a Windows update that broke that option? Version: 24.8.6.1 (X86_64) / LibreOffice Community Build ID: 051bf11303684a0a982c9966e8be766d0a9efbc7 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ro-RO (en_US); UI: en-US Calc: threaded
LibreOffice 25.2.2.2 Writer on Windows 10 hast the same problems.
Confirm with Version: 24.8.6.2 (X86_64) / LibreOffice Community Build ID: 6d98ba145e9a8a39fc57bcc76981d1fb1316c60c CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ro-RO (en_US); UI: en-US Calc: threaded But could be a Windows bug, not a LibreOffice one. Should be investigated.
OpenOffice 4.1.15 on Windows 10 works as expected.
LibreOffice 24.2.7.2 on Windows 10 works as expected :-) Maybe someone changed the Windows version of the code which constructs the path of the current document? That wouldn't cause problems on Linux. Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 4; OS: Windows 10.0 Build 17763; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded
I was using 25.2 last month and was ok. This is the reason I suspect Windows to be the cause. Now I moved back to 24.8, but useles, it is the same. I prefer now the stable (still) version of LibreOffice.
At work: Windows 11, LibreOffice 25.2.2.2, PDF exports to recent folder (unwanted behavior) At home: Windows 11, LibreOffice 25.2.1.2, PDF exports to document folder (wanted behavior)
(In reply to henrik.ericson from comment #11) > At work: Windows 11, LibreOffice 25.2.2.2, PDF exports to recent folder > (unwanted behavior) > At home: Windows 11, LibreOffice 25.2.1.2, PDF exports to document folder > (wanted behavior) In 25.2.2.2 version from work, please go to Help - About and copy info from there. Should be a link with all the changes for 25.2.2.2.
*** Bug 165967 has been marked as a duplicate of this bug. ***
bisected with linux-64-25.2 commit 67cffdf1b2872b4bcac657f7bcf63f19c261a5c6 author Samuel Mehrbrodt <samuel.mehrbrodt@allotropia.de> Thu Feb 13 09:55:04 2025 +0100 tdf#165228 Don't reuse previous path in save dialog
Samuel, please take a look at this bug. My current workflow is this: I open a folder with some documents, I edit, save and export as PDF, then try to export the PDF to clients. I expect as before that a document will be created in the folder I am in at the moment. In fact, the PDF will go to the most recent folder where I have something else, not related with what I am doing. So I have to change the folder in order to export the PDF. Then, I change the current working folder, and edit another file, and repeat all the steps, and again I have to change the folder where the exported PDF will go.
More, many apps (WhatsApp, email) allows you to drag and drop documents from current folder. But I do not have what I need in the current folder, if I am in a hurry and did not read where the PDF was exported, I will send an old version of the PDF, if there was one.
Created attachment 200094 [details] video testing the bug I have created a video with both behaviors. In the first minute is the old behavior, is very easy, you get the folder where you work. In the last minute, you can see I have to change each time the folder I need to export.
So this works as designed. If there a are other workflows where the current implementation is not ideal, there are two possibilities: 1. Create a macro which does exactly what you want it to do, and replace the current Save/Export/... action with your macro 2. File an enhancement request with a specific proposal what should be changed In any case, this is not a bug and not a regression.
This is the macro exporting a PDF in the current folder: Sub ExportToPDF() Dim oDoc As Object Dim sURL As String Dim sFilePath As String Dim sPDFPath As String oDoc = ThisComponent If oDoc.hasLocation Then ' Get the document's directory sURL = oDoc.getURL() sFilePath = ConvertFromURL(sURL) If sFilePath = "" Then MsgBox "Error: Could not determine file path.", 48, "Error" Exit Sub End If sFilePath = Left(sFilePath, Len(sFilePath) - Len(GetFileName(sFilePath))) ' Define PDF file path sPDFPath = sFilePath & GetFileNameWithoutExtension(sURL) & ".pdf" ' Export to PDF Dim aProps(1) As New com.sun.star.beans.PropertyValue aProps(0).Name = "FilterName" aProps(0).Value = "writer_pdf_Export" oDoc.storeToURL(ConvertToURL(sPDFPath), aProps()) MsgBox "Document exported to: " & sPDFPath, 64, "Export Successful" Else MsgBox "Please save the document before exporting.", 48, "Error" End If End Sub Function GetFileName(sFilePath As String) As String If sFilePath = "" Then Exit Function Dim sName As String Dim i As Integer i = LastIndexOf(sFilePath, "\") If i = 0 Then i = LastIndexOf(sFilePath, "/") ' Handle UNIX-style paths If i > 0 Then sName = Mid(sFilePath, i + 1) Else sName = sFilePath End If GetFileName = sName End Function Function GetFileNameWithoutExtension(sFilePath As String) As String Dim sName As String sName = GetFileName(sFilePath) If sName = "" Then Exit Function Dim i As Integer i = LastIndexOf(sName, ".") If i > 0 Then sName = Left(sName, i - 1) End If GetFileNameWithoutExtension = sName End Function Function ConvertFromURL(sURL As String) As String If sURL = "" Then Exit Function ConvertFromURL = Replace(sURL, "file://", "") ConvertFromURL = Replace(ConvertFromURL, "/", "\") ' Ensure Windows-style path End Function Function ConvertToURL(sFilePath As String) As String If sFilePath = "" Then Exit Function ConvertToURL = "file://" & Replace(sFilePath, "\", "/") ' Ensure URL-style path End Function Function LastIndexOf(text As String, character As String) As Integer Dim i As Integer For i = Len(text) To 1 Step -1 If Mid(text, i, 1) = character Then LastIndexOf = i Exit Function End If Next i LastIndexOf = 0 End Function
Created attachment 200101 [details] the only change on many machines
(In reply to Samuel Mehrbrodt (allotropia) from comment #18) > So this works as designed. ... > In any case, this is not a bug and not a regression. Sorry, that's wrong. I've tested several different machines (see below) with CALC. Until Friday, the behavior on all machines was: Export PDF to the same directory as the CALC file. Then, three Windows devices received an update from 25.2.1.2 to 25.2.2.2 via winget-autoupdate (see uploaded image). This was the only change - no Windows updates, no settings changed, no user change! Since then, the behavior on these three machines (2x Win 11, 1x Win 10) has been: Export PDF to the last directory used for export. Please check again if there has been a code change where org.openoffice.Common:LastDirectory['ClacSaveAs'] and ['CalcExport'] may have been swapped. Or explain to me why the standard behavior you claim did NOT work from version 7.4.7.2 to 25.2.1.2 and nobody has reported this alleged misbehavior so far - but several people are now reporting it because the previous behavior has changed. ============= OLD BEHAVIOR: Version: 7.4.7.2 / LibreOffice Community Build ID: 40(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 1:7.4.7-0ubuntu0.22.10.1~bpo20.04.1 Calc: threaded Version: 25.2.1.2 (X86_64) / LibreOffice Community Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded NEW BEHAVIOR: Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 12; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: threaded Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: de-DE (de_DE); UI: de-DE Calc: CL threaded
This is not a Windows only bug, I experience this in Linux as well (Manjaro, if that matters). This is very annoying, especially since this worked (export to directory where original file resides) for *many many* years, I consider this as a feature not a bug. I would suggest, if I can ofc, to revert that commit and create an enhancement request like "Always force save-as/export dialog to use default directories" or smth along those lines. --------------------------------- Version: 25.2.2.2 (X86_64) / LibreOffice Community Build ID: 520(Build:2) CPU threads: 8; OS: Linux 6.13; UI render: Skia/Raster; VCL: kf6 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US 25.2.2-1 Calc: threaded ---------------------------------
"So this works as designed." Samuel, I have seen similar software opening the most recent folder. BUT, can this option be made customizable through advanced settings or settings somehow. It was a bug, but everyone loved it as a bug. It's one of the most loved bugs that were sadly fixed. If the difference is one line of code, could this line of code be accesible from a setting?
Hm, same behavior for Save As. In 25.2.1.2 default folder is the current documents folder. In 25.2.2.2 default folder is last saved folder.
I can confirm on *Linux* that the PDF export goes to the last used directory at least since version 25.2.2.x. PDF export always went to the current directory by default in older versions. So this is a regression, a very serious regression, and needs an emergency fix. I have hundreds of Libreoffice documents spread all over a directory tree with several hundred directories, five levels deep. For each LO document, there is a corresponding PDF file in the same directory. As common in Linux, I start editing documents from the command line, not by the "Open" dialog. Documents are edited and exported in random order, so the current dirctory never corresponds to the last directory, and hence all PDF exports go to the wrong directory since 25.2.2.x, far away from the current directory. Moreover, I found no quick way in the file dialog to select the current directory with a single click. Changing to the current directory in a deep and wide directory tree requires many clicks, and even worse, it requires typing into the filename/folder field (because I found no way to go to the parent directory by clicking?) So this is really a desaster!
*** Bug 166017 has been marked as a duplicate of this bug. ***
*** Bug 166022 has been marked as a duplicate of this bug. ***
Will have a look at this next week.
> So this works as designed. > If there a are other workflows where the current implementation is not ideal, there are two possibilities: > 1. Create a macro which does exactly what you want it to do, and replace the current Save/Export/... action with your macro > 2. File an enhancement request with a specific proposal what should be changed > In any case, this is not a bug and not a regression. Please, let others respectfully disagree. The previous behavior was as intended: making it easy to export the PDF side to side to the original document, which I guess was part of the design of the PDF export feature in first place. I believe that it is bug 165228 that should not have been treated as a bug but as an enhancement request. To see why, please consider that OpenOffice, from which LibreOffice derives, has supported exporting to PDF since OpenOffice.org 1.1, which was released in October 2003. So, for approximately 22 years, no one complained about the fact that it was making it easy to export PDFs side to side to their corresponding editable documents, which is evident from the fact that bug 165228 was opened in 2025, and certainly not marked as a duplicate of some previous complaint. Now, if bug 165228 had been treated as an enhancement request, then your needs would have been fixed without breaking the workflow of others, by adding some new behavior, rather than replacing some existing behavior on which workflows had consolidated. There are various possibilities, just to mention two of them: - the file dialog is modified to add a button to quickly select the current document location, so you can default to the last location, or viceversa add a button to quickly select the last location so that you can default to the current document location (might be complicated, given that the software relies on many different toolkits for the save dialog); - the PDF options dialog that appears before the file dialog is augmented with an extra section "Export location" with a tickbox: "Side to side to current document" assuring that the file dialog is not opened at all and that the document is saved side to side to the current document, with the same name and the extension changed to .pdf. Trying to get back the well acceded behavior with a macro, is not acceptable, unless: 1. The macro is made easy to install, e.g. via an extension. 2. The install process for the macro can be told to replace the File→Export to PDF dialog entry or to add a similar entry side to side to this. 3. Most important, the possibility of entering the PDF export properties via the regular dialog (e.g., if you want to export to PDF/A, what kind of image compression you want, etc.) is completely preserved.
Interesting discussion. I hope this gets fixed. Having files from one client get exported to another client's folder does not seem like a good design choice! It is at best embarrassing, and at worst a legal disaster given that clients view folders in real time. Thanks Derek
> Having files from one client get exported to another client's folder does > not seem like a good design choice! The same from me, I exported PDF in the wrong folders (on Windows the path where the file is exported looks similar, that area is 4 words only, so for me it looks correct when expoerted) and I send them the wrong ones.
*** Bug 166034 has been marked as a duplicate of this bug. ***
Hello, Here on GNU/Linux Debian 12 with Cinnamon, after upgrading to LibreOffice version 25.2.2.2, I'm experiencing the same issue — but not only with the Export to PDF function. More critically, the regular Save As... function is also affected. This is quite frustrating (in case it's considered an intentional change), because when working on a new version of an existing document, the file ends up saved in an unexpected location — often the generic "Documents" folder. This causes confusion, and I often have to spend time investigating where the file actually went. :/ Thank you to the development team for the amazing work on LibreOffice. I kindly ask: could you please fix this bug soon, so we can rely on an upcoming update — rather than having to mess around with downgrades or apt-mark hold and similar workarounds? Best regards, Serge
There was a question on Japanese Ask about this issue where the default settings for saving were changed. He wants that it go back to the previous behavior. I also think that the previous behavior is easier for many users to use. https://ask.libreoffice.org/t/25-2-1-25-2-2/120258
We also have requests on Ask/fr category to return to the previous behavior which was a much better and practical workflow.
Calc not saving in originating folder when doing Save as https://ask.libreoffice.org/t/calc-not-saving-in-originating-folder-when-doing-save-as/120349
Default "export pdf" folder (Dossier par défaut "export Pdf") https://ask.libreoffice.org/t/dossier-par-defaut-export-pdf/120437
*** Bug 166082 has been marked as a duplicate of this bug. ***
Libreoffice does not remember location for each document file https://ask.libreoffice.org/t/libreoffice-does-not-remember-location-for-each-document-file/120581
(In reply to nobu from comment #39) > Libreoffice does not remember location for each document file > > https://ask.libreoffice.org/t/libreoffice-does-not-remember-location-for- > each-document-file/120581 I'm not sure what the author of 120581 really wants. I think he wants the following: If he has several LO windows/documents open in parallel, in each window the "save as" dialog should present the folder from which the document in *this* window was loaded. even if each window's document comes from a different location. This is what we all want, and what this bug is about, and what LO did until now (except for the latest version). He complains that now, "save as" in each window defaults to the *same* single location, namely the location the last "save as" saved into, not the location of the document being saved. That's what we all complained. There is no need to "remember" the location for each document file. Whenever "save as" (or "export pdf") is opened, just query the location of the current document (the one being saved / exported) and use that location for the dialog (as it always has been done).
For anyone using Flatpak, while we wait for this to be fixed, you can sudo flatpak update --commit=58b1760056dafe56e380e1eac0d75aa6ca36cea38db5727c196389349a20f196 org.libreoffice.LibreOffice This takes you back to the last version before the bug was introduced. Regards, d
*** Bug 166115 has been marked as a duplicate of this bug. ***
*** Bug 166114 has been marked as a duplicate of this bug. ***
*** Bug 166119 has been marked as a duplicate of this bug. ***
I really missed the old behaviour, especially for Save As... The behaviour of LibreOffice 25.2.2.2 is very inconvenient when you have to work with documents from many projects (many folders) at the same time.
The following report may be related to this defect. Libreoffice is deleting our work https://www.reddit.com/r/libreoffice/comments/1jvv3p0/libreoffice_is_deleting_our_work/
Samuel Mehrbrodt committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 tdf#165917 Improve Export directory pre-selection It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
New behavior: When calling an Export dialog (PDF, epub, ...) the following folder will be preselected: For stored documents: * Current document directory * If another directory was chosen for the export, that directory will be preselected for subsequent exports (stored only during runtime - per document) For unstored documents: * The last used export directory is restored (last used in unsaved doc) Hope this fixes the issue for you guys.
I am building now LibreOffice with your last change. And in some hours I will test. Thanks for updating the code, Samuel.
It seems fixed for me. The first export location for a saved file is in the current folder. If the user wants another location to export multiple times, it will be remembered. Samuel, can this be backported to avoid new reports? And thanks for fixing this annoying bug. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 3fa39a4dadc8e2777185465a6f7c9968c8cf44d1 CPU threads: 16; OS: Linux 6.11; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Same issue on Ubuntu 24.04 using the LibreOffice 25.2.2.2 Flatpak. I don't think this should be intended behaviour. Derek's solution worked for me > sudo flatpak update > --commit=58b1760056dafe56e380e1eac0d75aa6ca36cea38db5727c196389349a20f196 > org.libreoffice.LibreOffice
(In reply to Samuel Mehrbrodt (allotropia) from comment #48) > New behavior: > > When calling an Export dialog (PDF, epub, ...) the following > folder will be preselected: > > For stored documents: > * Current document directory > * If another directory was chosen for the export, > that directory will be preselected for subsequent exports > (stored only during runtime - per document) > > For unstored documents: > * The last used export directory is restored (last used in unsaved doc) Please also make the 'Save as' and 'Save a copy' dialogues work in the same way as 'Export'.
*** Bug 166168 has been marked as a duplicate of this bug. ***
*** Bug 166151 has been marked as a duplicate of this bug. ***
Could you please backport this to 25.2 too? 25.8 is 4-5 months away. (Or maybe revert the change in 25.2 back to the original behaviour)
*** Bug 166224 has been marked as a duplicate of this bug. ***
(In reply to Ninjoe from comment #55) > Could you please backport this to 25.2 too? > 25.8 is 4-5 months away. > > (Or maybe revert the change in 25.2 back to the original behaviour) Yes please, as I would call this a severe hindrance in my daily work. Because most of the time I either overlook tat it's the wrong directory I have saved the file or I just can't remember it.
I'd also like to see this fixed or reverted as soon as possible.
@Samuel, Xisco, * Comment 47, https://gerrit.libreoffice.org/c/core/+/184062 only in master for a 25.8 release. Kind of leaves folks on 25.2.2 and 24.8.6 hanging. Suspect a workup of a backport to 25.2.3 (or.4), and maybe also get a backport in and tested for a 24.8.7, would be appropriate and would be appreciated by users.
*** Bug 166244 has been marked as a duplicate of this bug. ***
*** Bug 166257 has been marked as a duplicate of this bug. ***
How can I return to the last working version ? (or get a patch) LO is really a huge pain to use with this bug.
This arbitrary change of behaviour is a major regression to me as well: my workflow is severely affected. Please fix quickly, or at least provide an option for the user to choose.
I don't believe this bug should be closed yet. The author reported it for 25.2. The affected versions are both 24.8 and 25.2. These are the current versions most people are using. I would like to suggest reverting the patch for these current versions. This would restore the previous behaviour that users expect and are accustomed to. An improved behaviour could then be introduced in version 25.8, allowing for more thorough testing.
Can you clarify what the "better behavior" would be ? "File - Save as" pointing to any OTHER directory than the document's original location would be a show-stopper IMO. In general, it would be useful to ask actual users before changing important features, or maybe have a significant panel of intensive users beta testing, and in any case communicate about the future features ! One bad thing I didn't report : a document protected by a password, when edited by 25.x becomes impossible to open with prior versions ! At least, a warning when saving the document with 25.x would have been a minimal safety ? I would prefer to see efforts spent on key features that don't work as they should (like formatting of bulleted lists, or styles recording that don't quite work etc) But I digress...
I think the improved behaviour the devs are working on in 25.8 is to default to the open document' s folder when the document was first opened. Then if you "Save As..." or "Export" to different folder, it will remember the new folder (for this particular open document). I might be wrong though, haven't try the alpha.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/446fe1d1b85ee98a4b8146c921e7eea22ed7e3a5 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 25.2.4. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-25-2-3": https://git.libreoffice.org/core/commit/041ccc2af2406884f3b1f5efc6bdb51952db5c8c tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 25.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/2490fe156ea14f2ee92fd08e901eed8df9f8c9f4 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 24.8.8. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 166331 has been marked as a duplicate of this bug. ***
I checked that the 25.2.4 nightly build does fix : * The cursor movement within justified paragraphs and line breaks * the Save as, Export, etc issue. But know I have two LO installed :-( with LibreOfficeDev. Is there a way to apply the fix to the "normal" LO version ?
(In reply to Bert Cuzeau from comment #71) > But know I have two LO installed :-( with LibreOfficeDev. > Is there a way to apply the fix to the "normal" LO version ? Here is the schedule of LibreOffice updates for version 25.2: https://wiki.documentfoundation.org/ReleasePlan#25.2_release 25.2.3 will be released next week.
Aron Budea committed a patch related to this issue. It has been pushed to "libreoffice-24-8-7": https://git.libreoffice.org/core/commit/beb328011725b3243ab03e8afe26fe2e43ecede5 tdf#165917: Revert "tdf#165228 Don't reuse previous path in save dialog" It will be available in 24.8.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 166375 has been marked as a duplicate of this bug. ***
IMHO "better behavior" would be to generate PDF in the current directory, and provide an shortcut to previous directory on the left panel of the dialog box. In the meantime, every single day this bug is driving me crazy.
I can't agree more ! I edit, save as and export as pdf tens of files everyday, of all kinds, from different directories, and it's a nightmare. Why is it so easy to break things that always worked and so difficult to revert to the correct code ? ANd why the problem in the 1st place ? Who did request this change ? Who verified that it made sense ? The days fly by, and the latest version available is still unusable :-( We were told the update would be available this week... I'm lucky to have an excellent file finder (File Locator Pro) that helps me chase files that are saved by LO in ridiculous places. Grrrr
For those complaining, the 25.2.3.2 release has posted to mirror network. https://www.libreoffice.org/download/download-libreoffice/ Be aware that additional refactoring has occurred and the future behavior is present in builds of master against the 25.8.0 release. Or as any other changes occur. https://wiki.documentfoundation.org/Installing_in_parallel https://dev-builds.libreoffice.org/daily/master/ The changes to 25.2.0 and backported to 24.8.6 were available long before folks in production were affected. Sorry, but incumbent on users to stay current with ongoing development. So for those of you complaining, please test behavior of 25.8.0 in a nightly build installed in parallel. It is much better to get your comments and feedback into devs while features are actively being worked up--as opposed to claiming regression and clamoring for reversion.
Absolutely agree also. I used to install the "preliminary version for enthusiasts" or whatever it was called, precisely for this purpose (as an intensive and long time user, to test and report issues on versions before they hit regular users). I think it would be useful to have in advance a list of future features and a way to prioritize them to make sure the efforts spent on development are well invested and productive. I still see too many things that don't really work as they should (for formatting and style management in particular) and would deserve some work... It would be also extremely useful to provide support for markdown ! And avoid "fixing" things that ain't broken (like save as and export). Just saying... Note : I still have LO 25.2.2.2 saying "LibreOffice 25.2 is up to date." I guess it waits until the minor will change ?
And Hoorray : 24.2.3.2 is out and it fixes both the file saving and the cursor up issue. Thanks ...
As a side note: is there any news on the modernization of the build platform for the pre-release binaries? Lack of Qt6 and KF6 VCL are making usage (including usage for testing) a bit problematic on wayland platform (e.g., menus open in weird places on the screen due to buggy wayland support in the Qt5 based VCLs, due to the Qt version being used).
(In reply to Bert Cuzeau from comment #78) > Note : I still have LO 25.2.2.2 saying "LibreOffice 25.2 is up to date." > I guess it waits until the minor will change ? No. The Tools -> Options -> Online Update options to "Check for updates" remains under development. The legacy "notification only" remains the default behavior. TDF release engineering does not toggle that on the back end "for a couple of weeks" after git tag and "release". No "automatic download" results--update remains a manual process. The intentional delay provides a final opportunity for TDF to spin a new build package should something really bad show up in the release for those paying attention. After that delay, the "notification" of new release be enabled. Users can do what they like. Activation of the other "Automatic Updates" (Mozilla MAR based) is likewise delayed, exposing a "released" incremental patch to be downloaded and installed. Primarily for Windows builds, but Linux is also supported. macOS is not currently. Intention there is to allow users to set and forget it. The "notification only" triggered by "Check for updates" will likely be reworked at some point into something more helpful to users.
Just installed 25.2.3.2 in Fedora 42, and I could confirm that the Export PDF and Save As behaviour is back to what it was before. It makes me realize that sometimes such a small behaviour makes a lot of difference in a user's everyday life. Thank you so much @Aron Budea for reverting the change for all current versions.
*** Bug 166423 has been marked as a duplicate of this bug. ***
*** Bug 166460 has been marked as a duplicate of this bug. ***
I have this problem with the 24.x version under Manjaro not only when saving PDF but also with everything else when using "Save as". This is an incredible annoying bug. Even worse, I cannot switch to 25.x as all my Calc files cannot be opened due to "Error in XML file". It definetly is not fixed with this version (newest on Manjaro/Arch) Version: 24.8.6.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 22; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland) Locale: de-DE (de_DE.UTF-8); UI: de-DE 24.8.6-2 Calc: CL threaded
(In reply to thorsten.brandau from comment #85) > I have this problem with the 24.x version under Manjaro not only when saving > PDF but also with everything else when using "Save as". This is an > incredible annoying bug. > > Even worse, I cannot switch to 25.x as all my Calc files cannot be opened > due to "Error in XML file". > > It definetly is not fixed with this version (newest on Manjaro/Arch) > > Version: 24.8.6.2 (X86_64) / LibreOffice Community > Build ID: 480(Build:2) Please read the history for this bug. Whiteboard: target:25.8.0 target:25.2.3 target:24.8.7. So it isn't fixed in LO 24.8.6.2. Download the veriosn 24.8.7 from http://downloadarchive.documentfoundation.org/libreoffice/old/
(In reply to thorsten.brandau from comment #85) > Even worse, I cannot switch to 25.x as all my Calc files cannot be opened > due to "Error in XML file". If you create a new report for this while including an example file, the cause can be found quickly.