X Strike Force XFree86 SVN commit: r1838 - in trunk/debian: . local
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>
Reply to: