Bug 1415322

Created attachment 1243000 [details]
shows problem using vi in terminal with UKai font.

Created attachment 1243001 [details]
shows problem not occurring with vi in terminal with UMing font.

 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.

(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.

Please report this UKai font bug to upstream.

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

(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.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

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.

As of November 27, 2018, this problem still occurs in Fedora-28.

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?

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.

(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>:
550: 5.1.1 <arne>: Recipient address rejected: User unknown in virtual alias table

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

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/

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

The upstream seems not active now.

(In reply to Peng Wu from comment #16)
> The upstream seems not active now.

I'm not surprised.

I do appreciate the effort you did put into this.

I saw somewhere (I don't remember where), some time ago (I don't recall when), that Fedora was changing to google fonts.  I looked at google fonts today to see if they had something equivalent to the "AR PL Ukai" fonts.  I didn't see anything really close.  The kai (or kaiti, maybe also called "regular"?) fonts are among the most used of Chinese fonts.  Is there another source of these that Fedora can adopt to replace the "AR PL Ukai" fonts?

Sorry, I dunno. Usually the UKai font glyph issues are fixed by upstream.

UKai is Traditional Chinese fonts, the glyph may be correct for Traditional Chinese, but not sure.