<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /></head><body style='font-size: 10pt; font-family: Verdana,Geneva,sans-serif'>
<p>And in the SVG param primer, you can see examples of adjustable text in <text/> elements (e.g. buttons, icons, etc.):</p>
<p><a href="https://www.w3.org/TR/SVGParamPrimer/#Examples">https://www.w3.org/TR/SVGParamPrimer/#Examples</a></p>
<p>Given that we already have the param mechanism in QGIS, it would fell natural to extend it to text as well.</p>
<p>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.</p>
<p>It is one of the advantages of XML (and SVG in that respect), that you can extend with your own extensions.</p>
<p>Andreas</p>
<p id="reply-intro">On 2020-07-28 10:46, Andreas Neumann wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0">
<div id="replybody1">
<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">
<p>Hi Régis,</p>
<p>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.</p>
<p>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.)</p>
<p>See <a href="https://www.w3.org/TR/SVGParam/#AdaptTextToUse" target="_blank" rel="noopener noreferrer">https://www.w3.org/TR/SVGParam/#AdaptTextToUse</a></p>
<p>Adapt text in an icon or button is exactly a use case in the SVG param specification (working draft).</p>
<p>Andreas</p>
<p id="v1reply-intro">On 2020-07-28 10:15, Régis Haubourg wrote:</p>
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">
<div id="v1replybody1">
<div>
<div dir="auto">Hi,
<div dir="auto">I think we should better follow the standard for internationalizing instead of progressively making a proprietary format. </div>
<div dir="auto">See <a href="https://www.w3.org/TR/SVGTiny12/i18n.html" target="_blank" rel="noopener noreferrer">https://www.w3.org/TR/SVGTiny12/i18n.html</a></div>
<div dir="auto">Cheers!</div>
</div>
<br />
<div class="v1v1gmail_quote">
<div class="v1v1gmail_attr" dir="ltr">Le mar. 28 juil. 2020 à 09:57, Andreas Neumann <<a href="mailto:a.neumann@carto.net" rel="noreferrer">a.neumann@carto.net</a>> a écrit :</div>
<blockquote class="v1v1gmail_quote" style="margin: 0 0 0 .8ex; border-left: 1px #ccc solid; padding-left: 1ex;">
<div style="font-size: 10pt; font-family: Verdana,Geneva,sans-serif;">
<p>Hi all,</p>
<p>I am only loosely following this discussion.</p>
<p>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?</p>
<p>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.</p>
<p>Just an idea,</p>
<p>Andreas</p>
<p id="v1v1m_8777697399697761416reply-intro">On 2020-07-28 02:39, Nyall Dawson wrote:</p>
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">
<div style="margin: 0; padding: 0; font-family: monospace;">On Mon, 27 Jul 2020 at 21:57, Jonathan Moules<br /><<a href="mailto:jonathan-lists@lightpear.com" rel="noreferrer">jonathan-lists@lightpear.com</a>> wrote:
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><br />Hi List,<br /><br />The more I look at the current SVG icons, the more I'm thinking it<br />really needs some TLC (Tender Loving Care). As far as I can tell, icons<br />are categorised by the directory they're in, so if you want an icon to<br />appear in two categories, you put the icon in there twice... and so<br />that's just what has happened! I suspect the current set has simply<br />accreted over time.</blockquote>
<br />For reference: I'm totally in agreement that we need to improve the<br />DEFAULT set of svg files, and that the resource sharing plugin isn't<br />the best solution here. It's a great solution for some use cases, but<br />we need to improve the out-of-the-box experience in this regard and<br />that means extending the default set.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">My thoughts:<br />* Move the svg's into a single directory. (Though would break any<br />current projects symbology using them I guess?)</blockquote>
<br />Yes -- we CAN'T do this. What we've got now has to stay, in its<br />current structure, and without renaming.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Use a metadata file to categorise them, so you get a list of<br />categories as now and a single symbol can be in multiple categories.</blockquote>
<br />We could potentially add tags to the svg files themselves to add this<br />information.<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Add a search feature so the user can quickly find "museum" without<br />having to guess where it has been categorised.</blockquote>
<br />Big +1 to this. Especially if we also add search by tag support!<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Clean up the current symbols by removing duplicates.</blockquote>
<br />Again, we can't do this without risking breaking people's existing<br />projects (which is off-limits!)<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;">* Add the font-awesome symbols (per my thread on the User List) to fill<br />in the gaps and flesh out the collection. As a bonus, it comes with<br />metadata for categories and search terms (YAML files).<br /><br />* bonus - metadata is internationalised so "museo" (IT), "muzeu" (RO),<br />etc would also work for finding that museum.<br /><br />Thoughts?</blockquote>
<br />Sounds good to me! To clarify -- are you volunteering to lead this effort?<br /><br />Nyall<br /><br />
<blockquote style="padding: 0 0.4em; border-left: #1010ff 2px solid; margin: 0;"><br />Cheers,<br />Jonathan<br /><br /><br />_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br /></p>
</div>
_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org" rel="noreferrer">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote>
</div>
</div>
</div>
</blockquote>
<p><br /></p>
</div>
</div>
<br />
<div class="pre" style="margin: 0; padding: 0; font-family: monospace">_______________________________________________<br />QGIS-Developer mailing list<br /><a href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a><br />List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br />Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank" rel="noopener noreferrer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></div>
</blockquote>
<p><br /></p>
</body></html>