Once we get design direction I'll create subtasks with the technical implementation.

I have attached sample PDFs for mobile and desktop.

We can do amazing typography when it comes to printing. this is just an example.

i am using a 12 column page setting grid for this.

If we want to go in this direction I can come up with a set of rule and then visual design spec for it, which we can easily translate into css. rules would be like hiding elements and visual design spec would be font sizes for all specs.

Safari's reader mode is also good inspiration for this.

I'm also using elements from iOS app and soon android will use the same layouts, so we have consistency.

I usually use the Moon article on enwiki as a use case, as it contains a large number of the features which make good quality layout difficult. The attached mockup seems to be missing very basic print features such as page numbers. The requirements for attribution are more complicated than the mockup indicates as well.

@cscott that was just a rough idea. I will work on the different content types and templates. one thing to consider, do we want multiple pages or one single long pdf. if we are using this as only a feature for offline use then long pdf makes sense. if we are looking to also have it for print purpose then multiple pages. I am fine with any.

with page numbers, a lot of pdf viewers on phone and desktop have page numbers on it already.

One perennial sore spot is pagination. The most obvious one is frequent page breaks right after a heading, or with only 1-2 lines of a paragraph on the preceding page. The underlying issue is a lack of support for page-break-before and page-break-after & related CSS rules in Chrome (and Firefox). page-break-inside: avoid is the only one that works, and is what we apply to figures & some other elements.

Possible solutions:

• T114072: <section> tags for MediaWiki sections plus page-break-inside: avoid on the section
• JS solutions: See "Browser print improvement projects" in https://phabricator.wikimedia.org/T134205.

A related gotcha is that avoiding breaks on a nested element sometimes stretches a surrounding box across page boundaries. This is quite ugly, so care needs to be taken that only the outer box has this set.

Another idea worth exploring might be to reach out to CSS / JS wizards to have a go at Wikipedia print styles. This could be a competion / call for designs, or inviting specific communities like http://osp.kitchen/tools/html2print/ or https://github.com/vivliostyle/vivliostyle.js (contact page ).

Since this is a specialized topic, outside experts might have ideas & tools we haven't thought of yet. Applying / showcasing them on a site like Wikipedia could be attractive to them.

@GWicke Do you like to have artwork or “just” a splendid experience for people printing our articles? From my point of view, we should make sure that

• the info including all kinds of crazy template layouts is
  • easily readable
  • fast to print (less borders, less backgrounds)
  • beautiful to look at in comparison to other sites, at best a good book layout like output

@Volker_E: I completely agree that accessibility & completeness of information should trump fancy artwork, especially for print.

The aspect I find interesting about the projects I mentioned is their work on better pagination & text flow control. While some of the outputs might be more artistic than what we need, elements of their tools could be useful to improve pagination & page layout in our print view as well.

@GWicke Agreed that it makes sense to look at their work for inspiration and good practices.

I just discovered that the vivliostyle viewer already supports loading random web content via CORS:

http://vivliostyle.github.io/vivliostyle.js/viewer/vivliostyle-viewer.html#x=https://en.wikipedia.org/api/rest_v1/page/html/Barack_Obama&f=epubcfi(/2!)

To select a paper size, click on the icon in the top-right corner. While the WMF-specific print styles are clearly missing, the pagination looks quite good.

Update: working on this. will try to incorporate feedback from this card. i will be delivering a print.css with some complicated article examples. you can apply that css to any article and test the print styles.

Few thoughts for anyone who is interested

• do we want to highlight blue links to other wikipedia articles by any means?
• do we want to hide references? mostly not. but could be a nice clean experience without reference brackets
• serif/sans-serif for body?
• i think page-break-before:always is good for all sections. new section starts on new page. "avoid" is very unreliable and doesn't work.
• page break increases number of pages. so evaluate the value of it.
• everything should work with black and white
• use only 3 colors. one #000 and #666 and #f5f5f5 for backgrrounds
• avoid borders
• borders vs backgrounds to differentiate block elements - preference based on saving ink
• hide everything except for content
• wikipedia branding? 300dpi wikipedia logo on top?

Related discussion at T142207: Investigate which styling quick fixes could be made to the print style

@Lea_WMDE can we merge this into T142207 or the other way around?

@Nirzar

