Created attachment 3176 [details] [review]
xls_locale_en_US

This patch at a first glance, seems to undo a change that was made before
to fix other bugs.  This might be a case of having 2 problem cases, and
having to pick between which one is fixed and which one stays broken
perhaps.

Before anyone commits this to CVS, please go back through CVS history
and logs to make sure this doesn't cause a regression ping-pong
cascade scenario.

Owen: Do you remember this issue at all?

Not in detail at this point. In general, I think that changing the 
en_US_UTF8 file to try and fix stuff up for cyrillic at this point
is mistake. Don't wake the sleeping monster. We have a better font
system now; trying to fix stuff like this will only break something
else.

If anything, the only right thing to do would be to add a separate
config for ru_RU.UTF-8 (and other cyrillic locales).

Valery, your patch also resolves the problem with broken "³" character in
GTK+-based apps when using pl_PL.UTF-8 locale →
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160554 :D

(In reply to comment #4)
> Not in detail at this point.

Yeah, I don't recall either.  It's something that could be pulled from a
changelog, commit mail, or bug report somewhere though if we really needed
to find it, but I don't think that's necessary.  I remember that it was
changed to be this way intentionally for a reason, even though I don't
remember the reason off hand.  ;o)   All I remember about it besides that,
was that you were CC'd on the bug and IIRC made the recommendation for
the change to solve the problem. ;)

> In general, I think that changing the 
> en_US_UTF8 file to try and fix stuff up for cyrillic at this point
> is mistake. Don't wake the sleeping monster. We have a better font
> system now; trying to fix stuff like this will only break something
> else.

Indeed.

> If anything, the only right thing to do would be to add a separate
> config for ru_RU.UTF-8 (and other cyrillic locales).

That seems to be a much more sensible solution for this bug.  Does someone
want to go ahead and do that and attach a patch to add ru_RU.UTF-8 support?

Setting to NEEDINFO

The same suggestion applies to the pl_PL.UTF-8 locale.

(In reply to comment #6)
> > Not in detail at this point.
> 
> Yeah, I don't recall either.  It's something that could be pulled from a
> changelog, commit mail, or bug report somewhere though if we really needed
> to find it, but I don't think that's necessary.

I looked through the CVS and found this:
http://cvs.freedesktop.org/xorg/xc/nls/XLC_LOCALE/en_US.UTF-8 (rev. 1.2.4.1)

2004-12-12 Roland Mainz <roland.mainz@email-protected>
  * xc/nls/XLC_LOCALE/en_US.UTF-8
  Bug #1842 (https://bugs.freedesktop.org/show_bug.cgi?id=1842)
  attachment #1389 [details] [review] (https://bugs.freedesktop.org/attachment.cgi?id=1298):
  Move iso10646 last so the "fallback"
  fonts will actually be used if they are better matches.

In bug #1842 there's a link to RH Bugzilla ->
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=77045

> That seems to be a much more sensible solution for this bug.  Does someone
> want to go ahead and do that and attach a patch to add ru_RU.UTF-8 support?

I can try writing a patch for pl_PL.UTF-8 locale. I 've been searching for the
documentation and I've found only this document ->
/usr/share/doc/xorg-x11-doc-6.8.2/i18n/LocaleDB.PS.gz (FC4's xorg-x11-doc
package). Is there anything else what can help me with this task?

Created attachment 3448 [details] [review]
Fixes broken characters in pl_PL.UTF-8 locale

I haven't checked this in the real build system (compilation of the monolitic
X.org X11 realease takes ages on my crappy box) but I've made all the changes
manually and everything seems to work fine. It's based on the en_US.UTF-8 and
iso8859-2 locale (information included in LocaleDB.PS.gz file was also really
helpful).

Another one for ru_RU.UTF-8:

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170925

Marking broken (status null/blank) bugs in xorg with no activity in a long time as fixed. Please reopen if you think it's necessary, but first do a search if a similar bug report is already filed and in a NEW/ASSIGNED state. These bugs do not currently show in most search results as they do not have any status.

Sorry for this janitorial spam, you know where to send hate mails to when your inbox gets full of bugs you're subscribed to.