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