[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [docbook] making macros
Per Bothner wrote: > Steven Cogorno wrote: > >> You can't do that. There's no facility for creating "macros" that >> group elements together. You need to include the entire element >> structure. > > > One thing one can do is can design a new format that you translate into > docbook. But then the input format isn't docbook. However, if you want > "macros" you can define your own tags, and then write a little xslt > script to translate that to standard docbook. I'm so new to docbook and xml, I am very uneasy to contradict people. I've read that one of Sun's major contributionns is in the field of documentationm which makes me doubly unwilling to contradict. I'm a programmer, not a document specialist, or editor. That in mind, here I go making a fool of myself ... Yes, it seems you're absolutely right that docbook provides no such facilities, but as a programmer, i really never expected any, and instead I began looking over tools to see which might serve to produce such a facility OK, the most difficult would be C, and I would only use that because of it's very good portability. Another possibility would be python and the ElementTree, which seems very capable of performing this. However, it seems that the xslt processors couild do this very nicely, and many xml environments include a xsl processor right along with the rest of their tools, so portability is great. So, something like zsltproc would serve, if I wrote a good enough xslt script, wouldnt it? Yes, I would want to use an entirely new set of elements, which would have to be translated back into docbook elements, but that's exactly what I suggested, exactly how the mm macros work with groff. So (note I tend to take a bit to repond usually, fellas), tell me again how I'm wrong, please. I'm stubborn, I know that, but I can see the light, given enough time. Oh, if you consider that I am right, then what I'm after is NOT the script to do this, I would write that. It's in the definition of what serve as macros. I mean, if I chose something like mm's chapter entries, or the llist facility, as a macro target, and I called this macro 'chuck1' (I couldnt name things at all, guys, I'm quite poor at that), say i asked for lists, could I get some help in formulating (in maybe meta-language) what might the macro be? I'll write the processor, but I'm not a very good docbook author yet. > > This translation could be combined with regular dcobook processing, > by adding extra rules to the standard docbook xslt scripts for handling > the new tags. > > An alternative: The GNU texinfo format is a lot less verbose than > docbook, and you can translate texinfo into docbook. (Last year > I made numerous fixes to the makeinfo program for its option to > generate docbook instead of the default info format.) However, > texinfo is a completely different format from docbook - it's not > even XML.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]