Created attachment 98069 [details] chinese characters as blocks I download the .docx file found at < http://download.microsoft.com/documents/customerevidence/Files/710000003670/Xiamen_Tungsten_Group_unifies_enterprise.docx > and opened it with kingsoft writer and then saved it as an RTF. When i opened the file in LibO, all the chinese characters show up as blocks with a font name set as '0'. Tested from 4.1 to 4.3. Document doesnt open in versions below 4.1.
Created attachment 98070 [details] kingsoft rtf file
Created attachment 98071 [details] error dialog for opening in versions below 4.1
This related to some degree to my other bug, bug 77979.
Created attachment 98281 [details] 4.2.3.3 screenshot under Win7x64 font name is 0 in my PC but I correctly see the chinese fonts unlike your screenshot. please define your O/S
running on linux mint 13 32-bit. from your screenshot i can see that windows is defaulting it to the simsun font though the file's font is set to Microsoft YaHei.
Created attachment 98282 [details] the 0 character style info dialog
Working on Windows with Version: 4.4.0.0.alpha0+ Build ID: bdd87b2acddb2e244569dcc8f228e270614dc59e TinderBox: Win-x86@39, Branch:master, Time: 2014-06-23_00:37:24 If Linux NOTOURBUG, if font is not installed it should switch to default font.... @Jay: Your opinion?
tommy already confirmed this so i'm setting it to NEW. The issue here is incorrect importing of font styles, not whether i have the font installed or not. Tested on 4.4 and it still shows font '0' if you are on the first line of chinese lettters.
Created attachment 101679 [details] Font 0 in the LibO UI in 4.4 I set regression in keyword for miklos as the old rtf importer in 3.3.0 doesnt have the same problem.
There is a bug with reading Unicode escapes in RTF font table. "0" seems to be a name for an unnamed font.
the problem is that in the stylesheet entries the nested groups are not handled properly; effectively the style names are ignored; somehow that results in all style names being "0", overwriting each other. there is a similar problem with other destinations such as the document properties \author and \operator, which are also lost. 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=82e17dbb2a16c7653a163139f0eea51faa4d46b8 fdo#77996: writerfilter: RTF import: re-work destination text buffering 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=033154d99a834024993b3faf3af9a6842dc907b8&h=libreoffice-4-3 fdo#77996: writerfilter: RTF import: re-work destination text buffering It will be available in LibreOffice 4.3.1. 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]