Am Sonntag, dem 28.03.2021 um 18:47 +0200 schrieb Tilman Hausherr: > Am 28.03.2021 um 18:44 schrieb sahy...@fileaffairs.de: > > Am Sonntag, dem 28.03.2021 um 16:36 +0200 schrieb Tilman Hausherr: > > > I don't have an opinion on XMP because I don't use it. > > As XMP is needed for getting/setting metadata esp. since PDF 2.0 > > there > > needs to be support for it - not neccesarily from us directly i.e. > > we > > could integrate a different lib. > > > > I'll revert the work done in PDFBOX-5128 and we get back to it > > after > > 3.0 - WDYT? > > > No, why revert? As far as I understand it, it makes possible that > XMPs > with non standard schemas can still be parsed so that people can > retrieve the standard stuff, so that is very useful.
it's still very limited - I can keep it but as long as the XMP doesn't conform to the (strict) initial parsing rules it will still fail. The idea to revert was because of getting time to work on it (if we decide to do so) or otherwise keep it in the state it has been before i.e. targeted to PDF/A-1 conforming XMPs. BR Maruan > > Tilman > > > > > > > BR > > Maruan > > > > > Re preflight, I agree with you. It was great but it has hit a > > > dead end, > > > and VeraPDF is better because it is more flexible. > > > > > Tilman > > > > > > Am 28.03.2021 um 15:52 schrieb Andreas Lehmkuehler: > > > > Am 28.03.21 um 15:00 schrieb sahy...@fileaffairs.de: > > > > > Fellow colleagues, > > > > > > > > > > there was some discussion about the ability of XMPBox to > > > > > parse > > > > > arbritary XMP which lead to PDFBOX-5128. > > > > > > > > > > Now, after digging into the code and after reading through > > > > > the > > > > > various > > > > > specs for XMP and PDF/A as it stands now XMPBox in it's > > > > > current > > > > > implementation is too restricted from the start as it not > > > > > only per > > > > > default (although there is a way around it) only supports > > > > > parsing > > > > > predefined XMP schemas restricted to the ones defined in > > > > > PDF/A-1 > > > > > but > > > > > also does some validation in the parsing phase. > > > > Exactly the point where I stopped some time ago, when trying to > > > > just > > > > expand the parser ;-) > > > > > > > > > > > > > Now, in order to get to an implementation for arbritary XMP > > > > > that > > > > > needs > > > > > to change with the validation for PDF/A-1 put on top. We > > > > > could use > > > > > the > > > > > existing implementation in a generalized way, use an existing > > > > > Java > > > > > XMP > > > > > parser such as Adobes XMPCore or approach it in a layered > > > > > fashion > > > > > XML - > > > > > > RDF -> XMP with supporting libs for that. > > > > > The other option would be to keep XMPBox as is and for > > > > > general > > > > > purpose > > > > > add a general parser into the project or simply refer to > > > > > XMPCore. > > > > > > > > > > That leads me to the question about the benefit of having a > > > > > general > > > > > purpose (ASL licensed) XMP lib as part of PDFBox? Thoughts? > > > > It replaced JempBox when preflight was added to PDFBox, saying > > > > that, > > > > it was a more or less historical reason. > > > > > > > > I myself never needed that XMP-stuff. It is used by TIKA and > > > > preflight > > > > and maybe others. > > > > > > > > I have to admit that I already thought about the future of > > > > preflight. > > > > I've planned to come up with that topic after releasing 3.0.0, > > > > but > > > > why > > > > waiting. > > > > > > > > Preflight is part of PDFBox but is practically not maintained. > > > > Preflight support is limited to A1B and I don't see anybody who > > > > plans > > > > to extend it. VeraPDF has a lot more to offer and is open > > > > source as > > > > well, so maybe a better alternative ... > > > > > > > > How about removing preflight with 4.0.0? This would remove the > > > > one > > > > and > > > > only hard dependency of XMPBox, so that it would be easier to > > > > decide > > > > if we really need to maintain out own XMP lib. > > > > > > > > > > > > Andreas > > > > > > > > --------------------------------------------------------------- > > > > ------ > > > > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > > > > For additional commands, e-mail: dev-h...@pdfbox.apache.org > > > > > > > > > > ----------------------------------------------------------------- > > > ---- > > > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > > > For additional commands, e-mail: dev-h...@pdfbox.apache.org > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > -- -- Maruan Sahyoun FileAffairs GmbH Josef-Schappe-Straße 21 40882 Ratingen Tel: +49 (2102) 89497 88 Fax: +49 (2102) 89497 91 sahy...@fileaffairs.de www.fileaffairs.de Geschäftsführer: Maruan Sahyoun Handelsregister: AG Düsseldorf, HRB 53837 UST.-ID: DE248275827 --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org For additional commands, e-mail: dev-h...@pdfbox.apache.org
