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.
I may have expressed the idea not very clearly.
We do add PDF pages to a FOP-generated document, except we do not use
extension pight now.
We modified PDFRenderer A BIT and particulary have added there the method
renderExternalPage(...)
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.
To extend PDF library is the perfect solution.
But it might take a long time and we need the working solution asap.
So as a temporary solution we can consider the use of iText instead of Pj.
Right now I do not think such substitution is a bit problem.
If iText is able to parse PDF document and if it provides the API to
retrieve PDF entities (e.g. Pages, resources, objects) - no problem.
Should say again, in case of the present implementation PDFRenderer is
affected in a little extent.
2. MathML 2.0 support.
Are you aware of the MathML extension in the FOP repository?
http://svn.apache.org/repos/asf/xmlgraphics/fop/trunk/examples/mathml/
Have just had a look on it and was really surprised - it uses JEuclid!
Just would like to say that we have been developing MathML support for
several month and made a deep tests for it.
During development we were modifying JEuclid and have almost re-written it.
We can now consider the case of the implementation of mathML sub-project in
the scope of FOP (as PDF library)
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
Ok,
we are ready to provide you our source code for features I outlined above
through Bugzilla.
As I understand, the license agreement (CLA) is requried when the issue of
becoming a contributor will arise (after several sucessfull contributions
through Bugzilla, as you wrote).
--
Siarhei Baidun