• Highlight blue links: For printing speed and also given that we also provide PDF rendering, links should be clearly indicated and text-decoration: underline seems better suitable.
• Serif/sans-serif: What is the reason for not relying on downloadable fonts? Thinking in UI-Standardization terms here. Also, is the old convention of serif fonts being better readable in print still true?
• page-break-before: I'd rather avoid page-break-before as much as possible. It doesn't effect readability too much IMO and thinking of the scale of our decision, we can save a lot of paper around the globe.
• Everything should work with black and white: Everything must work with black and white. We can't assume that people have access to color printers.
• Use only 3 colors: Sounds good to me.
• Avoid borders: Sounds good to me.
• Borders vs backgrounds: Borders preferable to increase print speed and lower costs.
• Wikipedia branding: SVG logo with PNG fallback for best results

It might be worth keeping in mind that we are really talking about two different use cases here:

1. Screen oriented PDF: Saving web content to PDF, for later on-screen reading & sharing.
2. Print to paper.

We don't have precise numbers about which of those use cases is more common, but I would not be surprised if save-to-PDF for on-screen reading was more common than actual printing.

While some changes benefit both use cases, some improvements targeted at physical printing are actually detrimental to the on-screen use case. It might make sense to separate the physical print changes from the on-screen PDF formatting, and give users the option to choose either when retrieving a PDF.

@GWicke

some improvements targeted at physical printing are actually detrimental to the on-screen use case

I think we can strike a balance. do you have any specific examples of this^^

@Volker_E

old convention of serif fonts being better readable in print still true?

not really. it's mostly comes down to choice and non latins upport etc. we can't use custom font and support all languages. sans-serif seem to have greater coverage than serif alternatives?

Use only 3 colors: Sounds good to me.

Actually i removed all #f5f5f5 backgrounds. so now it's either #000 or #666 both AAA accessible

Borders vs backgrounds

Removing all background colors and using borders instead is more efficient, ink and speed wise. also it works. tables or any content areas won't have subtle grey background colors to distinguish between block elements. it will have #666 borders

Wikipedia branding: SVG logo with PNG fallback for best results

Yep

Okay.. here's a first draft print css

Typography

• Body typeface 12pt - most optimal for reading and printing
• Headers margins perfected to be closer to the text of the section.
• Good contrast between headers and body
• inherited styles from Vector for tables, infoboxes and block elements
• dotted underline for all Blue links to suggest these articles exist on wikipedia for further research

Print optimizations

• No background colors
• only 3 colors used

Features

• Wikipedia branding on top. for english to begin with
• Crisp serif body text with open source Charter

More info on here - https://en.wikipedia.org/wiki/Bitstream_Charter
Open discussion: How to include this typeface on server side for PDFs

• Body typeface will fallback to system Serif most of the times.
• Works with non latin
• Works on RTL

^ Raise issues if I missed anything

• Improved footer with hierarchy of date stamp and URL

About CSS

• CSS is documented with purpose for most things written in there
• totally independent CSS, do not include any other styles than this
• Just add this css alone

Some features highlighted here

See the PDF yourself

Download the CSS and try it out -

Nice improvements!

Here's a few notes from that example pdf:

• Section titles in the middle of the page lead to weird page breaks
  • Maybe we need page-break-before: always on top level section titles?

• Branding at the top, header, reference and link styles look good to me. Styles are subtle but visible.
• References styles occupy too much vertical space, leading to them using up several pages
  • I'd suggest removing the horizontal gray borders, making the vertical spacing a lot narrower, to make them a lot more compact. Maybe even keeping the 2 columns per .references at a4 width

Thanks for working on this @Nirzar

On another note, the pdf in OSX preview is kind of laggy for me, not sure why. Does anyone else notice anything similar? Does anyone know of ways go diagnose pdf rendering/structure performance?

In T135022#2672465, @Nirzar wrote:

Okay.. here's a first draft print css

I have been looking to the example PDF compared to the current printed version, and the proposal seems a very good step forward. Easier to read, and more clearly structured.

The proposed style for links provides a good balance between the "print in PDF" vs. "print in Paper" cases. Regarding the scanlines on subsections, I'm not completely sure they are needed since the visual hierarchy seems clear now, but they don't harm either I guess.

