Proposal: Enable PDF engine switching

[hkato]

Configuration option

plugins:
  - to-pdf:
      engine: [weasyprint|chromium|pandoc|etc|   # default weasyprint

Background

When I try to check mkdocs-material sample.

Update samples/mkdocs-material/mkdocs-material/mkdocs.yml.

plugins:
  - to-pdf:
      debug_html: true

Create an HTML debug output.

$ cd samples/mkdocs-material/mkdocs-material
$ mkdocs build > debug.html

Then convert this HTML to PDF with Google Chrome(macOS)

$ /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
    --headless \
    --no-pdf-header-footer \
    --print-to-pdf=debug.pdf \
    debug.html 

The PDF output seems almost acceptable to me.

#34

Generated PDF is 14 pages but should be several hundred.

The PDF was 449 pages.

Implementation

Sequence

1. Generate an HTML file in the tmp directory
2. Convert the HTML to PDF using Chrome/Chromium

Class

• Create an abstract base class for the PDF engine
• Implement the current WeasyPrint PDF engine
• Then implement a Chromium PDF engine

May I try this? (if I have a free time...)

[hkato]

WasyPrint has several layout bugs #43

[domWalters]

Yep, happy for you to test this.

Honestly, I'd possibly even support making a web browser the default.

WeasyPrint has the annoying quirk of requiring non-python packages that a user will have to remember to install.

However, pretty much everyone is going to have a web browser.

[domWalters]

@hkato, FYI, I should have added you as a collaborator to this repo.

That should allow you to create branches directly on this repo, rather than on a fork.

Test it out if you want to make a branch for this.

[hkato]

That should allow you to create branches directly on this repo, rather than on a fork.

Thank you so much!

I found an issue in the readme branch, and I will fix it first

[hkato]

#51 -> #58