Help talk:SVG guidelines: Difference between revisions

Content deleted Content added

Inline

Revision as of 00:17, 2 June 2019

Optimizing SVG

@Glrx, Sarang, Thomas Linard, Habitator terrae, and Redrose64: User:Thomas_Linard optimizes 1000s of SVG-files, simmilar to me. I had several discussions about reasonablity of keeping files invalid, and the longer I am working the more I am noticed that there is almost no sense of fixing invalid files, which are rendered correctly. Since it often just produces version-history/trafic/rendering-time it is often even undesired.

current Occasion File:Oxygen15.04.1-computer-laptop.svg, was uploaded, User:Thomas_Linard made it valid, my bot corrected a minor librsvg-bug, than User:Thomas_Linard optimized again, and then User:Thomas_Linard removed the (hardly visible) desktop-background, therefore I compressed the background-png lossless and reuploaded it with background.

I checked the last 13 elements with "Without raster data" in Thomas uploads and all of them have small rendering differences, and (almost) all were already made valid in an earlier upload.

However I tried to write an inofficial guideline: User:JoKalliauer/Optimization, which in generally says that making files valid does not justify reuploading.

User:Thomas_Linard in contrast says "Having useful and valid files for the various Wikipedia projects is. [...] ..., but I strongly oppose any statement who would say that it is desirable to keep invalid files,..." on User_talk:Thomas_Linard#removing_rasterdata/optimizing.

I don't know any guideline about validity of SVGs on Wikimedia, but there seems to be contradicting opinions, therefore this guideline should be edited/discussed together, to come to a rough conclusion.

— Johannes Kalliauer - Talk | Contributions 16:25, 30 May 2019 (UTC)[reply]

IMHO there are just two reasons (except substantial ameliorations) to reupload SVG and create more versions; validating is not one of these - when an image looks fine, I'll give a damn whether the W3C-validator finds unimportant syntactical errors.

it can be an educational reason, to show others how to draw images with less effort, less errors and less filesize; esp. when it is possible to draw very simple images with a text editor instead a tool.
a not so important reason is to keep often used files, as project logos, at a reasonable file size. Users with slow internet or mobile access might appreciate that.

My general opinion is that SVG drawing should be coded efficiently and should be clean and errorfree before the first upload; there is almost no sense to validate them afterwards. -- sarang♥사랑 16:44, 30 May 2019 (UTC)[reply]

@Sarang:

I aggree with your first point.

Regarding your second point: Reducing the file-size in SVG does hardly correlate with reducing the file-size in the PNG-preview. I assume a lossless PNG-compression would in generall reduce more, with even less prozessing time than rendering a new uploaded SVG (for each resolution). (e.g. File:Dojikko2.3.svg - 700pxPNGpreview of the original 18,32MiB-SVG is about 1% smaler (PNG:475 294 Bytes), than the 700pxPNGpreview of the current 4,94MiB-SVG with the librsvg-workaround (PNG:478 137 Bytes), so depening on the preview-size an optimized SVG can increase PNG-Previews). Or did you ment the downloading-time of the svg itself would reduce?

— Johannes Kalliauer - Talk | Contributions 20:23, 30 May 2019 (UTC)[reply]

Ok, may be you are right with the download time; the converting to PNG happens on the server(s), and that resulting PNG is much smaller. When it lasts for long with a large SVG it is not the line, just the server is busy. I "redraw" the 2^nd point! -- sarang♥사랑 20:34, 30 May 2019 (UTC)[reply]

The issue of uploading files when it makes no visual difference is complicated. In general, I agree that making small or insignificant changes should be avoided.

On en.WP, robots are forbidden from making edits that do not change the appearance of the page. That means that robots are forbidden from adding/removing spaces or adding/removing line breaks that do not change paragraph layout. There are exceptions to the en.WP robot rule. Robots are allowed to do some maintenance tasks that fix broken markup or update/improve template arguments even if the page layout is unaffected.

The notion of "invalid SVG" is often too strict. The SVG file may be valid XML and otherwise well formed SVG, but it may have been checked with a validator that does not have all the appropriate XML schemas. A file should not be considered bad because it has rdf:, inkscape:, sodipodi:, chem:, or other namespaces. I see no compelling reason for files to be modified to make them valid in the strict sense. (I have been meaning to see if the W3C validator processes xsi:schemaLocation.)

