You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pdfbox.apache.org by Maruan Sahyoun <sa...@fileaffairs.de> on 2014/04/09 15:10:48 UTC

xmpbox vs. jempbox - which is the one moving forward

Hi,

did we make a decision about xmpbox or jempbox are the one to use for XMP metadata moving forward? There is a discussion in PDFBOX-1187 about cutting the dependency to jempbox and preflight uses xmpbox.

BR
Maruan

Re: xmpbox vs. jempbox - which is the one moving forward

Posted by Maruan Sahyoun <sa...@fileaffairs.de>.
Hi

Am 25.04.2014 um 12:38 schrieb Andreas Lehmkühler <an...@lehmi.de>:

> Hi,
> 
> 
>> Maruan Sahyoun <sa...@fileaffairs.de> hat am 9. April 2014 um 15:10
>> geschrieben:
>> 
>> 
>> Hi,
>> 
>> did we make a decision about xmpbox or jempbox are the one to use for XMP
>> metadata moving forward? There is a discussion in PDFBOX-1187 about cutting
>> the dependency to jempbox and preflight uses xmpbox.
>> 
> Thanks for bringing this up again.
> 
> How about the following scenario:
> 
> We could alter PDMetadata as follows:
> 
> - remove the import/exportXMPMetadata methods
> - provide new methods get/setMetadatastream to provide an Input/Outputstream to
> be used with your favourite XMPMetadata implementation

+1 for being independent.

E.g. Adobe has a Java XMP lib under BSD license http://www.adobe.com/devnet/xmp/library/eula-xmp-library-java.html 

> 
> Pros:
> 
> - this would remove a in many cases not needed dependency in pdfbox
> - users can choose what library to use for handling XMP-Metadata, even any
> thirdparty lib could be used
> 
> Cons:
> 
> - we still have to maintain 2 XMP-libs

I’d think we should remove one of the XMP metadata libs which we can do independent of the above decision.


> 
> WDYT?
> 
> 
> BR
> Andreas Lehmkühler


Re: xmpbox vs. jempbox - which is the one moving forward

Posted by Andreas Lehmkühler <an...@lehmi.de>.
Hi,


> Maruan Sahyoun <sa...@fileaffairs.de> hat am 9. April 2014 um 15:10
> geschrieben:
>
>
> Hi,
>
> did we make a decision about xmpbox or jempbox are the one to use for XMP
> metadata moving forward? There is a discussion in PDFBOX-1187 about cutting
> the dependency to jempbox and preflight uses xmpbox.
>
Thanks for bringing this up again.

How about the following scenario:

We could alter PDMetadata as follows:

- remove the import/exportXMPMetadata methods
- provide new methods get/setMetadatastream to provide an Input/Outputstream to
be used with your favourite XMPMetadata implementation

Pros:

- this would remove a in many cases not needed dependency in pdfbox
- users can choose what library to use for handling XMP-Metadata, even any
thirdparty lib could be used

Cons:

- we still have to maintain 2 XMP-libs

WDYT?


BR
Andreas Lehmkühler