| Re: [AD] grabber ._txification |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
On Sun, 2004-10-24 at 16:20 +0100, Grzegorz Adam Hankiewicz wrote:
> On 2004-10-24, Elias Pschernig <allefant@xxxxxxxxxx> wrote:
> > Btw., there is still no solution for problems like PDF not
> > containing external files, or the missing "back to contents"
> > links. And adding it to makedoc isn't trivial - if the internal
> > format is changed, all the output generators have to be adjusted.
>
> Yes, the trick is to modify makedoc without modifying the format.
> So far improvements have been done to the writers, but "swallowing"
> external files has to be done on the reader side.
>
Yes, I'm was trying to extend the @chapter hack so "root" can have any
value. This is necessary to include @external in e.g. PDF, since the
file can no longer be external, but needs to be swallowed. And
therefore, its complete TOC hierarchy must be shifted down.
> > I just looked again at the XML docs suggestion for Allegro 5 -
> > and a ._tx to XML converter would be fairly easiy (i.e. just
> > another makedoc output target). But, what was the idea behind
> > this? Wouldn't we still need e.g. the maketexi.c?
>
> We would. Whatever the format, there are still input and output
> processes. The main reason for using XML as input format is to have
> a richer than ._tx format which accepts easier addition of features
> (example: have an embedded graphic in the documentation and an ascii
> aproximation in text output). In the end, whether it is XML or ._tx,
> at some point is an undocumented hierarchical structure in memory.
>
Hm. I see. So ._tx can as well be kept. Maybe the best is to just
document that internal structure.
--
Elias Pschernig