I'm OK with fixing XML errors. "Invalid XML" is much more serious than "invalid SVG". For example, XML files that have mismatched tags or elements with the same id="ncname". All SVG files should validate as XML. If an SVG file is invalid XML, then there is no guarantee that an SVG agent will display it.

The XML processing instruction (<?xml … ?>) should never be removed. The title and desc elements should never be removed. The metadata element should usually be preserved; files are copied from Commons, and that copying should not divorce the metadata. A robot that added a cc:attributionURL that links to the Commons file page would be an acceptable robot edit. The xml:space attribute is complicated; it is not clear to me what should be done with it.

I have trouble with "optimized" SVG. Optimization can destroy structure when it collapses groups. A goal of minimizing the number of bytes in an SVG file may do more damage than good.

I have trouble with bloated SVG files, but I do not know what to do with them. In the long run, I want MediaWiki to serve SVG files directly because that will allow tooltips, hyperlinks, and animation to work. But MW should not serve bloated SVG files; the data bandwidth is probably too costly (but I do not know for sure). There are many fabulous SVG files that are in the 5 MB range; that's big, but the PNG thumbnail is probably small, maybe 20 kB. Servable SVG files are probably in the 20 kB range.

I am in favor of making more rational SVG files. I'm in favor of removing path text; most illustrations on Commons do not need artistic text; removing path text can encourage translation, too. If an SVG file paints a text line "H SO" and separately paints the lines "2" and "4", it is reasonable to change the file to paint the single text element H₂SO₄. That allows a better user experience in selecting text. A SVG file may paint identical copies that would be better done as painting symbol instances (i.e., the use element).

Glrx (talk) 21:22, 30 May 2019 (UTC)[reply]

Hi,

Thanks for the discussion. My main points:

1. The purpose of SVG files on Wikimedia Commons is to provide useful files for the various Wikipedia projects, not for the "scientific purpose" of forming a museum of SVG freaks (except for some very limited and very specific cases).

2. "Correct rendering" vs. formal validity: With a invalid SVG, you can't be sure of rendering everywhere, but only with a specific rendering engine and version (librsvg, in the case of present-day MediaWiki). But I can't believe MediaWiki is doomed to use librsvg forever.

3. Validity: according to Help:Vector graphics tutorial, "Every SVG file uploaded to Wikimedia Commons should show […] whether it is W3C valid or invalid: set the appropriate parameter of the template". If you think we shouldn't care about validity anymore, this should be revised, and the {{Valid SVG}} template, the {{Invalid SVG}} template and the relevant parameters in {{Image generation}} should be removed.

4. Bloated SVG: we have a whole category (Adobe files with CDATA blocks) about a particular sort of bloated SVG. If you think we shouldn't care anymore, this category and the relevant parameters in {{Image generation}} should be removed.

5. My proposition: We should agree on the parameters of svgo, svgcleaner, etc. (the elements we want to keep, the elements that could be deleted) and propose it as official recommendations. Thomas Linard (talk) 09:59, 31 May 2019 (UTC)[reply]

@Thomas Linard: Thanks for your answer

1)The main purpose is in my Opinion to serve rendered PNGs for Wikipedia, where optimizing SVGs can reduce quality, but not improve (Reducing Transforms can increase pecission[1], but in general it reduces precission.).

2)phab:T40010 there is resvg, developed by @RazrFalcon: , which in future (0-5 Years) might be a fast and good Renderer. If you make workarounds for librsvg/resvg/ImageMagick/Batik/Chrome/Firefox/Inkscape/AdobeIllustrator/scourBugs/svgcleanerBugs/svgoBugs thats generally desired, but that does hardly correlate with making file valid. e.g. If someone uses <sodipodi:guide, that won't be rendered by any common renderer, since they do not know what to do, therfore they ignore it, and if they know this element the render know it should not get rendered.

3)That text was added by @Sarang: , see Special:Diff/121194715, and you should interpret this text with his text above. But you are right maybe Help:Vector graphics tutorial should be written more clear, that's the reason why I wrote this guideline for optimization/validation.

4)Category:Adobe files with CDATA blocks, was created by @Sarang: (and edited only by him and myself). In my opinion it is for finding uploaders, that should be informed about Removing CDATA before uploading, but that does not mean that those svgs should be reuploaded afterwards. (Also I did it for several images, because I missinterpreted it and this category was(past) a subcategory of Category:SVG files with errors.)

