Problem description: special characters are encoded incorrect when saved as RTF under Windows Steps to reproduce: 1. create new empty file with writer 2. Insert special character: Menu Insert -> Special Character 3. Choose e.g. the Copyright Sign 4. Save file as RTF 5. Close the document 6. reopen the saved RTF document Current behavior: wrong character displayer Expected behavior: original character should be dispayed eg. the Copyright Sign Platform: Windows 7 64 Bit reproduced with the following LibreOffice Versions: 3.4.3 final 3.4.4 final 3.5.0.beta2 works with version 3.4.4 under Ubuntu Linux 64 bit
Confirmed (Platform Windows Vista 64)
Which font did you use ? Calibri ? Have you tried to play with different standard font like Arial, Times New Roman, etc. Best regards. JBF
the error occurs with Times New Roman (which is the default font) i tried with Verdana and Arial which seems to work ok any ideas?
Created attachment 55372 [details] copyright sign with arial
Created attachment 55373 [details] copyright sign with times new roman
i compared the .rtf source that is saved in both cases: when switching the font to Arial the copyright sign is saved as \u169\'a9} (line 16 in attached arial.rtf) when saving the same sign with times new roman the rtf looks like \'a9} (also line 16 in attached timesnewroman.rtf) when manually adding the missing \u169 to the rtf source in timesnewroman.rtf the sign is displayed correctly
I reproduce the problem with LibreOffice 3.4.5 rc2, LO 3.5.0 beta2 and LO3.5.0 beta2+ (daily build : LOdev 3.5.0beta2+ Build ID: cbb7814-7f15fca-9e804be-2d9b003) under MS-Windows-XP (VM) But *not* with LO 3.4.5 rc2 under Ubuntu 10.04 (x86) and LO 3.5.0 beta2+ under Ubuntu 11.10 (x86_64) So it seems it is a MS-Windows only problem. Miklos: i think it is for you. Please feel free to reassign if you can't handle this bug. Thank you :-) Best regards. JBF
For some crazy reason the inserted character with no additional formatting applied gets the font with SHIFTJIS_CHARSET (128). Why?
Urmas, Can you see if this export bug also happens with docx? Just to see where the bug is. Thanks.
I will check if this bug is stil on windows, special characters was a problem on Linux byut not anymore
anything new on this? can i help on something?
The issue is still present in 3.5.0 RC1, Kubuntu 11.10, WINE 1.3.37. Here's how to reproduce: 1. Start a new document in Writer. 2. Type in some text. It can be any text, not just special characters. Font selection doesn't matter either. 3. Copy the text to the clipboard. 4. Paste into ActionTest editor. (ActionTest can be downloaded from: http://trichview.com/resources/actions/actiontest.zip) 5. Save as rvf. 6. Assigned charset is SHIFTJIS_CHARSET. If I go to Format/Character/Font/Language in LO, Japanese isn't listed; the only languages available in Country/Region & Language under Kubuntu's System Settings are American English and British English. So,... no obvious reason for SHIFTJIS.
Hi, I tried to reproduce this, indeed it's specific to RTF and Windows. (However the relevant part of the RTF export filter is really simple, there is nothing RTF or Windows-specific there...) I guess a solution is to do the same what we do on Linux when the locale is UTF-8 (emit the unicode character instead of playing with charset), but I don't have a Windows build around. Will try to get a mingw build soon - hopefully reproducible there. Miklos
any progress on this issue?
Not really. I don't have a Windows build environment (I plan to set up one in the next few weeks) and mingw is broken on master (builds, but doesn't start), so I'm blocked on that one.
not reproducible with LO 4.0.2.2 (Win7 Home, 64bit) Does this issue still persist for you with the latest release of LO?
tested with 4.0.3 under win7 pro 64-bit not reproducible we are on 3.6, but since there is no explicit patch it probably won't be fixed in a 3.x release?
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1.2 or later): https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-03-03
Per comments #16 and #17 closing as WorksForMe. Please, feel free to reopen if you disagree. Best regards. JBF