[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: DOCBOOK: marking up keycaps according to their semantics
Bob > Let me see if I understand you. You are suggesting that > the DTD be changed Yes, probably best extended. > so that keycap can have a way of > identifying certain keys that have functions that go > beyond entering a character. Yep; many keys don't really enter characters (where character is something which very closely is tied to a certain set of glyphs). > You want to capture the > semantic concept of a Ctrl key, so that it can be expressed > by the stylesheets in many ways rather than as a literal > key name, right? yep :) > So for Emacs doc, a stylesheet would > render it as "C", while another stylesheet would > say "Ctrl". In other languages it could be > translated by the gentext files. This would be one of the advantages of a more semantic notation, yes. Generate "ctrl" in the English version, "strg" in the German one, etc. > This would seem to apply to just a few keys, like > Alt, Esc, Shift, and Ctrl at least. Maybe Enter as well? > Or should it be for all the named keys, including Insert, > Home, etc.? This would need to be discussed. But I'm sure we could specify a list which makes sense as a starting point, eg: * enter * alt (meta) * shift * ctrl * "arrow keys": up, right, down, left * escape * backspace * tab * space * delete * F1-12 perhaps also * help * page up / down * command-key (Mac) [etc?] It would need to be discussed what people need: Emacs user, Vim users, etc. In Vim for example, :help key-notation brings http://vim.sourceforge.net/htmldoc/intro.html#key-notation > Were you thinking of an enumerated list of values > for an attribute on keycap? The syntax may be best figured out by people like you, who are very familiar with the DocBook language. But I like your suggestion. What name would you suggest? <keycap function="shift">[shift]</keycap> where the content of the element is the suggested default ASCII rendering. But also allow for empty elements: <keycap function="shift"/> so that <keycombo action="simul"> <keycap function="control"> <keycap>h</keycap> </keycombo> Pure semantics, no rendering info. The transformer/renderer can then provide a default rendering (eg pics, ASCII), and the customizer can override it. Or a new element <input type="shift"/> ... since some people use other means than keyboard to enter input. Tobi -- http://www.pinkjuice.com/
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]