5)I think we can't agree on svgo/svgcleaner/scour since those three do not offer any bug-free parameters-set. In generall they can do more harm. (e.g. all three have problems with embedded CSS, and even vor CSS-free SVGS non of them offers a bug-free parameterset) We can only agree of why which parameter is problematic and why (see User:JoKalliauer/Optimization#options_how_to_use_optimizers), but that does not mean that this parameter is problematic for every file. (e.g. if you put CDATA in a comment, that has 100 times the size of the actual SVG, then you should probably remove also comments.) The options --keep-editor-data --remove-nonsvg-attributes no --disable=removeEditorsNSData keeps editor-data, which are important for making derivatives (I do not know any Editor-Data-rendering-bug for the current librsvg/Browsers.), but at the same time they are per definition (Editor-data) not included in the SVG-Standards(Picture-Data) and therfore invalid by some validation-checks. But we can agree that every Workaround for any (common) software (e.g.Browsers/Editors/Optimizers/SVG2PNG-Converters) is at least tollerated (and often even desired).

My Conclusion:

You can make Workaroud for any current common software (e.g.Browsers/Editors/Optimizers/SVG2PNG-Converters), see User:JoKalliauer/Optimization#Optimizing_SVGs_that_are_already_uploaded
Validating/Optimizing SVGs is in general good, but in general that does not justify reuploading, see User:JoKalliauer/Optimization#Optimizing_SVGs_that_are_already_uploaded
Even if you reupload there are several invalid features that should explicitly be kept for making derivatives, see User:JoKalliauer/Optimization#invalid_elements_that_should_be_kept

— Johannes Kalliauer - Talk | Contributions 14:15, 31 May 2019 (UTC)[reply]

Well, it seems that this discussion is rejuvenating me for at least 20 years. In the 1990s, it was said: "Why valid HTML? The rendering is good in Netscape! (or IE, a little later)". It took time to be (roughly) understood that writing HTML for a single rendering engine wasn't a good practice. I hope it'll take less for SVGs.

And formal validity (valid HTML, valid SVG) isn't the same thing as bug workarounds: it's about making sure the basics are healthy.

And when I talked about not using librsvg, I wasn't thinking of a replacement, but of direct rendering by browsers (at least for the interface icons).

Btw, rdf:, inkscape:, sodipodi:, chem:, or other namespaces don't make a SVG invalid (they generates some warnings, but no errors — if they are correctly used, which isn't too often the case: in this case, it's faster to ask a cleaner to remove them. But we can agree on a longer method.)

Btw, the discussion has started about a collection of SVG (Oxygen) icons for which the primary repository isn't Wikimedia Commons, but github (where the original files can be obtained much more conveniently than on Wikimedia Commons).

Anyway, if you don't want to correct bad SVGs: don't correct them. Thomas Linard (talk) 15:25, 31 May 2019 (UTC)[reply]

What do you consider as valid? On User_talk:Sarang#Automatically_inserting_Igen there is an current disscussion about validation.

<sodipodi:guide is invalid (Error) according to

validator.nu(SVG) 1Error
validator.w3.org(DTD) 54 Errors
https://tools.wmflabs.org/validator/ with DTD, for File:1940-1943_Medaglia_commemorativa_del_periodo_bellico_it_BAR.svg

<sodipodi:guide is valid according to

https://tools.wmflabs.org/svgcheck/index.php
Commons:Commons_SVG_Checker
https://tools.wmflabs.org/validator/ (xml-Validation without DTD)
xml-validators: https://www.w3schools.com/xml/xml_validator.asp and https://codebeautify.org/xmlvalidator

I hardly know any case of SVGs that are invalid xml, and mostly they were not rendered at all, therfore xml-validating is almost always true, therfore I assume you hardly fixed SVGs that are invalid XML.

@Thomas Linard: I do not know which kind of validity you are meaning. On Commons if we talk about SVG-validation we normally talk about validator.nu or validator.w3.org .

I suggested to allow SVGs for direct embedding: meta:Community_Wishlist_Survey_2019/Archive/Option_to_embed_SVGs_as_SVGs, but it was declined before finishing voting because it is too big. There are also security-issues. Therfore I assume it won't happen in the next years.

~~Correcting SVGs produces unreasonable trafic.~~

