On 26.07.2005 16:51:35 Siarhei Baidun wrote:
> >> 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(...)

Ah, I see. But in that case external-graphic is probably not the right
element to use as it is an inline-level element.

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

iText is able to handle that, yes.

> >> 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)

Provided, we get the licensing issues right, yes. This would include
contacting the original authors of JEuclid if you based your code on it.
Furthermore, bringing in a whole subproject such as JEuclid would
involve going through the Apache Incubator. But let's first get some
opinions on that move (see my other thread).

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

No, the ASF policy was recently changed (or rather clarified) so you
would need to submit a CLA for any contribution bigger than a trivial bugfix
on an existing file, i.e. for new files, even if you're not yet a
committer.


Jeremias Maerki

Reply via email to