Created attachment 98054 [details] chinese characters to to block characters I downloaded the .docx file found at < http://download.microsoft.com/documents/customerevidence/Files/710000003670/Xiamen_Tungsten_Group_unifies_enterprise.docx > and opened it in LibO and then saved it as a rtf file. Then i reopened the saved file, and all the chinese characters turned into block characters as the font is set to arial rather than microsoft yahei, as well as font colors arent retained as the second line is supposed to be blue and the third line is supposed to be grey. Confirmed in LibO 4.1 to 4.3, while it works fine when exporting from 4.0.
I opened the rtf in word 2010 and the font colors were still there but the font wasnt microsoft yahei, but still the chinese characters did appear.
In 4.0 the font used is arial and the chinese characters still appear. With regards to the font color, it is only lost in 4.2.
I'm just going to focus on the blocks - if you could report the other (color) issue separately that would be great.
So I cannot confirm this - I do confirm that font changes to Arial (which is strange) but I don't see blocks. I'll await other QA members to confirm. Tested on: Ubuntu 14.04 Version: 4.2.3.3 I see the exact same font thing in 3.6 (name change, but no blocks)
Well blocks will show up when the font used(In reply to comment #3) > I'm just going to focus on the blocks - if you could report the other > (color) issue separately that would be great. Filed as bug 78313. (In reply to comment #4) > So I cannot confirm this - I do confirm that font changes to Arial (which is > strange) but I don't see blocks. I'll await other QA members to confirm. > not sure why its showing in blocks in versions 4.1 to 4.3 but thats not important. whats important is that it should be microsoft yahei and not arial, as i can select the text and the blocks will disappear if i change it to microsoft yahei.
I see correct chinese characters (no blocks) under Win7x64 using LibO 4.2.3.3 however the font turns to Arial so I'm not reproducing completely the bug. @Joel should we mark NEW because of the font change?
Hi all, Opening this docx file with LO 3.1.6.2 or LO 4.3.0.0.alpha1+ Build ID: 0b03f7ed575838f90e6b1ebec3538a3a214f81fb TinderBox: Win-x86@39, Branch:master, Time: 2014-04-30_01:30:46 & Windows 7 Home Premium there's few displaying issues, but Formating bar display 微软雅黑 as font name and not Microsoft Yahei. When you pass the mouse cursor over this name, an info balloon display: "Font Name. The current font is not available and will be substituted". Of course, Microsoft Yahei is available on my OS. Jacques
(In reply to comment #7) > there's few displaying issues, but Formating bar display 微软雅黑 as font name > and not Microsoft Yahei. When you pass the mouse cursor over this name, an > info balloon display: "Font Name. The current font is not available and will > be substituted". > Of course, Microsoft Yahei is available on my OS. I had noticed that as well when i was opening the original file but just ignored it, as i assumed it was simply displaying the chinese name of Microsoft Yahei, as when i save the .docx in kingsoft office to a .doc and opened it in LibO, i saw different chinese characters when the font was Simsun.
Created attachment 98571 [details] chinese characters in the font drop down for Microsoft Yahei and Simsun
the fonts have names that are chinese characters, and an associated charset of UTF-8, which the RTF export maps badly to code page 1252: {\f7\froman\fprq2\fcharset0 ????;} this problem did not occur in the old RTF export in OOo 3.3, which produced this: {\f7\fnil\fprq2\fcharset128 \'94\'f7\'3f\'89\'eb\'fc\'4b;} so apparently using a fall-back from UTF-8 to Shift-JIS... we can't really tell which charset should be the target (especially not if we don't have the actual font and don't know what Unicode code-points it covers) so perhaps something like this is the best that can be done. Word apparently does not support \ucN\u...\'.. in font table, so write only the fall-back charset in the font table. came up with something that seems to work mostly, fixed on master.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=04d5a280beeeb6e056df68395dc9c3b3a674361b related: fdo#77979: writerfilter RTF import: read encoded font name The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e47a02b1524061143d8e77a54eb95c77f2e6dae2 fdo#77979: sw: RTF export: write non-ASCII font names encoded The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=90b2b378aecfa1914be0ce9aa7aa4e006e225e96 fdo#77979: argh forgot to add the test document The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=790df682574eb4b3da9a973c3116b54d7666837c&h=libreoffice-4-3 related: fdo#77979: writerfilter RTF import: read encoded font name It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=276fb59ee66806709382d0eeef20f62a094a5995&h=libreoffice-4-3 fdo#77979: sw: RTF export: write non-ASCII font names encoded It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=80b6b175f438dd56f6c107d956e6c00876ff3dba&h=libreoffice-4-2 related: fdo#77979: writerfilter RTF import: read encoded font name It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Stahl committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=8f80cde668b50c939aeff0d98a3e67c362df1fd4&h=libreoffice-4-2 fdo#77979: sw: RTF export: write non-ASCII font names encoded It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0dc7d6367dcedff8741b64f5b8775ebf26f7f14f fdo#77979: Make rtl_TextEncodingToWinCharsetRTF work for non-Unicode The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=6a4e688c84a12ced4113ea28f9d8837d2d616690&h=libreoffice-4-2 fdo#77979: Make rtl_TextEncodingToWinCharsetRTF work for non-Unicode It will be available in LibreOffice 4.2.6. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Stephan Bergmann committed a patch related to this issue. It has been pushed to "libreoffice-4-3": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f5458dc3a69d1e46d05406e32679286b6da7b1c&h=libreoffice-4-3 fdo#77979: Make rtl_TextEncodingToWinCharsetRTF work for non-Unicode It will be available in LibreOffice 4.3. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Migrating Whiteboard tags to Keywords: (filter:rtf) Replace rtf_filter -> filter:rtf. [NinjaEdit]