[documentation] Are SVG's in documentation viable now?

newer
[iterators] Missing typedefs in...

John Maddock

8 Dec 2014 8 Dec '14

12:51 p.m.

Folks I need your opinions, Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable. So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue. Many thanks, John. PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

Show replies by date

Marc Glisse

8 Dec 8 Dec

1:02 p.m.

On Mon, 8 Dec 2014, John Maddock wrote:

...

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues?

Is the SVG version supposed to be much smaller than the PNG? That makes the comparison less easy. -- Marc Glisse

Paul A. Bristow

2:23 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Marc Glisse Sent: 08 December 2014 13:02 To: boost@lists.boost.org Subject: Re: [boost] [documentation] Are SVG's in documentation viable now?

On Mon, 8 Dec 2014, John Maddock wrote:

...
So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues?

Is the SVG version supposed to be much smaller than the PNG? That makes the comparison less easy.

Yes - that's a major advantage of SVG - looking better regardless of size - try ctrl+ and ctrl-. If you want the same quality from PNG, the file would have to be gigantic. (although John monster equation collection makes the browsers sweat a bit ;-) Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

Marc Glisse

3:19 p.m.

On Mon, 8 Dec 2014, Paul A. Bristow wrote:

...

...
Is the SVG version supposed to be much smaller than the PNG? That makes the comparison less easy.

Yes - that's a major advantage of SVG - looking better regardless of size - try ctrl+ and ctrl-.

That's only an advantage if people don't abuse it by making equations unreadably small. Some equations have small symbols in exponent or subscript... Assuming the left column shows the size of regular text for reference, I prefer the third column because the second one is too small. Rescale the second one and it becomes better. I just want to make sure that the scale difference is an accident and does not reflect an intention to make equations smaller than regular text in the doc. -- Marc Glisse

John Maddock

4:34 p.m.

First of all, thank you so much to everyone who's responded, it's very much appreciated! To answer the various points raised: * Font Size: Yes the SVG's could be larger, in fact I think I changed the png dpi size a while back to make those larger, when probably I should have just changed the font size. In any case any difference in size between the two is a pure accident that depends on your screen's size and dpi, as the SVG's are scaled in "real" units where as the png's just show up at "whatever" size. * The missing png for the second beta() equation is my SNAFU - that line shouldn't have been in the table, likewise the first line of the table has it's formatting messed up because it should be a header, not content. * Marco thought the SVG's looked uglier - if that's the case then it's almost certainly a font-substitution issue on your platform/browser, as they look way nicer (and less fuzzy) here. Investigating the STIX webfonts is on my TODO list. * Slow page load: yes I know, sorry! Just dumped everything on one page to see if it would work. Real pages would have half a dozen svg's max. * Edward: SVG's are used the same way as PNG's in quickbook, with a [$myfile.svg]. * Clipping: yes, this is what I was afraid of - at least you didn't get scroll bars around every equation! I have no real control over the generated HTML BTW as it all comes from the docbook stylesheets. * Ellint24 and "?": this looks like something unsupported by SVGMath was used in the original MathML, I'll investigate. Thanks all! John.

Marco Guazzone

4:50 p.m.

Thank you, John. Just for your interest, here's is like I see the page with Firefox 34 64 bit: http://ibin.co/1jwmEuouKTbf (or http://imagebin.ca/v/1jwmEuouKTbf ) And here is with chrome 39.0.2171.71 (64-bit) The PNG versions appears smoother then SVG ones (IMO). http://ibin.co/1jwoB7Ssh1xV (or http://imagebin.ca/v/1jwoB7Ssh1xV) In both cases, my OS is linux Fedora 20 x86_64. Cheers, -- Marco On Mon, Dec 8, 2014 at 5:34 PM, John Maddock wrote:

...

First of all, thank you so much to everyone who's responded, it's very much appreciated!

To answer the various points raised:

