[Doc-SIG] Re: [Docutils-develop] master plan for interpreted text?

[Benja Fallenstein]

David Goodger wrote:
> In `The Chicago Manual of Style`, the section "Distinctive Treatment
> of Words" (6.62 through 6.91 in 14th ed.) lists many cases:
> 
> * emphasis
> * foreign words
> * special terminology & technical terms
> * words used as words
> * letters as letters
> * musical dynamics (pianissimo as italic "pp" etc.)
> * letters indicating ryme schemes (as "aabba" for a limerick)
> 
> All of these are mapped to italics.  Should we have roles for each of
> them?  Even if we combine closely-related cases (words as words &
> letters as letters; musical dynamics as a case of foreign words), we
> have 4 or 5 cases here.  DocBook has dozens more inline elements.  How
> far should we go?

I'm thinking that following HTML's model may make sense: in addition to 
*emphasis* and **strong**, have `italics`:i: and `bold`:b:. So if there 
is no semantic class matching what you need, you just use one of these two.

Another option would be being able to declare your own interpreted text 
roles and assigning them a class: Then, the writers would handle all of 
these in the same way, and the decision on how to render them would be a 
stylesheet issue. E.g., ::

     .. role:: foreign f

     This is the `de facto`:f: standard.

And in a CSS stylesheet::

     .foreign { font-style: italic }

> The to-do list has this item: add a runtime setting (directive and/or
> command-line option) to set the default role of interpreted text.
> I.E., map "`" to something.  Should we have a directive to map other
> inline markup (i.e., "*" & "**", maybe even "``") to arbitrary inline
> element types?

This doesn't make sense to me; when I read a reST source, I parse the 
asterisks and backquotes in a certain way, and if a text would 
arbitrarily redefine them, the benefit would be lost. -1...

- Benja