Created attachment 71535 [details] The ODT file to show this problem. Problem description: I upload a mi4.odt to show this problem. In version 3.5.4, the chinese character 𥅽 can be shown correctly even though the current font did not contain this unicode character (see attachment lo-3.5.4.png). But in version 4.0 beta, Writer would not show any character (see lo-4.0-beta1.png ), unless I manually selected a font that contains the unicode chinese character𥅽. In shorts, Libreoffice 4.0 do not find other fonts to display unicode chinese characters while this characters not found in current font, but Libreoffice 3.5.4 can do it automatically. Is it a problem of PANGO ? Note: If you were using Debian, you will need to install fonts-arphic-uming or fonts-arphic-ukai to show this unicode chinese character. You can download and extract them from the deb file if you were not Debian user: http://packages.debian.org/sid/fonts-arphic-uming http://packages.debian.org/zh-tw/sid/fonts-arphic-ukai Steps to reproduce: 1. Install fonts-arphic-uming or fonts-arphic-ukai (Debian or Ubuntu), but do not set these 2 fonts as default font in Writer. 2. Open mi4.odt with Libreoffice 4.0 beta1 or 3.5.4 3. You will see nothing there if you open it with Libreoffice 4.0 beta1, but you will see a chinese word if you open it with Libreoffice 3.5.4. Current behavior: Libreoffice 4.0 do not find other fonts to display unicode chinese characters while this characters not found in current font. Expected behavior: If the unicode character not found in the current font, Libreoffice 4.0 beta should try to search other fonts that contains this unicode character and to display it. Operating System: Debian Last worked in: 3.5.4 release
Created attachment 71536 [details] Screenshot: Libreoffice 4.0 beta failed to find other font to display the unicode word.
Created attachment 71537 [details] Screenshot: Libreoffice 3.5.4 find other font to display the unicode word automatically.
Could some developer close it as NOTABUG?
(In reply to comment #3) > Could some developer close it as NOTABUG? It's not a bug? For what?
hmm... seems to work here, all LO 3.5/3.6/4.0/master versions i've tried (incl. 4.0.0.0.beta1) show a chinese glyph for the bugdoc, though obviously from a different font than in the screenshot. i wonder, is this because i'm using a "newer" version of the font in the document? (testing on Fedora 17) i don't know how to check if there is indeed some fallback going on here; probably only Caolan can debug this...
All respected contributor, I find that if we close a document using the windows upper right corners cross button (even after saving it), during re opening the LibreOffice it starts the recovery process! But if we close the document from menu, then this problem does not happen. I believe rectifying this would help millions of user around the world. Even in OO 2.0 I also found this problem. Since I am new to this bug reporting area I might have posted it to wrong place. Apologies for inconveniences. Thank you, Ferdous
caolanm->minhsien0330: This "works for me" with those fonts installed. So presumably its because I have additional fonts installed which fontconfig suggests as better replacements. So in order for me to attempt to reproduce this bug I need to a) get the full list of fonts you have installed so that I can synchronize my installed fonts with your installed fonts. fc-list -v > /tmp/fontlist.txt and attach /tmp/fontlist.txt here b) get the output of "locale -a" because that can affect the suggested fallback font too. caolanm@fk: Open a new bug for your different problem which is unrelated to this issue.
Created attachment 72980 [details] font list Dear Caolán McNamara: The fontlist.txt is attached here. And the result of "locale -a" is: C C.UTF-8 en_US.utf8 POSIX zh_TW.utf8 Thanks a lot!
Created attachment 72983 [details] font list (new) Sorry, I added and removed some fonts, so I generate a new font list here. Thanks a lot~
The word processor should not substitute arbitrary fonts for documents and display random glyphs with them.
caolanm->urmas; There's nothing arbitrary about it, if a font is missing or cannot render a requested glyph we request a suitable replacement from fontconfig. Obviously the result depends on the input font, requested glyph and available installed fonts.
surrogate pair seems to be getting chopped up
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=0dd3b8b24364d31a00ef30b70dcc6fb63c5d96c9 Resolves: fdo#58324 keep both halves of surrogate pairs if glyph isn't found 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.
fixed for 4-1, patch submitted for 4-0 review
Caolan McNamara committed a patch related to this issue. It has been pushed to "libreoffice-4-0": http://cgit.freedesktop.org/libreoffice/core/commit/?id=700da51c5629f3b6a9b7c8e651cabbeb66960731&h=libreoffice-4-0 Resolves: fdo#58324 keep both halves of surrogate pairs if glyph isn't found It will be available in LibreOffice 4.0. 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.
Dear Caolán McNamara: I tried the daily builds(Time: 2013-01-21_10:33:51), and I found this problem is really soloved. Thank you so much! Best Regards, Minhsien0330