Re: Status of project, and where to next

On Sun, 24 Apr 2005 00:15:42 +0200, Nikolai Prokoschenko =20
<[email protected]> 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 seem=
s
> 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 fi=
nd
> most "big" mistakes - at least I could verify that my table morerows co=
de
> 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 s=
ay
> I understand all the background for this or that decision.

I agree. I think it comes from the XSL language translation code by N. =20
Walsh stylesheets to map how to say "chapter" in spanish for instance. It=
 =20
is well suited for the original purpose, but not really to translate =20
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 =20
> 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 "\\" =
=20
to make latex happy. Doing this task with XSL is quite possible but reall=
y =20
slow. I wanted something really faster because I need to drive books =20
containing more than 200 pages. This said, maybe that EXSL functions now =
=20
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 =20
programming skills with this point. Currently it's for table support.
- to do some compilation stuff once the latex file is available. Typicall=
y =20
it detects and converts some figures format to the expected one for the =20
tex compiler. For example it converts EPS figures to PDF when pdflatex is=
 =20
used.

So I would say that:
- Having all the XML translation done by XSL would be the best (and =20
cleanest) thing provided that the two first points are really possible to=
 =20
do with XSL. I confident with this. At least the string replacement is no=
t =20
a functionnal problem (XSL can do this) even if it is still a performance=
 =20
issue. Besides the David Hedley contribution skip the table coding I =20
needed to do with perl.
- The last perl processing seems to me interesting (I don't have to care =
=20
how to compile the file) but is not a part of the XML translation. It's =20
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 tel=
l
> what I would like to see changed.
>
Even if dblatex is different from db2latex in some aspects I'm sure that =
=20
we can converge to a common set of well defined core XSL stylesheets. And=
 =20
maybe a wiki is a good way to do the necessary exchanges, but I don't kno=
w =20
how this can be installed. At least the mailing list is a good start to d=
o =20
exchanges ;-)

Regards,

BG


-------------------------------------------------------
SF.Net email is sponsored by: Tell us your software development plans!
Take this survey and enter to win a one-year sub to SourceForge.net
Plus IDC's 2005 look-ahead and a copy of this survey
Click here to start!  http://www.idcswdc.com/cgi-bin/survey?id=3D105hix