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