Bug 132426 - Saving an opened txt with a specific character encoding is overwritten when saved
Summary: Saving an opened txt with a specific character encoding is overwritten when s...
Status: RESOLVED DUPLICATE of bug 120574
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
6.4.3.2 release
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-26 08:55 UTC by AndreasD
Modified: 2020-05-02 07:40 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
utf-8-saved (43 bytes, text/plain)
2020-05-02 06:17 UTC, AndreasD
Details
utf-8-saved-reopened-saved (37 bytes, text/plain)
2020-05-02 06:20 UTC, AndreasD
Details
utf-8-saved-reopened-saved (5.32 KB, image/png)
2020-05-02 06:23 UTC, AndreasD
Details
utf-org (6.37 KB, image/png)
2020-05-02 06:24 UTC, AndreasD
Details

Note You need to log in before you can comment on or make changes to this bug.
Description AndreasD 2020-04-26 08:55:20 UTC
Description:
When opening a txt with a specific character encoding UTF-8 this is reverted when saving. Would be nice if it could save in the same encoding as the document had when opened or ask which encoding to use. 

Actual Results:
Open a txt with UTF-8 and save it. When reopened is ha changed the encoding.

Expected Results:
Should keep existing encoding


Reproducible: Always


User Profile Reset: No



Additional Info:
[Information automatically included from LibreOffice]
Locale: sv
Module: TextDocument
[Information guessed from browser]
OS: Windows (All)
OS is 64bit: no
Comment 1 Dieter 2020-05-02 05:59:23 UTC
Andreas, thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it)
Comment 2 AndreasD 2020-05-02 06:17:41 UTC
Created attachment 160210 [details]
utf-8-saved

This i a filed saved with the option to choose encoding with utf-8 selected
Comment 3 AndreasD 2020-05-02 06:20:50 UTC
Created attachment 160211 [details]
utf-8-saved-reopened-saved

This file is closed, reopened and saved with a standard save. It vill loose utf-8 and return to ansi
Comment 4 AndreasD 2020-05-02 06:22:05 UTC
Same in 6.2.2.2 and 6.4.3.2
Comment 5 AndreasD 2020-05-02 06:23:47 UTC
Created attachment 160212 [details]
utf-8-saved-reopened-saved

Notepad reports this as ansi
Comment 6 AndreasD 2020-05-02 06:24:26 UTC
Created attachment 160213 [details]
utf-org

Notepad reports original as utf-8
Comment 7 Ming Hua 2020-05-02 07:17:02 UTC
(In reply to AndreasD from comment #2)
> Created attachment 160210 [details]
> 
> This i a filed saved with the option to choose encoding with utf-8 selected
Reproduced with 6.4.4 RC1 using this example on simplified Chinese Windows:
版本: 6.4.4.1 (x64)
Build ID: b50bc319eca5cd5b66fbfe2ebd0d3bd1eed099b5
CPU 线程: 2; 操作系统: Windows 10.0 Build 18363; UI 渲染: GL; VCL: win; 
区域语言: zh-CN (zh_CN); UI 语言: zh-CN
Calc: threaded

The second line of this file is "åäö".  When opened in LO and saved again (maybe type a character and then delete it to activate the Save button), a warning dialog pops up and warns that some information can't be saved in Text format and recommends saving in ODF format instead.  If I choose to save as text anyway, LO doesn't let me choose encoding and saves to something other than UTF-8.

On my system I haven't figure out what encoding it's saved yet.  It's different from what the reporter got in comment #3.  The file there is in ISO-8859-1 encoding (not sure if it can be called ANSI when non-ASCII characters are involved).  Mine is definitely not ISO-8859-1 encoding.  I also get different saved files depending on whether I open the original file as "All Files (*.*)" or "Text - Choose Encoding (*.txt)".
Comment 8 Ming Hua 2020-05-02 07:20:41 UTC
Hmm, so we don't have a filter:txt keyword. :-P

At least there is a nice meta bug.
Comment 9 Ming Hua 2020-05-02 07:40:30 UTC
(In reply to Ming Hua from comment #8)
> At least there is a nice meta bug.

And I jumped the gun.  It turns out this issue has already been reported and can be found in that meta bug.

*** This bug has been marked as a duplicate of bug 120574 ***