Bug 68725 - (xkb) Add ru_RU.UTF-8 locale for Xlib
(xkb) Add ru_RU.UTF-8 locale for Xlib
Status: CLOSED UPSTREAM
Product: Fedora
Classification: Fedora
Component: xorg-x11 (Show other bugs)
rawhide
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
http://freedesktop.org/bugzilla/show_...
Awaiting upstream changes to incorporate
:
: 73659 101224 (view as bug list)
Depends On:
Blocks: 67218 79579 82770
  Show dependency treegraph
 
Reported: 2002-07-12 17:54 EDT by Leonid Kanter
Modified: 2007-11-30 17:10 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-02-18 00:21:13 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
first evolution screen (9.91 KB, image/png)
2002-07-12 17:54 EDT, Leonid Kanter
no flags Details
gnumeric (25.01 KB, image/png)
2002-07-12 17:55 EDT, Leonid Kanter
no flags Details
gaim login window in C and ru_RU.UTF8 - compare font size (58.54 KB, image/png)
2003-01-28 17:14 EST, Leonid Kanter
no flags Details
the same pair of windows but with 75dpi koi8-r fonts (42.21 KB, image/png)
2003-01-28 17:31 EST, Leonid Kanter
no flags Details
test XLC_LOCALE for ru_RU.UTF-8 (4.41 KB, application/octet-stream)
2003-01-28 17:35 EST, Leonid Kanter
no flags Details

  None (edit)
Description Leonid Kanter 2002-07-12 17:54:02 EDT
Description of Problem:

See attachments (screenshots of evolution and gnumeric)

Version-Release number of selected component (if applicable):

gnome-libs-1.4.1.2.90-18

How Reproducible:

always


Additional Information:
	
ru_RU.UTF-8 locale
Comment 1 Leonid Kanter 2002-07-12 17:54:46 EDT
Created attachment 65185 [details]
first evolution screen
Comment 2 Leonid Kanter 2002-07-12 17:55:46 EDT
Created attachment 65186 [details]
gnumeric
Comment 3 Havoc Pennington 2002-07-14 20:07:51 EDT
*** Bug 67129 has been marked as a duplicate of this bug. ***
Comment 4 Havoc Pennington 2002-07-14 20:08:06 EDT
*** Bug 67136 has been marked as a duplicate of this bug. ***
Comment 5 Havoc Pennington 2002-07-14 20:08:29 EDT
*** Bug 67144 has been marked as a duplicate of this bug. ***
Comment 6 Owen Taylor 2002-08-13 23:53:41 EDT
This is closely related to bug 69285 (see my comment about why
the spacing out occurs), but has the additional issue that 
our X configuration doesn't really work for ru_RU.UTF-8;
basically the en_US.UTF-8 locale needs to be duplicated
to a ru_RU.uTF-8 locale, and koi8-r fonts added, then the
locale.alias / locale.dir files updated.
Comment 7 Owen Taylor 2003-01-14 17:39:53 EST
*** Bug 73659 has been marked as a duplicate of this bug. ***
Comment 8 Owen Taylor 2003-01-14 17:45:02 EST
Reassigning to Xlib, since it's completely a problem with the config files 
in XFree86-libs-data. 

The current XFree86 now has locales for el_GR.UTF-8, ja_JP.UTF-8,
ko_KR.UTF-8, th_TH.UTF-8, but still no cyrillic Unicode locales.
(I think one locale probably can do for all Cyrillic locales - you
could include both koi8-r and koi8-u in the config file)
Comment 9 Mike A. Harris 2003-01-15 08:48:26 EST
Please report this issue to XFree86.org upstream developers.  Someone can
likely make the changes trivially to CVS and commit it, at which point
I can get it in a CVS update.  That is the fastest way to get changes
like this integrated.  xfree86@xfree86.org

I will monitor XFree86 CVS for commits for this issue.
Comment 13 Mike A. Harris 2003-01-26 01:28:24 EST
Ping...

Has anyone requested this feature be added upstream?  My own personal
requests upstream related to xkb do not get "positive" responses and
tend to lower the chances of the changes being made due to political
reasons I wont go into here.  If someone wants this change implemented
I strongly suggest emailing the request to xfree86@xfree86.org, because
if I do it it will most likely get ignored.  If nobody is willing to
submit this request upstream, I might as well close it WONTFIX because
I most likely wont be trying to figure out how to do this correctly
myself anytime soon.

