Michael(tm) Smith <[EMAIL PROTECTED]>: > The only way for doclifter to generate proper markup for .RS/.RE > instances like that would be be for it to figure out what semantic > meaning the author intended for that indented block to have. Is it > a program listing, an example, or what? It sound like you already > have doclifter doing some AI stuff to make that determination in > some cases.
That's right. There are several cases. 1. When .RS/.RE is detected within list structure generated by .TP or .IP, it generates no tags in the result at all, but does start a new level of nested list structure. 2. When .RS/.RE is detected in association with .nf/.fi and/or .ft CW, some display processing is invoked that looks at the content and decides whether to translate the result as <screen>, <programlisting>, <synopsis>, or <literallayout>. 3. Only when .RS/.RE is found surrounding running test and not within a list does it generate <blockquote remap='RS'>. > But I'm sure there are many cases where it can't > figure out what the author's intention was. Actually, those cases are not at all common. Most instances fall under cases 1 and 2. > I don't think generating <blockquote> for those cases is the right > thing to do. I guess the only thing I can suggest is that you > generate a, say, remap="RS-RE" attribute/value on whatever block > element you output (<para> or whatever) for the block that the > RS/RE instance contains. Been there. Tried that. Won't work. One major problem with that approach is that .RS/.RE sometimes occurs as a wrapper around several paragraphs, not just one. > And maybe emit a warning: "RS/RE found > but can't determine intened semantics" (or whatever). I used to have such a warning. I reinstate it for case 3. The good news is that this is certainly the worst and probably the only DocBook tag abuse that doclifter commits. -- <a href="http://www.catb.org/~esr/">Eric S. Raymond</a> _______________________________________________ Groff mailing list Groff@gnu.org http://lists.gnu.org/mailman/listinfo/groff