[Qgis-developer] SVG-Icons instead of PNGs?

2012-07-29 Thread Andreas Neumann
Regarding the discussion around the icons?

How about using SVG icons instead of fixed size png icons? That way one
could easily scale the icon sizes on different devices to the preferred
scale and taste of the user.

Are there any technical reasons for using PNGs instead of SVGs? I
believe the source of the icons is SVG anyway?

For my own in house python plugins I always use the SVG icons.

Andreas
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-30 Thread Robert Szczepanek

Hi Andreas,

On 29.07.2012 12:22, Andreas Neumann wrote:

Regarding the discussion around the icons?

How about using SVG icons instead of fixed size png icons? That way one
could easily scale the icon sizes on different devices to the preferred
scale and taste of the user.


From my test and literature I found that simple vector scaling for 
small size icons (16x16 - 24-24) is not recommended. For higher images 
blur effect is not so visible and important.



Are there any technical reasons for using PNGs instead of SVGs? I
believe the source of the icons is SVG anyway?

For my own in house python plugins I always use the SVG icons.


The main technical reason was image quality. We decided to use already 
rendered images in "native resolution". I know it sounds stupid in 
Scalable Vector ... context, but that's the reality.
Whole version 0.1 of GIS icons was designed in just one SVG file. In 
version 0.2 I save them in separate files. So most of the icons is at 
the moment available as one file per icon.


regards,
Robert


Andreas
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-31 Thread Andreas Neumann

Hi Robert,

Thanks for the reply.

Do you have a side-by-side comparison of SVG vs. png and the rendering 
quality somewhere? I wonder if this is still an issue and if it is - how 
much of a problem it really is.


Having just one icon size instead of n different sizes also has a lot 
of advantages. Think about all the new high-dpi devices. These would 
benefit a lot from SVG instead of PNG.


Andreas

On Tue, 31 Jul 2012 00:53:40 +0200, Robert Szczepanek wrote:

Hi Andreas,

On 29.07.2012 12:22, Andreas Neumann wrote:

Regarding the discussion around the icons?

How about using SVG icons instead of fixed size png icons? That way 
one
could easily scale the icon sizes on different devices to the 
preferred

scale and taste of the user.


From my test and literature I found that simple vector scaling for
small size icons (16x16 - 24-24) is not recommended. For higher 
images

blur effect is not so visible and important.


Are there any technical reasons for using PNGs instead of SVGs? I
believe the source of the icons is SVG anyway?

For my own in house python plugins I always use the SVG icons.


The main technical reason was image quality. We decided to use
already rendered images in "native resolution". I know it sounds
stupid in Scalable Vector ... context, but that's the reality.
Whole version 0.1 of GIS icons was designed in just one SVG file. In
version 0.2 I save them in separate files. So most of the icons is at
the moment available as one file per icon.

regards,
Robert


Andreas
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer



--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-31 Thread Robert Szczepanek

Hi Andreas,

I made fast SVG downscaling test. Rendered with Inkscape.
Second column is shifted vertically by 0,5px.
As you can see main problem is "travelling blur" effect. Perhaps there 
are some smart renderers to overcome this.


I would also like to have just one SVG file...
Robert

On 31.07.2012 10:30, Andreas Neumann wrote:

Hi Robert,

Thanks for the reply.

Do you have a side-by-side comparison of SVG vs. png and the rendering
quality somewhere? I wonder if this is still an issue and if it is - how
much of a problem it really is.

Having just one icon size instead of n different sizes also has a lot of
advantages. Think about all the new high-dpi devices. These would
benefit a lot from SVG instead of PNG.

Andreas

On Tue, 31 Jul 2012 00:53:40 +0200, Robert Szczepanek wrote:

Hi Andreas,

On 29.07.2012 12:22, Andreas Neumann wrote:

Regarding the discussion around the icons?

How about using SVG icons instead of fixed size png icons? That way one
could easily scale the icon sizes on different devices to the preferred
scale and taste of the user.


From my test and literature I found that simple vector scaling for
small size icons (16x16 - 24-24) is not recommended. For higher images
blur effect is not so visible and important.


Are there any technical reasons for using PNGs instead of SVGs? I
believe the source of the icons is SVG anyway?

For my own in house python plugins I always use the SVG icons.


