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 <wiki(a)physikerwelt.de> wrote:
Hi,
On Mon, Oct 27, 2014 at 4:52 PM, Gabriel Wicke <gwicke(a)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