Bug 72483 - various problems in UTF8 compose rules
various problems in UTF8 compose rules
Status: CLOSED CURRENTRELEASE
Product: Red Hat Public Beta
Classification: Retired
Component: XFree86 (Show other bugs)
null
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-24 08:15 EDT by Alexandre Oliva
Modified: 2007-04-18 12:45 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-20 10:59:09 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch containing the two patches and the corresponding change to the spec file. (11.76 KB, patch)
2002-08-24 08:18 EDT, Alexandre Oliva
no flags Details | Diff

  None (edit)
Description Alexandre Oliva 2002-08-24 08:15:59 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020809

Description of problem:
I've noticed three important problems in the utf8 compose rules:

the sequence <dead_circumflex> <space> was not defined

the sequence <dead_acute> <dead_acute> did not take effect, even though it was
defined

the sequence <dead_acute> <c> didn't produce g, like it used to in the en_US
locale, but rather &#263;

While verifying whether these problems had already been fixed in XFree86 CVS,
I've merged a number of typo fixes, included in the first patch contained in the
attached patch file.

The second attached patch file attempts to fix the three problems I described. 
It does fix the first problem, for sure.  The second is trickier, because there
are sequences starting with <dead_acute> <dead_acute>, followed by o and u, that
are used to create &#337; and &#369;.  This disables entirely the rule to
generate the acute accent.  I ended up fixing the rule such that, with one more
dead_acute, you'd get an acute accent, and with a space, you'd get a
doubleacute.  It even makes some sort of sense: dead_accent followed by space
generates the accent, in ascii if possible, but there's no ascii for
double_acute.  The closest is quotedbl, but that's already covered with
dead_diaeresis.

The last and trickiest problem, was that of ccedilla.  It's way too common in
Portuguese to require as cumbersome a sequence as <Multy_key> <comma> <c>, but I
don't think it's reasonable to turn a perfectly valid sequence, <dead_acute>
<c>, that generates a perfectly valid &#263;, into something else that doesn't
make as much sense.  However, being quite used to typing <dead_acute> <c> to get
g, I thought I could at least get something closer that made more sense.  That
was how I came up with the sequence <dead_acute> <comma> <c>.  <dead_acute> is
not as awkward to type as <Multi_key>, and it doesn't require two neighbor keys
to be held pressed at the same time, so I thought it would be an improvement,
and while at that, I introduced <dead_acute> <comma> <space> as a way to
generate cedilla too.  However, since double <dead_acute> was already
overloaded, and it didn't have any sequence ending in <c>, I thought I could use
that too.

I'm submitting the patch with these changes to XFree86, but I don't know whether
the changes for cedilla are going to be accepted.  The others definitely should,
so feel free to merge only them in.  Putting the others in would be appreciated,
though, since it can't possibly hurt to have more ways to generate a common
sequence, can it?
Comment 1 Alexandre Oliva 2002-08-24 08:18:20 EDT
Created attachment 72727 [details]
Patch containing the two patches and the corresponding change to the spec file.
Comment 2 Mike A. Harris 2002-09-01 06:20:22 EDT
Defering for upstream inclusion.
Comment 3 Alexandre Oliva 2002-09-01 12:59:19 EDT
Are you deferring the installation even of those typo fixes merged from XFree86
CVS in the first patch contained in the patch file I posted?
Comment 4 Daniel Resare 2002-09-12 07:20:51 EDT
Does deferred mean that these problems will not be fixed in the next public
release? Not being able to type ^ (circumflex, ascii 0x5e) the ususal way
certainly will be a big problem lots of people worldwide.
Comment 5 Mike A. Harris 2005-04-20 10:59:09 EDT
Since this bugzilla report was filed, there have been several major
updates to the X Window System, which may resolve this issue.  Users
who have experienced this problem are encouraged to upgrade to the
latest version of Fedora Core, which can be obtained from:

        http://fedora.redhat.com/download

If this issue turns out to still be reproduceable in the latest
version of Fedora Core, please file a bug report in the X.Org
bugzilla located at http://bugs.freedesktop.org in the "xorg"
component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes that
become available for consideration in future updates.

Setting status to "CURRENTRELEASE".

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