Re: [I18n] Patch to use double width font (xft) in xterm
I have made a patch on xterm so that, it can accept one more option / resource, to utilize two fonts when using xft. Originally, -fa option will make xterm to use xft instead of XFontSet, but however, in most cases, this option is broken, as most CJK TTF fonts can't have good (acceptable) monospaced appearance. Hence, I add one more option '-fd' to accpet another font for 'double width' char. For changes to xterm, please talk with Thomas Dickey. He is the maintainer of xterm and will evaluate your changes. His site is: http://dickey.his.com/xterm/xterm.html Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Unicode and KDE
On Friday 19 December 2003 10:36, levan shoshiashvili wrote: KDE 3.1.4 In any kde text editor utf-8 input (georgian) works fine, but it seems it's not saved in unicode. When I save and Open after I see ??. In GNOME editors (gedit) everything works fine. p.s. I have not set utf-8 locale If it works in Gnome, then it's not an X problem. You should ask on one of the KDE lists at kde.org. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] us_intl + Russian in 4.3.0
On Thursday 02 October 2003 11:31, Vladimir NOVIKOV wrote:
First of all, I can't understand this difference between Compose, AltGr
and dead key modes (that's why I definitively need more documentation).
It's complicated. First, AltGr only exists on the keyboard, not in the
software. For Linux, there are two totally different keyboard mechanisms:
console and XFree86's XKB. We're talking just about XKB here. The four sets
of modifiers we're talking about are the deadkeys (dead_cedilla, et al.),
Multi_key, ISO_Level3_Shift and Mode_switch.
deadkeys are symbols that don't generate a glyph by themselves, but affect the
glyph printed when the next key is pressed. If you have a dead_cedilla key,
you would first press and release the dead_cedilla, then press the 'c' key.
This will print ç. There are lots of different dead_* keys.
Multi_key is also known as Compose. After pressing and releasing the
Multi_key, sequentially press the two keys that you want combined into one
glyph. So press and release Multi_key, then press and release ',' then 'c' to
get ç. Pressing 'c' then ',' also works.
ISO_Level3_Shift and Mode_switch have been confused in X's history. In XFree86
4.3, the new pc/ directory uses ISO_Level3_Shift, which is the right way.
You can see the difference in the symbol files.
The ISO_Level3_Shift way looks like this:
key AE01 { [ ampersand, 1, onesuperior, exclamdown ] };
and the Mode_switch looks like this:
key AE01 {[ ampersand, 1 ],
[ onesuperior, exclamdown ] };
The problem with using the Mode_switch way like this is that it is very
difficult to mix two keymaps (say, a US keyboard for Latin script and a
Russian keyboard for Cyrillic).
If I have us_intl keyboard alone, I normally should have deal keys
working without any Compose key. If I have one I use Compose + +a to
get ä, but even without I should be able to get ä using only +a. And
AltGr mode should be used to have even more characters.
If you want dead keys to type ä with the us_intl keymap (which uses the old
Mode_switch method), you have to generate a dead_diaeresis symbol. In the
us_intl map, that is the shifted second group on the semi-colon/colon key. Or
it is also the shifted first group of the apostrophe/doublequote key. So, to
get a dead_diaeresis, you can either press Shift+apostrophe/doublequote
together, or press Mode_switch+semi-colon/colon together.
Otherwise, using Multi_key, you can get the behavior that you describe for
Composing.
However, the AltGr key can be mapped to either Mode_switch or Multi_key, so
the behavior to the user might appear the same.
Frank
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [XFree86] Keyboard configuration for Alt chars
On Thursday 11 September 2003 12:18, Ph Legay wrote:
Frank Murphy wrote:
On Friday 05 September 2003 12:56, Ph Legay wrote:
Well, the modifier that it sees is Alt_L. You want it to see Mode_shift.
You can cause this to happen by putting this into your .Xmodmap file:
keysym Alt_L = Mode_switch
Then run `xmodmap .Xmodmap` and the left alt key should generate
Mode_switch and you can get your characters.
OK, Thanks. You have rights. Everty thing is perfect.
Great! Glad to hear that it works.
Just to be a little less dummy, Is there a way to say to X keyboard
that Alt_L = Mode_switch in the configuration file. In other words
where are the modifiers defined ? in one file or in several files ?
I assume that you mean in the system Xkb configuration files. On Debian,
they're in /etc/X11/xkb/, but I think the default is /usr/X11R6/lib/X11/xkb.
Under symbols, there are the files that define how X maps keycodes to
keysyms. In these files, you'll see lines like this:
key RALT {[ Mode_switch, Multi_key ] };
They define how to get Mode_switch.
Frank
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [I18n] Creating a keymap
On Saturday 06 September 2003 7:46, Ævar Arnfjörð Bjarmason wrote:
I am currently Planning on working on a icelandic keymap for X(Free) on
Apple PPC machines as of now one does not exist.
Sounds great.
The project page (temporary) is http://212.30..56/ICELANDIK/
You got a bit aggressive with the 2s. :) It's http://212.30.222.56/ICELANDIK/
I have some questions which i hope you can answer:
a)
What if any licence should i put the X keymap under? X11? i want it to
be used by XFree86 and all its current and future forks.
X11. I'd recommend this for any console keymap you do as well. Then if FreeBSD
or someone wants to use it, they can. I assume that you want this keymap to
be usable by as many people as possible. Public domain might be good, but the
X11 is probably best (and the only one possible to distribute with XFree86).
b) When i'm done where do i submit it, will i have to submit it here and
to all the forks or do you maintain some common sourcecode/mailing list
with the forks for this sort of thing?
If by all the forks, you mean Xouvert, I wouldn't worry about it at this
point. Once you have something good, send a cvs -u diff here and we can let
you know if you're making any big mistakes. If you licence it with X11, then
they can pick it up later.
I've looked at what you have, and I have a couple of points for you. The first
is with the difference between Mode_switch and ISO_Level3_Shift. The
old-style Xkb keymaps used Mode_switch to get to the third symbol engraved on
the keys. The new-style use ISO_Level3_Shift. The new-style are located in
xc/programs/xkbcomp/symbols/pc. The main difference is that each key is
defined in a single group, as opposed to using two groups. You should do the
iceland keymap in the new style.
Instead of this:
include ralt(mode_switch)
...
key AE09 {[ 9,parenright ],
[ bracketright, plusminus ] };
Do this:
include level3
...
key AE09 { [ 9, parenright, bracketright, plusminus ] };
Frank
___
I18n mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/i18n
Re: [XFree86] OT: image manipulation
I take a screenshot with xwd -root bla.rgb How can I convert this rgb file to a png, jpeg ... Not using gimp but a cli tool .. Not really an XFree86 question, but look at ImageMagick (http://www.imagemagick.org) Frank ___ XFree86 mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xfree86
Re: [XFree86] Keyboard configuration for Alt chars
On Tuesday 02 September 2003 2:52, Ph Legay wrote:
I have installed the mandrake 9.1 on my Macintosh (Of course this
distribtion has a XFREE 4.3 environment).
But I have no # { [ | \ with my keyboard. In a tty console (CTL+ALT+F1),
I succeed to modify my keyboard configuration, But nothing with the X
Keyboard.
The keyboard maps for the different consoles (ctrl+alt+F1, +F2, etc) are
different from the keyboard maps for X. I don't know about Mandrake, but for
Debian, the console keymaps are stored in /usr/share/keymaps and the
configured keymap is stored in /etc/console/boottime.kmap.gz.
For X, there are two ways to configure keymaps, Xkb and the legacy core Xlib.
XFree86 4.3 defaults to Xkb, so I'll assume that's what you are trying to
configure.
The Xkb files are kept in either /etc/X11/xkb or /usr/X11R6/lib/X11/xkb.
However, xmodmap does things with a different syntax to Xkb.
I try a lot of things (create my own rule, so no keyboard, CTL+ALT does
not work, ...), but it seems to difficult for me, without any tutorial.
I can access to the Xkeyboard protocol PDF file.
So today I have a keyboard, I can modify the mapping of the key 5 : ( +
5 to a + 5, but no braceleft char.
I assume by this that your keyboard has a key that is engraved with a '5', a
'+', a '(', and a ':' -- is this true? It seems from what you say below that
the key has a '5', a '(', a '[', and a '{'.
Questions
-
a) Is there a tutorial to understand the rule file ?
The best place to understand all the Xkb files is normally at
www.charvolant.org/~doug/xkb/html/ but it seems to be down a lot recently.
b) Is there a tutorial to build a keyboard mapping ?
No. Do you want to build an Xkb key symbol file, or an .Xmodmap file?
c) In my symbol file, there is key = ( 5 braceleft braketleft. Why
can not obtain the braceleft char ? I kown (I see by typping) that the
first column is for normal char, the second column is for the shift
char. What for are the third and the fourth column ? In other word,
whare is the modifier order ?
What file do you see this line? For Xkb, I would expect to see:
key AE05 { [ 5, parenleft, braceleft, bracketleft ] };
In this case, '5' is a simple press, '(' is Shift+5, '{' is
ISO_Level3_Shift+5, and '[' is Shift+ISO_Level3_Shift+5.
However, in Xfree86 4.2 (and similar to xmodmap) the following happens:
key AE05 { [ 5, parenleft ], [ braceleft, bracketleft ] };
In this case, 5' is a simple press, '(' is Shift+5, '{' is
Mode_level+5, and '[' is Shift+Mode_level+5.
Confused? It's confusing. What has probably happened is that your AltGr key
(which often gets the third char) is configured to Mode_shift, but XFree86
4.3 expects ISO_Level3_Shift to be used.
When I solve my keyboard tty problem, I read a document that explain
each column. The keyboard mapping is an array the first char is for
normal char, the second for shift char, ... and if you want a char in
the last column, you can introduce voidsymbol for the useless column.
When it's back online, the above Xkb doc explains these.
d) how to active the third and the fourth column for each char ?
See above explaination.
e) Can I create new modifers ? (I try an xkbcomp does not like)
You can't invent a new Legays_special_modifier symbol. You can use the Super
and Hyper symbols to do what you want.
f) Is the order of modifiers fixed ?
Sometimes. In order to get the 3rd engraved symbol, yes, you can use only the
proper one. Otherwise, I'm not sure I understand.
g) My distribution has no xev ? Where can I found it ? (I want to check
if the modifiers are generated)
I imagine mandrake has it in a package on the CD. Ask at one of the Mandrake
forums.
h) I read that there is some graphical interface for xmodmap ? Do you
know it ? Where can I find it ?
What you're probably talking about is xkeycaps. You can get source here:
http://www.jwz.org/xkeycaps/
I'm sure Mandrake has a package.
i) Is there a tutorial of xmodmap ?
Only `man xmodmap`.
j) Where are the x-doc.org files ? where is http://www.tsu.ru/~pascal/en/ ?
I don't understand what you mean here.
Notice :
Macintosh mouse is a single button, so F11 and F12 keys are used to
emulated a 3 button mouse. Perhaps this mechanism brakes the alt
modifier of my keyboard ? How can I chack this idea ?
I really doubt that this is the problem, but I'm not sure how to check this
idea.
Frank
___
XFree86 mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xfree86
Re: [I18n] why does Mode_switch not work sometimes?
keycode 54 = C NoSymbol Ccircumflex For this line, you need 'keycode 54 = c C ccircumflex Ccircumflex' otherwise you lose the lowercase 'c'. Actually, that isn't true. On the machine where things are working correctly, this line enables shiftless lower case and shifted upper case. These three lines have the same effect: keycode 54 = C keycode 54 = c keycode 54 = c C keycode 54 = C NoSymbol Of course, you need to choose one of the latter two if you're going to assign a character in Mode_switch. Huh. When I tried to do this before, I was only able to type the capital or lowercase, but now it works as you say. Very strange. ccircumflex. I don't see that as a keysym in any of the files in symbols/. What language is that used for? Esperanto, for which i need Ccircumflex, Gcircumflex, Hcircumflex, Jcircumflex, Scircumflex, and Ubreve. As i mentioned, i have no trouble getting these symbols in X, as long as i don't try to get them with Mode_switch. Consider this line: keycode 54 = a b c d This means i should get: c - a c+Shft - b Mode_switch+c - c Mode_switch+c+Shft - d However, on this one machine Mode_switch doesn't have any effect, no matter what key i assign it to. Another thing you could try would be to set up an Esperanto XKB keymap based on whichever national keymap you're using, though the ideas behind Mode_switch and ISO_Level3_Shift have changed in XFree 4.3. Good luck, Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] why does Mode_switch not work sometimes?
On Sunday 24 August 2003 4:17, Leston Buell wrote: keycode 0x71 =Mode_switch Multi_key This is Alt_R, right? keycode 54 = C NoSymbol Ccircumflex For this line, you need 'keycode 54 = c C ccircumflex Ccircumflex' otherwise you lose the lowercase 'c'. clear Mod1 clear Mod2 clear Mod3 clear Mod4 clear Mod5 add Mod1 = Alt_L Alt_R add Mod2 = Mode_switch Multi_key I don't do any of these modkey changes, just the two lines above, and it works fine in xev, and if I use something other than ccircumflex. I don't see that as a keysym in any of the files in symbols/. What language is that used for? When i open xkeycaps, when i mouse over the right Alt key (on my US keyboard), i see that changes have taken place. However, when i try to type anything into any application using the AltR key, nothing happens. And yet, if i do Shift+AltR the Multi_key compose function does work. This is not a problem with the Ccircumflex symbol; if i replace Ccircumflex with some more common symbol (such as r), Mode_switch still doesn't work. Any clues? Try using `xev` to see what the keysyms are when pressing the keys. After hours of tinkering, Mode_switch finally started working on my laptop, but i can't figure out what i did to make it work. I am essentially running the same xmodmap file over two practically identical keyboard mappings. Why would the result be different between the two machines? Do `xmodmap -pk outfile` on both machines and do a diff. That will show you your differences. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
On Friday 22 August 2003 10:25, Ivan Pascal wrote: Hi, Frank Murphy wrote: So what's the difference between alt+c on Mac OS and Multi_key+, on X11? Is it just the display of the greyed-out character? I had thought that a dead key was a real key on the keyboard (that had the accent engraved on it) that would not cause a character to be displayed until the next character was typed. I think your origin example was incorrect (or I misunderstood what you meant with 'Multi_key+' ). ... good explaination snipped ... Is it clearer now? :-) Thanks. I almost had it, but I was missing the dead_cedilla idea. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] First patch for pc/ directory rationalization
So after some deliberation, I have the first patch to the pc/ directory. It's just the README.naming to define what the files in this directory should contain. This is probably just an intermediate solution, but will enable people to easily separate the language keymaps from the country keymaps for any future work to make these all language (or even script) based files. Ivan, could you check this in? If you'd prefer that someone else do the check-ins, just tell me who. I imagine there will be around 10 patches in all. Frank --- pc/README.naming 2003-08-22 10:58:54.0 +0200 +++ pc/README.naming.new 2003-08-22 10:25:58.0 +0200 @@ -0,0 +1,21 @@ +The files in this directory describe possible layouts for a given keyboard. The names of the files are referenced in the X server configuration and in user configuration tools. These files should be named as follows: + +Files describing a keyboard from a national perspective must use the 2-letter ISO 3166-1-alpha-2 code element for the nation as the filename. (e.g. the file 'gb' contains the keymap for Great Britain.) Applications could use the national flag to distinguish keymaps following this convention, but that is not reccommended. + +These codes can be found a the following address: + +http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html + +Files describing a keyboard from a language perspective must use the 3-letter ISO 639-2B bibliographic code for the language as the filename. (22 languages, including Greek, have two 639-2 code elements, a bibliographic and a terminology code. The bibliographic code is guaranteed not to change.) (e.g. the file 'ben' contains the keymap for Bengali.) Applications must NOT use a national flag to distinguish keymaps following this convention. + +These codes can be found a the following address: + +http://www.loc.gov/standards/iso639-2/englangn.html + +Keymaps that vary from the default keymap should be added to that file, not put into a separate file. The keymap will be referenced as filename(alt_keymap) (e.g. se(nodeadkeys) for Sweden). There are current;y files that use the underscore '_' key to separate different layouts. This usage is deprecated. The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that dead keys actually print the symbol printed on the key). + +Keymaps that don't fit into this model should be given filenames that are 4 letters or longer. + +In the files, the description of the name[Group1] should be the name of the nation or language (as appropriate) in 7-bit English. For keymaps with filename of 4-letters or longer should have the description of the name[Group1] be a description of the keymap in 7-bit English. + +The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that Caps Lock and Control are switched).
Re: [I18n] Re: Some thoughts on XKB symbols
On Thursday 21 August 2003 3:38, Kent Karlsson wrote: Frank Murphy wrote: Actually, here's a screenshot from the gswitchit page that shows that they did in fact use flags for keymaps: http://gswitchit.sourceforge.net/gsw.applet.png So, I stand behind by premise that developers tend to use flags for keymaps. And the text next to the flags are *language* names... Yes, and the HIG team agreed that this was the *wrong* thing to do. If it's a country-layout, a flag is appropriate, not if it's a language-layout. We have examples of *both* types of layouts. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
On Thursday 21 August 2003 3:37, Kent Karlsson wrote: Danilo Segan wrote: I like the idea. While working on my proposal, I thought that a main keymap per script was the way to go. Have a latin, cyrillic, greek, gujarati base, and change from there (qwerty, azerty, etc.). At least cyrillic keyboards differ too much for this to work -- eg. there are many phonetic keyboards (which are similar with english ones based on the sound) and there are completely different ones (a standard Russian I believe to be an example of this). That gives at least two *basic* layouts for Cyrillic, probably less than a handfull *basic* layouts for Cyrillic (there being two [that I know of] for Latin). The reast would be per language modifications of that. There are more for Latin, depending on what you consider *basic*: qwerty, qwertz, azerty, dvorak, and svorak. Unless you consider *basic* to be qwerty and dvorak (which would be fair). Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
On Thursday 21 August 2003 4:55, Kent Karlsson wrote: Frank Murphy wrote: Absolutely on Mac OS. In the US (where therre are no deadkeys), Yes there are (see below). in order to type on Mac OS (9 X), press alt/option+c, then press c again. alt+u is for umlaut, etc. alt/option+c is a dead key (the MacOS X UI shows a yellow background and an indication of which dead key you have typed, this disappears when you type the base character, it being replaced by the combination). Similarly, alt+u is dead key for umlaut. (I don't like the term dead key, but that is the common term for it.) So what's the difference between alt+c on Mac OS and Multi_key+, on X11? Is it just the display of the greyed-out character? I had thought that a dead key was a real key on the keyboard (that had the accent engraved on it) that would not cause a character to be displayed until the next character was typed. are, then Xkb could be configured with se+dvorak and avoid all the That will not work since the default Swedish map is qwerty-ish one, and are not in the same place as in Dvorak as in qwerty (some punctuation is consequently moved too). Why won't it work? Whatever is added afterwards should override any done before (or can be written to do so). Apart from differenced in row E between en-US and sv keyboards, have their unique position in svorak (and as a consequence some punctuation is moved too). That is not expressed by se+dvorak. Sorry. I get it. Just had a brain fade on your explaination. I don't know why. Because they are identical for so many countries and languages. Plus, the main interaction people have with the two-letter codes is with internet domainnames. Yes. And on the internet, .fr is France, not French. Eh, no. That is context dependent. In XML (very intenetty) xml:lang='fr' means French, not France... xml:lang='fr-FR' tag French French, xml:lang='fr-CA' tags Canadian French, etc. (Similarly for HTMLs older lang attribute.) True, but end users aren't authoring raw XML, but they are typing URLs into their browsers (and seeing ads on TV and billboards) that end in these 2-letter country codes. How is this for an idea? I will start with my conservative proposal, separating language maps from country maps, and you can start with the script-based proposal, starting with the Latin and Gujarati scripts. As the Latin-script work progresses, we can start changing the language/country maps to include the script maps, making sure that people currently using the country/language maps still get their expected behavior. In parallel, we can start to build Brand specific additional maps (for Apple, Sun, SGI, etc). What do you think? I can start off by sending you the files I've done (with sv bias, since that is where I started). Then we have something concrete, and then we can discuss from there. (And maybe change our minds entirely...) Well, that depends. Are your files script-based or language-based? If they're language-based, then they would be parallel to my concrete proposal, and could just be added (though with the 3-letter code, swe). Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
On Tuesday 19 August 2003 5:04, David Dawes wrote: Or maybe all of the xkb config files can go to a new location outside of xc/programs/xkbcomp. Once there is a good proposal for a more consistent and logical structure for all of these files, they can be moved. That way we don't need to be constrained by these CVS limitations. The problem might also occur when installing XFree onto a filesystem that doesn't differentiate between upper- and lower-case. BTW, what did you think of my proposal for these files? Frank The files in this directory describe possible layouts for a given keyboard. The names of the files are referenced in the X server configuration and in user configuration tools. These files should be named as follows: Files describing a keyboard from a national perspective must use the 2-letter ISO 3166-1-alpha-2 code element for the nation as the filename. (e.g. the file 'gb' contains the keymap for Great Britain.) Applications may want to use the national flag to distinguish keymaps following this convention. These codes can be found a the following address: http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html Files describing a keyboard from a language perspective must use the 3-letter ISO 639-2B bibliographic code for the language as the filename. (22 languages, including Greek, have two 639-2 code elements, a bibliographic and a terminology code. The bibliographic code is guaranteed not to change.) (e.g. the file 'ben' contains the keymap for Bengali.) Applications must NOT use a national flag to distinguish keymaps following this convention. These codes can be found a the following address: http://www.loc.gov/standards/iso639-2/englangn.html Keymaps that vary from the default keymap should be added to that file, not put into a separate file. The keymap will be referenced as filename(alt_keymap) (e.g. se(nodeadkeys) for Sweden). There are current;y files that use the underscore '_' key to separate different layouts. This usage is deprecated. The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that dead keys actually print the symbol printed on the key). Keymaps that don't fit into this model should be given filenames that are 4 letters or longer. In the files, the description of the name[Group1] should be the name of the nation or language (as appropriate) in 7-bit English. For keymaps with filename of 4-letters or longer should have the description of the name[Group1] be a description of the keymap in 7-bit English. The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that Caps Lock and Control are switched).
Re: [I18n] Re: Some thoughts on XKB symbols
On Thursday 14 August 2003 11:02, Danilo Segan wrote: fr file governs keymaps for the French language, and it's sane (I already mentioned that there are other criteria, like population -- the criterium of language origin is just a sample one, for the sake of discussion) to have a default behaviour when loading a keymap for French *language* -- whether the default keymap would be Canadian or French is not directly relevant in this discussion -- it depends on the motives one has when defining a default. Actually, the current fr file describes the keymaps for the keyboard produced for France. But the file fr-latin9 describes a more general keymap for the French language. You seem to be misunderstanding my idea. Idea is to *allow* choosing a keymap on either language (eg. fr(CA)) or country (eg. CA(fr)). I never mentioned that any specific country would have supremacy over the keymap based on the language. I do understand your idea. But I think that it adds too much complexity for very little gain. And, by describing a keymap by language would require that there be *some* default for national differences. Why do I have a strange feeling that you're generalizing based on the (so many times) mentioned 5 or 6 languages? There are thousands of languages in the world, and hundreds of countries. Actually, what I'm generalizing on are the current keymaps in XFree86. Because a lot of countries to map to a single language and the country and language have the same 2-letter code for ISO 3166 and 639, and because CVS doesn't handle file renames very well plus Xkb uses the names of the files for configuration, I'd prefer to change the description in the file with no backward-compatabilty issues rather than move these files to a new name, lose the history in CVS, and have to provide files with the new and old names. There may be thousands of languages and hundreds of countries, but there are less than 125 keymaps in XFree86. Another problem with the US(en) model is that the current us file has lots of settings for 105-key keyboards and such things, that would be specified by US(105-key) or something, which has no language code. Didn't we already agree that anything which doesn't represent a ISO code is to be considered custom? No. I was only talking about the names of the files. I don't think it's necessary or wise to require that of the xkb_symbols names as well. Though, you'll certainly agree that this kind of thing (105-key) doesn't belong in the US keymap, but more like hardware or something along those lines. Perhaps, but it's a big step from the mostly-working setup X has now. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
[I18n] XKB symbols normalization proposal
After our discussion on the list, I propose two things. One is to include the following as a README.policy in the symbols/pc/ directory: --- The files in this directory describe possible layouts for a given keyboard. The names of the files are referenced in the X server configuration and in user configuration tools. These files should be named as follows: Files describing a keyboard from a national perspective must use the 2-letter ISO 3166-1-alpha-2 code element for the nation as the filename. (e.g. the file 'gb' contains the keymap for Great Britain.) These codes can be found a the following address: http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html Files describing a keyboard from a language perspective must use the 3-letter ISO 639-2B bibliographic code for the language as the filename. (22 languages, including Greek, have two 639-2 code elements, a bibliographic and a terminology code. The bibliographic code is guaranteed not to change.) (e.g. the file 'ben' contains the keymap for Bengali.) These codes can be found a the following address: http://www.loc.gov/standards/iso639-2/englangn.html Keymaps that vary from the default keymap should be added to that file, not put into a separate file. The keymap will be referenced as filename(alt_keymap) (e.g. se(nodeadkeys) for Sweden). There are current;y files that use the underscore '_' key to separate different layouts. This usage is deprecated. The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that dead keys actually print the symbol printed on the key). Keymaps that don't fit into this model should be given filenames that are 4 letters or longer. In the files, the description of the name[Group1] should be the name of the nation or language (as appropriate) in 7-bit English. For keymaps with filename of 4-letters or longer should have the description of the name[Group1] be a description of the keymap in 7-bit English. The default layout for each keyboard must describe a keyboard based on the symbols printed on the keys. Secondary keymaps can describe differences that are preferred, but not necessarily printed on the keys (e.g. preferring that Caps Lock and Control are switched). --- Secondly, I propose to make the following changed to the existing keymaps, always taking care to follow the above policy and to make sure that backwards compatability is preserved. Also, to minimize the changes needed to the current directory layout. When moving a filename to a new name, the old file will still exist merely including the new filename. All keymaps referenced in it will still be usable with the old name. In the National keymaps, do the following: - change the name[Group1]= from the name of the language in English to the name of the nation in English. - for files that have separate files for keyboard variations (e.g. cz_qwerty and pl2), move the variation into the original file and change the old variation file to include the variation from the original filename (so cz_qwerty will only consist of include pc/cz(qwerty)) - move the 'yu' keymap to 'cs' In the linguistic keymaps, change existing files to their 639-2B code. - move the Arabic language file from 'ar' to 'ara' - move the Inuktitut language file from 'iu' to 'iku' - move the Hindi language file from 'hi' file to 'hin' - move the Lao keymap from 'lo' to 'lao' - move the Greek keymap from 'el' to 'gre' - move the Tamil keymap from 'tml' to 'tam' In the miscellaneous keymaps, - move the Latin America keymap from 'la' to 'latin_america' - include the contents of the 'en_US' keymap in the 'us' file, and change the en_US file to include pc/us(latin1) - Ask the folks what they prefer for the Francophone layout (fr-latin9) - move the gur file to gurmukhi, because it is a script (like Latin or Cyrillic), not a language - in the sapmi file, ask the Skole Linux folks what they would like to rename the Group from the 8-bit Sámegiella to. - For the 'pc' file, ask this list what is a good solution. If folks here agree that *some* standard is needed, and that this is a decent plan forward, I'll start making the patches to do this, though not all at once. I'll break it up into easier pieces. Frank National: al (Albania) am (Armenia) be (Belgium) bg (Bulgaria) br (Brazil) by (Belarus) cz cz_qwerty (Czech Republic) de (Germany) dk (Denmark) ee (Estonia) es (Spain) fi (Finland) fo (Faroe Islands) fr (France) gb (Britain) ge_la ge_ru (Georgia) hr (Croatia) ie (Ireland) il il_phonetic (Israel) ir (Iran) is (Iceland) it (Italy) lt (Lithuania) lv (Latvia) mk (Macedonia) ml (Malaysia) mm (Burma) mt mt_us (Malta) nl (The Netherlands) no (Norway) pl pl2 (Poland) pt (Portugal) ro (Romania) ru (Russia) se (Sweden) si (Slovenia) sk sk_qwerty
Re: [I18n] Re: Some thoughts on XKB symbols
(I was just arguing against *country-only* based keymap names. That's the whole point. I don't mind country based keymaps, if there are also language based keymaps) As soon as you mentioned this, I agreed. What I'm suggesting now is 2-letter national code keymaps and 3-letter linguistic code keymaps. I think this is a bad idea. Differentiating based on case can be problematic (as was pointed out). However, I would think that using ISO 3166 2-letter national codes and ISO 639 3-letter codes would work OK. Besides, most of the current entries already follow this. Depending on how you look at this :-) I've already pointed out that many of the languages (uhm, nations) you mentioned actually use the ISO 639 two-letter code ;-) Or was it the ISO 3166 country code? If we don't ask the authors, we can only guess -- and guess what? My guess is different from your guess ;-) True, but my guess leads to less work. :) Just changing the Group description of all the 2-letter files from the language name to the nation name is less than moving the file to another name. And the Group description name is reall cosmetic, but might help when someone contributes a new keymap. I know I'll be a bit boring, but if case differentiation is a problem, I'd go for providing new namespaces for each: nation/ and language/ (perhaps in shorter forms of n/ and l/). I'd rather not add new namespaces. Of course, this would cause *major* breakage for old applications which rely on one layout being there with a specific name. The only applications that should care would be the installation programs. If systems are single-user, which defeats the purpose of X network transparency. In multi-user environments, you cannot expect every user to use the same language in every occasion. I imagine that most X deployments are single-user. Plus I imagine that nearly all the multi-user environments (with X-terminals with no local storage) all have the same keyboard layout -- probably the same keyboard *model* as well. I think I'll write up a proposal for the patch I intend to submit. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: [I18n] Re: Some thoughts on XKB symbols
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
I'd go for:
key AE01 { [ 1, exclam, any, any ] };
(I'm not sure if your idea would work like this -- if it would,
then this is unneccessary burden).
It's already done with only two levels in the pc/us keymap. I don't see a
reason to add the 'any's. The point was to move the generic us layout from
pc/us to pc/latin so that sun/, sgi/, etc could include them without getting
any PC-keyboard-specific baggage (like function keys or whatever).
Using a German keymap doesn't prohibit you from typing in English.
However, if you own a keyboard made for Switzerland, but you set
the keymap to be German (the dominant language here), you won't be
able to type the characters on your keyboard -- like finding
the @. Besides novices won't be setting this, the administrator will.
The thing I wanted to point out that if someone was offered with a
choice that read Germany (implying a country name) instead of
German, it'll be easy to mistake it for enter your current location.
It's a sort of Great Britain for the english layout -- would you ever
look for that if you needed english layout?
OTOH, when it says German there are no doubts, even if you're right
now sitting in a hotel in Germany wishing to type in English ;-)
The problem is that there is no English-language keyboard layout, nor is there
a German-language layout. There are different layouts for Britian, Ireland,
Canada, Australia, Germany, Switzerland, and Austria. So saying German or
French or English does leave doubts: is this a keyboard from France or does
this keyboard allow me to type the French language?
So, I cannot see any advantage to the naming scheme you seem to be
proposing, yet there are many disadvantages.
I agree. I think there are two ways of looking at this, but there are
three
types of keymap files: national (based on ISO 3166 country codes),
linguistic (ISO 639 language codes) , and random.
Looking just in the pc/ directory, I see the following breakdown:
Actually, many of these are the same for language and nation name,
thereby, this category would shrink very much. Besides, some would even
go to only lingustic (like sr for Serbian, because Serbia is a part
of larger country Serbia and Montenegro with ISO 3166 codes of CS and
SCG).
True, but that's really the problem with yu, isn't it? :)
The others, like de, es, fi, fr, hr, it, mk, nl, no,
pt, ro, ru, sk, th, tr apply to *both* language and country
(actually, these are the ones I know about; there are probably others).
The problem is that de, es, fi, fr, nl, and pt have different keymaps
depending on the *nation*.
Random: dvorak en_US la latin pc
So it seems that a good compromise would be to recomment the ones of
the national type to reflect the name of the country (in English), and
to leave the ones of the lingustic type to refect the name of the
language (in English). Does that address your concerns?
I see your point and it makes sense. Though, I'd go for an international
standard, because they've already invested time into avoiding
collisions.
I'd like to us an ISO standard for the filenames. For the description of the
group name, I would bet that we're constrained to 7-bit characters. Besides,
they are all in English now. Plus, in the ISO document, the country names are
listed in English.
http://www.iso.ch/iso/en/prods-services/iso3166ma/02iso-3166-code-lists/list-en1.html
For the sake of difference, I would recommend the following:
- National keymaps should use ISO 3166 code in all UPPERCASE (eg. US)
- Linguistic keymaps should use ISO 639 code in all lowercase (eg. en)
This would allow one to have de which could apply to all the
countries where German is used (eg. de(DE)) and also a DE which
would only apply to Germany. In your example, CA (if that's the code
for Canada) would have CA(en), CA(fr), while fr would have fr(CA),
fr(FR),... It's up to the implementor to choose and see where to put
the actual definitions, and where to simply include them from the other.
I think this is a bad idea. Differentiating based on case can be problematic
(as was pointed out). However, I would think that using ISO 3166 2-letter
national codes and ISO 639 3-letter codes would work OK. Besides, most of the
current entries already follow this.
But I wouldn't encourage a large proliferation of these. For European and
North South Amarican keyboards, recommend the 3166 code. For Asian and
Arabic keyboards, recommend the 639 code. But don't go wild with all the
possibilities, otherwise we end up with the pt(BR)/en(US) problem that Andrew
Aitchison mentioned.
Of course, this would cause *major* breakage for old applications which
rely on one layout being there with a specific name.
Re: [I18n] Re: Some thoughts on XKB symbols
The only xkb_symbols us that I see are in digital/us and
xfree68/ataritt.
But the map would be the same as the xkb_symbols basic in pc/us,
basically, the same as latin(basic) only not including the group 2 or
3 symbols (exclamdown, etc.). However, it would be in the latin file
and included in the other us files.
Could you please differentiate between levels and groups in XKB
terminology. All keymaps in pc/ should use *only* one group to
facilitate multi-layout features of XKB in XFree 4.3.
Sorry, I meant shift levels. my proposed us-ascii would have just
key AE01 { [ 1,exclam ] };
not
key AE01 { [ 1, exclam, onesuperior, exclamdown ] };
Sorry for misusing the terminology.
But basicaly, this could be done simply without breaking compatibility.
You just create a xkb_symbols(ascii) in pc/us file, and put
NoSymbol or any on higher levels, and just include that from
basic.
Yeah. My simple proposed change here is to move these definitions to the latin
symbol file, then include them from the appropriate us symbol files. I don't
think it would break compatability. I do think that it would remind people
who make new keymaps that the default US behavior has to be to only output
ASCII, because that is the lowest common denominator for the US.
(Btw, basic in pc/us is practically us, eg. just calling
setxkbmap -layout us will set the pc/us(basic) map).
Wouldn't `setxkbmap -layout us` set the us(basic) map and `setxkbmap -layout
pc/us` set the pc/us(basic) map?
OK, so we can pick another name. My point is to preserve the (blurred)
difference between nations and languages. Nations determine keyboard
layouts, not languages (the French, Canadians, and Swiss all use
different keyboards to type the French language - azerty, qwerty, and
qwertz). But see more below.
I tend to disagree with this statement. There are a couple of language
(a dozen at most) that are used in several countries in the world (like
Spanish, French, Portuguese, German, English,...). For those languages,
and for those countries, your proposal would be sane.
Alas, there are another 150+ countries with even more languages that
don't belong into this category, and where the relation
language = country strongly holds.
So, maybe this would make sense for several keymaps, but it wouldn't
for most of them, especially since one may want to use a *language*
while in other country -- and many users (especially novices) will make
mistake if they're located in Germany, and then choose Germany as
their keymap (not knowing that they're actually setting a keyboard map
because they're just honestly stating their country of location), even
though they want to type in English.
Using a German keymap doesn't prohibit you from typing in English. However, if
you own a keyboard made for Switzerland, but you set the keymap to be German
(the dominant language here), you won't be able to type the characters on
your keyboard -- like finding the @. Besides novices won't be setting this,
the administrator will.
However, I imagine that using a Bengali keyboard will prevent one from typing
in Hindi (or something).
So, I cannot see any advantage to the naming scheme you seem to be
proposing, yet there are many disadvantages.
I agree. I think there are two ways of looking at this, but there are three
types of keymap files: national (based on ISO 3166 country codes),
linguistic (ISO 639 language codes) , and random.
Looking just in the pc/ directory, I see the following breakdown:
National:
al (Albania) am (Armenia) be (Belgium) bg (Bulgaria) br (Brazil) by
(Belorussia) cz cz_qwerty (Czech Republic) de (Germany) dk (Denmark) ee
(Estonia) el (Greece) es (Spain) fi (Finland) fo (Faroe Islands) fr fr-latin9
(France) gb (Britain) ge_la ge_ru (Georgia) hr (Croatia) ie (Ireland) il
il_phonetic (Israel) ir (Iran) is (Iceland) it (Italy) lo (Laos) lt
(Lithuania) lv (Latvia) mk (Macedonia) ml (Malaysia) mm (Burma) mt mt_us
(Malta) nl (The Netherlands) no (Norway) pl pl2 (Poland) pt (Portugal) ro
(Romania) ru (Russia) se (Sweden) si (Slovenia) sk sk_qwerty (slovakia) sr
(Serbia) th th_pat th_tis (Thailand) tj (Turkmenistan) tr (Turkish) ua
(Ukraine) us (United States) uz (Uzbekistan) yu (Yugoslavia)
Linguistic: ar(abic), ben(gali), hi(ndi), guj(arati), gur(mukhi),
iu(inuktitut), kan(nada), ogham, ori(ya), sami, telugu, tamil
Random: dvorak en_US la latin pc
So it seems that a good compromise would be to recomment the ones of the
national type to reflect the name of the country (in English), and to leave
the ones of the lingustic type to refect the name of the language (in
English). Does that address your concerns?
For the random ones, dvorak will have to stay, and both latin and pc are kind
of include files (though it there ever comes a country or language with ISO
code pc ...) The two that I'm worried about are en_US (which looks like a
locale for no good
Re: [I18n] Re: Some thoughts on XKB symbols
No, I didn't mean to imply that FR was choosen as a default for fr because of textual similarity, but rather, because France, with ISO 3166 code of FR, is the originator of French language fr (perhaps this is not a good enough reasoning, and your reasoning based on population might be more adequate, but that's another topic). The problem is that as the originator of the French language France has nothing to do with the keymaps that, say, Canada has chosen. Perhaps this model of keymap orientation works for other parts of the world, but not in Europe, or with European languages. This would imply that we would have en(GB) as default for en and pt(PT) (if PT is indeed a code for Portugal) for pt. Portugese (pt iirc) is worse; iirc pt(BR) massively outweighs pt(PT). The idea was exactly to try to limit these collisions. The Brazilian user would actually prefer to use BR (which would default to BR(pt) and be the same as pt(BR)), same as US user would probably prefer to use US (which would default to US(en), being equivalent to en (US)). Another problem with the US(en) model is that the current us file has lots of settings for 105-key keyboards and such things, that would be specified by US(105-key) or something, which has no language code. I believe that everyone can be satisfied at least a bit -- I don't expect Brazilians to mind that using just pt will not give them adequate keymap, if BR would do the trick. Still, Portuguese would be very happy that their keymap is considered default for pt. I think we have established that this is an area where people's prejudices will cause them to make unexpected assumptions. Yes, quite so. I was just trying to remedy that by providing *both* choices -- based on country, and based on language. So, if one Brazilian fellow actually insisted to access the keymap using the language name, it wouldn't (or shouldn't) be a problem for him to use pt(BR). It isn't necessary to fill this matix of language and country. I think a compromise of using nation or language codes when appropriate is a better idea than trying to manage an unwieldy matix. We have enough troubles keeping the keymaps supported. But, if we count in the prejudices, there'll probably never be a perfect solution. If there were, there would be no need to discuss this at all, and we would continue with the current trend of assigning keymap names on the when it comes basis. I would agree, with just the caveat that no 1-, 2-, or 3-letter files. Unless they fall into *some* category. Frank ___ I18n mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/i18n
Re: iBook us-keyboard problem
+#if defined (i386) defined (SVR4)
+/*
+ * PANIX returns DICOP standards based keycodes in using 106jp
+ * keyboard. We need to remap some keys.
+ */
+if(xf86Info.panix106 == TRUE){
+ switch (scanCode) {
+ case 0x56:scanCode = KEY_BSlash2; break; /* Backslash */
+ case 0x5A:scanCode = KEY_NFER; break; /* No Kanji
Transfer*/ + case 0x5B:scanCode = KEY_XFER; break; /* Kanji
Tranfer */ + case 0x5C:scanCode = KEY_Yen; break; /* Yen curs
pgup */ + case 0x6B:scanCode = KEY_Left; break; /* Cur Left
*/ + case 0x6F:scanCode = KEY_PgUp; break; /* Cur PageUp */ +
case 0x72:scanCode = KEY_AltLang;break; /* AltLang(right) */
+ case 0x73:scanCode = KEY_RCtrl;break; /* not needed */ +
}
+} else
+#else /* i386 SVR4 */
+{
+ switch (scanCode) {
+ case 0x5c:scanCode = KEY_KP_Equal; break; /* Keypad Equal */
+ }
+}
+#endif /* !(i386 SVR4) */
}
else if (
I'll commit this (and the rest of the patch). Could someone test it
and let us know if it works correctly?
Looking at the patch and xf86Events.c, I don't understand why this switch code
is if'ed out for the i386/SVR4 case. Is that a special configuration for
Japanese keyboards that don't have KPEQ?
Thanks for your help with this,
Frank
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
iBook us-keyboard problem
I have an iBook with a US keyboard layout, and I'm having a wierd problem I hope you can help with. The mac keyboards have a keypad equals key. X doesn't support that as separate from regular equals, but I'd like to use it to type equals. The problem is that both this KP-equals and the left-arrow key have the same keysyms. If I try to modify one, I modify both. Here's the relevent xev output: KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558015, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: KeyRelease event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35558135, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: KeyPress event, serial 27, synthetic NO, window 0x201, root 0x48, subw 0x0, time 35560194, (180,101), root:(183,519), state 0x0, keycode 100 (keysym 0xff51, Left), same_screen YES, XLookupString gives 0 characters: I am actually hitting different keys here, but it doesn't look like it. What is wierd is that these keys generate different keysyms and characters on the console. I type an '=' with both keys (on Debian sid). I had a suggestion to look in the XF86 keyboard code. Does anyone here have an idea of which files to start to look in? Will this be a C-code problem or a configuration issue somewhere? Or does anyone know how to see the scancodes that X thinks I have? Here's the version info from the top of the XFree86.0.log: XFree86 Version 4.3.0 (DRI mach64-0-0-6-branch) Release Date: 27 February 2003 X Protocol Version 11, Revision 0, Release 6.6 Build Operating System: Linux 2.4.20-ben8-xfs-lolat ppc [ELF] I'm using the Xserver packages that Michael Däzner provides. Do you need any other info? Thanks for any help, Frank ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
[Xpert]Prob with ATI Xpert98, Tyan mo-board, and Apple 20 MultiScan (M1823)
Hi, I've been having problems with a used Apple monitor I picked up recently. I have an ATI Xpert 98 AGP card with a Tyan Trinity 400 motherboard. The monitor is model M1823, and it dates from around 1995. I'm running XFree86 4.1.0 from Debian unstable. Linux kernel 2.4.2. The problem is that the black borders on both sides of the monitor are very big (about 3 cm each side). The borders are better under Win98. On boot, the initial BIOS splash screen has the proper space on the sides, but if I go into Setup (hitting DEL) or if I let it start to boot, the margins are the same size as what XFree puts them. I assume that this is related. The initial Windows start screen is also off, but once it shows the login screen, it's better. Anyone here have ideas? My leading canidate is the DDC stuff. I try to disable it, but I can't get XFree to take my specified ModeLine. I give one a different name (1024x768m), and try to select it, but xvidtune always shows the default (1024x768). The ATI docs say that the Xpert98 supports DDC 1, 2a, 2b, but I don't imagine that the '95 Apple monitor does. So there's two symptoms of the problem. One is how the video displays in text-mode, and the other is XFree. I'd be happy to just fix the XFree problem, but I'd appriciate any tips or thoughts or advice any of you would have. Thanks, Frank ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
