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.neum...@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-li...@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@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@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@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@lists.osgeo.org
List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
