Adding Matt Walker because I know he has been involved in the new PDF renderer and so may be able to give a sense of what (if any) of these are on the road map already. (WhatamIdoing did a great job distilling the action points from the conversation but for context if anyone is interested much of it came from https://en.wikivoyage.org/wiki/Wikivoyage:Travellers%27_pub#Print_versions )

mwalker wrote:

Right now none of those points are on our roadmap at all. The new parser works by taking the RDF produced by parsoid and massaging it. We don't currently have plans for the new parser to understand CSS rules; in that regard it'll act in much the same way as the old renderer.

That being said, there may be some way for us to incorporate the needs of Wikivoyage. I was unable to find a page with a map though... can you give an example? (Is it possible for the map to be statically rendered as an image?)

Also, can you give us more details on what your use case is for excluding images from the article?

You can look for anything transcluding {{mapframe}} but one quick link is https://en.wikivoyage.org/wiki/Amana_Colonies

Depending on your plans, you might want the default map image (which shows where the various villages are) or you might want to zoom into the main tourist area, where the multiple overlapping points of interest are represented by the orange (+) symbols.

himer2001 wrote:

Two comments from the Wikivoyage community:

1. Our maps are constantly updated. Therefore, they are dynamic. Of course, they can be rendered as static images, but this rendering should be part of the PDF tool.

2. The idea of excluding images is to make the printout as concise as possible, because printouts are something that travelers have to carry and something they often have to pay for (if they don't print stuff at home). Images are crucial for the online version where we even have pagebanners in the beginning of each page. On the other hand, print version should include images only as an option.

(In reply to Matt Walker from comment #2)

Right now none of those points are on our roadmap at all. The new parser
works by taking the RDF produced by parsoid and massaging it. We don't
currently have plans for the new parser to understand CSS rules; in that
regard it'll act in much the same way as the old renderer.

I'd remark though that we did originally think about using PhantomJS on the server to render HTML+CSS to PDF. For individual pages, the same can be achieved in most modern browsers by printing to a PDF right in the browser. I'm not sure how good the print styles applied in that case currently are. They can however be improved by the community on a per-project basis by wrapping print-only styles in a media query block:

@media print {

/* print-only rules */

}

In the longer term it seems likely that we'll add a server-side browser-based renderer as well. This would provide the same browser-based PDF render functionality also to users of older browsers, and for entire collections of articles. Any improvements to the print styles done in the meantime will benefit the server-side renderer as well.

Trying to create a PDF for https://en.wikivoyage.org/wiki/Amana_Colonies via https://en.wikivoyage.org/w/index.php?title=Special:Book&bookcmd=rendering&return_to=Amana+Colonies&collection_id=9a297db32953f499d84cef5215dd76272099195e&writer=rdf2latex I get an ugly strip marker only:

?'"`UNIQ--maplink-00000000-QINU`"'?

The new PDF tool (Proton) also doesn't render maps. PDFs are generated by using headless Chromium, the service navigates to article page and calls page.printToPDF() over DevTools protocol (using Puppeteer library). The generated PDF is almost identical to what we get when we call "Print" and store output ad PDF using latest Chrome/Chromium browsers. The only gimmick is that we render Wikipedia/Wikivoyage articles using no-js mode. The "no javascript" option is a small hack to disable all dynamic elements like lazy loading images.

If I disable the JS and go to any page on Vikivoyage and add printable=yes parameter I can see that maps are not visible in the print mode. Thats because: commonPrint.css rule:

/* Links */
a {
	background: none !important; /* stylelint-disable-line declaration-no-important */
	padding: 0 !important; /* stylelint-disable-line declaration-no-important */
}

Maps are rendered as:

<a class="mw-kartographer-map" 
     mw-data="interface" 
     data-style="osm-intl"
     data-width="420"
     data-height="420"
     data-zoom="13"
     data-lat="41.806"
     data-lon="123.42796"
     data-overlays="[...]" 
     style="background-image: url(https://maps.wikimedia.org/img/osm-intl,13,41.806,123.42796,420x420.png?[...]); height: 420px;"
     href="/wiki/Special:Map/13/41.806/123.42796/en">
</a>

but the default print styles set a.background: none !important. Because of that maps are not visible in print mode, nor in rendered PDF.

This works pretty well right now. I did notice that wikivoyage uses interactive maps by default and those controls are still visible in print. We probably want to hide those as well.