The main technical reason was image quality. We decided to use
already rendered images in "native resolution". I know it sounds
stupid in Scalable Vector ... context, but that's the reality.
Whole version 0.1 of GIS icons was designed in just one SVG file. In
version 0.2 I save them in separate files. So most of the icons is at
the moment available as one file per icon.

regards,
Robert


Andreas
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer





<><>___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-31 Thread G. Allegri
Scaling SVG in Inkscapes is known to be problematic. Are you sure that this
applies to Qt SVG scaling too?

giovanni

2012/7/31 Robert Szczepanek 

> Hi Andreas,
>
> I made fast SVG downscaling test. Rendered with Inkscape.
> Second column is shifted vertically by 0,5px.
> As you can see main problem is "travelling blur" effect. Perhaps there are
> some smart renderers to overcome this.
>
> I would also like to have just one SVG file...
> Robert
>
>
> On 31.07.2012 10:30, Andreas Neumann wrote:
>
>> Hi Robert,
>>
>> Thanks for the reply.
>>
>> Do you have a side-by-side comparison of SVG vs. png and the rendering
>> quality somewhere? I wonder if this is still an issue and if it is - how
>> much of a problem it really is.
>>
>> Having just one icon size instead of n different sizes also has a lot of
>> advantages. Think about all the new high-dpi devices. These would
>> benefit a lot from SVG instead of PNG.
>>
>> Andreas
>>
>> On Tue, 31 Jul 2012 00:53:40 +0200, Robert Szczepanek wrote:
>>
>>> Hi Andreas,
>>>
>>> On 29.07.2012 12:22, Andreas Neumann wrote:
>>>
 Regarding the discussion around the icons?

 How about using SVG icons instead of fixed size png icons? That way one
 could easily scale the icon sizes on different devices to the preferred
 scale and taste of the user.

>>>
>>> From my test and literature I found that simple vector scaling for
>>> small size icons (16x16 - 24-24) is not recommended. For higher images
>>> blur effect is not so visible and important.
>>>
>>>  Are there any technical reasons for using PNGs instead of SVGs? I
 believe the source of the icons is SVG anyway?

 For my own in house python plugins I always use the SVG icons.

>>>
>>> The main technical reason was image quality. We decided to use
>>> already rendered images in "native resolution". I know it sounds
>>> stupid in Scalable Vector ... context, but that's the reality.
>>> Whole version 0.1 of GIS icons was designed in just one SVG file. In
>>> version 0.2 I save them in separate files. So most of the icons is at
>>> the moment available as one file per icon.
>>>
>>> regards,
>>> Robert
>>>
>>>  Andreas
 __**_
 Qgis-developer mailing list
 Qgis-developer@lists.osgeo.org
 http://lists.osgeo.org/**mailman/listinfo/qgis-**developer


>>
>
> ___
> Qgis-developer mailing list
> Qgis-developer@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-31 Thread Andreas Neumann
I think it would be worth a try to use the SVG symbols directly - or at 
least offer the option to use them.


Andreas

On Tue, 31 Jul 2012 12:38:07 +0200, G. Allegri wrote:
Scaling SVG in Inkscapes is known to be problematic. Are you sure 
that

this applies to Qt SVG scaling too?

giovanni

2012/7/31 Robert Szczepanek


Hi Andreas,

I made fast SVG downscaling test. Rendered with Inkscape.
Second column is shifted vertically by 0,5px.
As you can see main problem is "travelling blur" effect. Perhaps
there are some smart renderers to overcome this.

I would also like to have just one SVG file...
Robert

On 31.07.2012 10 [3]:30, Andreas Neumann wrote:


Hi Robert,

Thanks for the reply.

Do you have a side-by-side comparison of SVG vs. png and the
rendering
quality somewhere? I wonder if this is still an issue and if it
is - how
much of a problem it really is.

Having just one icon size instead of n different sizes also has a
lot of
advantages. Think about all the new high-dpi devices. These would
benefit a lot from SVG instead of PNG.

Andreas

On Tue, 31 Jul 2012 00:53:40 +0200, Robert Szczepanek wrote:


Hi Andreas,

On 29.07.2012 12:22, Andreas Neumann wrote:


Regarding the discussion around the icons?