* Font Size: Yes the SVG's could be larger, in fact I think I changed the png dpi size a while back to make those larger, when probably I should have just changed the font size. In any case any difference in size between the two is a pure accident that depends on your screen's size and dpi, as the SVG's are scaled in "real" units where as the png's just show up at "whatever" size. * The missing png for the second beta() equation is my SNAFU - that line shouldn't have been in the table, likewise the first line of the table has it's formatting messed up because it should be a header, not content. * Marco thought the SVG's looked uglier - if that's the case then it's almost certainly a font-substitution issue on your platform/browser, as they look way nicer (and less fuzzy) here. Investigating the STIX webfonts is on my TODO list. * Slow page load: yes I know, sorry! Just dumped everything on one page to see if it would work. Real pages would have half a dozen svg's max. * Edward: SVG's are used the same way as PNG's in quickbook, with a [$myfile.svg]. * Clipping: yes, this is what I was afraid of - at least you didn't get scroll bars around every equation! I have no real control over the generated HTML BTW as it all comes from the docbook stylesheets. * Ellint24 and "?": this looks like something unsupported by SVGMath was used in the original MathML, I'll investigate.

Thanks all! John.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

John Maddock

9 Dec 9 Dec

5:27 p.m.

...

Just for your interest, here's is like I see the page with Firefox 34 64 bit:

http://ibin.co/1jwmEuouKTbf (or http://imagebin.ca/v/1jwmEuouKTbf )

And here is with chrome 39.0.2171.71 (64-bit)

The PNG versions appears smoother then SVG ones (IMO).

http://ibin.co/1jwoB7Ssh1xV (or http://imagebin.ca/v/1jwoB7Ssh1xV)

In both cases, my OS is linux Fedora 20 x86_64.

