Allow hexapdf to be installed

[lurch]

Would it be possible to add hexapdf to this Docker image please? Or would licensing conflicts prevent that?
EDIT: Would it be possible to allow users (at their own risk) to install hexapdf inside the Docker container please?

I tried gem install hexapdf inside the container, and got:

Fetching: cmdparse-3.0.4.gem (100%)
Successfully installed cmdparse-3.0.4
Fetching: geom2d-0.2.0.gem (100%)
Successfully installed geom2d-0.2.0
Fetching: hexapdf-0.10.0.gem (100%)
Successfully installed hexapdf-0.10.0
ERROR:  While executing gem ... (Gem::DocumentError)
    RDoc is not installed: cannot load such file -- rdoc/rdoc

I know nothing about Ruby, so I (naively) tried running gem install rdoc and that gives an error too:

Fetching: rdoc-6.2.0.gem (100%)
Successfully installed rdoc-6.2.0
ERROR:  While executing gem ... (NoMethodError)
    undefined method `reset' for RDoc::TopLevel:Class

😢

[mojavelinux]

My position is absolutely not. AGPL is an extremely viral and invasive language and is just asking for trouble.

The latest release of Asciidoctor PDF supports optimization out of the box using the -a optimize flag. The only requirement is that the image have ghostscript (gs).

[lurch]

The latest release of Asciidoctor PDF supports optimization out of the box using the -a optimize flag.

Hmmmm... (testing this outside the Docker container, since that doesn't contain gs)

$ asciidoctor-pdf --version
Asciidoctor PDF 1.5.0.beta.6 using Asciidoctor 2.0.10 [https://asciidoctor.org]
Runtime Environment (ruby 2.6.3p62 (2019-04-16 revision 67580) [x86_64-linux]) (lc:UTF-8 fs:UTF-8 in:UTF-8 ex:UTF-8)
$ asciidoctor-pdf -r asciidoctor-mathematical -v -a pdf-theme=my-theme.yml -o my-book-default.pdf my-book.adoc
$ asciidoctor-pdf -r asciidoctor-mathematical -v -a pdf-theme=my-theme.yml -a optimize -o my-book-optimize.pdf my-book.adoc
$ hexapdf optimize --compress-pages --force my-book-default.pdf my-book-default-hexapdf.pdf
$ hexapdf optimize --compress-pages --force my-book-optimize.pdf my-book-optimize-hexapdf.pdf
$ ls -lh *.pdf
-rw-rw-r-- 1 andrew andrew 6.9M Oct 15 10:47 my-book-default.pdf
-rw-rw-r-- 1 andrew andrew  17M Oct 15 10:48 my-book-optimize.pdf
-rw-rw-r-- 1 andrew andrew 1.3M Oct 15 10:51 my-book-default-hexapdf.pdf
-rw-rw-r-- 1 andrew andrew  12M Oct 15 10:52 my-book-optimize-hexapdf.pdf

I've edited this PR's title to (hopefully) be less controversial 😉

[mojavelinux]

This is the game of optimizing a PDF. Some optimizers make it better. Some optimizers make it worse. It highly depends on what objects are in the PDF.

You might try lowering the quality that ghostscript uses instead of using the default:

$ asciidoctor-pdf -a optimize=screen -o my-book-optimize.pdf my-book.adoc

If there are other settings we can enable in Ghostscript to reduce the size, I'm open to adding support for them. See https://github.com/asciidoctor/asciidoctor-pdf/blob/master/lib/asciidoctor/pdf/optimizer.rb.

But the hexapdf license is still a problem, regardless of how much better it works over Ghostscript.

I think this container should at least provide Ghostscript. It's an essential tool for working with PDF documents.

[lurch]

Just as a data-point, using -a optimize=screen then creates a PDF of 1.6 MB, but unfortunately it reduces the quality of the images too much.

I think this container should at least provide Ghostscript. It's an essential tool for working with PDF documents.

I'll create a separate issue for that 👍

[mojavelinux]

I recommend playing around with Ghostscript directly until you can figure out the settings that optimize the PDF without reducing the quality. It should be possible, though it will likely require a lot of trial and error.

To be honest, I really don't know why the default quality is not reducing the size of the PDF. Perhaps that's a bug in Ghostscript.

[lurch]

I recommend playing around with Ghostscript directly until you can figure out the settings that optimize the PDF without reducing the quality.

Despite your dislike of it's licence, hexapdf is working fine for me, so I'm going to stick with that for now rather than wasting time messing around with ghostscript 😉

[mojavelinux]

You're absolutely free to use hexapdf and I encourage to do so if you get better results. It's just dangerous to include it in an open source project because it's license is extremely viral. (Though I wonder how that holds for a Docker container since it's only used as a runtime, not a library).

[mojavelinux]

Just as a data-point, using -a optimize=screen then creates a PDF of 1.6 MB, but unfortunately it reduces the quality of the images too much.

You might try "ebook" instead of "screen".

[mojavelinux]

I've looked into this more and realized that the AGPL might not be a problem after all in a Docker container. In fact, there's likely already AGPL software in the image. And, much to my surprise, Ghostscript is also AGPL. (What is it with PDF software being AGPL?!?)

So if we're just talking about installing the gem so that hexapdf command is available, or installing Ghostscript so the gs command is available (which the Asciidoctor PDF optimizer uses), then I'm okay with that, revising my earlier statement.

Side note: The idea of calling hexapdf as a command (and not via the API) might actually allow us to use it in the Asciidoctor PDF optimizer, if available. I'll have to study that a bit more.

[lurch]

You might try "ebook" instead of "screen".

That produces a 2.4MB PDF which still has slight reduction in image quality, but not as bad as "screen". So for the time being I'll stick with the hexapdf solution.

[mojavelinux]

Good to know, though. Thanks for checking.

[gettalong]

@mojavelinux Just stumbled across this issue.

AGPL allows including the software in an aggregate. So if you create a docker image and install HexaPDF via gem install hexapdf, you are only creating an aggregate and that is allowed. So it should not be a problem if you include HexaPDF. Also see https://www.gnu.org/licenses/gpl-faq.en.html#MereAggregation

Furthermore, if you don't directly require "hexapdf" but only shell out to the binary - like you do with ghostscript -, the AGPL also doesn't come into play because you just call a binary.