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
>
>
_______________________________________________
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>