@TilmannR: ( and I) sometimes check the newest SVG-Uploads for bugs, that gets difficult if they are filled with massuploads.

Users like me get E-Mail every time sometimes someone edits files I edited once, that fullfills Mail-inbox (or at least the "Observation list/recent edits"(german: Beobachtungsliste)).

~~It creates severe server load. (rendering in serveral sizes, also it wastes diskspace and it "overfills" the version-history)~~ ( I withdraw my nomination by — Johannes Kalliauer - Talk | Contributions)

— Johannes Kalliauer - Talk | Contributions 11:23, 1 June 2019 (UTC)[reply]

Of course, against strict SVG DTD, File:1940-1943_Medaglia_commemorativa_del_periodo_bellico_it_BAR.svg is invalid. But SVG standard allows extensions, and the extensions are correctly declared, so no problem (well, in fact, there is one error in the file according to W3C validator: "Line 77, Column 24: Sodipodi element guide not allowed as child of Sodipodi element namedview in this context. (Suppressing further errors from this subtree.)").

"Correcting SVGs produces unreasonable trafic": well, the newest argument is traffic, now? In this case, we should push for mass deletion of raster clones of SVG files. As it is unlikely to happen, maybe that's not the right argument?

"Massive upload": About a thousand uploaded files (almost the entire Oxygen collection), it took me almost a year. "Massive upload", indeed! The discomfort has been unbearable for you for 12 months, but you complain on the last day, when everything is over? Thomas Linard (talk) 17:19, 1 June 2019 (UTC)[reply]

@Thomas Linard: I am complaining about removement of rasterdata, which reduces quality/complexityYour edits from 23.May to 28.May.

@Sarang: Maybe we should distinglish between {{BadSVG}} and {{SVG with desired Rasterdata}}, since {{BadSVG}} sounds "bad", but in several cases embedded Raster-Data are desired.

— Johannes Kalliauer - Talk | Contributions 17:53, 1 June 2019 (UTC)[reply]

@JoKalliauer: We do distinguish, between (topographic} wanted rastering, fake SVGs and "normal" embedded rasters; igen has the parameters for that and each one of these cases has a category. There are other examples where only rastering can create some structures with reasonable effort. When it is wanted and useful to parametrize, explain and categorize "desired" (or unavoidable?) bitmap embeddings, one parameter more can't do more harm? -- sarang♥사랑 18:16, 1 June 2019 (UTC)[reply]

I know all three of them {{TopoSVG}} (only from {{Igen}}), {{BadSVG}} and {{FakeSVG}}(was created on my request). I do not think {{BadSVG}} is right template for File:Oxygen480-devices-hidef-media-floppy.svg, since the embedded jpeg should in my opinion not be removed, as done in the last version, even the JPEG uses almost one quater of the original svg-file-size.

This SVG uses embedded raster graphics which do not need to be cleanuped.

@Sarang: Do you know a suitable name for the template?

— Johannes Kalliauer - Talk | Contributions 18:40, 1 June 2019 (UTC)[reply]

I personally would like to keep it simple and just a view templates, but often the text in templates are interpreted as guidelines, which seems in this cases to be missleading. — Johannes Kalliauer - Talk | Contributions 18:47, 1 June 2019 (UTC)[reply]

{we just got an edit conflict) In my humble opinion, such drawings .like Oxygen480 are far beyond the reasonable usage of vector graphics; I saw thousands of gradientings, and much more labourful coding. SVG is fine for symbols, logos and diagrams, as the easier files in Floppy disk icons, but for high definition images I would recommend JPG, or PNG or so. Your question: something like "required" might be understandable (for others than us two)? It would mean that there are the "justified" embeddings, with few non-topo files and a larger subcategory of the topos. Now we have Fake, Bad and Topo; when we cannot accept non-geographical structures also as topo (in a wider definition, as "topo-like"), we need a short and powerful-selfexplaining name for that. A long time ago some of us decided to collect all non-SVG files in the category PNG. I am not very happy with it, but I can live with that. A better idea now is welcome. -- sarang♥사랑 19:20, 1 June 2019 (UTC)[reply]

@Thomas Linard:

Covering your numbered points above:

