Re: [DB2LaTeX-devel] Status of project, and where to next

[nico <nic...@li...>]

On Sun, 24 Apr 2005 00:15:42 +0200, Nikolai Prokoschenko  
<ni...@pr...> wrote:

> On Apr 22, 2005 at 07:48:05PM +0200, nico wrote:
>
>> What is the docbook test suite you're talking about?  Is it the
>> 'testdocs' entry under the docbook sourceforge site?
>
> Exactly. I hasn't been "released" in a long time, but Norman Walsh seems
> to update the CVS repository on a regular basis. Current version is for
> Docbook 4.4. I think that this test suite is comprehensive enough to find
> most "big" mistakes - at least I could verify that my table morerows code
> needs rewriting badly.

Ok.
>
>> >So my opinion is that a lot of work needs to be done, especially in
>> >ensuring flexibility and Docbook-compliance.
>> If you have suggestions to improve flexibility, or even some hack,
>> please tell it on the list. You can send all your wishes, at least to
>> see the amount of work to do.
>
> I don't think I've explored the code deeply enough to give qualified
> reasons, but I didn't like the idea of "mapping", for example. I've got
> the impession that it just replaces certain elements with certain
> LaTeX-macros, which is not quite right, at least not without an obvious
> way to overload this _consistently_ throughout the code.
>
> But please note that I haven't read the code extensively and I cannot say
> I understand all the background for this or that decision.

I agree. I think it comes from the XSL language translation code by N.  
Walsh stylesheets to map how to say "chapter" in spanish for instance. It  
is well suited for the original purpose, but not really to translate  
structural things to others. In dblatex I don't use it heavily.

>
>> >Another field is ensuring TeX works the way we want it to (Unicode). If
>> >we get clearance from the developers, we might need to setup an
>> >automated test suite processing so that we can see which areas need
>> >work.
>> Good idea.
>
> This is actually something I can setup rather quickly. I just need some
> place to host it.
>
> Another item on the agenda: I know you used Perl for post-processing. I'm
> not quite sure it's sane enough, but I also can't tell you why we
> shouldn't be doing that. I would like to have a plain XSL solution - or
> else we can just take Perl and scrap XSLT. I know XSLT is PITA (I've  
> spent
> several days on the rather trivial task of adding morerows ;)), but if we
> choose that way, we should walk along it.

Well, the perl processing is used for three purposes:
- for fast systematic string replacement, e.g. a "\" is change to a "\\"  
to make latex happy. Doing this task with XSL is quite possible but really  
slow. I wanted something really faster because I need to drive books  
containing more than 200 pages. This said, maybe that EXSL functions now  
exist that can do this far better. Is it the case?
- "to do the things I cannot do with XSL". I confess my poor XSL  
programming skills with this point. Currently it's for table support.
- to do some compilation stuff once the latex file is available. Typically  
it detects and converts some figures format to the expected one for the  
tex compiler. For example it converts EPS figures to PDF when pdflatex is  
used.

So I would say that:
- Having all the XML translation done by XSL would be the best (and  
cleanest) thing provided that the two first points are really possible to  
do with XSL. I confident with this. At least the string replacement is not  
a functionnal problem (XSL can do this) even if it is still a performance  
issue. Besides the David Hedley contribution skip the table coding I  
needed to do with perl.
- The last perl processing seems to me interesting (I don't have to care  
how to compile the file) but is not a part of the XML translation. It's  
only a convenient way to do things after.
- Perl post-processing can become completely optional.

>
> Considering the structure of the project: a wiki might be good to store
> all Docbook definitions, rendering proposals and possibly an algorithms
> for translating that to LaTeX and of course some discussion.
>
> I will hopefully be looking into db2latex-xsl's code soon, so I can tell
> what I would like to see changed.
>
Even if dblatex is different from db2latex in some aspects I'm sure that  
we can converge to a common set of well defined core XSL stylesheets. And  
maybe a wiki is a good way to do the necessary exchanges, but I don't know  
how this can be installed. At least the mailing list is a good start to do  
exchanges ;-)

Regards,

BG