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 mailing list.

Doc writingYesYes

Doc Writing

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 impression.



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 languages.


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 formatting process.



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 the results.


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 something simpler.


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.

DocBookLibxslt SourceForge