It looks to me like the PNG's are anti-aliased, but the SVG's aren't, which would probably be a display setting or something? In any case, I've tried them again slightly larger than before (http://jzmaddock.github.io/doctest/html/svg_test/equations.html) is this any better? Thanks! John.

Andrey Semashev

5:50 p.m.

On Tuesday 09 December 2014 17:27:25 John Maddock wrote:

...

...
Just for your interest, here's is like I see the page with Firefox 34 64 bit: http://ibin.co/1jwmEuouKTbf (or http://imagebin.ca/v/1jwmEuouKTbf )

And here is with chrome 39.0.2171.71 (64-bit)

The PNG versions appears smoother then SVG ones (IMO).

http://ibin.co/1jwoB7Ssh1xV (or http://imagebin.ca/v/1jwoB7Ssh1xV)

In both cases, my OS is linux Fedora 20 x86_64.

It looks to me like the PNG's are anti-aliased, but the SVG's aren't, which would probably be a display setting or something?

In any case, I've tried them again slightly larger than before (http://jzmaddock.github.io/doctest/html/svg_test/equations.html) is this any better?

Firefox 34.0, Kubuntu 14.10. The italic z's have no diagonal lines for me. https://www.dropbox.com/s/vss8zpls359zdrd/firefox_formulas1.png?dl=0 There's no such issue in Chrome 39, though.

John Maddock

6:32 p.m.

...

Firefox 34.0, Kubuntu 14.10.

The italic z's have no diagonal lines for me.

Grrr, I've occationally seen that with the double-struck N's on Windows - seems to vary with font size which lines drop out :-( Thanks, John.

Henrik Sundberg

6:02 p.m.

On Tue, Dec 9, 2014 at 6:27 PM, John Maddock wrote:

...

...
In any case, I've tried them again slightly larger than before ( http://jzmaddock.github.io/doctest/html/svg_test/equations.html) is this any better?

Chrome (Windows 8.1; 64 bit): Version 39.0.2171.71 m SVG for ellint24 is smaller than the PNG. The rest look about the same. Don't understand the 1F1 in nc_t_ref1. (both PNG and SVG...) /$

...

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/ mailman/listinfo.cgi/boost

John Maddock

6:33 p.m.

...

Chrome (Windows 8.1; 64 bit): Version 39.0.2171.71 m SVG for ellint24 is smaller than the PNG. The rest look about the same.

That's another SNAFU from how they were generated, I've reset the DPI back to 96dpi and they should be the same now.

...

Don't understand the 1F1 in nc_t_ref1. (both PNG and SVG...)

The n's should have been v's, now fixed. Thanks, John.

Henrik Sundberg

6:05 p.m.

On Tue, Dec 9, 2014 at 6:27 PM, John Maddock wrote:

...

...
In any case, I've tried them again slightly larger than before ( http://jzmaddock.github.io/doctest/html/svg_test/equations.html) is this any better?

Chrome (Windows 8.1; 64 bit): Version 39.0.2171.71 m SVG for ellint24 is smaller than the PNG. The rest look about the same. Don't understand the 1F1 in nc_t_ref1. (both PNG and SVG...) /$

Marco Guazzone

10 Dec 10 Dec

12:17 p.m.

On Tue, Dec 9, 2014 at 6:27 PM, John Maddock wrote:

...

It looks to me like the PNG's are anti-aliased, but the SVG's aren't, which would probably be a display setting or something?

I've just looked in my window manager settings and anti-alias is enabled.

...

In any case, I've tried them again slightly larger than before (http://jzmaddock.github.io/doctest/html/svg_test/equations.html) is this any better?

Better than before, but not wrt PNG (IMO) This is the result in Firefox http://imagebin.ca/v/1k9P4HIJQMdV For instance: - Greek symbols: some of the special greek symbols (pi, epsilon,...) looks clearer in PNG. For example, compare $\pi$ in "bernoulli_numbers2" and $\varepsilon$ in "sinh3" - Spacing: it seems SVG formulas are more narrow and math symbols are closer than their PNG counterparts. For example, compare the $\cos\phi$ and $\sin\phi$ expressions in the "bessel_derivatives3". On the SVG side, The $\cos$ ($\sin$) is very close to $\phi$, while on the PNG side there is a little space that makes the expression more readable (IMO). Anyway, aside these small issues, I vote for the transition to SVG ;) I think that my issues are motivated by your note in the original email "... the equations reference Window's specific fonts,...". So this can be easily solved in the future Cheers, -- Marco

Bernd Prager

8 Dec 8 Dec

1:06 p.m.

John, This is very nice. It appears that the second "beta(a, b)" term is failing to generate the equation (Right row, line 70); I can only see a box. Cheers, -- Bernd Sent from my iPhone

...

On Dec 8, 2014, at 7:51 AM, John Maddock wrote:

Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Many thanks, John.

PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Marco Guazzone

1:34 p.m.

Hi John, As Bern pointed out, the image https://jzmaddock.github.io/doctest/equations/beta1.svg.png is missing. Also, the SVG-rendered math symbols look uglier than the PNG counterparts. Maybe, this is just a font issue. Best -- Marco On Mon, Dec 8, 2014 at 2:06 PM, Bernd Prager wrote:

...

John,

This is very nice.

It appears that the second "beta(a, b)" term is failing to generate the equation (Right row, line 70); I can only see a box.

Cheers, -- Bernd Sent from my iPhone

...
On Dec 8, 2014, at 7:51 AM, John Maddock wrote:

Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Many thanks, John.

PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Antony Polukhin

1:39 p.m.

2014-12-08 16:51 GMT+04:00 John Maddock :

...

Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

On all browsers SVG equations are smaller than the PNG versions. On all browsers zoomed to PNG size SVG equations look better than than the PNG versions (SVG is much more sharp). Windows, Firefox 33.1: * Page renders really slowly, but this could be because of a huge amount of SVG files. * Hard to see the Ai(0) = ... 3^2/3... in 'airy' * Page consumed ~800 MB of RAM Windows, Chrome 39.0.2171 : * Page renders slowly, but this could be because of a huge amount of SVG files. * Hard to see "z" letters, font is ugly * Page consumed ~600 MB of RAM Windows, Firefox 34.0: * Page rendered faster than in 33.1 but scrolling is slow and nervous * Page consumed ~800 MB of RAM Windows, IE 8: SVG is not rendered, but IE 8 is not supported any more by vendor. Linux, Firefox 34.0 - everything is great, page rendered fast, page consumed ~150 MB of RAM Resume: If there's not many equations on the page - SVG is good. P.S.: As a transitional solution, you could use a raster fallback: <img src="your.svg" onerror="this.src='fallback.png'"> for antique browsers -- Best regards, Antony Polukhin

Keith Burton

2:04 p.m.

...

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues?

Windows 7, IE 11 : acosh1 label is bold and indented , none of the others are Keith

Edward Diener

2:34 p.m.

On 12/8/2014 7:51 AM, John Maddock wrote:

...

Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Many thanks, John.

PS, I'm aware of MathJax and similar solutions for equations - but these generate so many security warnings on IE when used in local docs (not on a server), that it's a non-starter for now. Besides, we have the SVG's already, and it's a one line change to make use of them ;-)

Looks great and a bit clearer than PNG. is there a way of using SVG in Quickbook that is documented somewhere ?

Alex Perry

2:38 p.m.

On 08 December 2014 12:52 John Maddock [mailto:boost.regex@virgin.net] wrote:-

...

Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Just thought in the light of recent posts on bed-time reading on tablets with boost.book would try this on a mobile device. On Android Kit-Kat default browser there is some clipping of these equations but I'm not quite sure how you are calculating the width and height for the svg elements since these are just given in your html. I've attached a screen shot showing the clipping for airy_bi If I adjust the sizes in the html to say <object type="image/svg+xml" data="equations/airy_bi.svg" width="300" height="125"></object> then no clipping occurs HTH Alex Sorry for re-post if original does get through but the list didn't like the size of the png I attached so I've resent without it - see https://www.dropbox.com/s/oh0r7uqjrn9duyq/Screenshot_2014-12-08-14-19-29.png... Which hopefully is accessible.

Stuart Dootson

2:45 p.m.

On 8 December 2014 at 14:38, Alex Perry wrote:

...

On 08 December 2014 12:52 John Maddock [mailto:boost.regex@virgin.net] wrote:-

...
Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Just thought in the light of recent posts on bed-time reading on tablets with boost.book would try this on a mobile device.

On Android Kit-Kat default browser there is some clipping of these equations but I'm not quite sure how you are calculating the width and height for the svg elements since these are just given in your html.

I've attached a screen shot showing the clipping for airy_bi

If I adjust the sizes in the html to say <object type="image/svg+xml" data="equations/airy_bi.svg" width="300" height="125"></object> then no clipping occurs

HTH

Alex

Sorry for re-post if original does get through but the list didn't like the size of the png I attached so I've resent without it - see https://www.dropbox.com/s/oh0r7uqjrn9duyq/Screenshot_2014-12-08-14-19-29.png... Which hopefully is accessible.

And in light of this reply, I tried it in Safari on my iPhone 5S, running iOS 8.1.1 - they appeared to display fine (as far as I could see, no clipping a la Android), and also loaded and zoomed a lot faster than in Chrome 40 on my Windows 7 workstation. Stuart

Paul A. Bristow

3:37 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Stuart Dootson Sent: 08 December 2014 14:46 To: boost@lists.boost.org Subject: Re: [boost] [documentation] Are SVG's in documentation viable now?

On 8 December 2014 at 14:38, Alex Perry wrote:

...
On 08 December 2014 12:52 John Maddock [mailto:boost.regex@virgin.net] wrote:-

...
Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Just thought in the light of recent posts on bed-time reading on tablets with boost.book would try this on a mobile device.

On Android Kit-Kat default browser there is some clipping of these equations but I'm not quite sure how you are calculating the width and height for the svg elements since these are just given in your html.

I've attached a screen shot showing the clipping for airy_bi

If I adjust the sizes in the html to say <object type="image/svg+xml" data="equations/airy_bi.svg" width="300" height="125"></object> then no clipping occurs

<snip>

...

And in light of this reply, I tried it in Safari on my iPhone 5S, running iOS 8.1.1 - they appeared to display fine (as far as I could see, no clipping a la Android), and also loaded and zoomed a lot faster than in Chrome 40 on my Windows 7 workstation.

I've also compared http://jzmaddock.github.io/doctest/html/svg_test/equations.html on an iPad. Safari which renders a tiny bit better than Chrome (a few slight collisions between integral sign and limits). No clipping as seen on Android phone. But overall, SVG is definitely nicer. Paul PS The slow speed render is because this is such a monster test collection of *all* the equations in Boost.Math. Speed should not be a problem in real life usage. I believe that the equation font size can also be chosen to match the text.

Paul A. Bristow

3:05 p.m.

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Alex Perry Sent: 08 December 2014 14:38 To: boost@lists.boost.org Subject: Re: [boost] [documentation] Are SVG's in documentation viable now?

On 08 December 2014 12:52 John Maddock [mailto:boost.regex@virgin.net] wrote:-

...
Folks I need your opinions,

Since it's inception, Boost.Math has used PNG versions of equations and graphs even though scalable SVG versions have been available. Unfortunately, a variety of issues have prevented their use. Fortunately, the logjam now appears to have cleared, and use of SVG's appears viable.

So... I wonder if I can get folks to point their browsers at http://jzmaddock.github.io/doctest/html/svg_test/equations.html and let me know if there are any issues? One that I'm aware of, is that the equations reference Window's specific fonts, but so far in my tests this appears not to be an issue.

Just thought in the light of recent posts on bed-time reading on tablets with boost.book would try this on a mobile device.

On Android Kit-Kat default browser there is some clipping of these equations but I'm not quite sure how you are calculating the width and height for the svg elements since these are just given in your html.

I've attached a screen shot showing the clipping for airy_bi

If I adjust the sizes in the html to say <object type="image/svg+xml" data="equations/airy_bi.svg" width="300" height="125"></object> then no clipping occurs

HTH

Alex

Sorry for re-post if original does get through but the list didn't like the size of the png I attached so I've resent without it - see https://www.dropbox.com/s/oh0r7uqjrn9duyq/Screenshot_2014-12-08-14-19- 29.png?dl=0 Which hopefully is accessible.

I can confirm this clipping on Moto G Android KitKat on all the asinh(x) acosh beta (a,b)equations. gamma_p_derivative(a, x) are scrunched at the ve(a, point. And I noted a possible typo in the equation for ellint24 where the tan-1 equation has a ? in it. Some of the integral limits like pi/2 collide with the integral sign. We may be touching the limits of the rendering software? And a takes a which to render this monster overdose of equations. But overall it looks very good. Paul

Rob Stewart

6:55 p.m.

More mobile results: I see a little clipping on the left edge of some equations, particularly acosh2, in Chrome on Kit Kat. There were also some minor kerning issues. Scrolling want great, but not bad. Firefox 34.0 on Android crashes one way or another. Initially, with many other tabs open, it crashed well before loading the page. I was, eventually, able to load the page. The only issue I observed was with kerning with large parentheses. Scrolling was pretty good until I got well into the doc. Soon after, scrolling became sluggish and then it crashed. I take that to mean rendering is pretty good overall, but memory management is flawed on Android. ___ Rob (Sent from my portable computation engine)

3623

Age (days ago)

3625

Last active (days ago)

List overview

Download

22 comments

13 participants

participants (13)

Alex Perry
Andrey Semashev
Antony Polukhin
Bernd Prager
Edward Diener
Henrik Sundberg
John Maddock
Keith Burton
Marc Glisse
Marco Guazzone
Paul A. Bristow
Rob Stewart
Stuart Dootson