+Cross-reference links in the manual are reasonably stable, since they are
+independent of the ordering number (which gets removed from the URL) and the
+pretty page title (the URL is created from the file name). So unless a file
+is renamed or moved to another sub-directory, links should be ok.
4.1 Inline markups
------------------
@@ -105,13 +115,17 @@ default choice is , the plain paragraph.
encloses a newly introduced term that is being explained. Use for the first
occurrence of the main concept of every manual page, or the first occurrence
of a new concept after a sub-heading if necessary.
+Keep in mind that tags might be used to generate an index of keywords
+- don't pollute it too much.
is used to explain an abbreviation such as LADSPA. Browsers will usually pop up the
-definition when the user hovers over the word, and it can easily be
-extracted via CSS for printing.
-Use only for the first occurrence of every new abbreviation.
+definition when the user hovers over the word.
+On each page, use only for the first occurrence of every abbreviation. Avoid
+a redundant explanation in the text - the expansion can easily be extracted
+via CSS for printing.
+Use only in the text body, not in headings.
is used to emphasize a word. Commonly rendered as italics.
@@ -161,8 +175,9 @@ elements.
------------------------------------
-Any keys or key combinations, mouse buttons, or controllers should be marked
-with this element.
+Any keys or key combinations, mouse buttons or controllers, menu items or
+textual user input should be marked with this element. It is used here in
+the widest possible sense, qualified by classes.
E.g.:
"Press F to fit all tracks to the height of the Editor window."
"Move Fader 1 on your MIDI controller to bind it.
@@ -176,6 +191,23 @@ class="mod1">N. It will render as "Ctrl+N" for you, and as "Cmd+N" for
your Mac-using friend. Nice, uh?
For anything you want the user to type, use as a block-level element.
+See above for other classes to denote menu items, selections, mouse
+events and controller actions.
+
+Keys and mouse key names should always be capitalized. We do not need to
+distringuish between "x" and "X", because the latter would be "Shift-X".
+In case you forget, the stylesheet takes care of this.
+
+CSS Classes used with are:
+.modN
+.mouse: mouse buttons
+.cmd: a command line
+.lin, .win, .mac: add nice prompts to that command line
+.input: inline text to be entered by the user
+.menu: path to an Ardour menu or other GUI item
+.option: path to an option, with (X) at the end.
+.optoff: path to an option, with ( ) at the end.
+.button, .fader, .knob: external controllers (OSC or MIDI).
is only used for program code, or the content of configuration files etc. Do
@@ -193,10 +225,15 @@ types or presses.
The image tag must contain a 'src="/images/yourimage.png"' element and a
descriptive 'alt="A short textual description of the image content"'
element.
+Images are usually placed as block-level elements, i.e. outside of a
+paragraph.
+
+5. Other conventions
+====================
-5. Typography
-=============
+5.1 Typography
+--------------
* Avoid any typographical quotation marks to highlight terms or express any
kind of subtle inflection, use semantic markup instead.
@@ -206,5 +243,54 @@ element.
the long em-dash.
* For ranges of values, use the en-dash: Monday – Friday, 0 –
11.
+* Use a non-breaking space (" ") between a number and its unit.
+
+5.2 Language
+------------
+
+* The Ardour manual is written in Americal English spelling.
+* Use SI units with standard abbreviations. Give imperial units only as
+ additional information, if at all.
+
+
+5.3 Chapter Headline Capitalization
+------------------------------------
+Capitalization follows
+https://developer.gnome.org/hig-book/3.6/design-text-labels.html.en#layout-capitalization
+:
+
+* Capitalize all words in the headline, with the following exceptions:
+ Articles: a, an, the.
+ Conjunctions: and, but, for, not, so, yet ...
+ Prepositions of three or fewer letters: at, for, by, in, to ...
+* Keep headlines short and concise.
+* secondary headlines in articles are not capitalized
+* Do not capitalize concepts in the text body, with the possible exceptions
+ of _the_ Editor and _the_ Mixer.
+
+
+5.4 Janitorial tasks/review
+---------------------------
+
+If you encounter something that is unclear or patent nonsense, but you are
+not bold or knowledgeable to fix it, express your doubts with an editorial note
, so that readers will be warned and fellow
+editors know where there's work to do.
+
+5.5 Writing style suggestions
+-----------------------------
+
+* "Click OK" and similar explanations of the utterly obvious should be
+avoided. Keep the writing concise and to the point. Explain as much as
+possible, with as few words as possible.
+* Do not fear repetitions, this is not artistic prose. Repeat important
+keywords, rather than burden the user with synonyms made up on the spot.
+* Do not create headings for different ways of doing the same thing (Via
+the context menu,...Via hotkeys). Headings separate new
+concepts. To not add gratuitous sub-headings if there is very little
+content per heading and you do not expect the article to grow.
+* If pages grow long, consider splitting them into sub-chapters at their
+headings.
+* Nobody needs "the next paragraph is about the following" paragraphs.