end-user browsers vs e-printer browsers

[castedo]

One of the topics that came up today is choice of software generating PDF from HTML/CSS, in particular, the choice between Chromium and WeasyPrint. For any specific software package there are many short-term practical and tactical pros and cons depending on the situation. But I will skip writing about that. Below I write about medium-term (this decade) strategic reasons one class of software might be more or less promising than the other.

The first class is the "end-user's browser", such as Chromium. The second class is the "e-printer's browser", such as WeasyPrint. By "e-printer" I mean a service, (automated or semi-automated) that takes some kind of content and produces HTML and PDF formats. In my narrow situation, the content is JATS XML of preprints and journal-article-like research documents.

For an e-printer browser:

• the authors of the source content intend for some service to e-print it to HTML and PDF
• the e-printer is generating the HTML and CSS used to generate PDF
• the source content is NOT free to use every possible modern HTML capability
• the content is pre-filtered, not malicious and is not a security threat
• the typesetting quality should be similar to traditional printed typesetting
• PDF generation can take many seconds

For an end-user browser:

• works with essentially ANY webpage on the web
• must protect the end-user from malicious untrusted HTML content
• must be at the "cutting-edge" of whatever cool new tech is getting used by web pages
• most websites are not designed with print in mind, probably making zero effort for it
• most end-users do not print web pages and don't really care about printing web pages
• PDF preview should take less than a second

These observations I find highly suggestive that in this decade, e-printer services will find the specialized e-printer browsers more useful rather than end-users browser.

Or perhaps I am off. Perhaps end-user browsers will work better for both end-users AND e-printing services? e-printer browsers might never implement JavaScript or other HTML features that maybe are too valuable to give up [1].

Perhaps @CourtBouillon, @JulieBlanc, @fchasen or @SimonSapin want to share opinions on whether general end-user browsers like Chromium or specialized e-printer browsers like WeasyPrint are the best medium-term choice for e-printers.

[1] Note: I am able to render attractive math in HTML without JavaScript using server-side KaTeX instead of MathJax.

[RLesur]

Hi,

Interesting topic! I put in my two cents.

IMHO, the main point is the support of CSS Paged Media. One can find some great resources (e.g. tools comparison) created by @zopyx on his website https://print-css.rocks/.

In itself, Chromium does not fully support CSS Paged Media but Paged.js does a great job to fill in what is missing in Chromium.

After that, I think that choosing between two rendering tools compliant with CSS Paged Media is mostly a matter of taste. It also depends on the type of services that you want to build.

Personnally, I like playing with Paged.js/JavaScript and Chromium because I can hack it as I want (but this is another topic).

[castedo]

... I can hack it as I want (but this is another topic).

Good point. Perhaps an important distinction between end-user and e-printer browsers is which API / document object model they allow developers to hack on. The end-user browser provides the full HTML DOM to JavaScript whereas an e-printer browser can provide a specialized PDF-specific API / document object model. For instance, the weasyprint.Document class provides a PDF-specific object model for the PDF to be generated. @CourtBouillon showed me how to use this to add lines numbers for instance.

I conjecture that for e-printers who want to use PDF specific features (perhaps PDF accessibility or PDF metadata) an e-printer browser object model will be more powerful than the HTML DOM (for PDF specific tasks). In the end, paged.js can only polyfill so much. Polyfilling I suspect will always be limited to whatever CSS and DOM the end-user browser bothers to implement.

Perhaps a PDF-specific doc object model might even be easier to program for PDF tasks than the HTML DOM which might not expose any print-specific page-layout information, I'm not sure.

[RLesur]

I agree, I use ghoscript for some PDF specific tasks but if WeasyPrint provides you all the features you need in one library, maybe this is the best choice. I haven't used Weasyprint recently, I like it very much but I had to render JavaScript generated content and using Chromium was straightforward. All depends on what you need 🤷‍♂️

[ronste]

Hi @castedo,

thanks for bringing up this topic in our call and for initiating a further discussion here.

You put forward a number of good points I didn't consider in the first place making me review my decission again.

One of the reasons I went for paged.js was that I didn't want to have another language (Python) in the stack (we already deal with Javascript in other contexts). Although I would be able to handle Python I have to also consider what skills we have in the team now, and maybe what skills we would need in the future if we run such a stack in production (of journal articles).
So I was not only looking at the hard technical issues but also considering questions of maintanace, personnel resources and customer support in the production environment.

[ronste]

Hi again,

I meanwhile played around a little more with Paged.js and WeasyPrint and like to share my experiences.

I can see the point of being independent of any particular browser when using Print CSS to generate PDF. However, this wouldn't be my main reason for switching to WeaysPrint.

One major reason I stubled upon is the incompatibility between Paged.js as run in the browser with its own CLI tool pagedjs-cli. With the same install package, they come in different versions which are not at the same stage in terms of Print CSS support, i.e. the same CSS produces different results with each of the tools. This renders the browser Paged.js tool essentially useless as a live editor (which was very convenient to have) for developing a layout that later should be rendered by the CLI tool.

That said, also WeasyPrint doesn’t have any kind of live view for development purposes as far as I know.

With respect to missing math support of WeasyPrint I went for MathJax instead of KaTeX. Mainly because it i general also supports Latex notaion and AsciiMath. I run MathJax as a node module (because I have node installed anyway) in a pre-processing step on my server (or in Docker container) like:

node -r esm shared/mml2chtml-page "html-file.html" > "html-file_mathjax.html"
weasyprint -p "html-file_mathjax.html" "weasyprint.pdf"

I essentially followed the documentation at MathJax-demos-node.

Unfortunately also WeasyPrint has its limits and doesn't support important css features. One thing I stumbled upon is the text orientation when trying to layout a rotated table. This requires writing-mode: vertical-rl to be set which works well in the browser but is not supported by WeasyPrint (a simple transform: rotate(90deg) doesn't work with tables in general it seems).

I guess we'll find a number of things that work with one tool but not with the other (as we already know from Jats). I'll work with WeasyPrint for now but whether or not it will stay lile that probably denepnds on the future support these tools receive. In general I think the detailed requirements of the task at hand will decide for one or the other.

[castedo]

Thank you for sharing your experiences! I was not aware of this MathJax approach. I suspect this is a better approach and will be much faster than what I am doing now.

Regarding print CSS debugging during development, this is challenging. I am still trying to learn how best to do this. I feel like I've regressed 10 years in CSS debugging and have resorted to putting red 1px borders around HTML elements. 😱 😄

Also really nice to know about these limitations you've encountered, thank you.

@ronste Is your vertical-rl challenge due to JATS XML with <table-wrap orientation="landscape"> ?

[ronste]

@castedo ,

@ronste Is your vertical-rl challenge due to JATS XML with ?

Not really. I don't set <table-wrap orientation="landscape">, although I probaly should for the more general use case.

Coming from Pandoc I put the infomation on the rotation state directly into the Jats XML table element like <table specific-use="Tabelle-gedreht-rechts"> (the name is really arbitrary´, I could also use "landscape" here). The point is that the the table elment is passed on to the HTML directly. The css writing-mode: vertical-rl then works on the HTML thead and tbody elements to rotate all text within the table. So I can simply use css like:

table[specific-use="Tabelle-gedreht-rechts"] thead,
table[specific-use="Tabelle-gedreht-rechts"] tbody {
  writing-mode: vertical-rl;
}

table[specific-use="Tabelle-gedreht-rechts"] {
  width: 100%;
}

Note that the HTML table attribute is also specific-use, i.e. the HTML table inherited it directly from the Jats XML and I put the css on this inherited Jats XML specific-use attribute. No additional processing required here.