For content such as images and infoboxes, I was wondering if it would be better to base them on the mobile web style where borders are removed which in addition to save ink may contribute to a cleaner look in print.

Definitely looks much cleaner and easier to read in this form. My two bits of feedback are +1s.

Firstly agree with @Pginer-WMF that the scanlines on subsections aren't so necessary since the hierarchy is conveyed well in the typography and spacing on the subsection titles. They are also quite short like an n-dash before the section rather than a marker.

Second also @Jhernandez's comment about removing lines between references. The spacing and indentation of the numbered bullet points is sufficient; and considering there are many underlined links in the references section, the lines can also make it slightly harder to discern which part of each reference is the link.

Oh one more thing – are we able to support localization of the Wikipedia wordmark as well?

Thanks everyone for feedback. comments in-line

@Jhernandez

Section titles in the middle of the page lead to weird page breaks. Maybe we need page-break-before: always on top level section titles?

I really wanted to use "Always" but then number of pages per article goes up considerably. 20-30% I would say. e.g. Mona lisa will be 19 pages instead of 14. because it starts new sections on new pages, there are times when last section is just 1-2 lines and rest of the page is empty. it's unfortunately, not eco friendly :(

@RHo

References styles occupy too much vertical space, leading to them using up several pages. I'd suggest removing the horizontal gray borders, making the vertical spacing a lot narrower, to make them a lot more compact. Maybe even keeping the 2 columns per .references at a4 width

Makes sense. i will make it compact and remove the lines.

@Pginer-WMF & @RHo

Regarding the scanlines on subsections, I'm not completely sure they are needed since the visual hierarchy seems clear now, but they don't harm either I guess.

Yeah, i guess the hierarchy is enough to not have them plus totally agree on that they look more like n-dash. i can fix that but i think they are not necessary. will update.

For content such as images and infoboxes, I was wondering if it would be better to base them on the mobile web style where borders are removed which in addition to save ink may contribute to a cleaner look in print.

That could be good too. the only issue in that is the image captions look stranded and not part of a block element. i have been meaning to talk about that on mobile web too. but we can try.

Oh one more thing – are we able to support localization of the Wikipedia wordmark as well?

The wordmark and the subtle thick border will show up only on english wikipedia. for other languages, the branding will be absent unless we create a fallback solution. i'm looking at it from pov of current solution which doesn't have branding anywhere. so starting with english.

^^ this is all great feedback. thanks. i will update another draft soon.

Here's 2nd draft of the CSS and more PDF examples
CSS - >

People article

Typeface article

Non-latin article from Hindi Wikipedia

Some of the questions arising on print have been discussed in-depth when building and improving
https://phabricator.wikimedia.org/diffusion/MW/browse/master/resources/src/mediawiki.legacy/commonPrint.css
Mind that Wikipedia is just one “product” using this. Some languages also have their extensions or overrides. So the abstraction in the stylesheets to work for this huge number of wikis is pretty high. In the beginning it might seem better to make a complete new start, but to find buy-in for the changes takes much longer.
Therefore we should double-check and compare which parts of the current styles of commonPrint.css are affected from the proposed change or could probably be just incorporated. @GWicke can provide a lot of experience about several of current rules.

A few points from scanning quickly through the provided PDFs and the print.css:

• When defining the colors, also make sure to add #fff as background-color on body in order to provide best and fastest print experience.
• I'd pledge for link underline to be solid rather than dotted as latter is often used for hints and abbreviations.
• The superscript sup references are strongly disturbing the typographic beauty right now for me, we should use something like this position: relative; top: -.4em; vertical-align: baseline;
• Numbered list and bullet lists seem have a different left margins – compare References and External Links section for example.
• Do we have blockquote, a code block, a MathML and other special HTML markup examples?
• Depending if we want to have one stylesheet rules it all (PDF & print), we should consider switching to pt values at least on the small values, definitely 1px, but probably up to 3px.
• Question that last modified info hierarchy-wise is more important than retrieved from info.
• Greys in references should IMO be switched to black.
• We replace color by black and white, but there are a few leftovers that are harder (and unnecessary) to print, like Commons logo in Charter example or link icons like Video icon in Mona Lisa.

RTL languages would be another interesting example to look into.

