Bug 19506

As it was mentioned in xorg the maillist, for producing multiple chars on one keypress, you should use some input method. For the rest of the layout, it should be trivial to make a patch for symbols/fr and rules/base.xml.in. Looking forward to it.

Using XIM, I finally managed to map the C'H and CH keys to multiple
characters. My C'HWERTY keyboard now fully works.

In the discussion in the Xorg mailing list, it is suggested to add
keysyms for those Breton trigraph and digraph:

http://lists.freedesktop.org/archives/xorg/2009-January/042356.html

For the record, all the files that I modified the get my C'HWERTY
keyboard to work are available at:

http://dominiko.livejournal.com/20206.html

The patches for symbols/fr and rules/base.xml look ok to me. Will apply them.

I took freedom to remove the GPL clause, because xkeyboard-config is licensed under X11 licence. Also, I changed the variant name to "bre" because it is assigned to Breton by ISO 639-1. Are you ok with these changes?

Committed. Thanks for the contribution!

> I took freedom to remove the GPL clause, because xkeyboard-config
> is licensed under X11 licence. Also, I changed the variant name
> to "bre" because it is assigned to Breton by ISO 639-1. Are you
> ok with these changes?

Of course, that's fine.  Glad it gets integrated so quickly!

/Dominique

Your use of the private-use chars keysyms was indeed the right thing to
do locally.

I see that you, as I suspected from reading the web pages you mentioned
earlier, needed six keysyms.

I need to determine where to stick the new keysyms.  Are you aware of
any encodings where those letters exist as single characters?

(In reply to comment #7)

> I see that you, as I suspected from reading the web pages you mentioned
> earlier, needed six keysyms.
> 
> I need to determine where to stick the new keysyms.  Are you aware of
> any encodings where those letters exist as single characters?

First of all, I'm not an expert, I'm only learning the language.
It would be nice to get the advice from an expert.

Having said that, this is what I found online: even though C'H and CH
are considered as unique letters in Breton, there is no existing
encoding with the C'H trigraph or CH digraph as one single character,
as far as I know. At least Unicode does not have yet such character
as I see in this FAQ:

http://www.drouizig.org/Saozneg/Keyboard/keyboard-FAQ-FrequentlyAs.html

May also be useful:

http://unicode.org/cldr/bugs/locale-bugs/data?id=857;user=guest
http://developer.mimer.com/features/unicode/tailorings.htm

Some random facts which may be relevant:

- There is a locale setting "br_FR.UTF-8".
- C letter alone does not exist in the Breton alphabet.
- For sorting (collation order), the order should in theory be:

  A  B  CH  C'H  D  E  F...

Nearly two years after this bug has been opened, the problem is not completely fixed: the Breton keyboard is still using the private use characters UF8FD, UF8FE, UF8FF, UF8FA, UF8FB and UF8FC and six lines, such as
   UF8FD : "c’h"
   UF8FE : "C’h"
   UF8FF : "C’H"
   UF8FA : "ch"
   UF8FB : "Ch"
   UF8FC : "CH"
must be added manually in the file ~/.XCompose for the keyboard to work correctly.

Wouldn't it be possible to make six new keysyms for those trigraphs and digraphs ?

If the keysyms trigraph_c_h, trigraph_C_h, trigraph_C_H, digraph_ch, digraph_Ch and digraph_CH were available, it would be possible to add
   trigraph_c_h : "c’h"
   trigraph_C_h : "C’h"
   trigraph_C_H : "C’H"
   digraph_ch   : "ch"
   digraph_Ch   : "Ch"
   digraph_CH   : "CH"
in the /usr/share/X11/locale/en_US.UTF-8/Compose file and the bug would be fixed.

Instead of trigraph_c_h, trigraph_C_h, trigraph_C_H, digraph_ch, digraph_Ch and digraph_CH, you could use the names c_h, C_h, C_H, ch, Ch and CH (I think they aren't used yet).

In this case, the six lines to add in the file in the /usr/share/X11/locale/en_US.UTF-8/Compose would be
   c_h : "c’h"
   C_h : "C’h"
   C_H : "C’H"
   ch  : "ch"
   Ch  : "Ch"
   CH  : "CH"

Jean-François, I cannot add keysyms to xkeyboard-config unless they are known to X server. You can register another bug against xorg, Input/XKB requesting those keysyms. If you do that, please mark this bug as blocked by that new bug. But I doubt that Xorg team would be happy to create new keysyms just for that special case.

I requested the creation of six new keysyms at https://bugs.freedesktop.org/show_bug.cgi?id=34453

James Cloos proposed a patch to fix the problem: http://cgit.freedesktop.org/xorg/proto/x11proto/commit/?id=06ebd5b8

Could some one commit a patch for the /usr/share/X11/locale/en_US.UTF-8/Compose file?
Here is the text to add to that file:

==================================================================
# Compose sequences to support the CH digraph and the C’H trigraph on a Breton keyboard
CH  : "CH"
Ch  : "Ch"
ch  : "ch"
C_H : "C’H"
C_h : "C’h"
c_h : "c’h"
==================================================================

Thanks a lot.

Could you pls file another bug against xlib? The compose patches are not related to xk-c

(In reply to comment #12)
> Could you pls file another bug against xlib? The compose patches are not
> related to xk-c

What is xk-c? I don’t understand.

xkeyboard-config, of course:)

Before the changes to the Compose files can be pushed, we need to
decide on what character to use for the apostrophe in the cʼh strings.

I spent some time before the holiday researching that.

The fdo bug reports and related posts in the list archives use U+2019
RIGHT SINGLE QUOTATION MARK.

Every Breton site I found (by way of google) uses U+0027 APOSTROPHE
(aka the ASCII apostrophe).

But neither of those characters are letters.

The character U+02BC MODIFIER LETTER APOSTROPHE probably is the most
accurate choice, from the point of view of the UCS and Unicode.  It
is a letter, not punctuation, so word break algorithms and the like
should Do The Right Thing.  Google and the like map all of U+0027,
U+02BC and U+2019 together when comparing, so web interaction should
not suffer.

On the other hand, only the libré fonts tend to have glyph support for
U+02BC (generally as a homoglyph to U+2019), the commercial fonts seem
to ignore it.

Thoughts?

(In reply to comment #15)>
> [...]
> The character U+02BC MODIFIER LETTER APOSTROPHE probably is the most
> accurate choice, from the point of view of the UCS and Unicode.  It
> is a letter, not punctuation, so word break algorithms and the like
> should Do The Right Thing.  Google and the like map all of U+0027,
> U+02BC and U+2019 together when comparing, so web interaction should
> not suffer.
> 
> On the other hand, only the libré fonts tend to have glyph support for
> U+02BC (generally as a homoglyph to U+2019), the commercial fonts seem
> to ignore it.
> 
> Thoughts?

http://unicode.org/cldr-apps/survey?_=br&x=characters
The CLDR uses {cʼh} with U+02BC. That's pretty authoritative.
Other Breton keyboard layouts (for other platforms) should be updated too.