From: Stefan S. <se...@sy...> - 2006-03-10 14:46:41
|
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' ? > - 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. 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. > - integrates easily with other programs > > I have been working on reducing the references to third-party libraries in > libfo headers. > > Stefans idea of bundling PangoXSL with xmlroff fits in here since, as Mauro > also noted recently, it would save downloading and installing another > package just to use xmlroff. > > - and with scripting languages > > Mauro and I have been discussing API changes (and anyone else can chime > in). > > There has been no action on creating a SWIG interface. (I did download > SWIG, but that hardly counts as action.) > > > There's a bunch of other stuff that needs to be done just because this is > 0.4.0 instead of 0.3.x, including: > > - Update the libfo-examples module to work with libfo-0.4. > > I would also like to update the GTK+ examples to use real tree widgets > instead of the current shortcut of creating text representations of trees. > Any takers? > > > What else needs to be done for xmlroff 0.4.0? I'v been meaning to look at the test suite for quite a while now. I'm still not sure I understand everything. How are results validated ? Is there some program that checks that the generated pdf is correct or not ? Thanks, Stefan |