Re: [Wikimedia-l] new Math options: phrasing the preferences
Hi Peter,
On Tue, Oct 28, 2014 at 8:40 AM, Peter Krautzberger
peter.krautzber...@mathjax.org wrote:
While I can understand that the SVG images were orginally optimized of
inline use, I do not see any principal reason why inline SVG's are
better.
a) all rendering issues have been due to SVGs not being linine
That's what I do not understand. Do you need to produce different SVG
images for inline and external images? That does not sound intuitive
for me. Or are ther problems in the way browsers render svg-images.
This would indicate that there are browsers with limited MathML and
SVG support.
b) accessibility of the SVG output: only inline SVG can be styled by
client-side CSS. A very important accessibility use case are User Style
Sheets since many users just need visual enhancements.
I'm convinced that content MathML is needed for good accessibility.
See the ntcir-11 challange regarding $f_xy=f_yx$ or
$\langle\frac1x\rangle\ge\frac1{\langle x \rangle}$
http://ntcir11-wmc.nii.ac.jp/index.php/NTCIR-11-Math-Wikipedia-Task#Content_Queries
.
c) improve page performance by reducing http requests. A math page seems to
easily gather 100 and more equations, all of which cause separate http
requests. @physikerwelt do you have data on how much equations are actually
used across pages? In particular, beyond simple math \mathbb{N} \math
situations.
I see your point. However this is a general problem with images. So we
need a general solution, if the number of requests is a problem. I had
the impression that squid could handle quite a few requests per second
http://wiki.squid-cache.org/KnowledgeBase/Benchmarks#Squid_trunk_revno_13251
I'm not sure which cachig system is currently used in production but I
guess the number of requests is not an issue at the moment.
Yes, I have numbers about the cross page use of formulae. I'll send an
updated report on enwiki in the following weeks. (Latests on 15'th of
Jan.)
Best
Moritz
As I said, I did not mean to open up that debate -- that's simply not my
call.
P.
On Mon, Oct 27, 2014 at 5:05 PM, Physikerwelt w...@physikerwelt.de wrote:
Hi,
On Mon, Oct 27, 2014 at 4:52 PM, Gabriel Wicke gwi...@wikimedia.org
wrote:
Peter,
On 10/27/2014 03:08 AM, Peter Krautzberger wrote:
Gabriel wrote:
It would also be nice to reduce the size of the SVG fall-back images,
which are
currently about 50% larger than the (low-resolution) PNGs.
I think this only holds for smaller equations. For more complex
equations it
seem to me that minified+zip'ed SVGs are the same size (or smaller)
than the
PNG.
@physikerwelt do you have data on that by any chance?
Yes. I'm currenty in the process of summarizing the data. Recently
LaTeXML added SVG output. This provides even a better basis for
comparision.
we aren't minifying yet. I did some tests last night (see
https://bugzilla.wikimedia.org/show_bug.cgi?id=72547), which suggest
that we
can reduce the size of small SVG formulas by about 25-30% with
minification.
This looks pretty straightforward to add to mathoid.
Yes we should defintly do that. I do not see any reason for not doing
that.
As for further optimizations, you could drop the paths entirely and
point
the use elements to external files, i.e., use global svg data like
webfonts. This then raises a different question of balancing: is it
worth
loading such fonts/spritemaps when there's only a few equations in
the page?
For most page views this would likely increase the size, unless those
maps
only had the glyphs needed in a certain page. Which would then reduce
the
caching between pages.
I would like to keep it simple. I think this would additional
complexity and make debugging much harder.
Just for the record since we've rejected it for other reasons, inline
SVGs
would also reduce the number of http requests and would resolve the
clipping
and baseline problems we've seen in the past.
It's a trade-off between making everybody download both MathML *and* SVG
(which is larger), or only doing so where MathML is not supported. There
is
also a complexity trade-off between simple stand-alone fall-back images,
and
the maintenance of a global per-page glyph table. Overall, the size of
math
fallbacks is moderate compared to a page with photos, and it looks like
we
can get the size close to that of low-resolution PNG images with
minification. To me, this seems to be a good compromise for now, and we
can
always re-evaluate later.
Gabriel
We could benchmark a solution that replaces MathML with inline SVG via
Javascript as well. However, this would not reduce the number of HTTP
requests and would not help people without javascript.
While I can understand that the SVG images were orginally optimized of
inline use, I do not see any principal reason why inline SVG's are
better.
Peter, can you explain that?
Best
Moritz
___
Re: [Wikimedia-l] new Math options: phrasing the preferences
Peter, On 10/27/2014 03:08 AM, Peter Krautzberger wrote: Gabriel wrote: It would also be nice to reduce the size of the SVG fall-back images, which are currently about 50% larger than the (low-resolution) PNGs. I think this only holds for smaller equations. For more complex equations it seem to me that minified+zip'ed SVGs are the same size (or smaller) than the PNG. @physikerwelt do you have data on that by any chance? we aren't minifying yet. I did some tests last night (see https://bugzilla.wikimedia.org/show_bug.cgi?id=72547), which suggest that we can reduce the size of small SVG formulas by about 25-30% with minification. This looks pretty straightforward to add to mathoid. As for further optimizations, you could drop the paths entirely and point the use elements to external files, i.e., use global svg data like webfonts. This then raises a different question of balancing: is it worth loading such fonts/spritemaps when there's only a few equations in the page? For most page views this would likely increase the size, unless those maps only had the glyphs needed in a certain page. Which would then reduce the caching between pages. Just for the record since we've rejected it for other reasons, inline SVGs would also reduce the number of http requests and would resolve the clipping and baseline problems we've seen in the past. It's a trade-off between making everybody download both MathML *and* SVG (which is larger), or only doing so where MathML is not supported. There is also a complexity trade-off between simple stand-alone fall-back images, and the maintenance of a global per-page glyph table. Overall, the size of math fallbacks is moderate compared to a page with photos, and it looks like we can get the size close to that of low-resolution PNG images with minification. To me, this seems to be a good compromise for now, and we can always re-evaluate later. Gabriel ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
[Wikimedia-l] new Math options: phrasing the preferences
As a follow-up to the discussions about the new Math rendering options, I'd like to raise the question of how to write the preferences in way that will really be helpful to the users. I made a little patch at https://gerrit.wikimedia.org/r/#/c/167024/ It only fixes some minor things, and the problem is wider: How is a person supposed to choose the best option? What are modern browsers? If one thing is recommended for modern browsers, and another improves (or enhances) rendering on modern, which one should I choose? What is slow? Why is improved visual rendering mixed with accessibility in *two* options? Which accessibility features do I get in each option? Are they even different? These options confused me for years as a Wikipedia user. The recent developments in Math are great technically (kudos to Moritz, Gabriel, TheDJ and everybody else who was involved!), but the options are still not so helpful. Let's fix them! Suggestions?.. -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com “We're living in pieces, I want to live in peace.” – T. Moore ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
Re: [Wikimedia-l] new Math options: phrasing the preferences
Amir, On 10/25/2014 01:16 PM, Amir E. Aharoni wrote: As a follow-up to the discussions about the new Math rendering options, I'd like to raise the question of how to write the preferences in way that will really be helpful to the users. I made a little patch at https://gerrit.wikimedia.org/r/#/c/167024/ thank you for your patch, I just merged it. I agree that the current options are confusing. We should be able to improve things a bit further by tweaking the descriptions, but in the longer term we are working towards having only a single mode that works really well, out of the box, for everybody. Before we can consider moving to One True Math mode, we need more refinement and testing, both with older browsers and various accessibility tools. It would also be nice to reduce the size of the SVG fall-back images, which are currently about 50% larger than the (low-resolution) PNGs. Thankfully, users with MathML-enabled browsers like Firefox don't even load them, and are now saving bandwidth relative to PNGs. Why is improved visual rendering mixed with accessibility in *two* options? Which accessibility features do I get in each option? Are they even different? As I understand it, client-side MathJax still defaults to an HTML+CSS rendering mode on browsers without MathML support, which provides better accessibility than the PNGs on IE 9 (so hardly 'modern'). It also has some nifty context menu features like zooming, but this could also be added to the server-side MathML mode. I added Moritz and Peter in the CC, maybe they can chime in. Gabriel ___ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-requ...@lists.wikimedia.org?subject=unsubscribe
