You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@pdfbox.apache.org by Aaron Kaplan <li...@aaronkaplan.info> on 2009/11/12 20:16:15 UTC
Copyright issues
Why are glyphlist.txt and other Adobe-copyrighted files not included in
the source? I assumed it was because copyright precluded their
redistribution, but now but now I see that they're included in the
PDFBox binary jar. Why is it ok to redistribute them in a jar but not
ok to put them in the source repository?
-Aaron
Re: Copyright issues
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Fri, Nov 13, 2009 at 3:45 PM, Aaron Kaplan
<li...@aaronkaplan.info> wrote:
> Most of the resources are downloaded from maven repositories, but three
> (additional_cmaps.jar, removed_cmaps.jar, glyphlist.txt) are downloaded from
> JIRA. Is there a reason for that?
We just haven't gotten around to getting those resources uploaded to
Maven central yet.
> What is planned with regard to maven? I see that there's a pom.xml, but it
> isn't sufficient for building the project, because it doesn't download these
> external resources (and perhaps for other reasons, I haven't checked).
We've already migrated the FontBox and JempBox builds from Ant to
Maven, and the next goal is doing the same for the main PDFBox build.
I expect to get to it within the next week or so.
> Would you accept patches to pom.xml to make it handle more of the build
> process?
Patches are always welcome. :-) If you want to work on this, please
attach patches to PDFBOX-545 [1]. I'll keep that issue updated as the
migration proceeds.
[1] https://issues.apache.org/jira/browse/PDFBOX-545
BR,
Jukka Zitting
Re: Copyright issues
Posted by Aaron Kaplan <li...@aaronkaplan.info>.
Jukka Zitting wrote:
> See LEGAL-36 [1] for the discussion we had with the Apache legal team
> about how to handle resources that may be redistributed but not
> modified. The consensus was that there is no problem redistributing
> such material, but that we should try to make it clear that these
> files are not open source. The easiest way to do that is to simply
> avoid including them in the source release.
Got it, thanks.
Most of the resources are downloaded from maven repositories, but three
(additional_cmaps.jar, removed_cmaps.jar, glyphlist.txt) are downloaded
from JIRA. Is there a reason for that?
I'm unhappy with the fact that doing a clean build involves downloading
a bunch of files from several different servers. Besides the fact that
it's a waste of time and bandwidth to download the same files again and
again, it means that the build fails if any of the servers is down. If
all the files were in maven repositories, and maven were used to
download them, then they would be cached in the maven local repository.
What is planned with regard to maven? I see that there's a pom.xml, but
it isn't sufficient for building the project, because it doesn't
download these external resources (and perhaps for other reasons, I
haven't checked). Would you accept patches to pom.xml to make it handle
more of the build process?
-Aaron
Re: Copyright issues
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Nov 12, 2009 at 10:02 PM, Jukka Zitting <ju...@gmail.com> wrote:
> The Adobe license permits redistribution but not modification.
Or more accurately: the license permits redistribution only in
unmodified form. There's nothing in copyright law that would prevent
you from modifying the files for your own private use.
BR,
Jukka Zitting
Re: XFA form
Posted by Claudius Teodorescu <cl...@yahoo.com>.
Thank you for the hints.
At this very moment I am beginned in Java, so that I can only use examples, but I will do all my best to use what you point out.
Claudius Teodorescu
Re: XFA form
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
Claudius Teodorescu wrote:
> Thank you for this quick answer.
>
> I think I expressed myself in a wrong way.
>
> My intention is to get the XFA, modify it outside PDFBox and set it again within the PDF file, replacing the original one.
>
> If this is possible, there is an example?
There is some kind of a starting point but AFAIU the code it is only a
placeholder for the code which has to be implemented. Have a look at [1] and you
will see what I'm talking about. If you want to play around with that code, have
another look at [2]. It's an example how to get access to a form and its fields.
Further informations about XFA Forms can be found in chapter 8.6.7 of adobes pdf
1.7 reference manual.
> Thank you,
> Claudius Teodorescu
BR
Andreas Lehmkühler
[1]
http://svn.apache.org/repos/asf/incubator/pdfbox/trunk/src/main/java/org/apache/pdfbox/pdmodel/interactive/form/PDXFA.java
[2]
http://svn.apache.org/repos/asf/incubator/pdfbox/trunk/src/main/java/org/apache/pdfbox/examples/fdf/PrintFields.java
Re: XFA form
Posted by Claudius Teodorescu <cl...@yahoo.com>.
Thank you for this quick answer.
I think I expressed myself in a wrong way.
My intention is to get the XFA, modify it outside PDFBox and set it again within the PDF file, replacing the original one.
If this is possible, there is an example?
Thank you,
Claudius Teodorescu
Re: XFA form
Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,
Claudius Teodorescu wrote:
> Hi,
>
> It is possible to manipulate XFA by using PDFBox?
AFAIK there isn't any support for XFA.
> Thank you,
> Claudius Teodorescu
BR
Andreas Lehmkühler
XFA form
Posted by Claudius Teodorescu <cl...@yahoo.com>.
Hi,
It is possible to manipulate XFA by using PDFBox?
Thank you,
Claudius Teodorescu
Re: Copyright issues
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Thu, Nov 12, 2009 at 9:16 PM, Aaron Kaplan
<li...@aaronkaplan.info> wrote:
> Why are glyphlist.txt and other Adobe-copyrighted files not included in the
> source? I assumed it was because copyright precluded their redistribution,
> but now but now I see that they're included in the PDFBox binary jar.
The Adobe license permits redistribution but not modification. See the
LICENSE.txt file for the details.
> Why is it ok to redistribute them in a jar but not ok to put them in the
> source repository?
See LEGAL-36 [1] for the discussion we had with the Apache legal team
about how to handle resources that may be redistributed but not
modified. The consensus was that there is no problem redistributing
such material, but that we should try to make it clear that these
files are not open source. The easiest way to do that is to simply
avoid including them in the source release.
[1] https://issues.apache.org/jira/browse/LEGAL-36
BR,
Jukka Zitting