my draft
This is my draft. Some points are poorly explained, feel free to ask any
question.
Please report spelling and grammatical mistakes and so on (anyway, someone
will probably have to rewrite that).
<START>
Debian Uniformed Keyboard Mapping Specifications
- UNIFORM DEFINITION OF COMPOSE SEQUENCES
- every charset will have his specific compose table
- the national KBD map must suggest a compose table and should suggest
compatible fonts
- every compose table must begin with a "charset" entry
- the admin should be able to redefine the compose key
- the national map must be must similar as possible to the standard linux map
- CONFIGURABLE SUPPORT FOR DEAD ACCENTS
- dead accents must be mapped to compose + accent key and/or to SUPER or
HYPER + accent key (???)
- national maps should support an "all accents are dead" option
- NO FIXED MAPPING BETWEEN MODIFIER KEYS AND BUCKY BITS
- the default mapping should be the most common one used by dos
- every bucky bit must be mappable to any key
- every hardware map must support some predefined modifier arrangements
(eg: "no caps", "swap caps and ctrl", etc) to be defined
- M-(key or sequence) must be produced by control + (key or sequence)
- S-M-sequence is different from M-sequence if the character exists, else
is equal
- C-(key or sequence) must be produced by control + (key or sequence)
- S-C-sequence is equal to C-sequence
- if it has no special meaning S-sequence is equal to sequence
- TOP + numeric keypad keys compose a character (decimal)
- TOP + numbers and [abcdef] keys compose a character (hexadecimal)
- left and right shifts are the same key
- left and right controls are the same key
- modifiers are:
- shift (Shift) [any shift, fixed]
- control (Control) [any control, fixed]
- meta (Alt) [left alt, fixed]
- top (AltGr) [right alt] for mode switch or some kbds symbols
(you can redefine this key to another modifier, but you will lose keypad
composing.)
- hyper (CtrlR)
- super (CtrlL)
- front (ShiftR)
- optional special mappings (eg: greek letters for a non greek kbd or
symbols) for HYPER or SUPER can be loaded by the user
- hardware maps must provide configurable support for sticky modifiers
- some support should be provided for a standard way to lock modifiers (?)
- HAVE MOST POSSIBLE GENERAL MAPS
- "If don't collide, map 'em all". Every map must support all widely used
mappings. If two mappings collides then a configurable option must be
provided. In extreme cases the map will be split in two different maps
- If more than one character encoding is widely used there should be
separate maps or a config option or a way to switch encoding using the
mode switch key
IMPLEMENTATION
The master file (/etc/kbd/config.m4) generated by kbdconfig(8) contains
definitions for config option values and includes:
- the macros
- local kbd map
- hardware map
- (opt) compose definitions
- (opt) special mappings
- (opt) local definitions (/etc/kbd/local.m4)
The /etc/kbd/default map file will be generated at config time with the macro
processor.
MAP FILE FORMAT:
#M some format identifier
#D one line of short description
#I multiple lines of long description
#C default compose table
#F compatible fonts
#O multiple lines with format <MACRO> <DEFAULT> <Question to ask to the user>
This document should become an addendum to the policy.
<END>
--
ciao,
Marco
--
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
debian-i18n-request@lists.debian.org .
Trouble? e-mail to templin@bucknell.edu .
Reply to: