On Tuesday, 10 de January de 2012 05.13.57, Martin Holmes wrote: > When I moved to Qt (from Delphi), I was delighted to discover that > QImage supported SVG, because I'd been used to having to provide icon > sets in multiple resolutions just to enable users to change toolbar > sizes. SVG icons seemed a huge step forward, just as they do when you > discover that your desktop icons on Linux are SVG and are scalable. Now > it seems that the Qt team (or community, or whatever) are not interested > in maintaining this forward-looking feature. Perhaps this is because the > person or people who developed it are no longer involved, and no-one > else wants to take it on; if so, I'd expect it to be classified as > QXmlPatterns: > > Overall module state: Done > New maintainer required.
I've already explained why it's different. There is a replacement for SVG
functionality in WebKit, however big that module is. It's far more complete
and it supports a larger specification of SVG. QtSvg was designed and
documented to support SVG Tiny 1.2 and even then we know of a few
shortcomings.
QtXmlPatterns also chases after a standard or three, but unlike QtSvg, there
is no other replacement for it. The few shortcomings that exist are
documented.
By the way, the icons you see on Linux are often *not* the SVG versions of
them. True, they often start as SVG, but they are pre-rendered to a few
resolutions by the artists themselves. Often, they retouch the resulting PNGs
so that the details are clear at that resolution and unnecessary noise is
removed.
And one of the reasons why that started is *because* QtSvg was too limited.
Artists don't care about SVG Tiny 1.2. They design their icons the way they
like it and then we have developers and artists complaining that the QtSvg
rasterisation wasn't the expected output.
> However, it seems things have gone further than this. The decision to
> deprecate seems to be based on the contention that webkit can be used
> instead, but frankly I don't see how, and in any case, that's an
> enormous overhead to get simple functionality in QImage. If the
> objection is that QtSvg supports only SvgTiny, then let it by all means
> be renamed QtSvgTiny.
Renaming doesn't solve any of the problems. It only introduces more.
> We're all familiar with the argument that "if you want it to be
> available, write and maintain it yourself", and of course that's a valid
> response to any complaint like this in an open source project. But if
> someone steps up to maintain it, could we expect that its status would
> be changed and the deprecation undone?
Yes, definitely.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
