Steps: 1) Open a file.txt 2) Write some stuff. Maybe even use formatting that .txt format doesn't support. 3) Save the file. (Leave it as plain text.) 4) Save a Copy and select HTML format. Result: Writer fails to change the extension to .html and instead offers the choice to overwrite the existing file. This ignores the user's intention of saving an alternate format version of the file. Writer then changes the file type from what the user selected (e.g. HTML) back to .txt. Until the user manually deletes the file extension from the filename in the Save a Copy text field, you cannot save the file as the file type you're trying to. This bug may relate to https://bugs.documentfoundation.org/show_bug.cgi?id=111070, but I think this may be a different use case. Note that this happens on Linux. The reason for wanting to do this slightly odd operation is to prepare clean source text for creating simple HTML. Using some formatting is a convenient reminder to apply similar formatting in the target environment. (Writer's HTML format is far too complex and unwieldy for many web platforms to use as input markup - e.g. for Wordpress, or MailerLite newsletters, or blogs. I mention this not to complain but merely to explain why the use case makes sense. Writer is an excellent editor for plain text and most other formats, but the underlying representation can cause problems due to the complexity caused by 1) editing operations, and 2) by direct formatting. Plain text does not capture any of those structural complexities from either of those causes.)
No repro for me in: Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I think I'm encountering this fairly often on Ubuntu, but inconsistently, and not always. I'm also not using Save a Copy... (but Save As...) perhaps that's also a special case, if it's 100% reproducible for you. (can't check now, will try in a few days if I don't forget)
Not reproduced NixOS Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: b1df9c67349cf4cc5be4128d797aefb87f50e38f CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: x11 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded
Created attachment 173767 [details] Very short video demonstrating it I want to keep the original plain .txt without formatting, but to have a copy with the formatting preserved in case of disaster (e.g. power failure), and preferably without accidentally overwriting my plain text version after I've explicitly selected the option to Save A Copy and chosen a different file type. I hope this video shows that the above steps reliably reproduce the problem, at least under Linux. (Under a MATE desktop, if that matters? Version: 6.4.7.2 Build ID: 1:6.4.7-0ubuntu0.20.04.1 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3; Locale: en-AU (en_AU.UTF-8); UI-Language: en-US Calc: threaded
It was only after posting my last comment I realised that since my shift to another computer, I was running an older version of LO. I just now upgraded and tried the exact same procedure, and can confirm the exact same results, in: Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 8; OS: Linux 5.11; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Perhaps you don't see the problem, if you launch from the command line with SAL_USE_VCLPLUGIN=gen libreoffice Can you test?
(In reply to Buovjaga from comment #6) > Perhaps you don't see the problem, if you launch from the command line with > > SAL_USE_VCLPLUGIN=gen libreoffice > > Can you test? It works fine in this mode. The UI behaves differently: the filename in the text field does not include the suffix, and is instead provided I assume by the selection of file type from the menu. In contrast, the normal UI does fill in the suffix along with the basename of the file, but does not strip the suffix and replace it with that of the file type selected from the menu, just as I described originally, and as you can see from the short video prebiously attached. Hope this helps.
Key here is: file is already shown as "file.txt" as in Comment 7. If it's shown as "file" no problem. Also no repro for me in Mint 19 Cinnamon or MATE with GTK3. My conclusion: origin of the problem is in OS, not LO, and it manifests as bug 111070. So not really a duplicate, rather NotOurBug but since we don't know the cause, I'll mark duplicate. *** This bug has been marked as a duplicate of bug 111070 ***