From: Mark N. <no...@so...> - 2003-01-20 22:30:32
|
Sorry, I meant to send this to the list. --Mark -------- Original Message -------- Subject: Re: [Docutils-develop] Interpreted text for terms? Date: Mon, 20 Jan 2003 15:04:22 -0600 From: Mark Nodine <no...@ib...> Reply-To: Mar...@mo... To: David Goodger <go...@py...> References: <BA51BCA1.2F16D%go...@py...> David Goodger wrote: > > Mark Nodine wrote: > > What I'm wondering how to do in RST is what was represented > > between tildes in structure-enhanced text. It is > > obviously closely related to interpreted text, and > > in fact, I always interpreted it as terms to be included > > in the index. For example, :: > > > > A ~behavioral bus monitor~ is a module written in the same > ... > > > > In this example, the term is actually defined in the text > > of the document (rather than a separate glossary). It is > > typeset as italics, but, and this is the key, it also creates > > an implicit target so that I can refer to this term from > > elsewhere in the document (and especially from the index). > > I wasn't aware of this feature of Setext. I thought ~tildes~ simply > indicated italics; see the files in > <http://docutils.sourceforge.net/mirror/setext/>, especially typotags.txt. > Are you using a different Setext description, perhaps derived later? Yes, the typotags documentation simply says that tildes produce italics. However, in private correspondence I had with Ian Feldman, the originator of structure-enhanced text:: From: ia...@ra... (Ian Feldman) Date: Sun, 12 Jun 94 17:40:42 +0200 That's right, they are the "natural" elements to enhance in this fashion. In the setext2HTML tool I've also specified (though yet to be implemented) that all by definition single-word ~italic~ elements be turned into <A NAME="italic"><i>italic</i></A> anchors and, that all (yet unnamed but soon to be named ref-tt) elements answering to the reg-exp of ^\[[A-Za-z0-9]+([\s][A-Za-z0-9]*\])\s such as, say, a fairly-frequent way to express exientific references in plaintext: [Feldman 1994] ...... be turned into <A NAME="Feldman_1994">[Feldman 1994]</A> .... (which may be linked to via #Feldman_1994_ etc). I implemented this enhancement and then used it for index entries. I actually used it in three contexts: (1) inline text as my previous example, (2) around the term of a definition list (*very* useful), and (3) in a comment to define an index entry that links to the section header. I'm not saying that's the best solution, but that's how I did things like:: Articles -------- .. ~article, definite~ Welsh has no indefinite article, only the ~definite article~ "the". In rST, it would be better to have "article, definite" be an indirect target to "definite article". > > Is there a way to make interpreted text (perhaps with specific > > role types) create implicit targets? Or is there some other > > way I should be going about this? > > As Benja pointed out, > > An _`inline target` does the trick > > And you can make it italic with a stylesheet entry. The above is rendered > as ``<a class="target" ...>``. I could live with this if I could tell the difference between an inline target and other targets; otherwise if everything is class="target", I can't sufficiently target the index entries. What about the possibility of extending the inline target syntax to allow a role:: An _`inline target`:index: would do the trick since the parser could keep the role attribute and the writer could use the role attribute to determine the class. > If you want a solution that doesn't resort to stylesheet trickery, then an > interpreted text role would be appropriate. The role could simply wrap the > text with both emphasis and target elements. This wrapping would be done by the writer? If so, does it need to insert the <system_message> if there's a duplicate target? I'd rather keep the name registration stuff in the parser if possible. --Mark |
From: David G. <go...@py...> - 2003-01-20 23:26:10
|
[David Goodger] >> I wasn't aware of this feature of Setext. I thought ~tildes~ simply >> indicated italics... [Mark Nodine] > Yes, the typotags documentation simply says that tildes > produce italics. However, in private correspondence I had > with Ian Feldman, the originator of structure-enhanced text:: Thanks for the reference. >> An _`inline target` does the trick >> >> And you can make it italic with a stylesheet entry. The above is rendered >> as ``<a class="target" ...>``. > > I could live with this if I could tell the difference between an > inline target and other targets; otherwise if everything is > class="target", I can't sufficiently target the index entries. Only inline targets contain text. So a style making ``<a class="target"...>`` italic should have the desired effect. > What about the possibility of extending the inline target syntax > to allow a role:: > > An _`inline target`:index: would do the trick > > since the parser could keep the role attribute and the writer could > use the role attribute to determine the class. Correction: the writer doesn't know anything about interpreted text. Interpreted text is simply a syntax construct, not an end in itself (there's no "interpreted" element in the DTD anymore; I ripped it out). For more background, see my Jan 5 post "Re: Handling interpreted text". As for the proposal, it's unnecessary. The "index" role will make its text into an inline target if that is part of its semantics (which it probably is). No need to complicate the markup. >> If you want a solution that doesn't resort to stylesheet trickery, then an >> interpreted text role would be appropriate. The role could simply wrap the >> text with both emphasis and target elements. > > This wrapping would be done by the writer? No, by the parser, or by a transform if the parser doesn't have enough information. > If so, does it need to insert the <system_message> if there's a > duplicate target? The hyperlink resolution transform would, yes. > I'd rather keep the name registration stuff in the parser if > possible. In the Docutils model, the parser registers most names, and the tranformer/transforms handle the rest of the bookkeeping. This is because all of the names need to be known to form links. If you haven't yet, please read PEP 258, which outlines the Docutils model. -- David Goodger http://starship.python.net/~goodger Programmer/sysadmin for hire: http://starship.python.net/~goodger/cv |