[QGIS-Developer] SVG icons in QGIS

[Andreas Neumann]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20200728/efc4f2f8/attachment.html>