Upgrade PDFBox and PdfBoxGraphics2D version. Also fix JDK 11 build

[rototor]

No description provided.

[rototor]

Thats strange... The tests pass when running them in IDEA, but they fail when running with maven ...
I am not sure if this is related to the PDFBox upgrade.

[rototor]

This pull request got a little bit bigger now than thought ...

I've fixed the javadoc for JDK 11 and now mvn install also works with JDK 11.

[danfickle]

Thanks hugely mate! I was dreading the jdk11 stuff. I’ve got the flu, but I’ll try to merge this and do a release in the next twelve hours as this is a security release of pdfbox. The release of pdfbox also incorporates a fix for font files being left unclosed if not used so I can remove our workaround code in the pdf font resolver.

Thanks again and feel free to add any commits in the next few hours while I try to sleep.

[rototor]

No hurry from my side, the CVE in PDFBox is about reading special crafted PDF files, which can burn many CPU cycles and theirfor DOS a system. As this project is mostly about writing PDFs we are not directly affected

But this project should benefit from the LosslessFactory improvments I contributed to PDFBox. The image compression got better. (See https://issues.apache.org/jira/browse/PDFBOX-4184)

Get well soon!

[danfickle]

Thanks. I’m impressed with your willingness to get dirty with the details of image compression. If you want to do the same for jpeg, I notice that in JPEGFactory it appears that the image is just decoded to get colour space, width and height. Width and height can be obtained without reading the pixels through the ImageReader api which just leaves color space, for which I couldn’t find a reliable built in api.

P.s: Found some code here:
https://github.com/drewnoakes/metadata-extractor/tree/master/Source/com/drew/imaging/jpeg

[danfickle]

NOTE to self:
I think the only reason we need JAXB dependency is the Base64 decoding in com.openhtmltopdf.util.ImageUtil but we have an alternative implementation of Base64 decoding in com/openhtmltopdf/protocols/data/DataURLConnection.java which we could perhaps use or find a more robust source implementation.

[Jugen]

Not sure if it's more robust but java.util has a Base64 class (since JDK1.8)

[rototor]

@Jugen If we just upper the required java version of this project to JDK 1.8 than we can just use java.util.Base64 and drop the JAXB dependency. I'm at least on JDK 1.8 with all my project for some years now, and on JDK 10 with my main project (I can't get on JDK 11 yet, as guice/cglib is not yet there; Those low level libraries always need an ASM upgrade...).

I would be fine with a JDK 1.8 requirement. But this is on @danfickle to decide.

@danfickle I'm in the process of migrating my main project from iText to PDFBox. For that I need feature parity, at least for the features I need. And writing images with color profiles into a PDF is just something I need for my main project.

[danfickle]

Lambdas sure are tempting... I’ll start asking if anyone is still on 7.

[danfickle]

Ok, I’ve asked the java 8 question.