Talk:Reading/Web/PDF Functionality/2017/05

Thoughts from the Wikivoyage community

1. Images should be excluded from the PDF version. We add a few (sometimes quite a few) images, because they help us to make destinations more attractive. That's not needed in the printed version, which is mostly used during traveling, where one cares about the space and needs as few printed pages as possible. The ideal solution would be excluding images by default with the possibility of adding an exception when the image is required during travel (e.g., a subway map). For those 'important' images, it should be possible to customize their size. For example, a 5x5 cm version of the subway map is OK in the online article (one can always click on it and zoom in), but useless in the printed version. It should be expanded to the whole page.
2. Page margins in the current PDF version are way too large. Page space is used inefficiently.
3. Large part of Wikivoyage content is based on Template:Listing and its derivatives, which put together information on each object of tourist interest (sights, hotels, train stations, etc.) Rendering of such content is far from ideal. In particular, the objects are numbered automatically in the online version, and the numbers correspond to map markers. However, PDF simply renders all numbers to 1, and printed version can not be used together with the map.
4. Ideally, it should be possible to generate printed versions of maps and include them into the PDF file. Each Wikivoyage article already specifies through Template:Geo map center and sometimes the zoom level. The rest is perhaps a matter of integrating PDF version with the Extension:Kartographer that generates our maps. --~ Atsirlin (talk) 17:08, 18 May 2017 (UTC)

With respect to images, I believe it would, in general, be more natural to include images by default and exclude specific ones through e.g. the use of a template, in a similar way to how meta-templates are left out of PDFs generated with the old system. (That doesn't, in principle, exclude the behaviour you describe being made available through e.g. per-wiki configuration.) Duplode (talk) 02:59, 19 May 2017 (UTC)

We may need a special discussion on that, but I am pretty sure that at least the community of Russian Wikivoyage considers using more images in the online version and excluding them in the printed one. Therefore, it will be much easier to include 3% of images than exclude 97%. Atsirlin (talk) 05:33, 19 May 2017 (UTC)

That isn't going to work as a default. The Wikisources in reproducing books would wish to have the book shown as originally produced. If there are images then show them. — billinghurst sDrewth 05:01, 6 June 2017 (UTC)

I think we are discussing defaults for Wikivoyage here. Other projects may, of course, follow a completely different approach. Atsirlin (talk) 07:03, 6 June 2017 (UTC)

So maybe the discussion is that you believe that there needs to be configuration (per wiki, or per user) around whether images need to be printed. At this point in time I am not certain that such configuration exists for a wiki or for a user, and if it doesn't exist there are no defaults. — billinghurst sDrewth 02:03, 7 June 2017 (UTC)

A travel guide without images? Surely you jest. Images are essential to creating print travel guides that are competitive with commercial products. LtPowers (talk) 23:46, 18 May 2017 (UTC)

We are not talking about the commercial product. The "commercial product" is on wiki, and it may have as many images as one likes. Printed version has a different usage concept. It is needed only in special situations (in a more general traveling situation, offline version saved in the smartphone via Kiwix will suffice), and in these situations printing and carrying less paper becomes crucial. Atsirlin (talk) 05:31, 19 May 2017 (UTC)

That is not true. One of Wikivoyage's explicit design goals is to produce good, attractive, and competitive printed guides. LtPowers (talk) 11:57, 20 May 2017 (UTC)

It could be a meaningful goal 10 years ago, but nowadays it is simply obsolete and unrealistic. Atsirlin (talk) 13:29, 20 May 2017 (UTC)

If you feel that's the case, you should take it up with the Wikivoyage community. At the moment, it remains an explicit design goal. LtPowers (talk) 00:28, 23 May 2017 (UTC)

Related to this discussion, the ability to HideInPrint or NoPrint a section of text, programming code (tagged code), or included file should continue to be supported.

To me, the most obvious approach to reduce confusion for end users is to print images by default, and hide them with some type of appropriate tagging. Using a bot, it's easy to tag and exclude as many images as necessary if that's what a particular community desires. Dave Braunschweig (talk) 20:09, 5 June 2017 (UTC)

User:Dave Braunschweig, do you think that adding 10-20 templates on each(!) page is a viable solution? Atsirlin (talk) 03:54, 6 June 2017 (UTC)

If each page needs 10-20 different things applied to it, then yes, adding 10-20 templates on each page is a viable solution. Technically this isn't a problem. Templates may include other templates, and a bot can update 10,000 pages a day, making short work of almost any editing requirements.

But the more important perspective is user experience rather than editor experience. In the context of this discussion, that means designing PDF functionality so that it works by default as users expect it to, and then adding any necessary features to accommodate editor concerns. Users are overwhelmingly going to expect that what they see on the page is what appears in the PDF. There should be a way to customize that, but the default needs to support user expectations. Dave Braunschweig (talk) 12:43, 6 June 2017 (UTC)

@Atsirlin do note that the plan for the future to move to template styles that sit separately, so that may change the issue/problem as you see it. It seems that the ability to hide/show images as an option for the user printing is something that should be available. — billinghurst sDrewth 05:05, 6 June 2017 (UTC)

I'd be very surprised if I would not get the images if I generated a wikivoyage PDF —TheDJ (Not WMF) (talk • contribs) 14:39, 9 June 2017 (UTC)

Why do you need them exactly? Have you ever tried to print a long travel guide like [[voy:en:Boston/Downtown]] or [[:voy:en:Bangkok/Rattanakosin]]? Will you spend extra pages and ink (or even money) on printing some fancy images, which you don't really need during your travel? Would you like to download a 5 Mb PDF file instead of a 100 Kb one when a slow internet connection in the middle of nowhere? These are all very practical issues. Atsirlin (talk) 15:43, 9 June 2017 (UTC)

Telling people how they should use a resource seems counter-productive to me. Listening to how people utilise our resources and making it available to the broadest possible audience seems like a good course to follow, than solely follow your own narrower needs. — billinghurst sDrewth 03:08, 10 June 2017 (UTC)

I do communicate with Wikivoyage readers and editors, I know their needs, and I convey those needs here. I do not think the opinion of non-Wikivoyagers is relevant here. Atsirlin (talk) 16:24, 10 June 2017 (UTC)

FWIW please do not remove images! I print to pdf and view on my phone. Printing to paper is a thing of the past and IMO wikivoyage doesn't have enough of them :) Jdlrobson (talk) 18:10, 12 June 2017 (UTC)

@ Jdlrobson, do you mean that we should forget about proper offline version and use pdf's instead? Atsirlin (talk) 18:43, 12 June 2017 (UTC)

Further feedback

1.) I guess if we have single columns PDF articles/books, the pictures won't bother and they also resample the website, which is what I would prefer, because already someone made up his mind about an appropriate layout. Maybe in addition, it would be possible to add a tag to the file/image template, so certain pictures are in addition stored in full PDF size at the, so e.g. maps can be read appropriately.

