--- Fred Drake <fdrake@...> wrote:
> I've got an RTF parser (in Python, of course!), but can't share that
> code since it belongs to my employer. I'd be much more interested in
> highly semantic markup than something general; that could then be
> styled in interesting ways.
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.
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." ;)
>
> Non-LaTeX would still be interesting to me if the markup is semantic.
>
> If we had a definition of the markup we wanted, we could share the
> encoding labor. I expect the conversion might be substantially
> manual
> for a sufficiently interesting markup. :-(
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.
What we'd need to work out, in order to share code, input and output,
would be to come up with the macros to be used for the various bits of
the SRD.
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.
>
> What I'd hope to have in the end would be a Subversion repository
> with
> 3.5 SRD as the trunk, and create branches for individual projects.
> :-)
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.
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! ;)
[deleted for brevity]
> > The SRD has been converted to docbook, and I'm pretty sure you
> could
> > easily convert the docbook to TeX. I've been thinking of using the
> > docbook to HTML conversion to have something more portable than
> RTF.
>
> Would that be Andargor's version? Just took a look at the Docbook
> for
> that; the tools I have don't seem to like it; the XInclude isn't
> getting processed. (Using docbook2pdf on Ubuntu Linux, which claims
> not to support XML anyway.)
>
> I think DocBook would be fine for me if I had decent tools, and a
> better clue about creating/modifying stylesheets, but LaTeX is what I
> already know.
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.
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.
Well, it's about time for me to get back to work.
Cheers,
Jason
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com