https://bugzilla.redhat.com/show_bug.cgi?id=1415322
Bug ID: 1415322 Summary: Wrong character displayed in UKai fonts for "zhi" (2nd tone) (character meaning "directly"), but not in ming fonts. Product: Fedora Version: 24 Component: cjkuni-ukai-fonts Severity: medium Assignee: pwu@redhat.com Reporter: mattison.computer@yahoo.com QA Contact: extras-qa@fedoraproject.org CC: i18n-bugs@lists.fedoraproject.org, kent.neo@gmail.com, petersen@redhat.com, pwu@redhat.com
Created attachment 1242997 --> https://bugzilla.redhat.com/attachment.cgi?id=1242997&action=edit shows problem in LibreOffice.
Description of problem:
In UKai fonts, in simplified Chinese, the wrong character is displayed for the pinyin spelling "zhi" (2nd tone) and meaning "straight; vertical; perpendicular; just, upright; frank, straightforward; stiff; numb; to straighten; directly; (other meanings)". But this is not the case when using UMing, WenQuan Yi Zen Hei, and Nimbus Roman fonts. See first comment and attachments for details.
Version-Release number of selected component (if applicable): (unknown)
How reproducible: See first comment.
Steps to Reproduce: See first comment.
Actual results: See first 3 attachments.
Expected results: A UKai version of what's seen in the UMing font. Or see the attachment to bug #1409011 (which was produced by windows-7 office-2016 word).
Additional info:
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #1 from Bill mattison.computer@yahoo.com --- Created attachment 1243000 --> https://bugzilla.redhat.com/attachment.cgi?id=1243000&action=edit shows problem using vi in terminal with UKai font.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #2 from Bill mattison.computer@yahoo.com --- Created attachment 1243001 --> https://bugzilla.redhat.com/attachment.cgi?id=1243001&action=edit shows problem not occurring with vi in terminal with UMing font.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
Bill mattison.computer@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mattison.computer@yahoo.com
--- Comment #3 from Bill mattison.computer@yahoo.com --- find the wrong character - the one in the UKai column of the table in the Writer doc.
* With the font for ibus's libpinyin set to a UKai font, I enter the pinyin spelling "ku" for a Chinese character. Most of the character choices offered are displayed using the UKai font, but a few are displayed using some other (UMing?) font. The same thing happens when I enter the pinyin spelling "mao". Unfortunately, I don't know how to get a screen capture of these.
So the problem shows up multiple places: LibreOffice Writer, the terminal, and ibus's libpinyin. I and the person who worked bug #1409011 both also saw a problem in Firefox. This leads me to suspect that the problem is not in those applications, but in either the character display system or the UKai font or both. I don't know if the problem is * gaps in the UKai font for “simplified” Chinese (the script used in mainland China, but not Taiwan), and the character display software then uses the equivalent “traditional” Chinese characters from the UKai font for “traditional” Chinese (the script used in Taiwan, but not mainland China) as backups; * gaps in the UKai font, and the character display software then uses other fonts as backups; * wrong characters in the UKai font; * mismatches in the UKai font between the keys (unicodes?) of the characters and the data and/or instructions for how to draw the characters; or * something else.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #4 from Bill mattison.computer@yahoo.com --- (I intended this to be comment #1. Also, please disregard comment #3; some of the text I pasted into it got lost.)
I know basically nothing about how character-display generation and fonts work. Also, I'm not fluent in Chinese, I am just (trying to!) learn it, and I'm definitely a beginner. I put a lot of time and effort over the past several days trying to pin down the problem as best as I can from a “black box” perspective. I hope that I've adequately described the problem and how to reproduce it. I do my Chinese input using ibus's libpinyin.
* I used ibus's libpinyin to enter the problem Chinese character into a LibreOffice Writer table with one column for each of 4 fonts. The Ukai column has the wrong character, the 3 rightmost columns have the correct character. More text below the table shows the problem again. Here, too, the Chinese characters are entered using ibus's libpinyin. See the screen capture attachment "UKai_gap.png" to see the page.
* I opened a terminal, set the font to a UKai font, and used vi to create the file "ukai.txt". I used ibus's libpinyin to enter the Chinese phrase. I saved the file. See the screen capture file "ukai.png" to see the result just before exiting vi. The first character of the Chinese line is wrong, just like in LibreOffice Writer.
* I opened a terminal, set the font to a UMing font, and used vi to create the file "uming.txt". I used ibus's libpinyin to enter the Chinese phrase. I saved the file. See the screen capture file "uming.png" to see the result just before exiting vi. The first character of the Chinese line is correct, just like in LibreOffice Writer. By the way, the Chinese phrase is meant to be the same in "ukai.txt" and "uming.txt".
* I can set the font in ibus's libpinyin by running the program "ibus-setup" from a terminal command line. When the font is set to a UKai font, and I enter the pinyin spelling "zhi" for the desired Chinese character, I cannot find the desired Chinese character, but I do find the wrong character - the one in the UKai column of the table in the Writer doc. When the font is set to a UMing font, and I enter the pinyin spelling "zhi" for the desired Chinese character, I do find the desired Chinese character (the one in the UMing column of the table in the Writer doc., but I do not find the wrong character - the one in the UKai column of the table in the Writer doc.
* With the font for ibus's libpinyin set to a UKai font, I enter the pinyin spelling "ku" for a Chinese character. Most of the character choices offered are displayed using the UKai font, but a few are displayed using some other (UMing?) font. The same thing happens when I enter the pinyin spelling "mao". Unfortunately, I don't know how to get a screen capture of these.
So the problem shows up multiple places: LibreOffice Writer, the terminal, and ibus's libpinyin. I and the person who worked bug #1409011 both also saw a problem in Firefox. This leads me to suspect that the problem is not in those applications, but in either the character display system or the UKai font or both. I don't know if the problem is * gaps in the UKai font for “simplified” Chinese (the script used in mainland China, but not Taiwan), and the character display software then uses the equivalent “traditional” Chinese characters from the UKai font for “traditional” Chinese (the script used in Taiwan, but not mainland China) as backups; * gaps in the UKai font, and the character display software then uses other fonts as backups; * wrong characters in the UKai font; * mismatches in the UKai font between the keys (unicodes?) of the characters and the data and/or instructions for how to draw the characters; or * something else.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #5 from Peng Wu pwu@redhat.com --- Please report this UKai font bug to upstream.
URL: https://www.freedesktop.org/wiki/Software/CJKUnifonts/Resources/
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #6 from Bill mattison.computer@yahoo.com --- (In reply to Peng Wu from comment #5)
Please report this UKai font bug to upstream.
URL: https://www.freedesktop.org/wiki/Software/CJKUnifonts/Resources/
Done. It's bug #315606 in their bug-tracking system.
Thank-you, Peng.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
Peng Wu pwu@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|24 |rawhide
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
Satyabrata Maitra smaitra@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |i18n
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
--- Comment #8 from Ben Cotton bcotton@redhat.com --- This message is a reminder that Fedora 27 is nearing its end of life. On 2018-Nov-30 Fedora will stop maintaining and issuing updates for Fedora 27. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '27'.
Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version.
Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 27 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above.
Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
https://bugzilla.redhat.com/show_bug.cgi?id=1415322
Bill mattison.computer@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|27 |28
--- Comment #9 from Bill mattison.computer@yahoo.com --- As of November 27, 2018, this problem still occurs in Fedora-28.
i18n-bugs@lists.fedoraproject.org