@unlimitedsola You're welcome! Glad to know you liked doqment. 🙂

Your idea is cool, I know; in fact this was how it was in the beginning. But I faced a few issues:

• PDF.js converts the pages into raster images while displaying/printing; so you end up with a pixelated, clunky, unsearchable PDF (like scanned PDFs)
• some OS/browsers add white margin while printing, ruining the effect of the color scheme
• it had large memory overrun problems

So for the moment I dropped it to allow users to print normally. I can check again if the library has any improvements. In any case, it won't be much work to expose this as an option you can configure (off by default). Please wait for an update!

Edit: if you want to try it out yourself now, just comment out this line in addon/doq.js:

I discovered that PDF.js has added an option to change the print resolution. For the moment you can set it via browser dev tools, although you have to do it every time:

PDFViewerApplicationOptions.set('printResolution', <DPI>);

There is a discussion (mozilla/pdf.js#12278) on adding this to the extension's options UI so that this becomes easier.

• PDF.js converts the pages into raster images while displaying/printing; so you end up with a pixelated, clunky, unsearchable PDF (like scanned PDFs)

Thanks for telling me this! And forgive me for not double-checking PDF.js's printing behavior. For some reason, I was expecting it to print the content in vector format 😅

• some OS/browsers add white margin while printing, ruining the effect of the color scheme

Indeed. I've tried the suggested change, it does the same for me too.

• it had large memory overrun problems

I experienced with DPI set to 600 and successfully turned a ~500KiB 18-page paper into a ~21MiB rasterized pdf. 🤣 It took me about 5 seconds to prepare but stuck at the printing preview dialog for an extra ~15 seconds. Additionally, it took an additional 15 seconds to write the file to disk.

I did not notice significant memory usage, however, and by significant, I mean memory usage > 2GiB (I had too many tabs open, so I can't say for sure how much memory was used during the printing process).

Given the issues we are facing, without further polishments, I acknowledge that this could be a niche feature to add and may not be appropriate for public users.
For now, I'm happy with making the tweaks myself for my own needs. Please feel free to close this if you think this feature may be better off waiting for further support from the underlying library.

Thanks again for sharing the technical details and an ad-hoc workaround for me to achieve this!

@unlimitedsola I have experienced the wait times in the print dialog as well. I guess the reason for these delays is the bitmap nature of the print output - the print server has to handle all those pixels. I think other PDF viewers are faster at this because they write to some vector print format (e.g. Preview on macOS probably writes to PostScript) which is again easy to convert back to PDF.

I will keep this issue open because this is indeed a desirable feature for this library. I can try discussing with the PDF.js devs to improve the printing/saving speed, because that delay is inherent to the library; doq adds only a marginally small processing delay. Meanwhile, I can add a configurable option for niche users.

But there is actually another way to achieve this. Some time ago I worked on a Node.js implementation of doq, which is like a headless variant without the add-on components. When used along with the Node.js version of the PDF.js library, PDFs can be directly saved with the color scheme, without involving the browser and its print dialog (there is still the problem of rasterisation and final file size though).

I couldn't finish the work on it back then, but it is nearly there. The development is tracked in #6. I hope I can finish it in near future.