Re: [xmlroff] Features required for xmlroff 0.4.0?

[Tony G. <Ton...@Su...>]

Stefan Seefeld <se...@sy...> writes:
> Tony Graham wrote:
>>  - fast
>>    We're still relying on the fact that xmlroff is written in C.
>>    Recent changes to, for example, avoid using xmlDocPtr in public libfo
>>    header files may mean that xmlroff is fractionally slower than previously.
>
> I'm not worried about this at all, but I'm curious: why do you want to hide
> the libxml2 dependency ? Do you expect to replace that, or at least make it
> a true 'implementation detail' ?

It should make it easier to interface to libfo, but my main motivation is to
get away from have seemingly all of xmlroff depend on seemingly all of the
third party libraries that xmlroff uses.

The changes that I've already made to headers and to Makefiles to add
convenience libraries means that compiling xmlroff is 25% faster now than it
was for xmlroff 0.3.9.  That makes a difference to me, at least.

>>  - free
>>    Yup, still free.
>
> Good ! :-)
>
>>  - high-quality
>>    Quality hasn't gone down AFAICT, but then 'quality' is a vague term.
>>    There are at least two recent reports of segfaults that should be fixed so
>>    xmlroff better exhibits the quality of not falling over when you use it.
>
> I think for usability is is important to be as transparent as possible, i.e.

The focus of this thread is what needs to be done before we can release an
xmlroff 0.4.0.

I would hope that xmlroff is already highly transparent: the current
conformance to the spec is on the website and in the xmlroff manual, and
libfo-compat.xsl has a 'verbose' parameter that, when true(), means
libfo-compat.xsl will output a message for nearly every change it makes.

When we incorporate libfo-compat.xsl into the xmlroff executable, we also need
to continue to support the 'verbose' parameter and support an xmlroff option
that will print out the libfo-compat.xsl stylesheet so people can see for
themselves what's being modified and how.

You are welcome to propose additional features that would be required for
xmlroff 0.4.0.

> not only avoid segfaults (obviously), but also report to the user whenever
> some input was encountered that couldn't be dealt with as mandated by the specs.
> This may be in part documentation that explains how to work around the unimplemented
> feature, or just a notice "Warning: this node is skipped !".
> Again, users will probably be unfamiliar with fo, as that is only an intermediate
> step between the initial xml (docbook, say), so giving meaningful messages may be
> out of scope for xmlroff. May be some docbook people may want to collaborate,
> though, for example Norm may want to modify the docbook-xsl stylesheets to
> accomodate xmlroff better (there are already special cases for saxon et al, so
> why not xmlroff ?)
>
>>  - multi-platform
>>    This is supposed to mean "also runs on Windows".  I was hoping I could say
>>    this would be nice to have for xmlroff 0.4.0, but I think it is essential
>>    that xmlroff 0.4.0 runs on Windows (even if it requires cygwin to do it).
>>    I need to reinstall Windows on a laptop before I'll be able to start on
>>    this.
>>  - XSL formatter
>>    Unfortunately, I don't see myself being able to implement any new FOs or
>>    properties for xmlroff 0.4.0 given the number of other changes that I'm
>>    working on.
>
> Understandably !
>
>>  - that aims to excel at DocBook formatting
>>    Stefan's idea of including libfo-compat.xsl in xmlroff fits in here, since
>>    you would then not need an additional step when processing DocBook files.
>>    The man pages in DocBook markup idea would also fit in here.
>
> I think you may consider announcing xmlroff on the docbook-app list, and in particular,
> ask for help to make the combination of docbook-xsl and xmlroff as usable as possible.

I (or someone else) still need to announce xmlroff 0.3.9 on all the usual
lists.

I (or someone else) still need to create a FreshMeat entry for xmlroff.

Regards,


Tony.