1. The purpose of Commons is to not only provide files for Wikipedia projects, but also files for everybody. I'm seeing more material on the web that explicitly credits uploaders at Commons. That means that SVG files should function not only in librsvg but also in other agents. I agree with the museum comment, but I'm milder. If an SVG file is broken in some way and it is possible to fix it, then I would fix it in place rather than uploading the fix under a new file name. In any event, such files presumably do not render properly, and there is no objection to uploading fixes.

2. "Correct rendering" vs. formal validity. Sadly, most uploaders will target a reasonable rendering without worrying about validity. More troubling, uploaders will not make the file work similarly on many user agents. That's partly due to vendor bias. Adobe Illustrator encourages the use of Adobe fonts. Unix, Microsoft, and Apple will encourage their standard font set. MW does not help there at all; it has its own font biases. If we are looking for consistent rendering, then we need a lot more than some notion of formal validity. XML schema checkers are probably not checking the validity of CSS. The notion of validity only addresses whether some XML document should be consistently interpreted. Given that SVG ignores content in metadata and discards unknown elements, the only validity that is important is the structure of the SVG elements. Elements in unknown namespaces are not problematic.

3. Validity. I think most of us want to see files that validate. I'd prefer that users upload such files rather than ones with errors or warnings. But that is not the issue here. If a user uploaded a file that fails to validate, what should be done with that file? In many instances, the lack of validation is harmless and may be left in place. It may also be reasonable to fix the file so it does validate. But what should it validate against? Should inkscape and adobe namespaces be tolerated? I do not think there's consensus on what should be done. Even if we do not insist that all files validate, that does not mean we should not track that information. Tracking that information will help us understand what reasonable requirements are. Some day, MW may impose some validation requirements. It is not a binary choice.

4. Bloated SVG files are much like files that do not validate. They are inconvenient, but we don't know what to do with them. CDATA PGF can reasonably be killed off; CDATA font information is a different story. But CDATA is not the only reason that files are bloated. And does removing the bloat gain much. If the original uploader edits the file, will the bloat reappear?

5. Agreeing on the parameters of svgo, svgcleaner, etc. is premature. It assumes that we need to optimize files, and I do not think we are there yet. Why do we need to optimize any file? It may be reasonable to replace width and height attributes with viewBox, but is there a reason to do that now? If something can be done automatically, then it can also be done automatically later. If it renders correctly now, then why does it need to be fixed now? If it ain't broke, then don't fix it.

I think it is poor practice to generalize. Claiming that the rdf namespace is often misused, so we should just have a cleaner remove it does not make sense to me. What about the times a namespace is correctly used? And what about impact. If the namespace material is 1 percent of the file or only a few thousand bytes, there's little savings. Even if removing the namespace from the SVG saves a significant amount of space, it may not be worth it if the image is used in an article that is viewed only once per week.

I do not know the cost of updating files, so I cannot make any judgments there. Storage is cheap but not free. More significant is tickling editor's watch lists. That's a big consideration in the restriction on robot editing of WP articles. A robot can make a trivial change to an article, and that can cause a hundred people to look at the updated article. That's a cost in man-hours. A conservative stance would be do not bother changing files if they do not need changing. Yes, the watchlists on Commons are not as deep as those on en.WP, but I'm watching 631 pages on Commons. If a file on Commons needs changing, then we should pay the cost in both storage and labor.

Glrx (talk) 00:16, 2 June 2019 (UTC)[reply]

@@ Line 88: / Line 88: @@
 :::: I personally would like to keep it simple and just a view templates, but often the text in templates are interpreted as guidelines, which seems in this cases to be missleading.  — [[User:JoKalliauer|Johannes <span style="color:black; font-family:Monotype Corsiva;">Kalliauer</span>]] - <small>[[User talk:JoKalliauer|Talk]] &#124; [[Special:Contributions/JoKalliauer|Contributions]]</small> 18:47, 1 June 2019 (UTC)
 :::::{we just got an edit conflict) In my humble opinion, such drawings .like Oxygen480 are far beyond the reasonable usage of vector graphics; I saw thousands of gradientings, and much more labourful coding. SVG is fine for symbols, logos and diagrams, as the easier files in {{C|Floppy disk icons}}, but for <u>high definition</u> images I would recommend JPG, or PNG or so. Your question: something like "required" might be understandable (for others than us two)? It would mean that there are the "justified" embeddings, with few non-topo files and a larger subcategory of the topos. Now we have Fake, Bad and Topo; when we cannot accept non-geographical structures also as topo (in a wider definition, as "topo-like"), we need a short and powerful-selfexplaining name for that. A long time ago some of us decided to collect all non-SVG files in the category PNG. I am not very happy with it, but I can live with that. A better idea now is welcome. --''[[User talk:Sarang| sarang]]''<span style="color:#800">♥</span>[[:de:User:Sarang|사랑]] 19:20, 1 June 2019 (UTC)
