[IPOL discuss] Vector graphics on IPOL: which format to use?

Mon Jul 4 13:43:38 CEST 2011

I know I'm being picky with this...but how many of that visits are
originated from us or our own labs? Because that could signifincantly
alter the statistics.

On Mon, Jul 4, 2011 at 7:10 AM, Nicolas Limare
<nicolas.limare at cmla.ens-cachan.fr> wrote:
>> Of course, statistics will be different on IPOL compared to the web
>> at large, but this is representative.
>
> For the first 6 months of 2011, the browsers used to see IPOL public
> pages (not counting demos) were (total 90550 page views 40188 visits):
>
> browser      pages  %      visits %
> Firefox 3.6  27275  30.12  10974  27.31
> Firefox 4.0  10146  11.20   4537  11.29
> IE 8.0       10040  11.09   4154  10.34
> Chrome 10.0   5648   6.24   2453   6.10
> Chrome 11.0   5084   5.61   2072   5.16
> Chrome 9.0    3679   4.06   1634   4.07
> IE 7.0        3497   3.86   1525   3.79
> Safari 5.0    3406   3.76   2083   5.18
> Chrome 8.0    3094   3.42   1713   4.26
> IE 6.0        2991   3.30   1515   3.77
> Chrome 12.0   2704   2.99   1156   2.88
> Firefox 3.5   2660   2.94   1181   2.94
> IE 9.0        1642   1.81   532    1.32
> Firefox 3.0   1288   1.42   629    1.57
> Firefox 5.0    976   1.08   480    1.19
>
> I think this data is more relevant than statistics for the whoel
> web. We can see that many people use the slightly outdated Firefox
> 3.6. This probably is because they are using a Linux distribution,
> which discourages upgrading yourself a single software
> version. Firefox 3.6 is shipped with Ubuntu versions 8.04 ~ 10.10.
>
> Another interesting number: 73.9% of the IPOL visitors have a PDF
> plugin.
>
>> > Regarding the choice, I think we should use something that has some
>> > future. And SVG is the way to go. Old browsers will disappear sooner
>> > or later, maybe we could just add a fallback option for that browsers.
>> > Is this possible?
>>
>> The statistics above show that IE9 adoption is unfortunately slow, it
>> doesn't look like IE8 is disappearing any time soon.  I would say PDF
>> has a future, and it is to continue to represent printed pages.  SVG
>> is undeniably more appropriate for the web.
>
> I think SVG will be the best solution, some day when old browsers have
> disappeared like dinosaurs have. For this reason, and to anticipate
> this bright future, all programs with a vector output should produce
> SVG files.
>
> But meanwhile, we need a solution to show vector results to our
> visitors, including the 20% of them still using IE <=8.0
>
>> I do like the idea of detecting old browsers and going with a
>> fallback.  Maybe the demo system could first determine the browser,
>> then set an "SVG supported" flag if the browser is known to support
>> SVG.  The demo would generate an SVG, and if the "SVG supported" flag
>> is not set, use for example ImageMagick's "convert" program to
>> rasterize to PNG.  The results page would then show depending on the
>> flag either the PNG or the SVG as an embedded SVG object.
>
> I think we don't need to detect and handle SGV support. It seems that
> with the <object> syntax we can display a PNG file id the browser
> doesn't support SVG.
> -> http://tavmjong.free.fr/INKSCAPE/MANUAL/html/Web-Use.html#Web-Use-Object
>
> I don't want to spend time doing web development, browser detection
> and javascript hacking[*], I prefer to work on, well, image processing
> code :) So, it the SVG+PNG fallback solution works well, we only need
> to add a generic svg-png conversion tool in the demo library, and use
> the <object> syntax for dual support in all our templates. Once 95% of
> the browsers support SVG, we can drop the PNG fallback.
>
> @miguel: could you add the SVG+PNG solution to your test page?
>
> Finally, even it IE8 users can see a PNG rendering of the svg image,
> they might want to download/edit a vector file. And here comes again the
> question, which format should be available for *download*? Which
> solutions are available on the desktop to view/edit vector files?
>
> If viewing is the only requirement, I think PDF is the good choice,
> because PDF readers are available everywhere. For editing, the
> Wikipedia comparison[1] tells me that all the major vector editors
> support SVG import, while some of them can't read PS/EPS/PDF.
> And lots of SVG viewers are available[2]. So maybe we can restrict
> ourself to SVG (simpler, less work, less maintenance) and hint at some
> software solutions, the same way we mention VRML readers for 3D data.
>
> [1] http://en.wikipedia.org/wiki/Comparison_of_vector_graphics_editors#File_format_support
> [2] http://en.wikipedia.org/wiki/Scalable_Vector_Graphics#Software_and_support_in_applications
> [*] all this web hacking is utterly unscientific, full of heuristics,
>    kludges, multi-layered partial solutions and undocumented bugs
>    turned features in a perpetually changing environment, and never
>    provides the satisfaction to obtain, even after long hours (days...)
>    of work, a solution that "just works"...
>
> --
> Nicolas LIMARE - CMLA - ENS Cachan    http://www.cmla.ens-cachan.fr/~limare/
> IPOL - image processing on line                          http://www.ipol.im/
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk4RkZIACgkQvviFAPpCP0/yxACfZE3HUaK8RjKRKyyPk5Zs7Dst
> SYcAn3PCjE4RCJZ+qizpPPz2MU7G/urC
> =3PPa
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> discuss mailing list
> discuss at list.ipol.im
> http://tools.ipol.im/mailman/listinfo/discuss
>