On 5/1/06, Jason <desade_ky@...> wrote:
> RTF doesn't look all that difficult to parse, but I'd need to play with
> a bit to make any sort of judgment on that. I've also found some free
> RTF parser code on the 'Net (in C), but I may just write my own as an
> exercise.

It's not all that bad, but not interesting enough by itself to write a
parser for if you already have one.

> What I'd like is something that can use pluggable optables to convert
> from RTF to any other arbitrary markup, essentially a 2-pass compiler
> with a swappable backend. I'm not sure that I'd go so far as to develop
> a fully functional pcode, but I've been known to do crazier things in
> the quest for "correctness." ;)

Table-driven replacements would be trivial, of course; not sure why
you're want something two-pass for that, unless I misunderstand what
you mean.

> Yes, semantically-styled markup would be best, 'cause then you can
> switch the visual output simply by loading a new macro set. Also, if
> you get enough abstraction, you've got yourself an interesting
> substitute for XML that's a bit less verbose.

Much less verbose than DocBook. The light weight of the markup is
definately why we're still using LaTeX for the Python documentation.
That and the cost of toolchain conversion.

> As for the ease of automatic conversion, that depends a lot on how
> consistent the styles are in the SRD RTF documents. If the creators
> used consistent formatting or even defined styles, then the conversion
> by software would be fairly straightforward.

That also assumes that the styles are different for different semantic concepts.

> That sounds interesting. I wouldn't think to put something like this
> into version control, but I can see where that would be handy. You'd
> have your rules at the core with branches for modifications and others
> for software, campaign material, etc. based on those rules.--Not a bad
> idea at all.

I've been doing technical documentation for long enough that
text-based markup and revision control are mandatory for me. It's not
the same as code, but more than close enough.

If nothing else, it provides a backup. :-)

> This thread reminds that I had a thought several months ago to write a
> PC/NPC generator in TeX, or possibly even PostScript. I was just
> beginning to study PostScript seriously at the time and I thought that
> it would make a good exercise. Now, I may just have to go ahead with
> writing one in TeX.--So much for people who think TeX is just a markup
> language! ;)

Now, that's just masochism. :-) What's the motivation to use TeX or
PS instead of conventional programming language, and generate
TeX/PS/PDF? I've done one tool that creates XML, and another that
converts that to OpenDocument files I can feed into OpenOfffice 2.

> On FreeBSD, I have used the docbook-nojadetex port. It works very well
> on the FreeBSD documentation that is written in docbook. I've not tried
> it on the docbook conversion of the SRD. However, in looking at the
> docbook SRD that I had available, I see that it is incomplete.

Does the FreeBSD documentation you've tried it with use XInclude at all?

> I've printed the SRD to PDF on my Windows computer at the office by
> using Microsoft Word, GhostScript and the Redmon port redirector. You
> set up a redirected port with redmon that runs GhostScript to convert
> the output to PDF.--PDF is another area that I have plans to study a
> bit more. I'd like to make my own programs for bookmarking sections,
> etc. after I've created PDFs with GhostScript.

My LaTeX toolchain for the Python documentation does all that, of
course. :-) I'd be interested in making that toolchain more usable
for other applications. There wouldn't be a lot to do, I don't think.
There are a lot of pieces, though.


-Fred

--
Fred L. Drake, Jr. <fdrake at gmail.com>
"Don't let schooling interfere with your education." -- Mark Twain