How about using SVG icons instead of fixed size png icons?
That way one
could easily scale the icon sizes on different devices to the
preferred
scale and taste of the user.


From my test and literature I found that simple vector scaling
for
small size icons (16x16 - 24-24) is not recommended. For higher
images
blur effect is not so visible and important.


Are there any technical reasons for using PNGs instead of
SVGs? I
believe the source of the icons is SVG anyway?

For my own in house python plugins I always use the SVG
icons.


The main technical reason was image quality. We decided to use
already rendered images in "native resolution". I know it
sounds
stupid in Scalable Vector ... context, but that's the reality.
Whole version 0.1 of GIS icons was designed in just one SVG
file. In
version 0.2 I save them in separate files. So most of the icons
is at
the moment available as one file per icon.

regards,
Robert


___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org [4]
http://lists.osgeo.org/mailman/listinfo/qgis-developer [5]




Links:
--
[1] mailto:Qgis-developer@lists.osgeo.org
[2] http://lists.osgeo.org/mailman/listinfo/qgis-developer
[3] http://webmail.carto.net/tel:31.07.2012%2010
[4] mailto:Qgis-developer@lists.osgeo.org
[5] http://lists.osgeo.org/mailman/listinfo/qgis-developer
[6] mailto:rob...@szczepanek.pl


--
--
Andreas Neumann
Böschacherstrasse 10A
8624 Grüt (Gossau ZH)
Switzerland
___
Qgis-developer mailing list
Qgis-developer@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/qgis-developer


Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-07-31 Thread Larry Shaffer
On Tue, Jul 31, 2012 at 5:49 AM, Andreas Neumann  wrote:
> I think it would be worth a try to use the SVG symbols directly - or at
> least offer the option to use them.

Hi Andreas, Giovanni, Robert and anyone else interested,

I have committed to master branch a preliminary test for SVG icon
scaling based upon Robert's icons. Ideally it should be tested on as
many platforms and devices as possible [0]. To test, please pull
latest master branch and compile, or wait for the nightly to come out.


Here's what I've done:

- Several PNG icons were switched out with SVG counterparts to test Qt
scaling on different platforms
- Added SVG icons to Default theme that are comprised of the regular
PNG embedded within
- Added SVG icons to GIS theme, mostly @ 32x32 and one @ 48x48 (note:
commit message is incorrect about 24x24)
- Testing with the supplied GIS theme allows for contrasting against
other similarly designed, preexisting PNG icons.

GIS theme Icons to test (with document, or page, size and description noted):

mActionPanToSelected.svg <- @32x32 (Pan Map to Selection tool)
mActionRotateLabel.svg <- @32x32 (Advanced labeling Rotate Label tool)
mActionSelectPolygon.svg <- @32x32 (Select Feature by Polygon tool)
mActionSplitFeatures.svg <- @48x48 (Split Feature tool)


To test:

1) Set your icon theme to Default. View whether each test icon looks
as it did before. This will verify whether SVG with embedded PNGs of
the original icons works with your version of Qt. (QIcon notes Qt 4.2
or > icon engine supports SVG.) If we wanted to move to all SVG source
files right now, this would provide an intermediate step for existing
PNGs that don't have SVG counterparts.

2) Switch to GIS theme and individually test the above noted icons at
the 16, 24, and 32 sizes.

- Test mActionPanToSelected by viewing in main menu, and as a toolbar button
- To test mActionRotateLabel, you will need a vector layer in edit
mode, and with data-defined rotation column. View toolbar button.
- Test mActionSelectPolygon by viewing it in the popup menu, main
menu, and as a toolbar button.
- To test mActionSplitFeatures, you will need a polygon vector layer
in edit mode, with two features selected. Also view in Edit menu
- Compare your results against mine [1]. Please share screen snaps of
any different findings.


My results on Mac, with Qt 4.8.1 and 4.8.2 [1]:

- Overall IMHO Qt down-scaling is better than that of PNG.
- SVG document size of 32x32 scaled to 24x24 (75%) showed some blurring.
- Qt will _not_ up-scale SVG toolbar buttons when setting the
toolbar's icon size, without doing so preprocessing first. SVG sources
used by the icon engine appear to be rasterized at their document
size, then later only scaled down when the icon size of the toolbar is
adjusted (just like PNGs). So, starting with an appropriate 'largest'
size for the SVG source seems to be key.
- Icons were pulled from OSGeo SVN repository and up-scaled in
Inkscape. SVG output from Illustrator CS5 could not be read.