I'd would be great to have the print.css shared somewhere, where code contributions are easier made than via file uploads here, like your GitHub.
In a general note, I like how this goes along.

On T142207, the team for the German Community Wishlist discussed some (although minor) changes for the print stylesheet, too.

@Volker_E suggested there:

please consider adding your thoughts on design-specifics at T135022, maybe we could split some of the changes proposed from there and fulfill them early-on by addressing this ticket in a patch.

Indeed, the minor changes of adjusting the line height and the position of the headings (to be closer to the following paragraph) are a subset of the proposal here.

What do you think about an early patch?

In T135022#2668854, @Nirzar wrote:

@Lea_WMDE can we merge this into T142207 or the other way around?

I'd rather keep it open, in case some of the changes here take longer to realize, and we could split some of the easy improvements for the first version. If it turns out that all proposals of the final version can be done easily, I'm happy to merge them, though.

hey @Nirzar – we're working on this idea of downloading to PDF on the New Readers project as a means to have offline access.

Reading through this thread, wondering if there is further iteration being done on that earlier separate mobile version of print styles (that Mona Lisa example) that we could potentially leverage?

I've provided a work-in-progress patch for MediaWiki core in order to get more feedback from other contributors on this.
Taken rules from v2 provided above, with those minor changes:

• General cleanup and alignment to Wikimedia stylelint rules
• Changed some minor pixel values to print-friendly points pt
• Added .noexcerpt for hiding speaker symbol in front of IPA
• Merged several similar a selectors into one rule
• border-bottom on a doesn't work well across browsers, left out for now
• Didn't include li rule (occurs twice) and ul li font-size property
• .thumbinner left alignment isn't taken

Open issues from my point in order of occurrence in the CSS file:

• If we use shades of grey, we can also use greys from our color palette M82 – it doesn't make a difference for printers not to use web safe colors.
• Logo should be localized
• We need central SVG, not PNG logo to link to
• What's #administrator, .hatnote { display:none; }
• Not sure if hiding TOC is getting broad agreement
• #siteSub:after will not work out in edge cases where people are overwriting font-sizes, I also guess it's meant to be a border so it should be a border property
• Rather be careful with distances in px, I'd rather like this to be in em
• Bringing sanity to margins across the board and go for margin-top and :first-child overrides everywhere. See also request at T142207 for h2-h6 margin-top: 1.8em
• Where does div.floatright, table.floatright come from?
• The colors are not reduced in #footer

Let's continue the code parts conversation there and general directional questions here.

Change 320720 had a related patch set uploaded (by VolkerE):
[WIP] Improve print styles

https://gerrit.wikimedia.org/r/320720

If we use shades of grey, we can also use greys from our color palette M82 – it doesn't make a difference for printers not to use web safe colors.

Sure.

Logo should be localized

For now the logo is shown only if the body language is "en"

We need central SVG, not PNG logo to link to

We will make sure it's SVG in final version. i was hotlinking a png. we have SVGs on mobilefrontend.

What's #administrator, .hatnote { display:none; }

We need to hide disambiguation warnings. disambiguations are for people to go to a correct page if they happen to be a wrong page. in case of printing, assumption is people know what they want to print.

Not sure if hiding TOC is getting broad agreement

We won't. the new version im working has toc.

#siteSub:after will not work out in edge cases where people are overwriting font-sizes, I also guess it's meant to be a border so it should be a border property

Removed it entirely. don't need it.

Rather be careful with distances in px, I'd rather like this to be in em

Does it matter anymore?

Bringing sanity to margins across the board and go for margin-top and :first-child overrides everywhere. See also request at T142207 for h2-h6 margin-top: 1.8em

I consolidated heading margins in new css.

Where does div.floatright, table.floatright come from?

comes from wikitext styles. need it for manual overrides for editors

The colors are not reduced in #footer

changed them to black.

Change 320720 merged by jenkins-bot:
[mediawiki/core@master] Simplify print styles

https://gerrit.wikimedia.org/r/320720

A suggestion regarding the printing the article as pdf. It would be nice if the table of contents of articles was found in the form of a PDF outline. It would enable easier access to various sections of the article while saving space (win-win). I'm not sure about the feasibility of it, though.

@Kaartic Filed under T183104: Transform TOC into PDF outline on export