User talk:JoKalliauer/SVG test suites

request for Feedback

Because of an message of @AntiCompositeNumber: on User:Glrx talkpage, I decided to check 3 SVG-test-suites:

1. The official #W3C_SVG_1.1_test_suite
2. The imho most sophisticated #ReSVG-Test-suite
3. The featured svg-images on commons from Category:Featured_pictures_on_Wikimedia_Commons_-_vector

and partially some others.

client-side rendering

Currently only svg2png-converters are reviewed, so the test does currently not say anything about client side rendering phab:T5593. Server-side Rendering has the advantage of uniform rendering, and low security-risks for wikipedia-readers, and reduced computational costs on client-side. (That should be discussed separately)

realistic Renderer

I think the possible render are:

1. Chromium/Firefox
2. librsvg
3. resvg
4. Inkscape
5. batik

comments on renderer

1. Using server-side browser-rendering (e.g. Chromium) might be a possibility see example, however they are not optimized for png-creation. (Installation will be difficult and be problematic similar to this comment on resvg by User:MichaelSchoenitzer, or comments on updates by User:MMuhlenhoff_(WMF))
2. librsvg is the current, and has the advantage of that files are optimiced for librsvg-bugs
3. resvg might be imho the most promising renderer
4. When I started to work on SVGs, I liked Inkscape much as a renderer, since I use it for editing, however we do not want Inkscape-files, that only work in Inkscape, on Commons, we want SVG-files, that can be edited by anyone, on commons. It is slow for small images.
5. batik crashes too often, it cannot be used alone, If it chrases we need to use another back-up-renderer as suggested by User:GDubuc_(WMF) on phab:T40010#5103695.

How to measure time

If a feature is not supported or imprecise, the renderer might be faster because of that, than others, how to put a fair time-penalty on that? If it crashes, it should be a larger penalty than just not suporting the feature, since it is difficult to find the reason, and the image is not slightly wrong it is not existing.

How important is time compared to correct rendering?

time-out-limit

There are hardly any files which end in an endless loop, they are considered as failed (no time-penalty).

There are some files which run render or crashes after several minutes:

• inkscape:
  • fails
    • after 7min 49.141sec:File:test_suite_resvg_e-feImage-015.svg
    • after 6min 56.771sek: File:test_suite_resvg_e-feImage-016.svg

they are considered as rendered/wrong/crashed (depending on the result) and the time is fully included (no time-out-limit).

90dpi vs 96dpi

That's might be the most common "bug" on Commons. 96dpi is the standard for almost all renderer, and will be also the default for the future-relesase librsvg 2.52. This change is independent on the renderer, dpi can be changed for librsvg,resvg,Inkscape,... (also this should be discussed separately) . However this change should imho be done, also it breaks files (to much transparent border), since 96dpi is the standard for several years now.

bugs

The number of files to check is imho so overwhelming, that it is difficult to distinguish relevant bugs (e.g. supporting textPath) from the irrelevant bugs (e.g. blocked User:JoKalliauer/IllegalSVGPattern). Some bugs might have an easy lossless workaround (e.g. by https://svgworkaroundbot.toolforge.org/ ) and that's imho also something to consider.

---

I thought I start asking for feedback before further files get marked as duplicates (e.g. File:Mahuri_rendersvg.png), and I upload more 1000s of files, which can't be checked anymore.  — Johannes Kalliauer - Talk | Contributions 19:10, 13 April 2021 (UTC)