Preliminary Conclusion

I think any single icon set, moving forward towards a 2.0 solution,
should be in the SVG format at 48x48 document size.

Marco B. has an issue ticket request for 48x48 size icons for use in
the QGIS mobile interface [2]. I think 48x48 document size scaled to
16x16 or 24x24 looks good and sharp, with only slight blurring at
32x32. So, 48x48 seems to work well for Qt scaling and addresses (at a
minimum) the mobile interface.


[0] 
https://github.com/qgis/Quantum-GIS/commit/738c1f36fe9bdcbeebce36014ff913dc091705fb
[1] http://dl.dropbox.com/u/4058089/qgis/svg-scaling-test.zip
[2] http://trac.osgeo.org/osgeo/ticket/846


Regards,

Larry


> Andreas
>
> On Tue, 31 Jul 2012 12:38:07 +0200, G. Allegri wrote:
>>
>> Scaling SVG in Inkscapes is known to be problematic. Are you sure that
>> this applies to Qt SVG scaling too?
>>
>> giovanni
>>
>> 2012/7/31 Robert Szczepanek
>>
>>> Hi Andreas,
>>>
>>> I made fast SVG downscaling test. Rendered with Inkscape.
>>> Second column is shifted vertically by 0,5px.
>>> As you can see main problem is "travelling blur" effect. Perhaps
>>> there are some smart renderers to overcome this.
>>>
>>> I would also like to have just one SVG file...
>>> Robert
>>>
>>> On 31.07.2012 10 [3]:30, Andreas Neumann wrote:
>>>
 Hi Robert,

 Thanks for the reply.

 Do you have a side-by-side comparison of SVG vs. png and the
 rendering
 quality somewhere? I wonder if this is still an issue and if it
 is - how
 much of a problem it really is.

 Having just one icon size instead of n different sizes also has a
 lot of
 advantages. Think about all the new high-dpi devices. These would
 benefit a lot from SVG instead of PNG.

 Andreas

 On Tue, 31 Jul 2012 00:53:40 +0200, Robert Szczepanek wrote:

> Hi Andreas,
>
> On 29.07.2012 12:22, Andreas Neumann wrote:
>
>> Regarding the discussion around the icons?
>>
>> How about using

Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-08-01 Thread Larry Shaffer
Hi,

Well, after lots more testing and head-scratching, I came to realize
the QSvgIconEngine plugin was not being bundled with the Mac builds.
This was why SVG icons were being rendered but scaled like rasters.
This skewed my previous SVG icon Qt scaling test. Sorry for that. I've
included the plugin for Mac bundling [0].

This changes my previous results in two ways:

- I no longer see any issues with down- or up-scaling with any of the
test SVG icons on Mac.
- Robert's 24x24 SVG icons scale OK to 32x32. I have not tested the
scaling up to 48x48. Since it is a straight 200% I expect it will
render even better.

To test up-scaling, I have reverted mActionPanToSelected.svg back to
Robert's original 24x24 design [1]. Set the icon preference to 32x32
to test.

Since my testing on Mac was not up-scaling SVG icons before I did not
notice the issue with the Default theme's switched-out SVGs with
embedded rasters. They are now up-scaling very poorly to 32x32, where
such embedded rasters were originally PNGs at 24x24
(mActionPanToSelected and mActionRotateLabel).

Second Test Conclusions

- 48x48 base icon size would probably still be ideal as a single icon
set base size, since it could be rasterized at that size (or lower) if
PNGs are required for something. However, 24x24 base size may work
well when scaled and rasterized (further tests needed here).

- Embedding rasters in SVGs (for having Default theme available while
moving to an SVG-only theme) is not a good idea. The rasters up-scale
poorly. I suggest a clean move to a SVG-only set, if QSvgIconEngine is
to be leveraged to solve scaling problems for core icons. PNGs could
still be supported once the getThemeIcon() method is removed, since it
currently chooses the icon based upon file name and extension.


[0] 
https://github.com/qgis/Quantum-GIS/commit/24eb02a99022e31b740f902204727cf1f25973ca
[1] 
https://github.com/qgis/Quantum-GIS/commit/ba575794f8803c80f9defe59ba1a40020ebd2834

