[Qgis-developer] many SVG symbols disappeared

Fri Jun 7 18:49:51 PDT 2013

Hi !

So I've been working a little bit about that "deprecated folder" idea.
It's not ready yet, but I have some questions since I'm not familiar at all
with QgsProjectFileTransform nor with how SVG search paths work.

https://github.com/olivierdalang/Quantum-GIS/tree/SvgLibraryRetroCompatibility

*Here's what it does :*

1. Installation
It creates a new "svg_deprecated" folder containing all original 1.8's
symbols (alongside the normal "svg" folder, right in the installation root)

2. Project file conversion
In the QgsProjectFileTransform::transform1800to1900() method, it updates
the svg paths.
- if the path starts with a "/" (which seems to correspond to the svg
folder path), it prepends "QGIS_PREFIX_PATH/svg_deprecated"
- if not, it does nothing (since it's an absolute path)

*Questions :*

A. Is it always right that a path starting with a "/" is a file inside the
QGIS's svg folder ? (I never used SVGs search paths, if such a thing exists
in 1.8)
B. Is it okay to refer to the deprecated folder using an absolute path (
starting with QGIS_PREFIX_PATH ) ? I tried to prepend "/../svg_deprecated"
instead, but with no success... (using absolute path has the major
disadvantage of making the project file unportable). Any idea ?
C. The file paths for SVGs in the print composer are absolute... So they
still link to the 1.8 installation's svg folder. This works, but only until
the user uninstalls 1.8... Is that OK ?
D. Are there other places where SVGs from the library can appear in QGIS
1.8's projects ? (I've thought of SvgMarker, SVGFill and as images in the
print composer)

(E: is it better to already open a pull request for this kind of questions,
even if the branch is not ready to merge ?)

Thanks !

2013/5/15 Larry Shaffer <larrys at dakotacarto.com>

> Hi,
>
> On Wed, May 15, 2013 at 11:26 AM, John C. Tull <jctull at gmail.com> wrote:
>
>> Hi everyone,
>>
>> On May 7, 2013, at 1:42 AM, Duarte Carreira <DCarreira at edia.pt> wrote:
>>
>> > If we can get hold of the old symbology lib than that's fine by me. But
>> please don't make us and others rebuild their entire organization's
>> cartography just because you don't like the symbols.
>> >
>> > Thanks,
>> > Duarte
>>
>> An option to get the old symbols should suffice, right? Instructions on
>> what needs to be done with these symbols for each platform might also be
>> helpful.
>>
>
> Well, even though I agree with the new changes, it will be a harsh
> situation for those who have used the deprecated ones in their projects.
> And, kind of rude (from the users standpoint) to force the change and
> require a manual rebuild of existing projects.
>
> There are still some issues regarding the new symbol setup:
>
> 1) IMO, the deprecation of many symbols is fine, if they are moved to a
> 'deprecated' folder. Such a folder may or may not be part of the SVG search
> paths, but still in source and installed. Then, just like when you move or
> restructure a web site, create some path rewrite rules that will
> auto-update a <2.0 project and rewrite the deprecated SVG paths to the
> deprecated SVGs folder.
>
> This could remove the deprecated SVGs from the selector interface, but not
> break existing projects. When user goes to work with the symbol, the
> correct path is visible, but they can only select new-style SVGs for which
> to update the symbol, unless they specifically browse to the deprecated
> folder and link to a deprecated one again.
>
> I think such an approach will keep good karma with the user community.
>
> 2) Many of the new symbols are white as default. This is probably so they
> work well on top of a colored background when layered. However, this makes
> them very difficult to preview (especially on Mac). Either the widget view
> needs to have a medium gray background, or the default color for those SVGs
> should be gray (or maybe black, but gray would work better). This assumes
> that all those SVGs have color parameters that can just be changed later.
>
> 3) The new SVG backgrounds for labels do not yet support such 'layered'
> symbols. Currently only a single SVG can be used. There needs to be a
> decent selection of background SVGs for labels (e.g. road shields) that do
> not require layering. Layering backgrounds may not be a good fit for
> labeling in the future either, since single SVGs with drop shadows already
> slow labeling down.
>
> Regards,
>
> Larry
>
>
>
>> > -----Mensagem original-----
>> > De: Tim Sutton [mailto:lists at linfiniti.com]
>> > Enviada: segunda-feira, 6 de Maio de 2013 21:56
>> > Para: Olivier Dalang
>> > Cc: Nathan Woodrow; qgis-developer; Giovanni Manghi; Duarte Carreira
>> > Assunto: Re: [Qgis-developer] many SVG symbols disappeared
>> >
>> > Hi
>> >
>> > On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang <
>> olivier.dalang at gmail.com> wrote:
>> >> I was asking that question on this thread :
>> >>
>> >> http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t
>> >> d5040508.html#a5046486
>> >>
>> >> Maybe I didn't emphasize enough on the deletion of symbols...
>> >>
>> >> IMO, the most elegant solution is to keep only the good-looking
>> >> symbols so we provide a simple and consistent library, and then to
>> >> provide a link on the website to download the unmodified 1.8 symbol
>> >> library in case one needs to keep full backwards compatibility (it's
>> >> quite easy to install : you just have to replace the SVG folder in
>> your installation folder).
>> >>
>> >> The whole pull request already breaks backwards compatibility with all
>> >> other symbols, since by removing their background, the may become
>> >> unreadable on most of the maps...
>> >>
>> >> So if the priority is the keep old projects looking the same rather
>> >> than having a clean and consistent library, the best is not to change
>> >> the svg library at all.
>> >>
>> >> (just as an illustration, do you really think it's pertinent to keep
>> >> this in the library ? :
>> >> https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye
>> >> rs.png
>> >> )
>> >>
>>
>> I use that symbol all the time! /sarcasm
>>
>> > Yeah that ain't pretty...
>> >
>> > Personally I like Oliver's patch and I think we should clean up house
>> for 2.0. Keeping compatibility is useful but most of my project files from
>> 1.8 are already broken to some degree and I would prefer we do all the big
>> changes in 2.0 and then become more conservative in subsequent 2.x releases.
>> >
>>
>> +1
>>
>> _______________________________________________
>> Qgis-developer mailing list
>> Qgis-developer at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>>
>
>
> _______________________________________________
> Qgis-developer mailing list
> Qgis-developer at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/qgis-developer
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130608/5c0d11b3/attachment.html>