Created attachment 160310 [details] Screen grabs of the dialog appearance first & second time I am importing a UTF-16 file which contains the ° character (alt-shift-8 on a UK Mac keyboard). I want to use these characters as separators. I enter the character as an 'other' separator and the file is imported. The next time I open a text file, in the Text Import dialog, the ° character has been replaced with a ﾰ The character should not change when the dialog is reopened. The attached document shows the appearance of the dialog with the original, correct character & the incorrect character when reopened.
@max : Ideally, we would need a test CSV file with some sample data with which to test. I don't have anything that makes UTF-16 CSV files by default on my Mac, unless you have another suggestion of where I might download one with such a configuration ?
Created attachment 160481 [details] Example UTF-16 format text file This file was generated by "LTSpice XVII for OS X, Build Oct 25 2018, 14:56:22 US Pacific", downloadable from https://www.analog.com/en/design-center/design-tools-and-calculators/ltspice-simulator.html (However I notice a more recent version has just been uploaded) To generate a file from a simulation result (i.e. waveform plot '.raw' file), click the settings icon (hammer) on the plot window toolbar, and then click the Data Export Tool button.
[Automated Action] NeedInfo-To-Unconfirmed
Can confirm on macOS and Windows: ° becomes garbled on second import try I guess it must be the encoding of the "other" text identifier that is not saved Version: 6.4.0.3 (x64) Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8 CPU threads: 2; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded
Dear max, 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 with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. 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) from https://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: https://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
The uploaded example file's encoding is now remembered and correctly applied to the delimiter character edit control, in version 7.3.2.2. OS is macOS 12.3.1