Regards,

Larry


On Tue, Jul 31, 2012 at 3:49 PM, Larry Shaffer  wrote:
> On Tue, Jul 31, 2012 at 5:49 AM, Andreas Neumann  wrote:
>> I think it would be worth a try to use the SVG symbols directly - or at
>> least offer the option to use them.
>
> Hi Andreas, Giovanni, Robert and anyone else interested,
>
> I have committed to master branch a preliminary test for SVG icon
> scaling based upon Robert's icons. Ideally it should be tested on as
> many platforms and devices as possible [0]. To test, please pull
> latest master branch and compile, or wait for the nightly to come out.
>
>
> Here's what I've done:
>
> - Several PNG icons were switched out with SVG counterparts to test Qt
> scaling on different platforms
> - Added SVG icons to Default theme that are comprised of the regular
> PNG embedded within
> - Added SVG icons to GIS theme, mostly @ 32x32 and one @ 48x48 (note:
> commit message is incorrect about 24x24)
> - Testing with the supplied GIS theme allows for contrasting against
> other similarly designed, preexisting PNG icons.
>
> GIS theme Icons to test (with document, or page, size and description noted):
>
> mActionPanToSelected.svg <- @32x32 (Pan Map to Selection tool)
> mActionRotateLabel.svg <- @32x32 (Advanced labeling Rotate Label tool)
> mActionSelectPolygon.svg <- @32x32 (Select Feature by Polygon tool)
> mActionSplitFeatures.svg <- @48x48 (Split Feature tool)
>
>
> To test:
>
> 1) Set your icon theme to Default. View whether each test icon looks
> as it did before. This will verify whether SVG with embedded PNGs of
> the original icons works with your version of Qt. (QIcon notes Qt 4.2
> or > icon engine supports SVG.) If we wanted to move to all SVG source
> files right now, this would provide an intermediate step for existing
> PNGs that don't have SVG counterparts.
>
> 2) Switch to GIS theme and individually test the above noted icons at
> the 16, 24, and 32 sizes.
>
> - Test mActionPanToSelected by viewing in main menu, and as a toolbar button
> - To test mActionRotateLabel, you will need a vector layer in edit
> mode, and with data-defined rotation column. View toolbar button.
> - Test mActionSelectPolygon by viewing it in the popup menu, main
> menu, and as a toolbar button.
> - To test mActionSplitFeatures, you will need a polygon vector layer
> in edit mode, with two features selected. Also view in Edit menu
> - Compare your results against mine [1]. Please share screen snaps of
> any different findings.
>
>
> My results on Mac, with Qt 4.8.1 and 4.8.2 [1]:
>
> - Overall IMHO Qt down-scaling is better than that of PNG.
> - SVG document size of 32x32 scaled to 24x24 (75%) showed some blurring.
> - Qt will _not_ up-scale SVG toolbar buttons when setting the
> toolbar's icon size, without doing so preprocessing first. SVG sources
> used by the icon engine appear to be rasterized at their document
> size, then later only scaled down when the icon size of the toolbar is
> adjusted (just like PNGs). So, starting with an appropriate 'largest'
> size for the 

Re: [Qgis-developer] SVG-Icons instead of PNGs?

2012-08-01 Thread John C. Tull
Hi Larry,

I took a look yesterday and was confused to find my interpretation of the 
scaling quality to be a little different than what you reported on OSX. With 
your update today, the pan select icon looks very good at various scales. I'm 
glad to see that the svg scaling is working good within qt and on OSX now.

Cheers,
John

On Aug 1, 2012, at 9:56 AM, Larry Shaffer  wrote:

