GIFLIB can be removed from the build about heroku-buildpack-vips HOT 9 CLOSED

Hi John,

Thank you for letting me know about this. I will do it over the weekend.

from heroku-buildpack-vips.

Hi again, I spent some time fixing up that Dockerfile I made a while back:

https://github.com/jcupitt/docker-builds/tree/master/libvips-heroku18

It seems to all work. You end up with a 4MB tarball which runs on a bare heroku 18 image and supports most file formats, including PDF. If you drop PDF support, it goes down to 1.5MB.

Hopefully this can copy-paste in a pretty simple way into your build pack. It works with heroku 20 too, I've not tried any others.

from heroku-buildpack-vips.

Thanks for the update, John.

I'm wondering what the ramifications of switching from poppler to PDFium would be. I seem to remember that a long time ago I had some image "ghosting" issues and it was related to the PDF renderer that was being used. I remember it was the same engine that is used by Firefox. Would that be poppler or PDFium? I use the PDF capabilities of vips very heavily, so I am hesitant to make that change in the buildpack...

from heroku-buildpack-vips.

libvips/libvips#1230

I found the issue here.

Are you aware of any differences in how PDF loading works between poppler and PDFium that I should be aware of? I'm still hesitant, but less so since the issue above involved poppler which the buildpack currently still uses.

from heroku-buildpack-vips.

Hi again, here's my understanding of the pros and cons:

• Robustness pdfium is the PDF reader that's built into Chrome, so it's extremely well tested and safe. Poppler is fuzzed too, but not to the same extent. The (maybe?) slight weak point is the libvips / pdfium link, since we don't fuzz that specific bit of code at the moment. I'll add it to the libvips fuzz package.
• Compliance Again, being Chrome's PDF reader means that pdfium ought to have excellent standards compliance. Though I don't actually know of any specific cases that pdfium handles better.
• Performance Pretty similar, both speed and memory use. You'll find some PDFs are faster with one and some faster with the other.
• Licence This is the largest difference: poppler is GPL3 and pdfium is MIT. All rails programs using the poppler buildpack are probably gpl3, maybe accidentally.
• Threading Poppler lets two threads render two separate PDFs at the same time, but pdfium is very, very single-threaded: only one thread may do any pdf rendering at any one time (this is because of its origins as the FoxIt Windows desktop PDF previewer and won't be fixed, unfortunately). I don't know if this has performance implications, it depends on the threading model used by rails.

In my opinion it's a change worth making for the robustness and the much more liberal licence, but it's certainly debatable and I can see people taking the opposite view.

from heroku-buildpack-vips.

I remember it was the same engine that is used by Firefox.

I think FF uses their own PDF previewer written in javascript. Chrome uses pdfium, derived from FoxIT, that they've open-sourced under the MIT licence. Poppler derives from the old Unix xpdf desktop previewer.

from heroku-buildpack-vips.

... adding pdfium to the libvips fuzzer: google/oss-fuzz#7336

from heroku-buildpack-vips.

Thank you again, John. I finally had time to get all of the open PRs taken care of, so this is my next item to handle.

from heroku-buildpack-vips.

This is finally done 👍

from heroku-buildpack-vips.