Upcoming default changes for Brotli Decode in PDFium

[Aryan Krishnan]

Hi everyone,

Writing this thread to talk a bit about what is next for Brotli Decode in PDFium and get some thoughts/feedback from embedders.

The context

For context, in about March of last year, the PDFa made an announcement regarding Brotli compression in PDFs. PDFium has had experimental support for this feature since about June of this year. Since then, we have continued to work on the feature to improve it and ensure compliance with the official specification released in August.

What is next

We would like to share that BrotliDecode and the associated dependencies will soon (after cl [1] lands) be compiled in (by default) as part of PDFium (Issue [2]).

[1] - https://pdfium-review.googlesource.com/c/pdfium/+/151650
[2] - https://issues.chromium.org/issues/475855993

While this would likely increase the binary size (by ~161KiB for a release build), this will allow PDFium embedders to support a wider array of Brotli-encoded PDFs going forward, especially as they continue to become more widespread.

Trying out Brotli Decode

For anyone willing to try out BrotliDecode, one can build PDFium with pdf_enable_brotli=true and test it out using either the binaries or PDFium test. Additionally, one can also use Chromium, Chrome Canary, Stable Chrome (although Stable may not have the latest changes), or anything else on Chrome waterfall with #pdf-brotli-decode set to true.

Disabling Brotli Support

To prevent compiling it in

Even still, if embedders would like to prevent BrotliDecode code and its dependencies from being compiled in (and keep the smaller binary size), the code can just be built with pdf_enable_brotli = false.

To toggle or edit whether Brotli is enabled at runtime

Furthermore, embedders can also disable or enable BrotliDecode at runtime. BrotliDecode is disabled by default when the Library version in the configuration is less than 6, with versions greater than or equal to 6 enabling or disabling Brotli based on the value of the m_BrotliEnabled configuration option.

Conclusion and TL;DR
BrotliDecode will soon be compiled in by default in PDFium, adding ~161 KiB to the binary size to support modern Brotli-compressed PDFs. Please feel free to test out the implementation as per the instructions above, and please feel free to file bug reports if you encounter any issues.

Thanks!
 - Aryan

[Jeroen Bobbeldijk]

I have just tried out a WebAssembly build (Emscripten) that enables the build flag and it compiled fine on the first go, so that's nice!

Will the config version 6 check be removed ad some point?

[Aryan Krishnan]

Thanks for the point. As of now, I don't think so. We came to this after a discussion about the clarity of the API, and we feel that Brotli being silently enabled in a version where the configuration option to enable or disable Brotli doesn't exist causes greater confusion. That being said, though, if others feel similarly about config version 6, we can be open to reconsidering removing it as well. Thanks!

[Jeroen Bobbeldijk]

I don't have a very clear opinion on it, to me it felt a bit odd since all the other image codecs don't have a configuration flag. If the PDF specification allows Brotli, then what would be the reason to put it behind a runtime configuration flag?

[geisserml]

For the time being, I'd say the current API is just fine.

> If the PDF specification allows Brotli, then what would be the reason to put it behind a runtime configuration flag?

Perhaps the idea is that it's an incredibly new feature and PDF 2 only...

[Aryan Krishnan]

Hi, thanks for the discussion - and yes, @geisserml is right on this.

BrotliDecode in PDFium was built when it was still experimental, and even now it is a very new feature exclusive to PDF 2.0. Given that the feature is still very new, we want to leave the choice up to specific embedders. For instance, Chromium has had it disabled by default for a long time; only recently has it been enabled by default in the latest canary. Even so, someone else may want to leave it disabled to focus on PDF 1.7 or leave the choice up to the user, another utility of the option.

In future as well, even when BrotliDecode eventually stabilises, we would likely be cautious when it comes to removing the configuration flag, as we wouldn't want to take the feature away from anyone who has come to rely on it for anything. Once again, what happens with flags much, much further down the line is something which we have not looked into yet, and our perspectives may change based on how the community uses the feature and what we may feel could be better then. Even still, we would (as we are doing so now) make sure to inform all embedders in such a case.

Thanks for the feedback!

[Lei Zhang]

Yes, the build and runtime flags exist because this is relatively new.
In the long run, they should go away, just as there are no toggles for
JPEG2000. Brotli-compressed PDFs will likely become more common over
time, so PDF libraries will just be expected to have Brotli support.

> --
> You received this message because you are subscribed to the Google Groups "pdfium" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to pdfium+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/pdfium/9b385826-1c80-41ff-aaf1-bd567e4369d2n%40googlegroups.com.