+:::: {{ping|Thomas Linard}}
+:::: Covering your numbered points above:
+::::: 1. The purpose of Commons is to not only provide files for Wikipedia projects, but also files for everybody. I'm seeing more material on the web that explicitly credits uploaders at Commons. That means that SVG files should function not only in librsvg but also in other agents. I agree with the museum comment, but I'm milder. If an SVG file is broken in some way and it is possible to fix it, then I would fix it in place rather than uploading the fix under a new file name. In any event, such files presumably do not render properly, and there is no objection to uploading fixes.
+::::: 2. "Correct rendering" vs. formal validity. Sadly, most uploaders will target a reasonable rendering without worrying about validity. More troubling, uploaders will not make the file work similarly on many user agents. That's partly due to vendor bias. Adobe Illustrator encourages the use of Adobe fonts. Unix, Microsoft, and Apple will encourage their standard font set. MW does not help there at all; it has its own font biases. If we are looking for consistent rendering, then we need a lot more than some notion of formal validity. XML schema checkers are probably not checking the validity of CSS. The notion of validity only addresses whether some XML document should be consistently interpreted. Given that SVG ignores content in <code>metadata</code> and discards unknown elements, the only validity that is important is the structure of the SVG elements. Elements in unknown namespaces are not problematic.
+::::: 3. Validity. I think most of us want to see files that validate. I'd prefer that users upload such files rather than ones with errors or warnings. But that is not the issue here. If a user uploaded a file that fails to validate, what should be done with that file? In many instances, the lack of validation is harmless and may be left in place. It may also be reasonable to fix the file so it does validate. But what should it validate against? Should <code>inkscape</code> and <code>adobe</code> namespaces be tolerated? I do not think there's consensus on what should be done. Even if we do not insist that all files validate, that does not mean we should not track that information. Tracking that information will help us understand what reasonable requirements are. Some day, MW may impose some validation requirements. It is not a binary choice.
+::::: 4. Bloated SVG files are much like files that do not validate. They are inconvenient, but we don't know what to do with them. CDATA PGF can reasonably be killed off; CDATA font information is a different story. But CDATA is not the only reason that files are bloated. And does removing the bloat gain much. If the original uploader edits the file, will the bloat reappear?
+::::: 5. Agreeing on the parameters of svgo, svgcleaner, etc. is premature. It assumes that we need to optimize files, and I do not think we are there yet. Why do we need to optimize any file? It may be reasonable to replace width and height attributes with viewBox, but is there a reason to do that now? If something can be done automatically, then it can also be done automatically later. If it renders correctly now, then why does it need to be fixed now? If it ain't broke, then don't fix it.
+:::: I think it is poor practice to generalize. Claiming that the <code>rdf</code> namespace is often misused, so we should just have a cleaner remove it does not make sense to me. What about the times a namespace is correctly used? And what about impact. If the namespace material is 1 percent of the file or only a few thousand bytes, there's little savings. Even if removing the namespace from the SVG saves a significant amount of space, it may not be worth it if the image is used in an article that is viewed only once per week.
+:::: I do not know the cost of updating files, so I cannot make any judgments there. Storage is cheap but not free. More significant is tickling editor's watch lists. That's a big consideration in the restriction on robot editing of WP articles. A robot can make a trivial change to an article, and that can cause a hundred people to look at the updated article. That's a cost in man-hours. A conservative stance would be do not bother changing files if they do not need changing. Yes, the watchlists on Commons are not as deep as those on en.WP, but I'm watching 631 pages on Commons. If a file on Commons needs changing, then we should pay the cost in both storage and labor.
+:::: [[User:Glrx|Glrx]] ([[User talk:Glrx|<span class="signature-talk">{{int:Talkpagelinktext}}</span>]]) 00:16, 2 June 2019 (UTC)

Help talk:SVG guidelines: Difference between revisions

Revision as of 00:17, 2 June 2019

Optimizing SVG

Navigation menu

Search