Author: branden Date: 2004-09-21 13:17:42 -0500 (Tue, 21 Sep 2004) New Revision: 1838
Modified: trunk/debian/CHANGESETS trunk/debian/local/FAQ.xhtml Log: Fix usage of nonexistent XHTML element "firstterm". My brain wandered off into DocBook-land, it appears. Modified: trunk/debian/CHANGESETS =================================================================== --- trunk/debian/CHANGESETS 2004-09-21 18:15:29 UTC (rev 1837) +++ trunk/debian/CHANGESETS 2004-09-21 18:17:42 UTC (rev 1838) @@ -51,6 +51,6 @@ Add FAQ entry: My keyboard configuration worked with XFree86 4.2; why is it messed up now? (Closes: #259740) - 1823, 1832, 1835, 1836 + 1823, 1832, 1835, 1836, 1838 vim:set ai et sts=4 sw=4 tw=80: Modified: trunk/debian/local/FAQ.xhtml =================================================================== --- trunk/debian/local/FAQ.xhtml 2004-09-21 18:15:29 UTC (rev 1837) +++ trunk/debian/local/FAQ.xhtml 2004-09-21 18:17:42 UTC (rev 1838) @@ -2681,22 +2681,22 @@ <p><em>Thanks to Denis Barbier for contributing much of this entry.</em></p> <p>Many users of the X Window System, particularly outside the United States, -find that they need support for multiple <firstterm>groups</firstterm> on their -keyboards. One or more of the keys on their keyboards are engraved with more -than two glyphs. On a typical U.S. keyboard, there are at most two glyphs on -each keycap — one is accessed with a <code>Shift</code> or <code>Caps -Lock</code> key, and one without. Many keyboards outside enable access to -glyphs beyond the third with modifier keys not found on most U.S. keyboards. -One approach is with an <code>AltGr</code> (alternate group) key, which is -analogous to <code>Shift</code>. The other approach is with a <code>Mode -Switch</code> key, which is analogous to <code>Caps Lock</code>. When either of -these keys are pressed, the X Window System needs to know to switch to an -alternative key layout — preferably one which corresponds to the -engravings on the user's keyboard. A U.S. keyboard, even if keys are remapped -so that <code>AltGr</code> and/or <code>Mode Switch</code> keys are available, -does not acquire much meaningful additional functionality unless and alternate -group is defined in software, so that "the keys know what to do" when the -alternate group is enabled.</p> +find that they need support for multiple <em>groups</em> on their keyboards. +One or more of the keys on their keyboards are engraved with more than two +glyphs. On a typical U.S. keyboard, there are at most two glyphs on each keycap +— one is accessed with a <code>Shift</code> or <code>Caps Lock</code> key, +and one without. Many keyboards outside enable access to glyphs beyond the +third with modifier keys not found on most U.S. keyboards. One approach is with +an <code>AltGr</code> (alternate group) key, which is analogous to +<code>Shift</code>. The other approach is with a <code>Mode Switch</code> key, +which is analogous to <code>Caps Lock</code>. When either of these keys are +pressed, the X Window System needs to know to switch to an alternative key +layout — preferably one which corresponds to the engravings on the user's +keyboard. A U.S. keyboard, even if keys are remapped so that <code>AltGr</code> +and/or <code>Mode Switch</code> keys are available, does not acquire much +meaningful additional functionality unless and alternate group is defined in +software, so that "the keys know what to do" when the alternate group is +enabled.</p> <p>Sometimes a key layout for a given territory (such as <code>gb</code> for the United Kingdom or <code>fr</code> for France) defines what should be in the @@ -2709,11 +2709,11 @@ engraved with primary group <em>and</em> alternate group glyphs. Russian keyboards, for example, because they must support both the Latin and Cyrillic alphabets, often work this way. As a consequence, users of the X Window System -need a way to <firstterm>combine layouts</firstterm>.</p> +need a way to <em>combine layouts</em>.</p> <p>Prior to XFree86 4.3, combining layouts was difficult because keyboard -symbols (<firstterm>keysyms</firstterm>) were defined to be specific to a given -group. For example, the <code>us</code> symbols file (in <code +symbols (<em>keysyms</em>) were defined to be specific to a given group. For +example, the <code>us</code> symbols file (in <code class="filespec">/etc/X11/xkb/symbols/</code>) defined the its keycode to keysym mappings specifically for group 1 — the primary group. The <code>us_group2</code> and <code>us_group3</code> files repeated these @@ -2723,10 +2723,10 @@ was consequently impossible without modifying the XKB data files directly — a skill most users do not possess.</p> -<p>XKB layouts have been revisited in XFree86 4.3, and new definitions can -now be used in arbitrary order so that <code>us,ru</code> and <code>ru,us</code> -use the same <code>symbols</code> files. The new definitions have been placed -in <code class="filespec">/etc/X11/xkb/symbols/pc/</code> while the old ones are +<p>XKB layouts have been revisited in XFree86 4.3, and new definitions can now +be used in arbitrary order so that <code>us,ru</code> and <code>ru,us</code> use +the same <code>symbols</code> files. The new definitions have been placed in +<code class="filespec">/etc/X11/xkb/symbols/pc/</code> while the old ones are still available in their traditional location; that is, directly within the <code class="filespec">/etc/X11/xkb/symbols/</code> directory.</p> @@ -2740,17 +2740,17 @@ <p>Modifiers have also been affected by these changes to make the system more modular. A consequence is that <em>fake keys</em> have been introduced in XKB data files for <code>Alt</code>, <code>Meta</code>, <code>Super</code> and -<code>Hyper</code>. (The fake keys are distinguished from real keys by not being -pair-oriented to the "left" or "right". Even keybords that have only one of a -pair of such keys — like laptop keyboards — report the keys they do -have as being either left or right, for compatibility with full-size models.) -By default, the modifiers <code>mod1</code> and <code>mod4</code> use these fake -keys instead of real ones. XKB-aware applications can handle those fake keys, -but some applications, like <application>GNU Emacs</application>, get confused -and will not recognize your keys as modifiers. Until these applications are -fixed, you can bind keys explicitly with <code>altwin</code> XKB options; for -example, <kbd>Option "altwin:super_win"</kbd> binds your logo keys to -<code>Super</code> modifiers.</p> +<code>Hyper</code>. (The fake keys are distinguished from real keys by not +being pair-oriented to the "left" or "right". Even keybords that have only one +of a pair of such keys — like laptop keyboards — report the keys +they do have as being either left or right, for compatibility with full-size +models.) By default, the modifiers <code>mod1</code> and <code>mod4</code> use +these fake keys instead of real ones. XKB-aware applications can handle those +fake keys, but some applications, like <application>GNU Emacs</application>, get +confused and will not recognize your keys as modifiers. Until these +applications are fixed, you can bind keys explicitly with <code>altwin</code> +XKB options; for example, <kbd>Option "altwin:super_win"</kbd> binds your logo +keys to <code>Super</code> modifiers.</p> <h2><a id="acknowledgements">Acknowledgements</a></h2>
