[lmi] notes on using xmlroff

[Vaclav Slavik]

Hi,

I looked into using xmlroff (its latest version as we as the SVN
version) instead of FOP, but my results are rather discouraging so far.

Out of the box, it will fail to parse LMI inputs (I'll get to this
later). If I tell it to ignore errors, it produces some outputs, but
there are some obvious defects. Some are minor (cover page missing,
because it couldn't parse border description; signature lines omitted),
some are major. Most importantly, headers and footers are missing on all
pages, because xmlroff doesn't support <fo:static-content> at all.

Also, xmlroff lacks support for some things that I don't think are
terribly advanced, for example:

  * border="2pt solid blue" is too complicated for it ("2pt" or "solid"
    is OK)
  * padding="1pt .5pt 0", likewise
  * I got this error for <external-graphic>:
    Invalid value datatype for 'src' property: company_logo.png (FoName)

If we wanted to use it, we'd have to either (a) make extensive changes
to our XSL files, or (b) fix xmlroff.


Doing (a) -- as well as developing against xmlroff in general -- is
further complicated by its poor error reporting. For example, the first
error I got from it was simply this:

  (xmlroff:25508): libfo-WARNING **: Expression evaluation error:: Evaluation 
resulted in an error
  Object path: /FoTree[1]/FoRoot[1]/FoPageSequence[1]/FoFlow[1]/FoBlockBlock[1]

I had to hack the sources to add some logging to figure out that xmlroff
failed to parse the "border" property in
<fo:block border="2pt solid blue" ...>. (If I could add this in one
place, I'd submit a patch upstream; but I'd have to do the same all over
the semi-generated source code to do it right.)

In my limited experience with FOP, it's error messages were rather good
and enabled me to identify problems easily. With xmlroff, I spent lot of
time tracking down the problems.


I'm pessimistic about (b) too. What I've seen of xmlroff's code didn't
make the impression of being easy to work with. Large chunk of the code
is generated from xslspec.xml (which appears to be human-readable(!) XSL
spec) by a set of cryptic XSL(!) programs; the generated files are then
manually modified.

In short, I think we're better off with Apache FOP.

Regards,
Vaclav