Brainstorm: new convertion backend for weasyprint

[flavianmissi]

http://weasyprint.readthedocs.io/en/latest/#

A little about the service:

WeasyPrint is a visual rendering engine for HTML and CSS that can export to PDF. It aims to support web standards for printing. WeasyPrint is free software made available under a BSD license.

It is based on various libraries but not on a full rendering engine like WebKit or Gecko. The CSS layout engine is written in Python, designed for pagination, and meant to be easy to hack on.

Background:

I've been trying to convert a not so straight forward html to pdf using the css3 specification for paged media. The specification is great, everything I need is covered there, the problem is that it doesn't work ATM with Athena's engine (webkit if I'm not mistaken?).

Athena has been of great use for our organisation, but this is something we really need support for.

I noticed that on #42 someone is also reporting sort of the same problem.

Additionally, I'm willing to help implement this if there's interest on doing so from your side.

Thank you!

[MrSaints]

It's running on Blink, a fork of WebKit. But yes, it does not support paged media, and I highly doubt it'll be supported for the next year or so at the very least.

I've been meaning to refactor the backend part of Weaver for quite some time now so that it'll be much easier for the service to be extended (not just for WeasyPrint).

Problem is, since it is packaged as a Docker image, I'm unsure what's the best approach to take without polluting / bloating it.

I was considering breaking the service image (Weaver) further so that it runs local backends in containers (by calling Docker inside Docker). But at the same time, this might complicate deployment. And I think the beauty of this service ATM is that it's pretty simple to deploy, and scale up.

Then again, the solution might just be as simple as creating multiple images for different combination of popular backends.

There's also the matter of reconciling the different conversion arguments / options across backends.

That being said, I'm open to the idea of adding Weasyprint.

[flavianmissi]

Glad to hear you're open to it!

I understand the problem. I like the multiple images solution, there could be a base "abstract" image without any backend set up (and not meant to be used standalone perhaps), and then other images would extend the base one, installing their respective backends and adding necessary configuration for them to work properly.

Offering a default one (with Blink I assume, since it's the default ATM) is also good, so people aren't required to choose a backend before having the service up and running.

Living with the different conversion options could be trickier IMHO. But I think that as long as athena keeps a shared set of base options and the backend specific ones are well documented it shouldn't be a big problem... but I don't know the system at all that well. Are there any docs for the currently supported conversion options (other than sample.env, if that's even the conversion options we're talking about...)?

[MrSaints]

I have added this to the v3 board, but I do not think it is an immediate priority.