Download/show wiki pages in printer-friendly style

[daniel]

There should be a "print this page" option/link as 'download in other format' for all modules.

If applicable, it should display a printer-friendly layout/css set (maybe rely on CSS media types?).

In any case, there should be a 'print this page' option almost everywhere.

[Christopher Lenz]

I'm not sure we need an actual 'printer friendly version' link on every page. It should actually suffice to add CSS rules for the CSS 'print' media type. These rules would hide the header and navigation bars, and adjust/override other styles where appropriate.

The user then gets the printer-friendly version simply by invoking the 'print' or 'print preview' function of her browser.

I'm planning to experiment with this approach for 0.8.

[jamesm@…]

I was thinking of that the other day. Is there a Python PDF library that could be used to generate printable output?

[jamesm@…]

I'm no Python programmer, but a quick Google search turned up this project: ​Python Reportlab It seems like a dual-licensed project: open source & commercial. Anyway, it may be something you are interested in - or maybe not.

I know that the QA folks here love anything that is printable (documentation, documentation, documentation) so despite the above comment about 'not sure we need it on every page' - I'd say at least consider it, if its PDF. A non-PDF print function will probably be difficult to control the page layout, page breaks, & font sizes across different browsers/operating systems.

[Christopher Lenz]

Sure it's difficult (or even impossible, sometimes) to control page breaks and some page layout details with HTML/CSS. But I think it should still work good enough for most use cases.

And if you start thinking about controlling page breaks, how would you do that for Wiki pages? Add special Wiki markup commands just for printing?

That said, here are some things where I would see a separate printable version useful:

• Wiki pages: the only issue here is that links dissappear when a page is printed. It might be a good idea to generate an alternative version that would list all link URLs at the bottom of the document, and reference them in the document somehow (for example with numeric indices such as[16]).
• Reports: here, controlling page breaks becomes very important. For example, you want to put the table headers over every table when it flow over to a new page. You might also want the printable version to directly include the ticket description, because the ticket summary alone will rarely be enough to understand the ticket.

To summarize, I think providing a nice print output with CSS-print rules should be relatively easy and provide most of the benefit. Alternative printable versions that provide extra features as described above would be a "nice-to-have" that we can probably postpone until after 1.0 (unless, of course, someone steps up to do it).

BTW, what's the license of the open-source Reportlab library? As Trac is GPL, we need to be careful there (or don't we?)

[jamesm@…]

Reportlab is licensed under the BSD license.

I'm sure that the CSS-print method will be fine - it would just be my preference to have a PDF document generated from Trac pages. This can always be done with an OS PDF printer driver. Still, that being said, I like the idea of having a "Generate PDF" link built into Trac. PDFs are just more useful, they can be printed & digitally stored/transmitted/etc. Providing a printer-friendly page only serves the purpose of providing immediate printer output.

[jamesm@…]

Some interesting Reportlab links… ​IBM DeveloperWorks ​Followup article on the DeveloperWorks article

[mario at ruggier dot org]

I would stay away from going the pdf generation route, as this introduces a whole lot of potential problems, and dependencies that further add to the installation. Just go for CSS print media option. As for pagebreaks… having had to put up for years with real bad page breaks (and all sort of other hideous formatting) for "page-laid-out" documents, prepared with a rather famous word processor, I think I will be very happy with the occasional odd page break.

In addition, Wiki formatting and printing should not be mixed in any way — these should stay completely independent one from the other.

[Christopher Lenz]

We've had printer-friendly CSS style rules in trunk for some time now (since [725] to be exact). Anything more fancy, such as PDF output, should go in a new ticket IMHO.