Bug 68725

Created attachment 65185 [details]
first evolution screen

Created attachment 65186 [details]
gnumeric

*** Bug 67129 has been marked as a duplicate of this bug. ***

*** Bug 67136 has been marked as a duplicate of this bug. ***

*** Bug 67144 has been marked as a duplicate of this bug. ***

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.

*** Bug 73659 has been marked as a duplicate of this bug. ***

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)

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

I will monitor XFree86 CVS for commits for this issue.

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

They told me that if I do it myself it will be commited. So work is in progress.

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 
 

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.

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.

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.

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.

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.

Re: comment #19. Should this inconsistency in gtkrc's be considered a bug?

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.

*** Bug 101224 has been marked as a duplicate of this bug. ***

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.

Thanks, I've added myself to the upstream bug CC.

Changing status to UPSTREAM for tracking.

I've filed http://freedesktop.org/bugzilla/show_bug.cgi?id=708

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.