Menu
▾
▴
#294 Typewriter/fixed-width font
Doctools has a command [emph] for empasizing text. Another font variation, which is very common in documentation, is that of "typewriter" or fixed-width fonts, to underline that something is exact text as typed by a user or the computer. In LaTeX this is marked up using the \texttt command, in WubWikit it is marked up using backquotes (`tt`), and so on.
The [example] and [example_begin]...[example_end] commands in doctools already use such a font where available, but always put the text on separate lines. In this, they are rather like the verbatim and alltt environments of LaTeX, but this RFE is for something like \texttt.
For output formats where this font variation is not possible, the command need not have any effect. I find it rather annoying not to have this style variation for HTML pages or LaTeX, however.
Logged In: YES
user_id=75003
Originator: NO
Note that for HTML the CVS head contains a revamp of the backend which marks all the pieces in the output with lots of class/id tags keeping the semantic information. Making it possible to change the visual style of the lot via CSS. Output contain an embedded default CSS style I mainly lifted from the TMML/HTML output. The embedded style is suppressed if you define your own via engine parameters (-style option of dtplite, or -meta option of dtp).
For LaTeX it might more sense to allow the specification of a latex-style through an engine parameter and have it define the formatting of examples. With default formatting embedded as definitions at the top if no style is specified.
Would that serve?
Logged In: YES
user_id=938835
Originator: YES
No, I don't see how that would serve. I'm not after changing the formatting of existing markup commands, but want an additional markup command, for expressing a variation not covered by the existing ones.
The concrete example which made me file this RFE is that I wanted to document the default for an option as being the regular expression [[:graph:] ]. No markup for the RE at all looks wrong (at least in HTML, and probably also in LaTeX), but this is not an [arg], [class], [cmd], [file], [fun], [method], [namespace], [option], [package], [syscmd], [type], [uri], [var], or [widget]. It /might/ be considered a [const], but I don't think it fits well under that heading either. It's simply a string, which happens to have very technical interpretation.
Making an [example] out of it would be to overemphasize it.
If you insist on all markup being semantic, then some kind of generic markup command might be the way to go, e.g.
[string regexp {[[:graph:] ]}]
so that [cmd whatever] is equivalent to [string command whatever], [option whatever] is equivalent to [string option whatever], [arg whatever] is equivalent to [string variable whatever], etc. Then there wouldn't be an immediate need to request another markup command as soon as someone encounters an object that doesn't match the standard set.
Logged In: YES
user_id=75003
Originator: NO
> I [...] want an additional markup command,
> for expressing a variation not covered by
> the existing ones.
Ok. Now I understand the request.
It is orthogonal to the 'macro' request. The macro request is extending the markup language by composing existing stuff into larger pieces and naming these, and this request is for extending the language by adding a new semantic category specifically, or allowing the writer to extend the language by defining new categories (generic markup command). Where the problem with the latter is that it is not at all clear how backends can treat such a generic markup.
Thank you for the clarification, and I will mediate more about this and your other requests in the next days.