Please respond.
Comment 14 Leonid Kanter 2003-01-26 05:42:22 EST
They told me that if I do it myself it will be commited. So work is in progress.
Comment 15 Leonid Kanter 2003-01-28 17:08:40 EST
I tried to create ru_RU.UTF-8/XLC_LOCALE entry and modify locale.dir. If koi8-r fonts are 
listed upper than 10646-1, they are used by gtk1 applications but applications look horrible. 
Metrics of 100dpy cyrillic fonts which are currently used in RH are quite incompatible with other 
applications. See screenshot attached 
 
Comment 16 Leonid Kanter 2003-01-28 17:14:58 EST
Created attachment 89664 [details]
gaim login window in C and ru_RU.UTF8 - compare font size

See that 100dpy cyrillic fonts are much bigger than regular fonts used by the
same application in C or en_US locale.
Comment 17 Leonid Kanter 2003-01-28 17:31:01 EST
Created attachment 89666 [details]
the same pair of windows but with 75dpi koi8-r fonts

I removed all broken cyrillic 100dpi fonts from system (fonts-KOI8-R-100dpi and
XFree86-cyrillic-fonts packages) and installed fonts-KOI8-R-75dpi. Things look
_much_ better.
Comment 18 Leonid Kanter 2003-01-28 17:35:05 EST
Created attachment 89667 [details]
test XLC_LOCALE for ru_RU.UTF-8

This is a small test suite. XLC_LOCALE is incomplete and based on koi8-r entry,
but it works. To test it, you should untar this file in
/usr/X11R6/lib/X11/locale directory.
Comment 19 Owen Taylor 2003-01-28 17:36:47 EST
Do you have 100dpi KOI-8 fonts first in your font path, but 75dpi ISO-8859-1
fonts?

In the C locale, GTK+ uses:

 -adobe-helvetica-medium-r-normal--*-120-*-*-*-*-iso8859-1

While /etc/gtk/gtkrc.utf8 has:

  fontset = "-*-helvetica-medium-r-normal--*-120-*-*-p-*-*-*"

So, there should be no difference in font size if the fonts available
are the same. (On the other hand /etc/gtk/gtkrc.ru has:

 adobe-helvetica-medium-r-normal--12-*-*-*-*-*-iso8859-*

so the font in ru_RU.KOI8-R would be be expected to be different
if 100dpi fonts are first in your font path.
Comment 20 Leonid Kanter 2003-01-28 17:51:19 EST
You are right. But in default phoebe install 75dpi iso8859-1/iso10646-1 fonts
are listed first, while 75dpi cyrillic fonts are absent at all. I can't
understand why package fonts-KOI8-R-75dpy was removed from distribution.
Comment 21 Aleksey Nogin 2003-01-28 18:02:01 EST
Re: comment #19. Should this inconsistency in gtkrc's be considered a bug?
Comment 22 Mike A. Harris 2003-07-17 05:50:24 EDT
Just noticed this bug was flagged as UPSTREAM to track, but there is no
upstream bug URL present in this bug report to track it.  Closing bug
as WONTFIX for now, however if this problem is still relevant in rawhide,
feel free to report it upstream at http://bugs.xfree86.org and then reopen
this report after pasting the upstream bug report URL into a comment, and
I will track the issue upstream and consider backporting any fixes that
go into official CVS.

Thanks.
Comment 23 Owen Taylor 2003-10-27 15:25:08 EST
*** Bug 101224 has been marked as a duplicate of this bug. ***
Comment 24 Aleksey Nogin 2004-02-17 23:17:09 EST
I filed http://bugs.xfree86.org/show_bug.cgi?id=1186 - hope I
formulated it correctly (I was hoping that somebody who understands
how it all works would file it upstream, but that never happened :-( ).

P.S. The relevant bugs (at least bug 73659) still exist in Fedora Core
1, so updating the product/release.
Comment 25 Mike A. Harris 2004-02-18 00:21:13 EST
Thanks, I've added myself to the upstream bug CC.

Changing status to UPSTREAM for tracking.
Comment 26 Aleksey Nogin 2004-06-01 07:01:05 EDT
I've filed http://freedesktop.org/bugzilla/show_bug.cgi?id=708
Comment 27 Mike A. Harris 2004-09-01 06:24:25 EDT
Added myself to upstream bug tracker and requested upstream review
for issue.  I suggest making it easy for upstream to review, by
attaching a unified diff (diff -u) of the proposed changes created
against the xkb source code (not installed system files) directly
to the upstream bug report, since the more work upstream developers
have to do in order to review a change, the lower the priority it
is likely to be for them to review.  That's the only reason I can
think of that this hasn't received comment so far upstream, and
hasn't made the 6.8.0 release.


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