Hi Martin and Roland, The FOP team is pleased to accept contributions to FOP, large and small. Contributions are best submitted as a patch attached to an issue in our bug tracking system bugzilla, http://issues.apache.org/bugzilla/enter_bug.cgi?product=Fop.
If you plan a larger contribution, such as the one you intend to develop, it is useful to create a single bugzilla issue, and attach subsequent patches to it. We will create a Subversion branch for your project, to which we will add your patches. We will also keep the branch up to date with respect to the main code (Subversion trunk), so that integration of your contributions with the main code is tested automatically. Our ant build system allows one to test the code with junit, checkstyle, and findbugs tests. We encourage contributors to run those tests. We also encourage them to create and submit test cases for their new functionality or feature and bug fixes. The use of a subversion branch allows you to submit an early implementation to FOP, and discard it later. In view of the complexity of the work, it may be useful to create design documents first, along with theoretical considerations about the algorithms used. You may publish these in your own web space, but you may also use FOP's wiki, http://wiki.apache.org/xmlgraphics-fop/DeveloperPages, for that purpose. The code in our subversion repository is automatically synchronized in a git repository, git://git.apache.org/fop.git or https://github.com/apache/fop. See also http://wiki.apache.org/general/GitAtApache. For larger contributions, the Apache Software Foundation (ASF) wishes to have a contributor license of all copyright owners (authors or their employers) of the submitted code, see http://www.apache.org/licenses/#clas. See also 'How can I contribute?', http://xmlgraphics.apache.org/fop/dev/faq.html#faq-N1000D. See also some parts of 'Guide for new committers', http://www.apache.org/dev/new-committers-guide.html. This enables the ASF to release the code under the Apache license version 2. All contributions must go via patches at bugzilla, so that it is clear that you submitted them under your contributor license with the ASF. Therefore, if you would maintain a public git branch or a public branch in another distributed VC system, we would not pull directly from it. Your first steps would be anything you need to do to arrive at your first submitted patch: design, code, test, submit. You could open a bugzilla issue early if you wish. You could create a wiki page for your project and add design documents to it. We hope to see your contributions to FOP, to the benefit of all its users. Best, Simon Pepping On Tue, Dec 21, 2010 at 04:40:11PM +0100, Roland Schwarz wrote: > Dear developers, dear members of the Project Management, > > we work on a research project called "XML-Print" at the University of > Trier, Germany. The idea is to implement (or improve) a XML to PDF > typesetter with an easy-to-use GUI which helps humanists to publish > their critical editions, dictionaries etc. It will be part of the > toolkit "TextGrid Lab" which is a long-term project to develop a general > framework containing different tools for collaborative work on digital > documents (http://www.textgrid.de/en/startseite.html). > > Having looked at existing approaches FOP seems to be a stable and > promising base to build on. However there are some features missing > either not yet implemented in FOP itself or even not defined in XSL-FO 1.1. > > We therefore would have to implement features based on XSL-FO 1.1, but > also on the requirements for XSL-FO 2.0 as described in > http://www.w3.org/TR/xslfo20-req/. > > Among others we are especially interested in some elements mentioned in > the current design draft like > > - marginalia (2.2.3) > - side-by-side flows (2.2.6) > - line numbering (188.8.131.52) ** > - cross references (2.2.8) > > ** The line numbering will also involve some more complex issues, not > only a simple line numbering of every n-th line. For example there could > be interactions between line numbers and marginalia, which have to be > considered in the typesetting process. > > > We would also have to design and implement new layout features currently > not mentioned in any seen XSL-FO design draft like the usage of a > complex bibliographic apparatus or a grid typesetting feature. There are > also requirements for complex footnotes, which may lead to an extension > of the currently available footnote mechanism in the XSL-FO standard. > > At the current point in our work we wonder how we can use the current > status of FOP, how we can embed our work into future releases and last > but not least, give some work back to the community. One developer would > work full-time on FOP for at least one year. > > Furthermore we would like to know if an early implementation of > requirements -- using a separate namespace of course -- is somehow > wanted and if there is any other group working on them. What would be > the next steps for us? > > Thank you for any responses. > > Best regards and Happy Holidays from > Martin Sievers and Roland Schwarz