Description: CJK Ideograph Rendering Issue on LibreOffice Impress All Platforms(All Linux, Windows, Mac OSX etc). Now, I use Noto CJK fonts ( https://www.google.com/get/noto/help/cjk/ ) on LibreOffice Impress. Because, I'm writting and checking about Ideographs Difference between Glyph in Chinese, Japanese, Korean, using Noto CJK Fonts. Noto CJK Fonts(Korean, Japanese, Traditional Chinese, Simplified Chinese) includes CJK Unified Ideograph glyphs. There are expressed CJK Unified Ideographs in each languages(Korean, Japanese, Traditional Chinese, Simplified Chinese). Korean, Japanese, Traditional Chinese, Simplified Chinese are different language, but There are use Ideographs(漢字/汉字,reads Korean: 한자/hanja, Japanaese: かんじ/kanji, Chinese: hànzì). I write one Ideograph character 漢 (U+6F22) on Impress. Also write same thing and changed Fonts, First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)] 漢 (U+6F22) is Same Code point, but Difference between Glyph in Chinese, Japanese, Korean. But, All platform's LibreOffice Impress shows only same glyph(I'm Korean users, I think, Maybe LibreOffice Impress follows Korean locale.) For the first time, I was wondering if there was a problem with KDE's CJK Ideograph font rendering. (Because I'm KDE Plasma & openSUSE Linux User). Last Sunday, I met KDE e.V members in Korea and KDE board member, I checked KDE's CJK Ideograph font rendering. KDE's presentation application, I opened odp file on Calligra Stage. But, It's correctly shown CJK Ideograph fonts. And I checked both KDE character map(kcharselect) & GNOME character map(gucharmap). It properly represent each font, I checked. (Noto Sans CJK JP[Japanese], Noto Sans CJK KR[Korean], Noto Sans CJK TC[Traditional Chinese], Noto Sans CJK SC[Simplified Chinese]) Also I checked MS Office both MacOSX & Windows. It shows correctly. But, I checked LibreOffice Impress Linux, Windows, MacOSX, I found the CJK Ideograph Rendering Issue. Steps to Reproduce: 1. Enter the same letter, '漢' (U+6F22) 3 times 2. Replace three letters with different fonts. In the following order, First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). 3. Checked it Actual Results: Depending on your language locale setting I'm Korean user and setting Korean locale on desktop, It shows Same Korean font glyphs. Expected Results: Checked the character 漢 (U+6F22) on The Unicode Standard, Version 11.0 CJK Unified Ideographs Code Point Chart Range: 4E00–9FEF https://www.unicode.org/charts/PDF/U4E00.pdf It shown Ideograph difference between Glyph in Chinese, Japanese, Korean, Vietnamese. Reproducible: Always User Profile Reset: No Additional Info: Noto Sans CJK and Noto Serif CJK comprehensively cover Simplified Chinese, Traditional Chinese, Japanese, and Korean in a unified font family. This includes the full coverage of CJK Ideographs with variation support for 4 regions, Kangxi radicals, Japanese Kana, Korean Hangul, and other CJK symbols and letters in the Basic Multilingual Plane of Unicode. 1. Noto Sans CJK KR (Korean) 2. Noto Sans CJK JP (Japanese) 3. Noto Sans CJK TC (Traditional Chinese) 4. Noto Sans CJK SC (Simplified Chinese)
Created attachment 146786 [details] CJK Ideograph 漢Font rendering Example file CJK Ideograph 漢Font rendering Example file Checked page 3, and 漢(Noto Sans CJK JP), 漢(Noto Sans CJK KR), 漢(Noto Sans CJK TC), 汉(Noto Sans CJK SC)
Created attachment 146787 [details] 漢 (U+6F22), Official Ideograph glyph in East Asia 漢 (U+6F22), Official Ideograph glyph in East Asia. Same Code point, but Difference between Glyph in Chinese, Japanese, Korean, Vietnamese. Checked the character 漢 (U+6F22) on The Unicode Standard, Version 11.0 CJK Unified Ideographs Code Point Chart Range: 4E00–9FEF https://www.unicode.org/charts/PDF/U4E00.pdf
Created attachment 146788 [details] LibreOffice 6.1.3.2 漢 example image on openSUSE Linux Tumbleweed 漢 example image LibreOffice 6.1.3.2 on openSUSE Linux Tumbleweed 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)]
Created attachment 146789 [details] LibreOffice 6.1.3.2 漢 example image on Ubuntu 17.04 漢 example image LibreOffice 6.1.3.2 on Ubuntu 17.04 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)]
Created attachment 146790 [details] LibreOffice 6.1.3.2 漢 example image on Mac OSX Mojave 漢 example image LibreOffice 6.1.3.2 on Mac OSX Mojave 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)]
Created attachment 146791 [details] LibreOffice 6.1.3.2 漢 example image on Windows7 漢 example image LibreOffice 6.1.3.2 on Windows 7 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)]
Created attachment 146792 [details] Calligra Stage 漢 example image on openSUSE Linux Tumbleweed It's correctly render Noto Sans CJK Fonts! KDE Calligra Stage 漢 example image on openSUSE Linux Tumbleweed 漢 example image KDE Calligra Stage on openSUSE Linux Tumbleweed. 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)] It's correctly render Noto Sans CJK Fonts!
Created attachment 146793 [details] MS Office 2010 漢 example image on Windows7 It's correctly render Noto Sans CJK Fonts! 漢 example image MS Office 2010 on Windows7 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)] It's correctly render Noto Sans CJK Fonts!
Created attachment 146794 [details] MS Office 漢 example image on MacOSX It's correctly render Noto Sans CJK Fonts! 漢 example image MS Office on MAC OSX 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)] It's correctly render Noto Sans CJK Fonts!
Created attachment 146795 [details] LibreOffice 6.2 Beta 漢 example image on openSUSE Linux Tumbleweed LibreOffice 6.2 Beta 漢 example image on openSUSE Linux Tumbleweed 漢 example image LibreOffice 6.2 Beta on openSUSE Linux Tumbleweed 漢 (U+6F22) First, Noto Sans CJK JP(Japanese), Second, Noto Sans CJK KR(Korean), Last, Noto Sans CJK TC(Traditional Chinese). Last one next one is another Ideograph character 汉(U+6C49) [Noto Sans CJK SC(Simplified Chinese)]
As far as I can tell the problem is your formatting of the characters in Impress and not a LibreOffice problem. I guess you're talking about Impress slide three. If you check the language of the single characters, all are set to "Korean (RoK)". You can check this by selecting the single character and then Format -> Character… Asian Text Font -> Language. The reason is that LibreOffice knows the language of the text and that the font doesn't have the glyph (= character) in your selected language. So it automatically looks for the correct glyph in the text language in other fonts LibreOffice finds on the system to show the correct character in the selected language, regardless of the selected font. If I change the language of a first character to Japanese, like the font indicates, the glyph actually changes. I don't see a difference between the KR and TC variants, if I set the third character to "Chinese (traditional)", but probably I'm missing a font here. I just tested with my master build which is almost your 6.2 beta, just a bit newer. Please reopen the bug, if this is still broken for you.
Created attachment 147596 [details] LibreOffice's Noto Sans CJK font rendering characters example odp file I uploaded the difference of Ideographs[漢字, Chinese Characters] Example odp file. It compares to That is the ODP file, comparing Noto Sans CJK Font(TC[Traditional Chinese], SC[Simplified Chinese], JP[Japanese], and KR[Korean]) with the Code Chart PDF file of the Unicode Consortium. on Microsoft Office, The glyph in the Selected Noto sans CJK font(TC[Traditional Chinese], SC[Simplified Chinese], JP[Japanese], and KR[Korean]) are displayed correctly. But LibreOffice don't look right, It follows Language settings on LibreOffice. Reference: 1. Noto Sans CJK Font https://www.google.com/get/noto/help/cjk/ 2. Unicode Code Chart - CJK Unified Ideographs Range: 4E00–9FEF https://www.unicode.org/charts/PDF/U4E00.pdf
Created attachment 147600 [details] When Checked the Spelling Check, It only shows Korean Hanja When It Checked on the Spelling Check on LibreOffice, It only shows Korean Hanja(한자/漢字) style Ideopgraphs. LibreOffice don't look right, It follows Spelling Check settings on LibreOffice. If you get off the spelling check option, The glyph in the Selected Noto sans CJK font(TC[Traditional Chinese], SC[Simplified Chinese], JP[Japanese], and KR[Korean]) are displayed correctly on LibreOffice.
Created attachment 147601 [details] Correct view on LibreOffice Impress, when It get off the spelling check option. This is correct example, when you get of the spelling check option on LibreOffice. If you get off the spelling check option, The glyph in the Selected Noto sans CJK font(TC[Traditional Chinese], SC[Simplified Chinese], JP[Japanese], and KR[Korean]) are displayed correctly on LibreOffice.
Created attachment 147602 [details] Correct view on Microsoft Office Powerpoint Correct view on Microsoft Office Powerpoint. This is correct example on Microsoft Office's Powerpoint. The glyph in the Selected Noto sans CJK font(TC[Traditional Chinese], SC[Simplified Chinese], JP[Japanese], and KR[Korean]) are displayed correctly on Microsoft Office's Powerpoint.
You can't confirm your own bugs. Moving it back to UNCONFIRMED until someone else confirms it.
LibreOffice Impress CJK Input Test on MacOSX(10.14 Mojave) Using Default MacOSX Input Method Engine(IME)[Chinese(Traditional, Simplified), Japanese, Korean], I found Japanese Input error on LibreOffice Impress. compare with Version 6.2.3.2 and Version 6.3.0.0.alpha1+ (Build ID: 1376bb3e44c4b9eb15cf788df04f7cc0bba8cb09). In CJK(Chinese,Japanese, Korean) Input test, Japanese Input kanji word rendering is error , unlike Chinese on LibreOffice Impress. Youtube video: https://youtube.com/watch?v=mws8LIYfdH0
Hello DaeHyun Sung, A new major release of LibreOffice is available since this bug was reported. Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Dear DaeHyun Sung, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear DaeHyun Sung, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp