|
Description
DaeHyun Sung
2018-11-19 15:16:41 UTC
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 |