<div dir="ltr">Hi,<br><br><div><div class="gmail_extra">On Wed, May 15, 2013 at 11:26 AM, John C. Tull <span dir="ltr"><<a href="mailto:jctull@gmail.com" target="_blank">jctull@gmail.com</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
On May 7, 2013, at 1:42 AM, Duarte Carreira <<a href="mailto:DCarreira@edia.pt">DCarreira@edia.pt</a>> wrote:<br>
<br>
> 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.<br>
><br>
> Thanks,<br>
> Duarte<br>
<br>
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.<br></blockquote><div><br></div><div>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.<br>
<br></div><div>There are still some issues regarding the new symbol setup:<br><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>I think such an approach will keep good karma with the user community.<br></div><div><br></div><div>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.<br>
<br></div><div>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.<br>
<br></div><div>Regards,<br><br></div><div>Larry<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> -----Mensagem original-----<br>
> De: Tim Sutton [mailto:<a href="mailto:lists@linfiniti.com">lists@linfiniti.com</a>]<br>
> Enviada: segunda-feira, 6 de Maio de 2013 21:56<br>
> Para: Olivier Dalang<br>
> Cc: Nathan Woodrow; qgis-developer; Giovanni Manghi; Duarte Carreira<br>
> Assunto: Re: [Qgis-developer] many SVG symbols disappeared<br>
><br>
> Hi<br>
><br>
> On Mon, May 6, 2013 at 2:31 PM, Olivier Dalang <<a href="mailto:olivier.dalang@gmail.com">olivier.dalang@gmail.com</a>> wrote:<br>
>> I was asking that question on this thread :<br>
>><br>
>> <a href="http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t" target="_blank">http://osgeo-org.1560.x6.nabble.com/Ideas-on-the-SVG-symbols-library-t</a><br>
>> d5040508.html#a5046486<br>
>><br>
>> Maybe I didn't emphasize enough on the deletion of symbols...<br>
>><br>
>> IMO, the most elegant solution is to keep only the good-looking<br>
>> symbols so we provide a simple and consistent library, and then to<br>
>> provide a link on the website to download the unmodified 1.8 symbol<br>
>> library in case one needs to keep full backwards compatibility (it's<br>
>> quite easy to install : you just have to replace the SVG folder in your installation folder).<br>
>><br>
>> The whole pull request already breaks backwards compatibility with all<br>
>> other symbols, since by removing their background, the may become<br>
>> unreadable on most of the maps...<br>
>><br>
>> So if the priority is the keep old projects looking the same rather<br>
>> than having a clean and consistent library, the best is not to change<br>
>> the svg library at all.<br>
>><br>
>> (just as an illustration, do you really think it's pertinent to keep<br>
>> this in the library ? :<br>
>> <a href="https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye" target="_blank">https://www.dropbox.com/s/jj9e852r08w5ysp/north-arrow_10_with_map_laye</a><br>
>> rs.png<br>
>> )<br>
>><br>
<br>
I use that symbol all the time! /sarcasm<br>
<br>
> Yeah that ain't pretty...<br>
><br>
> 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.<br>

><br>
<br>
+1<br>
<br>
_______________________________________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
</blockquote></div><br></div></div></div>