Created attachment 121258 [details] Fig 1. Badly displayed at the first paste Unicode ExtB+ chars are not well handled, especially when exported to the PDF.
Comment on attachment 121258 [details] Fig 1. Badly displayed at the first paste Unicode ExtB+ chars are not displayed correctly after pasted into the Writer (The original text of this figure is "大黃䗪蟲丸狐𧌒䒜𧀬") They are displayed correctly after saving the file and then reloading it.
Created attachment 121259 [details] Fig 2. Badly displayed when exported to PDF Unicode ExtB+ chars are badly displayed when they are exported to a PDF file.
Created attachment 121261 [details] Fig 3. Badly displayed when saved as .docx Unicode ExtB+ chars are badly displayed when they are exported to a docx file.
Created attachment 121262 [details] Fig 4. Badly displayed when saved as .doc Unicode ExtB+ chars are badly displayed when they are exported to a .doc file.
Created attachment 121267 [details] The demo .odt
I get the paste error, but they don't display correctly after save + reload. Win 7 Pro 64-bit, Version: 5.0.3.2 (x64) Build ID: e5f16313668ac592c1bfb310f4390624e3dbfb75 Locale: fi-FI (fi_FI) Version: 5.2.0.0.alpha0+ Build ID: 014633f83e44ae8ba33087b6f38e8e253e281969 CPU Threads: 4; OS Version: Windows 6.1; UI Render: default; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-12-15_06:21:44 Locale: fi-FI (fi_FI) 4.3.0.1
Created attachment 121498 [details] extB characters in different fonts I tried with different fonts, saved as odf file and reloaded. The result was the same.
Created attachment 121499 [details] extB characters saved as docx
Created attachment 128578 [details] Test file open with LODev 5.3 Comfirmed with LODev 5.3 even if I use SimSun instead. Version: 5.3.0.0.alpha1+ Build ID: 05d2a66955f8a6552a79696474386ca9f45f9ef2 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2016-11-07_23:34:48 Locale: zh-CN (zh_CN); Calc: group
Comfirmed with LODev 5.3.0 beta2, even if I try to use Hanazono Mincho. Version: 5.3.0.0.beta2 Build ID: a7e30712ad6d8bc9286007b37aa581983e0caba3 CPU Threads: 4; OS Version: Windows 6.2; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group
Created attachment 129925 [details] Fig 4. Badly displayed when making them vertically This problem also appearing in vertical layout, and several characters displaying with fallback fonts looks sideway instead of upright.
Created attachment 129926 [details] 2nd demo .odt
Test again on LO 5.3.2.1, with attachment 121267 [details] ExtB chars are still badly placed, with attachment 129926 [details] they looks not upright. Version: 5.3.2.1 (x64) Build ID: 7f6693c08cc110b9721245fc4bd4f1712e0c086c CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: CL
Although all the cases are related to EXT-B and Writer, each of them has a different symptom ( FILESAVE to different formats, FILEOPEN, exporting to pdf, vertical formatting). They even have different test files. So I suggest to create different issues, and maybe make this a meta issue, to make triaging and fixing the issue easier.
Volga: can you create the separate reports per Mark's suggestion?
Created attachment 132891 [details] 3rd demo .odt I made this file for further test. In this case I found characters encoded in CJK Ext B and D blocks are badly rendered when they are displaying with MingLiU and SimSun, but with Habazono fonts they looks pretty. This bug seems is font issue, but both MingLiU and SimSun are system fonts on Windows, and these characters are well handeled in Notepad, Wordpad, so this can be consider as LibreOffice bug. Version: 5.3.3.1 (x64) Build ID: 46360c72c4823cefeaa85af537fba22bd568da7e CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; Layout Engine: new; Locale: zh-CN (zh_CN); Calc: group Habazono fonts are available here: http://fonts.jp/hanazono/ For non Chinese versions of MS Windows, you can get MingLiU and SimSun following these instructions: https://answers.microsoft.com/en-us/windows/forum/windows_10-start/some-fonts-are-missing-after-upgrade/95839dfa-0df2-4bc0-875a-fd6b57e61fe4?page=1&auth=1
Created attachment 132892 [details] Fig 1. Well displayed with HanaMinA/HanaMinB This is a snapshot taken with attachment #132891 [details]
Created attachment 132893 [details] Fig 2. Badly displayed with MingLiU This is a snapshot taken with attachment #132891 [details]
Created attachment 132894 [details] Fig 3. Badly displayed with SimSun This is a snapshot taken with attachment #132891 [details]
Created attachment 132896 [details] Fig 4. Test for printing This test file made with PDFCreator, a virtual printer on Windows.
(In reply to Buovjaga from comment #16) > Volga: can you create the separate reports per Mark's suggestion? Not sure. This bug seems is caused by bad font loading that affect specific fonts, and then FILESAVE and FILEOPEN got affects.
Once information started to accumulate, we no longer know whether we are talking about the original issue or the new one. Then it will not be possible to close the bug. Even worse, the bug might be neglected by developers directly because of lack of readability. From Danny Lin's comment, it can at least split into 1. Writer PDF Exporting issue for ExtB+ characters. 2. Writer Paste issue of ExtB+ characters. 3. FILESAVE: Export issue for docx format. 4. FILESAVE: Export issue for doc format. Steps and the source file to reproduce for each has to be clarified. I close this issue as Invalid. Each issue can be reported independently if someone cares.
Volga, how would this be an a11y issue in any sense? Bit of a stretch to lump Font rendering to screen as affecting Assistive Technology tools. If supported, screen readers will sound the glyphs as recorded by their Unicode points.
(In reply to V Stuart Foote from comment #24) > Volga, how would this be an a11y issue in any sense? > > Bit of a stretch to lump Font rendering to screen as affecting Assistive > Technology tools. If supported, screen readers will sound the glyphs as > recorded by their Unicode points. I made a mistake. I think this should be font loading issue.
Reported 2 sub-issues in the separated threads. https://bugs.documentfoundation.org/show_bug.cgi?id=107487 https://bugs.documentfoundation.org/show_bug.cgi?id=107488