[Development] The dark side of QtSvg

[Guido Seifert]

> So my wonder is this: if the SVG rendering of QtWebKit/QtWebEngine is modern and solid, why not "extracting" it 
> from those monsters and place it into a brand new QtSvg ?

Very easy to ask for something like that. When do you start? 

> This would bring two advantages:1- applications that need to render SVG graphics can rely on a small footprint but 
> efficient QtSvg library2- QtWebEngine can be built without the SVG support (if needed) to reduce the library footprint. 
> Now it's all monolithic and on embedded systems with low memory availability, a 64MB library is a total killer.

This might be. However, if you follow this list, you will now and then read from a Digia developer: Not enough resources.
Very hard to argument against this. Apart from that, superficially your proposal sounds good, but it is a maintenance nightmare.
The Qt project has no real control over the webkit code. Modularizing a non trivial 3rd party product? Keeping it up-to-date?
Forget it. 

The only thing where I agree is that their proposal to use the webkit to render SVGs is ridiculous. I did it. On systems where 
the webkit stuff was needed and installed anyways. But even then it was a quite unwieldy solution. For systems with memory
restrictions.... 

Guido