Bug 217847

Summary:	[zh_CN/TW]the spacing of password is abnormal in login screen
Product:	[Fedora] Fedora	Reporter:	Akira TAGOH <tagoh>
Component:	fonts-chinese	Assignee:	Caius Chance <K9>
Status:	CLOSED WONTFIX	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	eng-i18n-bugs
Target Milestone:	---	Keywords:	i18n
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2007-03-19 00:31:33 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Akira TAGOH 2006-11-30 11:54:17 UTC

+++ This bug was initially created as a clone of Bug #216099 +++

Description of problem:
the spacing of password is abnormal on zh_CN and zh_TW locales in login screen. 

Version-Release number of selected component (if applicable):
gdm-2.16.0-19.el5
RHEL5-Client-20061111.0

How reproducible:
Always

Steps to Reproduce:
1.Log in system on zh_CN or zh_TW locale.
2.Type username and password.
3.
  
Actual results:
The spacing and character size is not same as that on en_US locale. The spacing
is big and character is displayed a small point.

Expected results:


Additional info:

-- Additional comment from mclasen on 2006-11-17 15:01 EST --
This looks like a font issue to me

-- Additional comment from pm-rhel on 2006-11-19 21:40 EST --
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

-- Additional comment from phuang on 2006-11-30 00:45 EST --
Password char is U+2022. Its width in Japanese font is bigger than others.

-- Additional comment from tagoh on 2006-11-30 06:51 EST --
After some discussion with Peng and testing, we found that uming.ttf and
ukai.ttf introduced this issue. current schedule is that tight and we aren't
confident to get the right fix in uming and ukai. so just removing U+2022 from
them is realistic and certain way for a workaround.

we may want to clone this bug for FC to get the right fix for future release.

Comment 1 Caius Chance 2007-03-16 06:50:49 UTC

It's technically is not a bug because in unicode, the character's description is
'BULLET, black small circle' which it is reasonable to be small.

How about we use U+25CF as password mask? Or there is a GNOME-wide or Red Hat
standard to use U+2022 as mask?

It would be fine to make U+2022 larger if the mainstream feedbacks think it has
to be scaled up.

Comment 2 Caius Chance 2007-03-19 00:31:33 UTC

Consulted upstream of uming.ttf & ukai.ttf, Arne Götje (IRC: irc.freenode.net
#cjkunifonts), such glyph is made by the original donator Arphic. 

Moreover, he suggested that the glyph size is reasonable which he is not
recommended to make changes on our side as well as he has no intention to that
on his future release.

Closing this bug as WONTFIX. If anyone insists that the glyph is not acceptable.
I personally recommend U+25CF as a replacement of the password mask. Please then
create a new bug to certain GNOME component to request for a change.