On 26.07.2005 15:47:03 Siarhei Baidun wrote:
> Hello
> Do not know exactly the person that is responsible for such issue as mine. 

Not a single person, but the whole FOP developer community and
eventually the XML Graphics project management committee (PMC). But you
found exactly the right spot to write to.

> So I decided to write to fop-dev.
> Our company has been sucessfully using FOP for several years.
> As our customers required extended functionality and FOP had several bugs 
> and restrictions, 3 years ago we created our own FOP branch.
> Those days we were in a hurry and did not consider the issue of commitment 
> of our modifications to Apache.
> 
> Now we have troubles with our FOP branch support because we have to 
> constantly merge it with Apache's FOP. Having now necessary resources we'd 
> like very much to commit our changes to Apache.

That's very good news.

> There are two main features we have implemented in the FOP:
> 1. the insertion of exeternal PDF documents into the rendered PDF document.
> The mechanism is similar on the images insertion, we use 
> fo:external-graphics element and put content-type property equals to "pdf"
> 
> For example,
> 
> <fo:external-graphics content-type="pdf" file="c:\test\testfile.pdf"/>
> An external PDF file is inserted into rendered PDF document AS-IS, also 
> there is a possibility to insert page range, not the whole external PDF.

This sounds quite interesting and has been asked for a few times. A
simpler use case would be simply to be able to add PDF pages to a
FOP-generated document, possibly through a custom extension.

> For external PDF uploading we use the third-party library Etymon Pj 
> (http://www.etymon.com/epub.html) .
> It is under GNU GPL license .

This is a problem. Apache software can't include or use GPL-licensed
software. A different approach would be to extend our own PDF library
to support parsing PDF or to use iText (which is MPL 1.1 licensed and
therefore usable for us). But the latter option would probably mean to
rewrite the whole PDFRenderer to use iText with all the implications
that arise with this. That's why I'd personally prefer extending our own
PDF library. But that is open for discussion.

> 2. MathML 2.0 support.
> To implement MathML support, we also used the  third-party library named 
> JEuclid.
> But we can consider the case of MathML support implementation fully inside 
> of FOP project, without JEuclid usage.
> It would be not very expensive in human/time resources as our guys almost 
> fully re-implemented JEuclid.

Are you aware of the MathML extension in the FOP repository?
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/

> Some other features and bugs fixes were made.
> 
> 3 years ago we based our FOP branch on the Apacehe FOP version 0.20.4rc.
> As FOP maintenance branch is not being developed, we'd like to make 
> contributions on the main branch.

That would be extremely welcome and just at the right time!!!

> Coule you please advise on the steps on how to contribute. I guess there 
> should be some code compliance rules and some agreements with Apache.
> Also in case our customers will port their applications on new FOP we could 
> participate in FOP contribution more actively and push forward its success.

Most of the basic information for contributors is found here:
http://xml.apache.org/fop/dev/index.html

If you plan to contribute anything larger than a bugfix on an existing
file we will need a CLA (contributor license agreement) for each person
that contributes to the project (to be sent to the ASF secretary). In
addition to that it may be necessary to submit a CCLA (corporate
contributor license agreement). Please see the following link for more
information:
http://www.apache.org/licenses/

Code conventions are found here:
http://xml.apache.org/fop/dev/conventions.html

Before you start to work on anthing bigger, please tell us what it is so
we can give some guidance and make sure there aren't any big
disappointments. Contributions should be sent to us using Bugzilla
entries which we will review and commit to the repository once
everything is fine. People contributing substantially to the project
(code, documentation, support etc.) over a longer period of time are
eligible to become a committer which includes write-access to the
code-repository, voting right and stuff like that. More infos on how
that works under:
http://xmlgraphics.apache.org/charter.html
http://www.apache.org/foundation/faq.html

I hope that helps. If you have any further questions, don't hesitate to
ask.

Jeremias Maerki

Reply via email to