Hi all, When we wrote xmpbox, we tried to keep compatibility with the previous jempbox. It had some limitations.
So some years ago, I needed a more open xmp implementation and I wrote xemph [1]. You can have a look, I can rework on it if needed (I guess there is an invalid dependency). Regards, [1] https://github.com/gbm-bailleul/xemph Guillaume Le dim. 28 mars 2021 à 19:37, Andreas Lehmkuehler <andr...@lehmi.de> a écrit : > Am 28.03.21 um 19:27 schrieb sahy...@fileaffairs.de: > > 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. > > I'm going to start a vote about the future of preflight after the release > of the > first RC for 3.0.0. Depending on the output we should think about a vote > about > the future of xmpbox as well. > > Let us see what happens and decide afterwards. > > Andreas > > > > > 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 > >> > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pdfbox.apache.org > For additional commands, e-mail: dev-h...@pdfbox.apache.org > >
