Bug 101588 - Can't write the cedila (ç) char
Can't write the cedila (ç) char
Status: CLOSED DUPLICATE of bug 80244
Product: Red Hat Linux
Classification: Retired
Component: XFree86 (Show other bugs)
8.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Mike A. Harris
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2003-08-04 10:46 EDT by Avi Alkalay
Modified: 2007-04-18 12:56 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-02-21 13:57:57 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)
Screenshot of the bug description text, to avoid bad charset conversion (68.02 KB, image/png)
2003-08-04 10:49 EDT, Avi Alkalay
no flags Details
OpenOffice-created bug text (5.49 KB, application/octet-stream)
2003-08-04 10:50 EDT, Avi Alkalay
no flags Details

  None (edit)
Description Avi Alkalay 2003-08-04 10:46:09 EDT
Description of problem:
I'm using Red Hat Linux 8.0 configured to Brazilian Portuguese with UTF-8, 
using redhat-config-keyboard us-acentos.

The correct way to make the 'ç' char appear is to compose it with a “'” and 
a “c”. But what I'm getting instead is a 'ć' char in KDE or Gnome, which 
doesn't exist. Currently the unique way to make the 'ç' char is thru a 
kcharselect-like program. All other accents work with the “'” composition.

Some other clues: When I use kterm with any font (including fixed) I still get 
the 'ć' char. When I use superplain xterm with superplain fixed font, instead 
of the unwanted 'ć' char, I get a white space. All other composed chars, 
like 'á', 'ê', 'õ', appear.

When I switch to ISO-8859-15 (or ISO-8859-1) (LANG=”pt_BR.ISO8859-15”) I can 
create the “ç” and all other accents with no problem.

I'm not sure if the us-acentos keymap is used only for pure-text (no X Window). 
But anyway, I don't have keyboard accents at all in a pure-text (frame-buffered 
though) command line.

I couldn't figure out if this is a charset, keyboard translation, or font 
problem.

I'll attach a screenshot of this text, to avoid incorrect charset conversion in 
the reader's system.




Steps to Reproduce:
1. Configure KDE or Gnome to Brazilian Protuguese
2. Open any X program (OpenOffice, kterm, kate)
3. Create composed chars using "'" as prefix
4. Use it to create the cedilla (ç): "'" + "c"



    
Actual results:
ć




Expected results:
ç
Comment 1 Avi Alkalay 2003-08-04 10:49:17 EDT
Created attachment 93372 [details]
Screenshot of the bug description text, to avoid bad charset conversion
Comment 2 Avi Alkalay 2003-08-04 10:50:51 EDT
Created attachment 93373 [details]
OpenOffice-created bug text
Comment 3 Alexandre Oliva 2003-08-08 20:19:45 EDT
Try compose (= right-alt) comma c.  This works for me, with a us-intl keyboard
configuration in X, but on Shrike.  I'm afraid I don't remember whether keymap
fixes to enable this sequence made it to 8.0.  It's been a while.
Comment 4 Alexandre Oliva 2003-08-08 20:24:23 EDT
I just remembered that I have RPMS for 8.0 that introduce ',c as a sequence to
generate ç, but they're significnatly outdated now (e.g., they certainly don't
include any recent bug-fixes in the XFree86 pakcages).  You may still get the
RPMS, SRPMS and the patch for the spec file, in case you decide to merge the
fixes into a newer SRPM, in ftp://people.redhat.com/aoliva/8.0.
Comment 5 Avi Alkalay 2003-08-10 11:23:52 EDT
On RH8, I tried right-alt+'+c and got "¢". Actually the "'" is not needed to make this char. 
On caps I got the copyright sign: © 
 
The compatible, lets say "correct", way to make the ç char is with "'" + c. 
On RH9 how the cedilla char can be generated? 
 
Thank you, 
Avi 
 
Comment 6 Alexandre Oliva 2003-08-10 15:46:43 EDT
comma is , not '.  Try Right-alt , c.  Or maybe your compose character is mapped
to something other than right-alt?  Or maybe you're not using a keyboard
configuration that has a compose key.  

Anyway, using 'c for ç was a mistake, since there are languages that use the ć
character, and UTF8 is an encoding that is meant to support all languages. 
Favoring Portuguese over Czech didn't feel right.  This was mistake was fixed in
some version of XFree86 (4.2?), that was adopted in Red Hat Linux 8.0 (IIRC).

My personal recommendation is to use the us_intl keymap if you have a us
keyboard, then the sequence compose ,, will generate ¸ (cedilla), and compose ,c
will generate ç (c-cedilla); if you have abnt-2 you already have a ç key.  I
actually use the gnome keyboard layout switcher to switch between a US and a
US-intl configuration, such that, with a keystroke like Super-Shift (Super is
the Windows-logo key), I can enable or disable compose rules and dead accents. 
IIRC KDE has something similar.

Would this setup work for you?
Comment 7 Avi Alkalay 2003-08-15 18:54:44 EDT
I'm using US-International configuration.
I made it happen on RH8 with the compose key.
But in another machine with RH9 it didn't worked.

