Last modified: 2014-07-17 18:31:36 UTC
The current (soon to be replaced?) PDF tool is not producing very useful results at Wikivoyage. The biggest problem is the dynamic map with location markers for places of interest (POIs). The pdf does not include the map or the POI markers. An ideal replacement would: * Render CSS styles * Control the inclusion of images (whether to include images, which to include) * Render iframe environment Alternatively, just having a way to include the map, complete with location markers/pins would be an improvement.
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 )
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.
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.
