| 1 |
On Tue, 10 Jan 2006 15:12:27 -0600 Lance Albertson |
| 2 |
<ramereth@g.o> wrote: |
| 3 |
| Last I knew, its not a simple task for generating those nice looking |
| 4 |
| html pages that ciaranm made a while back for the developer docs. |
| 5 |
| When I asked him about (he can probably provide more detail), It took |
| 6 |
| a lot of processing time and wasn't that scalable. Now, I'm not sure |
| 7 |
| if anything has changed since then. |
| 8 |
|
| 9 |
If you're using docutils, then yes, it's reaallly slow. I've got a |
| 10 |
(very fast) parser that handles a decent subset of the RST spec |
| 11 |
written, but getting it converted to be usable in a general kind of way |
| 12 |
isn't too high up my list of priorities... |
| 13 |
|
| 14 |
The thing is... If you're trying to do RST -> GuideXML, you'll run into |
| 15 |
all kinds of weirdness because of the GuideXML heading structure. |
| 16 |
You'll also run into a load more weirdness because about half of the |
| 17 |
GLEPs currently massively abuse blockquotes (in all but one case |
| 18 |
accidentally). |
| 19 |
|
| 20 |
See, this is a list in RST: |
| 21 |
|
| 22 |
* one |
| 23 |
* two |
| 24 |
|
| 25 |
And this is a list inside a blockquote: |
| 26 |
|
| 27 |
* one |
| 28 |
* two |
| 29 |
|
| 30 |
Very easy to screw up, especially since docutils goes to great lengths |
| 31 |
to create output even if the input is highly weird. My own parser moans |
| 32 |
on anything like that -- it disallows most nested structure markup -- |
| 33 |
which means it's useless on most GLEPs unless someone goes through and |
| 34 |
does some serious whitespace cleanups... |
| 35 |
|
| 36 |
-- |
| 37 |
Ciaran McCreesh : Gentoo Developer (King of all Londinium) |
| 38 |
Mail : ciaranm at gentoo.org |
| 39 |
Web : http://dev.gentoo.org/~ciaranm |
Archives