Bug 1415322 - Wrong character displayed in UKai fonts for "zhi" (2nd tone) (character meaning "directly"), but not in ming fonts.
Summary: Wrong character displayed in UKai fonts for "zhi" (2nd tone) (character meani...
Keywords:
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: cjkuni-ukai-fonts
Version: 31
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Peng Wu
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-20 20:57 UTC by Bill
Modified: 2019-08-13 19:28 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:


Attachments (Terms of Use)
shows problem in LibreOffice. (249.36 KB, image/png)
2017-01-20 20:57 UTC, Bill
no flags Details
shows problem using vi in terminal with UKai font. (67.31 KB, image/png)
2017-01-20 21:01 UTC, Bill
no flags Details
shows problem not occurring with vi in terminal with UMing font. (72.86 KB, image/png)
2017-01-20 21:03 UTC, Bill
no flags Details

Description Bill 2017-01-20 20:57:52 UTC
Created attachment 1242997 [details]
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:

Comment 1 Bill 2017-01-20 21:01:24 UTC
Created attachment 1243000 [details]
shows problem using vi in terminal with UKai font.

Comment 2 Bill 2017-01-20 21:03:16 UTC
Created attachment 1243001 [details]
shows problem not occurring with vi in terminal with UMing font.

Comment 3 Bill 2017-01-20 21:07:58 UTC
 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.

Comment 4 Bill 2017-01-20 21:12:57 UTC
(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.

Comment 5 Peng Wu 2017-01-22 01:14:29 UTC
Please report this UKai font bug to upstream.

URL: https://www.freedesktop.org/wiki/Software/CJKUnifonts/Resources/

Comment 6 Bill 2017-01-24 16:02:07 UTC
(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.

Comment 7 Jan Kurik 2017-08-15 09:35:34 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

Comment 8 Ben Cotton 2018-11-27 16:18:27 UTC
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.

Comment 9 Bill 2018-11-27 17:28:17 UTC
As of November 27, 2018, this problem still occurs in Fedora-28.

Comment 10 Bill 2019-02-13 19:54:07 UTC
Today (Feb. 13), I tried to find out the status of this bug and bug 315606 in the cjkunifonts-Bugs (a part of alioth.debian.org).  Bug 315606 was submitted as advised in comment #6 above.  I was unable to find the cjkunifonts-Bugs web page.  I took the problem to the Fedora users list for advice.  Matthew Miller (Fedora Project Leader) suggested that I follow up here.  See
"https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org/thread/TPOFBYEQZREFKBFRPZOICY7SBXY2UZKS/"
for that thread.

I believe that the strategy of having
"the problem fixed in the font itself, not as a one-off patch. That makes sense -- that way it gets fixed for everyone in the world, not just Fedora."
is the correct one.  But Matthew, like me, also could not find cjkunifonts-Bugs bug 315606.

How do we get the font itself properly fixed?  Is there something more that I should do?

Comment 11 Peng Wu 2019-02-14 04:19:27 UTC
It seems the upstream project is not active now.

Maybe you could send an email to ask arne at ubuntu dot com about current status of the project.

Comment 12 Bill 2019-02-14 20:48:21 UTC
(In reply to Peng Wu from comment #11)
> It seems the upstream project is not active now.
> 
> Maybe you could send an email to ask arne at ubuntu dot com about current
> status of the project.

I did so.  You were bcc'd.

The message bounced with the following error:
==================
Sorry, we were unable to deliver your message to the following address.

<arne@ubuntu.com>:
550: 5.1.1 <arne@ubuntu.com>: Recipient address rejected: User unknown in virtual alias table

--- Below this line is a copy of the message.
[... snip ...]
==================
What now?

Comment 13 Peng Wu 2019-02-15 07:01:22 UTC
Maybe you could contact the general mailing list of Ubuntu or Debian.

URL:
https://lists.ubuntu.com/mailman/listinfo/ubuntu-devel
https://lists.debian.org/debian-devel/

Comment 14 Ben Cotton 2019-08-13 17:04:14 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 15 Ben Cotton 2019-08-13 19:28:27 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.


Note You need to log in before you can comment on or make changes to this bug.