[Development] Version-controlling the SVGs of built-in icons

[Edward Welbourne]

On 18/06/2021 13:28, Edward Welbourne wrote:
>> The very fact that we're generating PNGs at different resolutions from
>> SVGs, when decent support for SVG would make that mostly redundant, says
>> we should be fixing our SVG support (and making it efficient enough to
>> make it practical to use it).
>>
>>       Eddy, who illustrates geometry essays with hand-written inline SVGs.

Giuseppe D'Angelo (18 June 2021 15:22) replied:
> Just to be The Grumpy One, this is:
>
> 1) an immense task given QtSVG is fundamentally unmaintained;

Indeed - step one in fixing our SVG support would be finding someone
willing (nay, enthusiastic) and able to take over maintaining QtSVG.

> 2) possibly an artistic anti-goal, given that artists want
>
> * use of full SVG profile and not just tiny/basic profile (=
>   implementation nightmare)
>
> * full control over SVG rendering, something hard to guarantee;
>
> * (related) not to rebuild+run the application after changing a SVG see
> if there's something wrong in Qt's rasterized results;
>
> * control over *lower* resolutions where one typically retouches the
>   pre-rasterized results;
>
> 3) a performance hit unless a SVG icon cache is put in place. Do we
>    already a working, cross-platform one?

All of which comes under the heading of what I'd call "decent support
for SVG".  As an author who routinely uses SVGs for illustrations, I've
had occasion to try QtSVG out on diagrams I've written - and found the
results embarrassingly underwhelming.  SVGTiny isn't really much use.
Fortunately for me, web browsers generally do better.

	Eddy.