In addition, I discovered something new: Can't create the '"' (aspas) char. 
Using compose or shift, makes appear '¨' (trema) char.
Comment 8 Avi Alkalay 2003-08-15 18:57:40 EDT
This last update is on a RH9 installation.
Comment 9 Alexandre Oliva 2003-08-15 20:38:17 EDT
Compose (Right-Alt) Shift ' should generate " in a us-intl keyboard.  There was
a patch for XFree86 that changed the UTF8 compose rules such that Shift ' blank
would generate it as well, but the changes were considered too risky for Shrike,
so we left them out.  They made it to Severn, though.  At some point Mike
suggested we might offer the patched UTF8 Compose rules as a file in
/usr/share/doc or so, but I can't find anything like that atm.  Mike, did we
carry that plan out, or does one have to actually rebuild the XFree86 RPMS after
removing the Compose rules patch from the spec file to get the new compose rules
enabled?
Comment 10 Alexandre Oliva 2003-08-15 20:40:52 EDT
Oops, I take that part of what I just wrote back.  " space doesn't generate a "
with X applications (say xterm or GNU Emacs), only in GTK applications (gtk uses
its own rules).
Comment 11 Avi Alkalay 2003-08-18 11:13:01 EDT
I'm working on some schools to deliver Linux labs to the students.
It is being very hard to find and explain this extra-terrestrial composition 
keys to them, specially when they are used to Windows.
This is bad for cultural user migration.

I think RH should look for Windows compatible keymaps. US-International keymaps 
on Linux should be identical to US-International keymaps on Linux. This is waht 
people are used to. UTF-8 is solving many problems but are creating others that 
may be bigger, specially when related to Windows migration.
Comment 12 Mike A. Harris 2003-08-18 11:26:10 EDT
Red Hat does not maintain nor have the resources to maintain a separate fork
of the XFree86 keymap file databases and other related files.  It is critically
important that there is one official master database, which is authoritative,
and which Red Hat, and all other distributions and OS's out there use.  That
official place is XFree86.org.  The experts in the xkb area are all at
XFree86.org as well, in particular Ivan Pascal, and Ivan as well as others
incorporate xkb changes into XFree86 CVS very quickly, and discuss reported
bugs and requests also very quickly.

The best place for any changes to xkb and related i18n files is thus at
XFree86.org, and not at Red Hat.  The changes get dealt with and/or included
at XFree86.org as reported rather quickly, and the experts in this area are
located there.  This provides Red Hat and other distributions with a central
area to get speedy changes to xkb from, and ensures cross OS and distribution
similarities.

Any discussion of making any major changes to xkb should be done at XFree86.org
on it's mailing lists.  Red Hat, like all other vendors, is going to follow
the official standard, and that standard is currently what ships with XFree86.
In general, I will not apply any xkb related patches, until someone has
submitted their suggestions/requests directly to XFree86.org via their bugzilla
located at http://bugs.xfree86.org and the changes requested have been commited
into the XFree86 development CVS repository and are deemed complete and safe
for inclusion in the existing product or erratum.  This is important both for
quality control, and for standardization and consistency.


Re: UTF-8

If you're refering to Red Hat Linux's change to use UTF-8 by default in
Red Hat Linux 8.0 everywhere, this change was made with an incredible amount
of thought, and the decision to use UTF-8 was unanimous that it was the best
thing to do and the right time to do it.  UTF-8 has been common in the Windows
using world since 1995, and is very important in the future of Linux.  The
sooner the changeover was made, the better for all multilingual users.

A bugzilla bug report against XFree86 is not however the proper forum to
debate that or discuss that though, so I won't get into further detail.
You may wish to search Red Hat mailing list archives for similar discussions
however which may provide the answers you're looking for, or to post a
question about UTF-8 there, and someone will likely go into greater detail.

Hope this helps.
Comment 13 Mike A. Harris 2003-08-18 11:30:01 EDT
Alex:  The changes you mention, which were disabled for Shrike due to being
considered a risk, I had planned on enabling in rawhide ASAP after shrike's
release, and up until today, I thought they were in fact disabled.  I just
checked a while ago however, and the 2 patches were still being applied,
giving the Shrike behaviour.  I've disabled the 2 patches now, and the next
build of 4.3.0-20 will contain this change.

I'm assuming that this new build will fix the problem described in this report
and setting the status to MODIFIED.  Once one of you has had the chance to
test this, please set the status to RAWHIDE if the problem is resolved now,
or set it back to ASSIGNED otherwise.  If the problem does persist, please
report the issue at http://bugs.xfree86.org if it isn't already, and please
include the upstream bug URL so that I can track XFree86.org's official
response and try to make our standard release compatible with their current
bits, backporting bugfixes if possible.

Thanks in advance guys.
Comment 14 Avi Alkalay 2003-08-18 11:54:49 EDT
Regarding the keymaps, I created the bug 608 in http://bugs.xfree86.org.

Regarding UTF-8, I don't know why everybody says Windows is UTF-8 or any 
Unicode. In any brazilian protugues Windows installation I saw or installed 
(XP, 2k, 9x), text files and filenames are always Latin1. In fact, I could 
never make a Windows machine work on any Unicode mode (only Internet Explorer 
when the web page explicitly asks for it in the header). And I can tell you I 
have spent some time trying to do specifically this configuration, without 
success.
Comment 15 Alexandre Oliva 2003-08-18 12:42:33 EDT
Mike, in order to fix the `aspas' (quotedbl) problem, we need the patch I
mentioned in that other bug, that made it to XFree86 CVS after the 4.3.0
release.  I hope it made it to 4.3.0-20, otherwise, would you please start
another build with that patch in?
Comment 16 Alexandre Oliva 2003-08-19 13:09:23 EDT

*** This bug has been marked as a duplicate of 80244 ***
Comment 17 Red Hat Bugzilla 2006-02-21 13:57:57 EST
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.

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