[QGIS-Developer] SVG icons in QGIS

Tue Jul 28 01:53:29 PDT 2020

And in the SVG param primer, you can see examples of adjustable text in
<text/> elements (e.g. buttons, icons, etc.): 

https://www.w3.org/TR/SVGParamPrimer/#Examples 

Given that we already have the param mechanism in QGIS, it would fell
natural to extend it to text as well. 

And - if we really want it - I think there is a fair chance to get
Inkscape to implement SVG params as well. They also implemented some SVG
extensions that unfortunately didn't make it into the browser, because
the browser companies blocked them during the standardization process. 

It is one of the advantages of XML (and SVG in that respect), that you
can extend with your own extensions. 

Andreas 

On 2020-07-28 10:46, Andreas Neumann wrote:

> Hi RÃ©gis, 
> 
> In general - you are right - but the problem with standards it that they are often ignored. Browser developer companies (like Google) basically ignore 80% of the W3C standards and just implement what they want. I was involved with SVG standardization a decade ago  - and I have to say - it was a big disappointment to see what the big companies did with standards - even if it were their own employees who worked on the standards documents. 
> 
> The SVG param specification is in "working draft" stage - it is from W3C, not an invention by QGIS - but in my opinion, it is much easier to use than the i18n section that you quote. And I don't think it is implemented in any browser or authoring system (like Inkscape, Illustrator, etc.) 
> 
> See https://www.w3.org/TR/SVGParam/#AdaptTextToUse 
> 
> Adapt text in an icon or button is exactly a use case in the SVG param specification (working draft). 
> 
> Andreas 
> 
> On 2020-07-28 10:15, RÃ©gis Haubourg wrote: 
> 
> Hi,  
> I think we should better follow the standard for internationalizing instead of progressively making a proprietary format.  
> See https://www.w3.org/TR/SVGTiny12/i18n.html 
> Cheers! 
> 
> Le mar. 28 juil. 2020 Ã  09:57, Andreas Neumann <a.neumann at carto.net> a Ã©crit : 
> 
> Hi all, 
> 
> I am only loosely following this discussion. 
> 
> But about the internationalization: couldn't we use the same param - mechanism we already have for fill-color, stroke-color, opacity, etc. and extend it to the content of <text/> elements? 
> 
> That would solve internationalization and would also be usefuly for dynamic text in icons anyway - there might be some use cases for this even without internationalization. 
> 
> Just an idea, 
> 
> Andreas 
> 
> On 2020-07-28 02:39, Nyall Dawson wrote: 
> On Mon, 27 Jul 2020 at 21:57, Jonathan Moules
> <jonathan-lists at lightpear.com> wrote: 
> Hi List,
> 
> The more I look at the current SVG icons, the more I'm thinking it
> really needs some TLC (Tender Loving Care). As far as I can tell, icons
> are categorised by the directory they're in, so if you want an icon to
> appear in two categories, you put the icon in there twice... and so
> that's just what has happened! I suspect the current set has simply
> accreted over time. 
> For reference: I'm totally in agreement that we need to improve the
> DEFAULT set of svg files, and that the resource sharing plugin isn't
> the best solution here. It's a great solution for some use cases, but
> we need to improve the out-of-the-box experience in this regard and
> that means extending the default set.
> 
> My thoughts:
> * Move the svg's into a single directory. (Though would break any
> current projects symbology using them I guess?) 
> Yes -- we CAN'T do this. What we've got now has to stay, in its
> current structure, and without renaming.
> 
> * Use a metadata file to categorise them, so you get a list of
> categories as now and a single symbol can be in multiple categories. 
> We could potentially add tags to the svg files themselves to add this
> information.
> 
> * Add a search feature so the user can quickly find "museum" without
> having to guess where it has been categorised. 
> Big +1 to this. Especially if we also add search by tag support!
> 
> * Clean up the current symbols by removing duplicates. 
> Again, we can't do this without risking breaking people's existing
> projects (which is off-limits!)
> 
> * Add the font-awesome symbols (per my thread on the User List) to fill
> in the gaps and flesh out the collection. As a bonus, it comes with
> metadata for categories and search terms (YAML files).
> 
> * bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),
> etc would also work for finding that museum.
> 
> Thoughts? 
> Sounds good to me! To clarify -- are you volunteering to lead this effort?
> 
> Nyall
> 
> Cheers,
> Jonathan
> 
> _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer _______________________________________________
> QGIS-Developer mailing list
> QGIS-Developer at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer

 _______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer 

_______________________________________________
QGIS-Developer mailing list
QGIS-Developer at lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200728/9be2dcca/attachment-0001.html>