> Hi,
> 
> Well, after lots more testing and head-scratching, I came to realize
> the QSvgIconEngine plugin was not being bundled with the Mac builds.
> This was why SVG icons were being rendered but scaled like rasters.
> This skewed my previous SVG icon Qt scaling test. Sorry for that. I've
> included the plugin for Mac bundling [0].
> 
> This changes my previous results in two ways:
> 
> - I no longer see any issues with down- or up-scaling with any of the
> test SVG icons on Mac.
> - Robert's 24x24 SVG icons scale OK to 32x32. I have not tested the
> scaling up to 48x48. Since it is a straight 200% I expect it will
> render even better.
> 
> To test up-scaling, I have reverted mActionPanToSelected.svg back to
> Robert's original 24x24 design [1]. Set the icon preference to 32x32
> to test.
> 
> Since my testing on Mac was not up-scaling SVG icons before I did not
> notice the issue with the Default theme's switched-out SVGs with
> embedded rasters. They are now up-scaling very poorly to 32x32, where
> such embedded rasters were originally PNGs at 24x24
> (mActionPanToSelected and mActionRotateLabel).
> 
> Second Test Conclusions
> 
> - 48x48 base icon size would probably still be ideal as a single icon
> set base size, since it could be rasterized at that size (or lower) if
> PNGs are required for something. However, 24x24 base size may work
> well when scaled and rasterized (further tests needed here).
> 
> - Embedding rasters in SVGs (for having Default theme available while
> moving to an SVG-only theme) is not a good idea. The rasters up-scale
> poorly. I suggest a clean move to a SVG-only set, if QSvgIconEngine is
> to be leveraged to solve scaling problems for core icons. PNGs could
> still be supported once the getThemeIcon() method is removed, since it
> currently chooses the icon based upon file name and extension.
> 
> 
> [0] 
> https://github.com/qgis/Quantum-GIS/commit/24eb02a99022e31b740f902204727cf1f25973ca
> [1] 
> https://github.com/qgis/Quantum-GIS/commit/ba575794f8803c80f9defe59ba1a40020ebd2834
> 
> Regards,
> 
> Larry
> 
> 
> On Tue, Jul 31, 2012 at 3:49 PM, Larry Shaffer  wrote:
>> On Tue, Jul 31, 2012 at 5:49 AM, Andreas Neumann  wrote:
>>> I think it would be worth a try to use the SVG symbols directly - or at
>>> least offer the option to use them.
>> 
>> Hi Andreas, Giovanni, Robert and anyone else interested,
>> 
>> I have committed to master branch a preliminary test for SVG icon
>> scaling based upon Robert's icons. Ideally it should be tested on as
>> many platforms and devices as possible [0]. To test, please pull
>> latest master branch and compile, or wait for the nightly to come out.
>> 
>> 
>> Here's what I've done:
>> 
>> - Several PNG icons were switched out with SVG counterparts to test Qt
>> scaling on different platforms
>> - Added SVG icons to Default theme that are comprised of the regular
>> PNG embedded within
>> - Added SVG icons to GIS theme, mostly @ 32x32 and one @ 48x48 (note:
>> commit message is incorrect about 24x24)
>> - Testing with the supplied GIS theme allows for contrasting against
>> other similarly designed, preexisting PNG icons.
>> 
>> GIS theme Icons to test (with document, or page, size and description noted):
>> 
>> mActionPanToSelected.svg <- @32x32 (Pan Map to Selection tool)
>> mActionRotateLabel.svg <- @32x32 (Advanced labeling Rotate Label tool)
>> mActionSelectPolygon.svg <- @32x32 (Select Feature by Polygon tool)
>> mActionSplitFeatures.svg <- @48x48 (Split Feature tool)
>> 
>> 
>> To test:
>> 
>> 1) Set your icon theme to Default. View whether each test icon looks
>> as it did before. This will verify whether SVG with embedded PNGs of
>> the original icons works with your version of Qt. (QIcon notes Qt 4.2
>> or > icon engine supports SVG.) If we wanted to move to all SVG source
>> files right now, this would provide an intermediate step for existing
>> PNGs that don't have SVG counterparts.
>> 
>> 2) Switch to GIS theme and individually test the above noted icons at
>> the 16, 24, and 32 sizes.
>> 
>> - Test mActionPanToSelected by viewing in main menu, and as a toolbar button
>> - To test mActionRotateLabel, you will need a vector layer in edit
>> mode, and with data-defined rotation column. View toolbar button.
>> - Test mActionSelectPolygon by viewing it in the popup menu, main
>> menu, and as a toolbar button.
>> - To test mActionSplitFeatures, you will need a polygon vector layer
>> in edit mode, with two features selected. Also view in Edit menu
>> - Compare your results against mine [1]. Please share screen snaps of
>> any different findings.
>> 
>