Page MenuHomePhabricator

Make math using MathML / SVG / PNG mode print properly
Closed, ResolvedPublic

Description

SVG and PNG math renders in the MathML render mode are pulled in as background images so that browsers with MathML support do not load SVG fallback images. We now know that it is most likely not required to have the images be background images and that as background images there are two problems: browsers default to printing without background images so the math is not printed and math can not be copied and pasted. The following solutions have been suggested: convert images to <img> or inline SVG (no known problems) or a couple of workarounds described below that may nor may not work for all browsers and the effects on different setups are currently unknown.

However, browsers default to printing without background images, which means that formulas go missing when printing web pages using default settings. Users can work around this by manually checking "print background images" in the print settings, but it is likely that they won't notice the missing formulas before holding a print-out in hand.

There is a CSS workaround for Webkit, which can be targeted at math elements: -WebKit-print-color-adjust: exact;. This makes Webkit print background images in the element this style is applied to, regardless of print settings.

However, it is not clear if there is a solution that will work reliably for other browsers. http://maxlapides.com/forcing-browsers-print-backgrounds/ discusses several options, but we'll have to test whether any of them can be made to work reliably for math. Formulas seem to be missing in print-outs even when using Firefox with the MathML plug-in.

If no workaround can be found, then this brings us back to the perennial question of whether MathML is worth the hassle. If we dropped MathML for regular SVG images, then this problem would go away.

From T131177#2343273:

This change means that it is no longer possible to copy and paste math (from Chrome at least). It might help to make the SVG fallback an actual inline image, but I can't even seem to get that to copy and paste.

I know a lot of people that copy and paste equations from Wikimedia sites (WP and WB) as a quick and easy way of displaying them in presentations and the like, and this is going to break that.

Event Timeline

GWicke added a project: Services.

printing works well for IE and Edge. So maybe we can use the same javascript code for printing. I'll look into the resource loader documention, if there is information on printing.

It seems that the resource loader supports css that is displayed on print, but no javascript that is executed on print.
I found an approach at stackoverflow... but it's not really nice
http://stackoverflow.com/questions/3619609/check-for-when-a-user-has-selected-to-print-using-javascript

printing works well for IE and Edge.

According to https://phabricator.wikimedia.org/T136672#2343966, the current mode does not use background images but regular images on Edge (so I'm guessing also on IE).

Using regular img tags would also resolve https://phabricator.wikimedia.org/T92812. Since SVGs are now always loaded (even on FF), the reason for meta-tags (performance hack for FF) seems less relevant.

Since SVGs are now always loaded (even on FF), the reason for meta-tags (performance hack for FF) seems less relevant.

Indeed. Moving the SVGs to plain <img>s (or even inline SVG?) seems like the cleanest solution to this problem.

@GWicke as far as I can tell doing that (inline SVG might work) would cause some MathML browsers to display both the image and the MathML.

@Hungryce, I believe we are currently using CSS to hide the background image for browsers that don't need it. The same CSS targeting (using display: none) should work for an <img> or inline SVG.

Ok, thanks, @GWicke. I don't know how exactly we do things, but it sounds like changing to <img> or inline SVG should work. I don't know who can add/test that (I think it would be tested on the beta cluster first) but whoever that it should do that soon.

Ok, thanks, @GWicke. I don't know how exactly we do things, but it sounds like changing to <img> or inline SVG should work. I don't know who can add/test that (I think it would be tested on the beta cluster first) but whoever that it should do that soon.

More on the proprietary [[ https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-print-color-adjust | -webkit-print-color-adjust: exact; ]] hack, which is supported only by Safari 6+ & Chrome (Blink) since at least v19.

I'll make sure that we address this in the next days.

Just a note: some people use CSS to force native MathML to be displayed
(in a user stylesheet, addon etc) so the optimization of not loaded SVG
images still makes sense for them.

Physikerwelt moved this task from Inbox to Doing on the Math board.

Given that a minority of browsers supports MathML, should we just consider making SVG the primary render and offer MathML as a user option?

I think, we should focus on the print problem, and not discuss the weaknesses of web "standards" in this task.
The fact that some users cannot print the page, is a severe problem, while better bandwidth usage for native MathML users is a nice to have. In theory, there might be other options to prevent loading of SVG images that are not displayed, and using the img tag for images seems more straight forward compared to the meta tag anyhow.

FWIW, not using background-images would also work around https://phabricator.wikimedia.org/T130967 (a WebKit bug re SVG and text)

Change 292332 had a related patch set uploaded (by Physikerwelt):
Use img instead of meta tags for SVGs

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

Change 292332 merged by jenkins-bot:
Use img instead of meta tags for SVGs

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

Change 292344 had a related patch set uploaded (by Mobrovac):
Use img instead of meta tags for SVGs

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

Change 292344 merged by jenkins-bot:
Use img instead of meta tags for SVGs

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

The change is in 1.28.0-wmf.4, bound to be deployed to all projects 5 hours from now. Resolving.

Thank you, @Physikerwelt, @mobrovac and @fredw!

To make sure that the copy / paste issue is followed up on, I re-opened T136672.

@GWicke like I said at T136672 if copy/paste (which I think works now from my testing) does not work then this issue is not resolved as they were merged.

I verified that printing now works fine with Chrome's default print options on https://en.wikipedia.org/wiki/Fourier_transform (after a purge).

I verified that printing now works fine with Chrome's default print options on https://en.wikipedia.org/wiki/Fourier_transform (after a purge).

Yeah, I printed it too yesterday :)