| Re: [AD] Allegro PDF documentation |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On 2004-01-02, Michal Molhanec <molhanec@xxxxxxxxxx> wrote:
> Grzegorz Adam Hankiewicz wrote:
> >Unfortunately none seems to fulfill all requirements: C, open
> >source like license and cross platform. I'm thinking more along
> >the lines of http://snark.ptc.spbu.ru/~uwe/lout/, which would be
> >also nice because it wouldn't require a strange C lib dependency.
>
> hmmm, but adds strange lout dependency :-)
No, it doesn't. I'm talking about the physical level, when
you "ldd" the makedoc binary and it tells you of library
dependencies. Outputting source code for another tool creates a
lowly coupled dependency: of course you need the tool to complete
the documentation process, but you are not required to have it
installed in order to create other more simple output formats.
Besides, lout looks like a nice succesor to LaTeX. It's worth
learning anyway.
> isn't simply easier to produce XML and then use XSLT+FOP for
> PDF generation? the advantage is that once in XML you can simply
> convert it to nearly anything
We are already there. Basically makedoc's format is kind of a
pre-xml era multiformat which accomplishes the same as xml, being
kind of format agnostic and defining just content. Makedoc turns
that content into output. We are meant to use XML as source code for
the coming makedoc version, it's just not feasible for the stable
branch now. And yes, a ._tx to .xml format should be possible and
not that difficult to write, it's basically a cosmetic rewrite of
the html generator. Xml generation tools, OTOH are a pain to use.
> BTW I don't understand why it cannot be C++ lib (e.g. libharu)
> as Allegro is AFAIK not supporting any only-C compiler
Oh, it's kind of a personal preference. You know, any decent
C++ library will have exotic ideas for... what where they
called... buckets, no... holders, no... objects. Feel free to provide
a patch using one of these libraries. It's enough if it works.