Getting Involved with xmlroff
Making progess on xmlroff needs a variety of skills, as the
following table shows. If you want to get involved with xmlroff, make
your interest known on the xmlroff-list
- xmlroff needs more user documentation on how to run
xmlroff and more developer documentation about how it works.
The xmlroff website is people's first
introduction to xmlroff. You can help make a good first
xmlroff is written in C, even if most of the C
is generated by XSLT stylesheets. Your C knowledge will give
you access to all areas of xmlroff.
We need more examples of how to use xmlroff
and how to use libfo with different toolkits and scripting
The Java Native Interface (JNI) uses C on the
"native" side. You can use your C skill to improve and expand
the interface to add configuration and more control of the
The testing module uses XSLT stylesheets to
control the testing, collate the results, produce HTML
reports, and perform updates of the test results XML fiie.
You can apply your XSLT skills to make the testing process
faster and to make the reports easier to read, more useful,
and easier to update.
The majority of the C code in xmlroff is
generated using the XSLT stylesheets in the "spec-dump"
module. There are many ways the stylesheets could be improved
without requiring knowledge of C, and even more ways that they
could be improved using some C knowledge or in cooperation
with someone else who does know C.
This website is built from DocBook Website XML
using the DocBook Website XSLT stylesheets. Much as we like
them, the stylesheets aren't perfect, and there are
customizations and improvements that we'd like to make.
xmlroff is an XSL formatter, after all, and
answering questions about "How should xmlroff work?" is more
efficient than asking "Why isn't xmlroff working correctly?"
when you come to use it.
We do, however, still need XSL expertise to
evaluate results of XSL testsuites. As well as the xmlroff
testsuite, there's multiple XSL testsuites from NIST and
elsewhere that we would like to test xmlroff against if only
we had more people with the expertise necessary to evaluate
Every new formatting object and property
should have test cases in the xmlroff test suite so the
developers can show when the formatting object or property is
implemented correctly. XSL knowledge is handy when developing
test cases for interrelated properties and other arcana.
The build process uses Perl to create some C
source code from an XSLT stylesheet (bucking the trend of
using an XSLT stylesheet to create C source code from XML).
There may be other opportunities to generate source code from
The testing module uses Perl for many things,
such as finding file sizes, that are beyond the ability of the
average XSLT processor. The testing module needs to be
reorganized to make it easier to run tests on multple versions
of xmlroff, e.g., to test multiple backends, and making those
sorts of changes will depend on Perl skills.
The current native interface is the simplest
possible. Expanding the native interface to, for example, add
more control over formatting will make libfo more useful to,
and therefore more used in, Java programs. Expanding the
interface requires Java skills to make the interface "feel
right" to other Java programmers.
Every xmlroff module uses the GNU Autotools both for resolving
dependencies and for packaging distributions. Modules, such as libfo
and libfo-examples, that compile code use Autotools to manage the
"make" process. Just because we use the Autotools doesn't mean that
we use them to their best advantage, as recent efforts to build
PangoXSL from xmlroff would illustrate. You can use your Autotools
skill and experience to work to improve the build processes for any
and all of the xmlroff modules.