Make printed version &printable=yes work as e.g. for Vector

[kghbln]

Setup

• Browsers and versions: all
• MediaWiki version: 1.31+
• Database version: -/-
• PHP version: 7.0+
• Pivot version: 2.0.0
• Extension version (if connected to the issue): -/-

Issue

The printable version was overhauled in MediaWiki somewhere along the way from 1.28.x to 1.31.x, meaning that if you click on the "printable version" link in your sidebar like e.g. https://sandbox.semantic-mediawiki.org/w/index.php?title=Main_Page&printable=yes immediately the browser dialog for printing opens. This works for latest Foreground 2.1.0 and MediaWiki 1.31.0 but it does not for Pivot 2.0.0. It will be fine to have this work for Pivot too.

Example

Just long into "sandbox.semantic-mediawiki.org" switch to Pivot as your skin and try print. Conversely for Foreground or other skins to see the difference.

[Hutchy68]

Thanks for the heads up. I’ll take a look.

[amorangi]

The print dialog pops up for me, but the formatting of the page is terrible. For example I have a heading, the the rest of the page is blank. The TOC starts on page 2, but is cut of incomplete at the bottom of the page. It is, in effect, unusable.

[kghbln]

The print dialog pops up for me

Affirmative. Just tired on https://pivot.wikiproject.net/

It is, in effect, unusable.

I have just tested https://pivot.wikiproject.net/w/index.php?title=Pivot_features&printable=yes and the result is not as bad as I feared. Some tweaks to MediaWiki:Print.css will probably be necessary but still it is somehow usable.

[amorangi]

I've narrowed down my problem - when the TOC is very long it jumps to the second page (wasting the first page after the title) in order to try and fit it on the page. When the TOC is longer than a page it ignores the rest of the TOC and goes on with the contents. The issue will reside with the TOC part of the CSS.

[kghbln]

Fair enough but I do not think that this is an issue with pivot specifically. I'd expect this on other skins too. Probably it will be the best to split the page up into several smaller pages i.e. reorganize the content.

[Hutchy68]

Yes, there isn't much I can do with a long TOC. Sharing a link for a screen share video showing a print view and an actual printer dialog box.

https://drive.google.com/file/d/1XVcru10qEnAtFXYI8SA_rQinVUxVD4v-/view

The print CSS is correct as far as I can tell and I plan on closing this issue.

I actually think, https://pivot.wikiproject.net/w/index.php?title=Pivot_features&printable=yes isn't really a way to view what the printed version will look like. I will investigate more, but &printable=yes is still technically a @screen media and not @print media. That's probably a wrong use by MediaWiki and should really be eliminated as valid URL to use outside of calling the actual printer screen.

Using emulation mode in Chrome (showed how), will show what a real printed screen will look like. Sorry about the Screencastify showing at bottom of every page on the actual printer dialog preview in the demo screencast. Screencastify adds the controls to the webpage automatically for recording, pausing, etc.

Anyway, that's my take.

[Hutchy68]

Looks like &printable=yes is still loading MediaWiki:SkinName.CSS too and not loading the print.css file.

[Hutchy68]

This whole thing on MW is a mess! Looks like a few years back Vector was using a special file to output the skin in a printable version. 👎

if ( isset ( $_REQUEST[ 'printable' ] ) ) { require_once ( "Vector.printable.php" ); } else { ... 

Now they just have noprint class peppered throughout their code. Yes, there was a discussion on Phabricator on removing the &printable=yes back a few years ago. Since the @print media calls are already loading you can just use the browser print function. In essence, &printable=yes should just flat out be removed. Yep, there are a lot of discussions on removing it https://phabricator.wikimedia.org/search/query/SVxyDQVQStyB/#R

Summary, it is still there because some browsers don't handle @print media queries??? Which would output a warning in Pivot, use a modern browser. If anything, I might unset that link in the sidebar for the skin.

[amorangi]

Firefox gave me a weird layout. The first time I went into Chrome it duplicated the Firefox problem. I investigated using Chrome and media print emulator and couldn't see a problem. Now I can't reproduce the problem on Chrome even in non-developer mode. I'm second guessing myself now that perhaps the problem never existed in Chrome (I use FF as default). The problem remains with Firefox though so I suspect it's a Firefox rendering issue. I guess I'll just use Chrome if I want to print.

[Hutchy68]

Hmm, I can’t reproduce it. Firefox print is fine. Maybe a hard ctrl-r or ctrl-f5 to reload page?

[kghbln]

Looks like &printable=yes is still loading MediaWiki:SkinName.CSS too and not loading the print.css file.

@Hutchy68 This appears to be a MediaWiki core issue or is there something that Pivot can do to get/help Print.css being honored?

Apart from that: yes, this issue can be closed.

Firefox gave me a weird layout.

@amorangi In the past Firefox was a real disaster for printing. I basically emitted bullsh in any case, however the situation seems to have improved in recent versions. Anyways I believe that Chrome is still better and more flexible when it comes to printing pages. This is actually the only feature I like about Chrome.