2.) In case (OSM)maps have been linked within an article, it would be meaningful to have the maps also available in the PDF. Currently, this doesn't work. However, like in the Lonely Planet, an overview map with the GPS-referred sights is more than useful. It doesn't have to be more complicated than the map already there for an article, zoom is correct, just it span over the whole PDF width.

2b.) In the old version also GPS listings (e.g. sleep, eat, etc.) did only have a "1" in front of them and not the actually number they received in the map . This should be corrected in the new version.

3.) Many infoboxes are currently not rendered, which is good for some but now for Visa Regulations etc., which are currently not available in an PDF. So generally this should be available.

4.) Links, colours, font weight and size should resample the original WV article, because this is the way it was originally intended. Ceever (talk) 21:50, 18 May 2017 (UTC)

Code formatting

How will the new generator handle code formatting (<code>, <pre>, <syntaxhighlight lang="text">, etc.)? The old one provides no support whatsoever, which makes it unusable e.g. for programming books over at Wikibooks. Duplode (talk) 03:06, 19 May 2017 (UTC)

Adding on here, the ability to print code using the tags Duplode has indicated are also necessary at Wikiversity for educational programming language resources.

How programming code displays when printed might determine whether one-column or two-column content would be preferred. This could also result in a situation where two or even three column text would be fine, but we might need single-column display for programming code. This would be similar to multi-column text and single-column examples or story-block sections in a typical textbook. In other words, multi-column could be fine if we have some type of single-column indicator for certain sections or code tags. Dave Braunschweig (talk) 20:02, 5 June 2017 (UTC)

Missing Features in Electron PDF

Are there any plans to mitigate the missing features of Electron PDF? AFAIK Electron doesn't support headers, footers as well as generated content like page numbers. Ckepper (talk) 20:29, 24 May 2017 (UTC)

Yes, the entire point about asking here is trying to figure out what to prioritise when continuing the work on the PDF service. Johan (WMF) (talk) 18:03, 10 June 2017 (UTC)

Intercompatibility with CSS print styling

I run a wiki in med school where we put all course materials, guides, flashcards and much more. Of all the features provided by a wiki, one my user base has been most enthusiastic about is the fact that they can cleanly print content, to which effect they use the book feature or the print function from within their browsers.

Sadly, the result from either is not consistent, especially when it comes to templates. I've been able to have them display properly in print through MediaWiki:Print.css but with the book creator and the "Download as PDF" feature it's currently impossible. I understand that the new PDF functionality will provide styling function, but it will be great if it can take into account MediaWiki:Print.css so styling information does not have to be duplicated.

That being said, I had to redeploy the old mw-lib service as the fact that the OCG service did not support tables was a killer. Therefore, I haven't been able to witness to what extend OCG supports Print.css styles, but I just wanted to state how important this feature is for my community. Tinss (talk) 21:15, 25 May 2017 (UTC)

I just wanted to add that it would great if the layout, titles, table of contents and such could be customized in CSS for the PDF functionality. A potential use case would be to add a university logo to the cover page of a book or print pages in portrait mode.

Thanks for all your great work! Tinss (talk) 15:16, 14 June 2017 (UTC)

Thank you for your feedback! As a part of this effort, we'll also be altering the browser print styles available - we want to get to a point where books, single-PDF, and browser print have consistency. I was wondering if you have a list of the templates that you've noticed broken with either OCG or the new PDF service? We're trying to collect a list of edge cases and current bugs. OVasileva (WMF) (talk) 13:11, 15 June 2017 (UTC)

Since I'm on a private mediawiki and using mw-lib, I can't provide you with any example of broken templates. The only case that comes to mind is the lack of support for tables, but that you probably already know.

If I come across anything I'll let you know. Tinss (talk) 12:59, 16 June 2017 (UTC)