Help talk:SVG guidelines

Optimizing SVG

@Glrx, Sarang, Thomas Linard, Habitator terrae, and Redrose64: User:Thomas_Linard optimizes 1000s of SVG-files, similar 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)

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.

1. 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.
2. 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)

@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 general 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)

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)

• 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)

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)

@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:

1. 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
2. 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
3. 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)

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)

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)

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)

@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)

@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)

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)

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 misleading.  — Johannes Kalliauer - Talk | Contributions 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 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)

I think it's important that non-technical users don't have anxiety-provoking message when choosing an image (when it's not justified).

I don't have firm opinions about raster data in Oxygen icons. I removed the bitmap data from some files, because I found some rendering problems in the past, when the files were invalid, but now that I've validated all the files, it looks OK, so I'm agree with a revert.

The value of the Oxygen icons: of course, they are complex, and they aren't exactly in keeping with the taste of the day (flat design, material design, etc.). But they form a good transition between Crystal and Crystal Project icons (still very much used by Wikipedia projects) and Breeze icons. Thomas Linard (talk) 09:37, 2 June 2019 (UTC)

@Sarang: Maybe {{SVG with required Rasterdata}}? (I know all Rasterdata can always be lossless "vectoriced", see User:Ralf_Roletschek/Auge for an example.)

 — Johannes Kalliauer - Talk | Contributions 14:11, 2 June 2019 (UTC)

@JoKalliauer: (ob du das wohl findest?) Weil ich nur uber Admin das "Igen" andern kann, hab ich es jetzt so gemacht, dass ich wie mit !=t auch mit !=r in das {{TopoSVG}} gehe, allerdings wird das nicht direkt sichtbar sein. Dort habe ich alle Parameter, und kann dann von dort in die "richtige" Vorlage gehen und alles weitere veranstalten. Und da ist nichts editprotected, da konnen wir uns austoben! Meinst du, dass wir noch weitere Differnzierungen brauchen, neben !, !=a/f/t und nun =r? -- sarang♥사랑 15:30, 2 June 2019 (UTC)

@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)

@Glrx:

1. agree also I did it differently till ~2017 (But Category:Pictures_demonstrating_a_librsvg_bug should not be overwritten with Workarounds)
2. agree, also till librsvg 2.40.16 unknown <flowRoot were rendered by a black path (phab:T43424), because they contain a <rect, <path or similar. This would also happen for <inkscape:flowRoot xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"> <flowRegion> <path d="m -145.71 129.51 h 702.86 v 308.57 h -702.86 z"/> </flowRegion></inkscape:flowRoot>.
3. Should inkscape and adobe namespaces be tolerated? IMHO: Tollerated yes (but not desired), if they do not lead to any rederingbug, because it should be easy to make derivatives. e.g. <path d="m23.5098 80.2501a60 60 0 0 1 60-60 60 60 0 0 1 60 60" fill="#24211d" sodipodi:cx="83" sodipodi:cy="80" sodipodi:end="0" sodipodi:open="true" sodipodi:rx="60" sodipodi:ry="60" sodipodi:start="3.1415927" sodipodi:type="arc"/> is half of a circle, see File:Bikomponens.svg, it contains information of center(83;80)/radius(60) and angle(0-pi) of the arc, which contains sodipodi-namespaces.
4. Tell the CDATA-pgf-Uploader to tick Minify in the export-SVG-menu https://helpx.adobe.com/cy_en/illustrator/how-to/export-svg/_jcr_content/main-pars/image2.img.jpg/5286-export-svg-fig3.jpg
5. Changing the preview-size (replace with/height with viewBox) on the descriptionpage is often undesired, see User_talk:JoKalliauer/Archiv#For_your_information

 — Johannes Kalliauer - Talk | Contributions 14:11, 2 June 2019 (UTC)

Johannes,

1. no comment.
2. I have no problem with removing flowRoot from SVG files. The uploader intended that text be displayed. Fixing the file so that text is displayed in many SVG agents is a good thing. Although librsvg may not display black rectangles anymore, that fix only applies to one agent.
3. There are many sodipodi: attributes that are redundant and can be safely removed, but it may be wise to keep some of them around. Attributes that identify standard marker symbols are an example. Others are font-* attributes that Inkscape leaves on a path when it converts text to curves. We could compile a list of removable attributes, but I fear that would encourage automated edits to SVG files that carry little value.
4. Educating uploaders could be a good thing, but it could also be overwhelming to the uploader. An editor decides to make a diagram for an article, but has never done it before. He downloads Inkscape and is confronted with a steep learning curve. After hours of work, he finally has an image that works but has plenty of minor problems. He may have done subscripts by painting separate strings. There may be objects that should have been deleted, but they are just covered up or moved outside the viewing area. The illustration may be in the upper-left corner of an A4 sheet of paper, so there is lots of whitespace. But the editor has spent hours getting to that point, so I'm not sure WMF should insist on him spending another hour learning how to set the output options correctly. I know of one editor who went through the learning curve only to get yelled at by other, well meaning, editors; he left the project in disgust. The recent Indian languages translation project wasn't so much about translating diagrams but rather developing users with some skills in Inkscape by giving them simple editing tasks.
5. SVG that is scalable needs a viewBox. Otherwise the display of the image becomes confused. If an SVG file specifies its width and height, then that means it should be displayed at that width and height. But how the SVG is inserted into other documents adds confusion. If an img element is used, the whole SVG image is scaled to fit within the img element. That's sort of what makes sense for JPEG files; if the JPEG has a certain width and height, then those dimensions should be scaled to fit the img element. But the img element is just the image; all the hyperlinks, tooltip, and animation possibilities are disabled. That's not the case with object or embed, but those elements use different scaling rules. If the SVG specifies width and height, that is the size displayed. If it doesn't fit, then the user must scroll to see the rest of the image. There are other ways to do it, but a simple method is to have SVG files specify their viewBox but not their width and height (well, 100%). When the SVG is used, the container (e.g., object element) specifies the width and height. A standard for SVG dimensions is something Commons should debate sometime. It will be important if and when WM projects serve SVG files directly.

Glrx (talk) 17:56, 2 June 2019 (UTC)

@JoKalliauer: A new version of Template:{{Igen}} became now active. It contains some reparations (of errors knew until yesterday), many changes for easier parametrizing (the "empty-definition" of parameters) and new features (e.g. the !=r). The latter exists in Igen, but not yet the template to treat it further. Johannes, if you detect an error, or get otherwise knowledge of one, please inform me immediately!

@Glrx: Your statement "SVG that is scalable needs a viewBox" is not true for the librsvg. I do not have your knowledge; to confess the truth, I know only how SVG is processed by the librsvg and by internet browsers mainly FF, and viewBox can be fine but is not a necessary requirement - when width&height are defined. -- sarang♥사랑 05:48, 4 June 2019 (UTC)

@Sarang:

I disagree with some statements at viewBox. It does not change the coordinate system; it specifies an important area in the current coordinate system. Embedding svg elements within an SVG file just to do a transform is more complexity than needed; a g element may have an arbitrary transform. The world is simpler.

If an SVG file is used directly, the behavior in browsers is different. librsvg no longer paints a PNG that the browser uses but rather the browser paints the SVG directly. Here's an HTML file that should show a difference. In the first example, the img element scales the SVG image, but the object element does not. In the HSK example, the img element is not animated, but the object element is animated.

Today, if SVG files are used outside of WMF projects, there are some subtle issues. A viewBox attribute with the width and height attributes set to 100% is probably the correct setting for most images because it will scale the image to fit the container.

If WMF ever starts serving SVG, then it will need to address those issues.

<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
    <meta charset="utf-8" />
    <title>Tests</title>
</head>
<body>
    <h2>Sarang Example</h2>
    <p>
        Try a picture without a <code>viewBox</code>. Dims are 179 by 50.
        The <code>img</code> element scales the image to fit.
        The <code>object</code> element is displays 179 by 50 because that's what the SVG files says the image is 179 by 50;
        there is plenty of unused space in the element.
    </p>
    <img style="border: solid black; border-width:medium;" width="358" height="100" src="https://upload.wikimedia.org/wikipedia/commons/b/bd/1940-1943_Medaglia_commemorativa_del_periodo_bellico_it_BAR.svg" />
    <object style="border: solid black; border-width:medium;" width="358" height="100" data="https://upload.wikimedia.org/wikipedia/commons/b/bd/1940-1943_Medaglia_commemorativa_del_periodo_bellico_it_BAR.svg"></object>
    <p>
        Now a picture with a <code>viewBox</code>.
        As before, the <code>img</code> element scales the image to fit.
        The <code>object</code> element also scales the image to fit because width and height were specified to be 100% of the container.
    </p>
    <img style="border: solid black; border-width:medium;" width="358" height="100" src="https://upload.wikimedia.org/wikipedia/commons/4/48/DIN_69893_hsk_63a.svg" />
    <object style="border: solid black; border-width:medium;" width="358" height="100" data="https://upload.wikimedia.org/wikipedia/commons/4/48/DIN_69893_hsk_63a.svg"></object>

</body>
</html>

Glrx (talk) 17:01, 4 June 2019 (UTC)

@Glrx: Different, but realted, question: I made a DIN A3-Poster: File:Grafikworkshop_Kalliauer.svg, which should not be scaled for printing. I originally used (see version-history) <svg width="297mm" height="420mm" xmlns="http://www.w3.org/2000/svg">, which works on common Browsers and Inkscape 0.92.x. But for librsvg I used now width="297mm" height="420mm" viewBox="0 0 1122.5 1587.4". As far as I know in earlier days (till Inkscape 0.91 r13725) 90dpi was the default now 96dpi is the "default" for screens-setting/svg-files. Do you know, is it possible to tell librsvg that it should assume 96dpi if no viewbox is available?

PS I know I should have cleaned the file up before uploading.  — Johannes Kalliauer - Talk | Contributions 19:43, 4 June 2019 (UTC)

I do not know if there is a way, and I am not aware of any standard that says 90 or 96 dpi.

If something needs to be a certain size, then one could use units such as cm or mm, but I'm not sure how such units behave when scaled or transformed. The conventional approach uses pixels in the body of the SVG, a viewBox to declare the extent, and width and height to specify the dimensions.

The poster should have a viewBox. I do not think it should have a width and height: it may be intended as an A3 poster, but it could also be printed as an A4 flyer (metric paper sizes are so reasonable in that respect). Prepress has other subtle issues such as separations, bleeds, halftone screens, margins, and crop marks.

Glrx (talk) 15:20, 6 June 2019 (UTC)

Automatically inserting Igen

(moved from Sarang's user talk page}

Hello, I think that there is a problem with your automatic insertion of the Igen template. A valid SVG file has code 0, while you seem to consider it 1 (-1 is "invalid"). I corrected in this file, but please correct the rest of your edits. Cheers Ruthven (msg) 13:41, 29 May 2019 (UTC)

@Ruthven: Thank you for your Information. Yes, the validity is automatically checked, but when I look for 1940-1943 Medaglia commemorativa del periodo bellico it BAR.svg the validator tells me "Line 77, Column 24: Sodipodi element guide not allowed as child of Sodipodi element namedview in this context. (Suppressing further errors from this subtree". It is a well known fact that tools like Inkscape, A-Illustrator and others create code that violates formal restrictions – in the opinion of the W3C-validator! Such "invalidity" is nothing bad, it is just a criterion for categorizing; on the other hand, Commons has some really bad files that are W3C-valid!

Yes, a W3C-valid SVG file has the error code 0; but W3C-invalidity ranges from 1 to several thousands of "errors", and -1 is a convention to flag W3C-uncheckable SVG code. Sorry, your correction was not useful, my automatic setting was correct. When you enter the light-green higligthed text ("valid" or "valido") you will get the validation result.

Just for fun, I drew within two minutes with a text editor, and it is W3C-valid with a reasonable file size. Cheers -- sarang♥사랑 15:57, 29 May 2019 (UTC)

Hi again! I checked the file 1940-1943 Medaglia commemorativa del periodo bellico it BAR.svg with Jarry's tool ([2]) and I get: No issues found..

Generally I use this tool to check all the files I create. It's the correct process? Is the message you get an error or just a warning? Thanks --Ruthven (msg) 18:49, 29 May 2019 (UTC)

Hi Ruthven, different tools will find different issues; W3C has three tools which can tell different error counts. As I told before, you can enter the validation by clicking the highlighted message; then you will see the warnings and errors (when it's highligthed red because of invalidity, that click leads you to the diagnosis; when it's green and valid, it leads you directly to the SVG code display). Most errors in files that display fine are mere formal, e.g. against syntactical rules of id names - without any effect for the use of the file. I believe that Jarry looks whether the file can be displayed; code quality, embedded rasters, poor drawing does not matter. As said, tools in general create a huge amount of dead code, I call it garbage: when you compare the size of the ribbon drawings, mine is just 0.5 % of the larger one. When you compare the code (no matter whether you understand it perfectly) you can see the difference. Files too small, like mine, may lack in portability - but I write for the librsvg used by mediawiki which does not care many specialities. At Commons we can choose three W3C validators and due to these the ribbon let them produce several warnings and one error.

Your process to check SVG before upload is a good one, I appreciate it. Don't take the W3C-invalidity too serious, it is sometimes difficult to be avoided with tools, without an afterwards cleaning. Depending on the tools, and how they are used, their output consists to 30 until 70 % of W3C-invalid files. And sometimes up to 99.5 % of their code is superfluous or dead, with unimportant syntactical lacks. -- sarang♥사랑 21:54, 29 May 2019 (UTC)

Thanks for the explanation; in fact I use tools, and never write SVG by hand. This "sodipodi" tags often appear in the code: can I remove them without second thoughts? Cheers Ruthven (msg) 18:12, 30 May 2019 (UTC)

@JoKalliauer: Because I have no real experience with the SVG tools, and also none with cleaning the tool output, I cannot answer that question. Sure you can give Ruthven the advice he asks for? If somebody wants to make things better, he should get every help! BTW, I would too read your explanations with interest. -- sarang♥사랑 20:38, 30 May 2019 (UTC)

@Ruthven: There are several validators, they check for different things. For checking SVG-validity I recommend to use

• validator.nu
• validator.w3.org

the first is the one used by User:Perhelion/simpleSVGcheck.js, and the second one is from W3C, those who define the SVG-standards.

Deleting sodipodi-tags does not change rendering and can be removed.

But in general I would not remove sodipodi-elements, since they do not do any harm. In the current file there is a <sodipodi:guide, which in general should be kept for aligning elements (e.g. align several objects on the same line without rending this line), see User:JoKalliauer/Optimization#invalid_elements_that_should_be_kept for more examples which invalid elements should be kept. However this specific guideline in this SVG seems to me quite useless, therefore you can remove

  <sodipodi:namedview
     inkscape:window-height="1003"
     inkscape:window-width="1403"
     inkscape:pageshadow="2"
     inkscape:pageopacity="0.0"
     guidetolerance="10.0"
     gridtolerance="10.0"
     objecttolerance="10.0"
     borderopacity="1.0"
     bordercolor="#666666"
     pagecolor="#ffffff"
     id="base"
     inkscape:zoom="8"
     inkscape:cx="88.354659"
     inkscape:cy="42.380841"
     inkscape:window-x="1945"
     inkscape:window-y="30"
     inkscape:current-layer="svg2"
     height="60px"
     width="218px"
     inkscape:showpageshadow="false"
     showguides="true"
     inkscape:guide-bbox="true"
     showgrid="false"
     inkscape:window-maximized="0"
     fit-margin-top="0"
     fit-margin-left="0"
     fit-margin-right="0"
     fit-margin-bottom="0">
    <sodipodi:guide
       position="29.278638,-0.014839979"
       orientation="0,1"
       id="guide4722" />
  </sodipodi:namedview>

You can also remove sodipodi:version="0.32" and sodipodi:docname="Commemorative_Italian-Austrian_war_medal_BAR.svg".

I would not remove xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" since it would break the file if the file still contains any sodipodi: and does not throw any error.

For inkscape-tags this is very similar.

Since not everybody can edit SVGs by Hand/Texteditor, there are some tools that can optimize/validate your SVGs: (see User:JoKalliauer/Optimization#How to optimize)

I think the easiest option is https://tools.wmflabs.org/svgworkaroundbot/ with enabled make file valid (not recommended), ignore the other options.

I just implemented this function a few minutes ago, so please be aware that it can still be buggy (It should reduce the SVG to 1530 Bytes instead of 53818 Bytes, which is still much larger than Hand-drawn-file (326 Bytes from Sarang) who is really an expert in texteditor-drawing.).

Since you are using Inkscape there is also another option:

Optimized SVG in Inkscape

• File → Save As… ( Ctrl+⇧ Shift+S )
• Filetype: Optimized SVG (.svg)
• uncheck/do not check "Keep editor data"

I hope it helps, otherwise I am happy to answer your questions

 — Johannes Kalliauer - Talk | Contributions 22:24, 30 May 2019 (UTC)

@JoKalliauer: Thanks a lot for the information. This morning I created Coa Illustration Elements 8 rays.svg (optimized manually) and Nesso (Italia)-Stemma.svg (using svgworkaroundbot). The latter was reduced from 950kB to ~500kB, and even if it contains a lot of other useless code, I'm pretty satisfied with the result. Thanks to you both: I've learned something new. Cheers! Ruthven (msg) 11:52, 1 June 2019 (UTC)

@Ruthven: the Coa Illustration Elements 8 rays.svg looks good! I hope it won't frustrate you when I say that still more minimization/optimization would be possible; but there is no need that you become as well as me a crazy minimization freak! I wish you further good success -- sarang♥사랑 17:05, 9 June 2019 (UTC)

new problem

hallo Johannes, ist das hier auch dir aufgefallen? ich wusste gerne, ob nur ich dieses Problem habe. -- sarang♥사랑 11:57, 15 December 2019 (UTC)

@Sarang:

Mir zumindest noch nicht bewusst aufgefallen (es war bei mir schon ach dass manuelle Textberabtiungen verschunden sind, aber weiß nicht wann), ich wechlse selten den Tab nachdem ich manuelle Änderungen gemacht habe (Ich weiß Wachlist-tickling sollte vermieden werden). Aber ich habe es soeben versucht den Bug zu reproduzieren und war nicht in der Lage.

Meine Vorgangsweise war:

1. Verwende Firefox 71.0/Windows 10
2. Das Skript auf File:KL-SG_HSR_Map.svg laufen lassen
3. "Warten" bis fertig (Zwei gelbe Pop-Ups erscheinen rechts oben), dieser Schritt ist wichtig!
4. ändere |s= zu |s=m
5. wechsle zu einem geöffneten Tab
6. in einem neuen Tab die Google-Suche verwenden
7. wechsle zurück zu der Seite die ich gerade editiere
8. alles da wie ich es verlassen habe mit |s=m.

 — Johannes Kalliauer - Talk | Contributions 18:40, 15 December 2019 (UTC)

interactions

Animated SVG with tool tips

@Glrx: regarding Special:Diff/560451681: As far as I know some interactions are blocked during upload. I noticed some blocked content: User:JoKalliauer/IllegalSVGPattern#on*, however I do not know any svg-interactions (you will know them better than me). So are there interactions which are not blocked? (If old files exist with such a content it does not mean you can still upload them.)  — Johannes Kalliauer - Talk | Contributions 21:53, 24 May 2021 (UTC)

@JoKalliauer: . MW upload blocks files when they have potential security risks. For example, script elements are not allowed because it is impossible to determine if the script is safe. That also means blocking SVG that has attributes such as onclick or onmouseover. Those attributes allow arbitrary script injection. For example, onmouseover is code that is executed when the user's mouse pointer happens to be over a portion of the SVG image; that code could redirect the user to a malicious website. Many external links are also blocked: the external links may have security risks now, or they may be changed later to have malicious code. Some SVG is blocked because to defeat tracking and promote privacy.

MW does not block title elements; they will provide popup tool tips when the user's cursor is above the parent element. That functionality is lost when the SVG is converted to a PNG. MW does not block SVG animation elements and attributes, but the resulting PNG images do not have animation. That loss of functionality is what the edit is about.

For an example of user interaction, see File:DIN 69893 hsk 63a.svg. It has title tool tips (a mouseover event action). Clicking on the right hand object will start the animation (a click event action).

Glrx (talk) 23:52, 24 May 2021 (UTC)

Thanks, did not know that  — Johannes Kalliauer - Talk | Contributions 15:42, 25 May 2021 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 15:42, 25 May 2021 (UTC)

Replacing SVG

As an example, this user (last contribution 2016) created a lot of SVG files using Inkscape and Adobe, each one with hundreds of W3C errors and with huge PGF CDATA blocks.
IMHO the concept should somehow mention: Adobe PGF CDATA should be removed before the upload. A new upload just to keep the CDATA off is of no use, and should be avoided!
Cleaning SVG code before the first upload will be nice - but afterwards it will seldom be an advantage. -- sarang♥사랑 12:53, 17 June 2021 (UTC)

@Sarang:

I agree that fixing files after upload just to fix them is pointless.

I looked at a few files by KarlUdo.

• File:Nepal Apis laboriosa.svg has 265 validation errors (W3 validator). Most of those errors are simple editor hints such as the attribute i:knockout. I do not see those as troublesome. There are four switch elements for Adobe extensions. It is legal SVG, but adding switch and foreignObject elements may cause inconsistencies. The file has three untyped data: URLs, so I think Mediawiki would block the upload today. File usage is important. This file is unused, so there is little point in improving the file.
• File:Köln Fortifikatorische Entwicklung.svg has 25 validation errors (W3 validator) (not 731 errors). The file has the SVG 1.0 DOCTYPE with a subset. Some of the validator errors seem wrong (xmlns attributes should be allowed on any element). Many of the validation errors are within a metadata element; metadata should be permissive. The file is bloated at 246 kB and uses path text. The file is used in a few articles. Converting some paths to text would be appropriate.
• File:Wappen von Burgthann.svg has 46 validation errors and warnings (nu validator). Those errors are editor hints. They may not add much value, but they do not hurt. The uncompressed file size is also only 42 kB. The file is included by several articles (usually through a template), so improvements may be warranted. The file graphics are poor. For example, there is uneven spacing in lower left quadrant (invisible construction lines would help), and the tree roots touch the border.

Yes, it is best if the first upload is a concise SVG; reuploading a concise SVG later may not be advantageous.

That said, I am in favor of always fixing some errors. For example, if a file has XML errors such as illegal identifiers (id="#label" or id="003" or id="a:b"), then the file should be fixed even if it is unused.

There may be other situations where an SVG file should be modified. Some files have embedded commercial fonts. Adding RDF metadata may also be reasonable.

Glrx (talk) 18:03, 17 June 2021 (UTC)

@Glrx: Thank you for checking. At File:Köln Fortifikatorische Entwicklung.svg the validator finds 25 errors, yes; but the script uses the W3C-Nu-Validator, who mentions 731. Never mind, not the W3C-errors make this file a bad one!

About the illegal identifiers: when they are just defined for nothing and nowhere used, no harm is done; they are counted each as an error, but I won't care about them.

As another example, Bayer pattern with polish descriptions.svg seems so bad that I nominated it for deletion. I replaced the 40 KB of Bayer pattern on sensor profile.svg with a three-language 2 KB version. May be that you will find my coding too tricky, but I reduced to the essentials. The Inkscape file (>208 KB) contained more than 99% mere garbage, useless code. Many definitions are often repeated e.g.

• style="opacity:0.81153845999999985; 17 decimal fractions - but fill-opacity and stroke-opacity is defined later:
• fill:#000000;fill-opacity:0; - it is black & invisible! (why not 0.00000000000000000 ?)
• stroke:#000000;stroke-width:1.70000005000000010;stroke-miterlimit:4;stroke-opacity:0.01339286; - practical too invisible
• stroke-dasharray:none;stroke-dashoffset:7.79999999999999980; an offset (17 fractions) for an invisible "none"-dasharray

Another thing: Hagar66 and TUBS generate thousands files bloated by PGF CDATA blocks. This way the Mediawiki databases are filled.... -- sarang♥사랑 20:32, 17 June 2021 (UTC)

@Sarang:

Your view of what is reasonable SVG is superb. I am not a fan of some uses of stroke-dasharray, but that is a minor style disagreement.

Most SVG agents can handle illegal identifier names without trouble, but I consider them a hard fail. I want strict XML compliance, but I am willing to accept SVG with extended attributes.

Absurd precision in values and coordinates is both sad and funny. Sometimes the absurd precision has a simple explanation. Some tools may read the value 1.7 as an IEEE single precision float (roughly 7 decimal digits), do some processing that does not affect the value, and then output the value as an IEEE double precision float (roughly 16 decimal digits). The small representation error in the single float can generate many spurious digits. The value of (0.00000005 / 1.7) = 2.9411764705882E-8, which is 0.24672376470588 of a single precision epsilon. If the number were output as a single-precision floating point number, the output would have been "1.7" instead of "1.70000005000000010". The value 7.79999999999999980 looks like the output of a weak conversion routine. The apparent error is 2.5641025641026E-17, which is 0.11547691352232 double precision epsilons. The conversion routine should have produced "7.8".

Inkscape often produces strange coordinate and font-size values. Drawing is often done on a pixel grid that has 96 pixels per inch. A 12-point font is then 12 points * (1 inch / 72 points) = (1/6) inch = 16 pixels. Inkscape does not says font-size="16". Instead, it scales the image to use millimeters, so the font sizes and coordinates look like random numbers.

Some SVG files have <path stroke="none" stroke-width="5.08" ... >.

Some SVG files also have near-unity scale factors such as transform="scale(0.99998, 0.99998)". I think the graphic artist accidentally scales a group and then fixes it by scaling it again rather than undoing the previous scale.

I'm sympathetic to removing i:pgf elements. They have little value: maybe they could be used to test SVG rendering by comparing the rendered result to the bitmap image, but that function is too specialized for ordinary images.

Glrx (talk) 22:24, 17 June 2021 (UTC)

@Glrx: We know of your concerns about dasharray and we respect them. We accept that misuses as shown in SVG simplification by linecapped dasharray are (at least a bit) too tricky. But the possibilities of dasharrray are far more than just to dot lines in different ways. Grids like EKG-Reto 001 BugSolved.svg can be drawn easily with that method; while a mm grid of one m² would need two times 1000 lines, or with cascaded cloning about 20 clones, with dasharray one single path is sufficient.

The last editor of NATO Medal Yugoslavia ribbon bar.svg is a well known fan of drawing each line, one for one, with Inkscape. I am thinking that images of such a simplicity or primitiveness - some stripes and the adumbration of a texture - should not be so large and complicated.

As you may see, instead of uploading new versions I rather show only the suggested SVG code of a variation. -- sarang♥사랑 05:09, 18 June 2021 (UTC)

@Sarang:

Instead of stroke-dasharray for the cardiac grid, I would use a pattern fill:

<?xml version="1.0" encoding="UTF-8"?>
<svg viewBox="0 0 355 355" version="1.1" xmlns="http://www.w3.org/2000/svg">
    <defs>
        <pattern id="cardgrid" x="-1" y="-1" height="17.75" width="17.75" patternUnits="userSpaceOnUse">
            <line x1="0" x2="17.75" y1="0" y2="0" stroke="red" stroke-width="1.0" />
            <line x1="0" x2="17.75" y1="3.55" y2="3.55" stroke="red" stroke-width="0.3" />
            <line x1="0" x2="17.75" y1="7.1" y2="7.10" stroke="red" stroke-width="0.3" />
            <line x1="0" x2="17.75" y1="10.65" y2="10.65" stroke="red" stroke-width="0.3" />
            <line x1="0" x2="17.75" y1="14.20" y2="14.20" stroke="red" stroke-width="0.3" />
            <line x1="0" x2="17.75" y1="17.75" y2="17.75" stroke="red" stroke-width="1.0" />

            <line x1="0" x2="0" y1="0" y2="17.75" stroke="red" stroke-width="1.0" />
            <line x1="3.55" x2="3.55" y1="0" y2="17.75" stroke="red" stroke-width="0.3" />
            <line x1="7.10" x2="7.10" y1="0" y2="17.75" stroke="red" stroke-width="0.3" />
            <line x1="10.65" x2="10.65" y1="0" y2="17.75" stroke="red" stroke-width="0.3" />
            <line x1="14.20" x2="14.20" y1="0" y2="17.75" stroke="red" stroke-width="0.3" />
            <line x1="17.75" x2="17.75" y1="0" y2="17.75" stroke="red" stroke-width="1.0" />
        </pattern>
    </defs>
    <rect x="0" y="0" width="355" height="355" fill="url(#cardgrid)">
        <title>Grid</title>
    </rect>
</svg>

I'd tweak the above SVG to avoid drawing the major gridlines twice, but the above SVG was quick and straightforward.

I hope that librsvg can handle the above pattern, but I have not tried it.

Another trick is a pattern that has just the horizontal grid lines, apply that pattern as a fill, rotate the coordinate system 90 degrees, and then apply the pattern fill again. That solution would be clever and interesting, but it would also be confusing. It would be better to apply the rotation within the pattern definition. Even that trick may be confusing to a subsequent editor.

A second option is to use the feTile filter, but I do not know how well SVG agents support filters.

The NATO ribbon came up a few months ago, so I tried simulating the weave using linearGradient highlights within pattern fills:

• https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20210328073516%21Test.svg

The result was good in my browser, but the librsvg renderings were poor:

• see File:Test.svg history at 07:33, 28 March 2021

Consequently, I did not even try replacing the linearGradient fills with feSpecularLighting.

BTW, your English is far better than mine. I had to look up "adumbration".

Glrx (talk) 19:01, 18 June 2021 (UTC)

@Glrx: Very interesting, your examples. I tried the above coded pattern, and it worked fine.

I just avoided to define coordonates eplicitly with zero, and took some definitions into a group:

(<pattern id="cardgrid" x="-1" y="-1" height="17.75" width="17.75" patternUnits="userSpaceOnUse" stroke="red" stroke-width=".3">)

It is a possibility, but looks rather complicated - compared to a single dasharrayed path. And I like to keep simple things simple. When I meet such a coding I would need my time to analyze it until I find out what it does. In SVG many variations exist to draw the always same output with very different code. A complicated fill pattern may be fine for a large area with numerous lines, but for e.g. Chinese calligraphy pad-A4.svg or for a Sudoku grid it would be better adequate to draw it otherwise. But I used successfully a fill pattern for Honeycomb texture.svg, selecting an image size where the use of ${\sqrt {3}}$ can be assimilated with integers.

Your Test.svg from March 28 shows the texture structure very well; almost too good - IMHO the thousands of our simple ribbons should be kept simple, and not masterpieces of art.

AAMOF my English is rather poor; it is my best known foreign language, discussions in English are possible while I won't try it in others. "adumbration" is not part of my vocabulary, yesterday I was just in the mood to look for a special expression in [[:en:Wikt:|]]. -- sarang♥사랑 13:48, 19 June 2021 (UTC)

real ribbon with highlights on threads

SVG ribbon with lines to simulate threads

PNG with block colors

SVG ribbon magnified

@Sarang:

Ooops, the x="-1" y="-1" should not be there — I tried something and then did not completely remove it.

You find the most unusual files: a 23 MB PNG honeycomb!

The campaign ribbons raise issues, but I'm not sure how I would resolve them. Real ribbons have shiny threads. Simulating the threads with lines works at a small scale, but it looks odd when magnified. If the images are only shown small, they are OK, and that is the typical usage. SVG offers some opportunities here. A simple block color ribbon could use a common filter="url(#ribbonFilter)" to produce the thread appearance with highlights. In other words, I'm trying to be clever in expression rather than clever in compression. That approach has its own problems because filter effects may not be implemented well. That is especially true when using feTurbulence: subimages that I expect to have random appearance may look identical.

@Sarang: (reping due to inadvertent publish)

Glrx (talk) 16:04, 19 June 2021 (UTC)

Expansion

At Help:SVG_guidelines#Optimizing_SVGs_that_have_already_been_uploaded should IMHO be mentioned whether pure FAKE SVG are always to be replaced by real SVG – ​as I did all the files in Valid SVG created with Text Editor:Japanese crests, not because of the reduction to 0.25% but to unfake them -- sarang♥사랑 08:01, 22 September 2021 (UTC)

@Sarang: Ich hab es etwas allgemeiner in Special:Diff/592841772 formuliert. Fake-SVGs in real-SVGs sind (bei groß genuger Auflösung) mMn schon visuelle Änderungen.  — Johannes Kalliauer - Talk | Contributions 16:03, 22 September 2021 (UTC)

@JoKalliauer: Vollkommen unabhāngig von allen Kriterien wie zB der visuellen Auflösung, die einen Newupload legitimieren: sollen FAKEs prinzipiell und immer durch Reals ersetzt werden – oder gilt das nicht wie eine Art Richtlinie? Es ist mir persönlich ja recht egal, aber ich bin/war der Meinung dass FAKEs dermassen unerwünscht seien dass ihre sofortige Ersetzung als Gebot gilt; ggf. auch durch ein nicht so hochwertiges SVG Coding, wenn nur echtes SVG.

Denn sollte das nicht der Fall sein, ist bei FAKEs die Maintenance-Kategorisierung und der bisherige grelle Hinweis unangebracht. Wenn bei so einer Sache die kompetente Meinung einiger Fachleute (du, Perhelion) nicht ausreicht, muss da ein Konsens als offizielle Richtlinie herbeigefuhrt werden?? Ich bevorzuge einen deutlichen Hinweis in den guidelines, explizit zu den FAKEs. -- sarang♥사랑 06:46, 24 September 2021 (UTC)

Help:SVG_guidelines#Optimizing_SVGs_that_have_already_been_uploaded

@Glrx: Thanks for your edit. The limit what is desired and what is tolerated is a bit grayish, and some of my svg-edits might be at the border. I think I might wrote this section a bit narcissistic. It allows most of my edits, but however forbids similar edits of others. Those limitations somehow make sense, but they might should be questioned from a neutral point of view. I think they allow many manual uploadings, but not blindfolded mass-edits.  — Johannes Kalliauer - Talk | Contributions 19:44, 23 September 2021 (UTC)

@JoKalliauer: Yes, many SVG issues are gray rather than black-or-white. The page is an essay rather than policy, so none of the observations are set in stone. You also have sensible views on SVG. My views are slightly different but not far off. For example, I think DTDs cause more trouble than they are worth. Deleting a DOCTYPE processing instruction may even suppress a lot of validation errors for known SVG extensions. However, I would not recommend removing DOCTYPE PIs just to remove them. At the same time, I'm not going to complain (or at least complain too loudly) if an editor removes a DOCTYPE or makes an effort to make an SVG file validate. I will complain if making an SVG file validate involves removing relevant metadata. Any editor making mass edits should be much more conservative than the average editor. Glrx (talk) 20:20, 23 September 2021 (UTC)

---

So it looks to me

Hello Glrx and JoKalliauer: Tt is an undeniable fact that images (e.g. SVG) with a height of about 600±100px can be viewed well without zooming. Fry1989 changed recently a lot of drawings (e.g.

• Cyprus road sign mandatory go streight.svg 600×600 to 2,147×2,147 (and others),
• IE road sign RUS-021.svg 724×722 to 2,133×2,133,
• UK traffic sign 811 (Gibraltar).svg 680×775 to 2,505×2,859)

from a fine size to a much too large size — I have no idea why. Of course an SVG can be displayed at any scale, but it is boring when only a part of it be seen on its file description page.
In my opinion mm is not a suggestable unit for drawing SVG, it will cause transformations with decimal fractions of px. Every other unit than px causes difficulties.
I do not intend to correct it back when he likes it that way, but also I won't support such nonsense. It may be thought about whether his changes (no alteration in appearance, just enlarging the view by a factor ~4) belong to the wanted contributions ? Due to my understanding such re_uploads are clearly undesired and should be discussed with the user. It is not "Optimizing SVGs that have already been uploaded" but making them less useable and worse -- sarang♥사랑 09:49, 30 December 2021 (UTC)

I think we should start to discuss the two extreem edge-cases. And then we should go to the gray area between them, and define what is white and what is black.

1. edge-case: Most svgs do not have any scale and can be zoomed smoothless, that is where User:Sarang's argument is true.

2. edge-case: File:Stahl_Details_JoKa.svg is a plan that is two A4-paper high (2*297mm=594mm) and three A4-paper width (210mm+2*190mm=590mm; 190mm due to 20mm-perforator-border). So this SVG should not be printed in any other size, otherwise the plan is not in scale.

@Sarang: do you understand and agree on the 2. edge-case?

If case 2 applies for the trafic signs is another question, that can be discussed imho after understanding case 2. (That's imho a point of view, and should imho not be defined.)

If case 2 would apply for the trafic signs, then it should be discussed if it such reuploads are desired. (Imho not.)

@Sarang: the tree files you mentioned:

1. Cyprus road sign mandatory go streight.svg changed the color of blue, so upload is desired
2. IE road sign RUS-021.svg which edit are you talking about? Some seem to be desireded, most likely not all of them, but some might have been unintended mistakes
3. UK traffic sign 811 (Gibraltar).svg changed to color from blue to black so the upload is desired.

@Sarang: You sometimes have one point of view and require that you know that the other understands on your point of view. ("they are using just the old wrong ignorant arguments" in Special:Diff/592391392)

So I'm doing not the same: I require that I know that you understand my point that I already mentioned at User_talk:Sarang#Request, before I respond to any new argument. I don't know it if you understood my counterargument already, so I would like that you summerize the counteragument as you understood it. Then I know that you are able to build your own determination.

My text may sound harsh, but I have the feeling that you might not understood my arguments at User_talk:Sarang#Request (or ignored it), and I simply want to know that you understood it, otherwise we might be lost in missunderstandings or useless repetitions and everybody is frustrated.

I don't have any problems if you are disagreeing with me and you are saying my arguments are bullshit (and therefore ignored it), I just want to be understood.

If and only if you understood my arguments, I do not have any problems if you decide&act differently. (I do no have a strong opinion on this.)

 — Johannes Kalliauer - Talk | Contributions 12:49, 30 December 2021 (UTC)

Hi Johannes, I had not checked everything about Stahl Details JoKa.svg and do not understand all problems; but I see that is a very special case with special needs and special solutions. What I had been talking is just about simple SVG, e.g. traffic signs, that do not require any high sophistic solution - such signs have some legal description but factory production will not always follow exactly the measures and the colors, so kind of simple sketch might be enough for wikimedia to give an impression. That is different to your Stahl plan.

I mentioned the three examples (many more exist) for the enlargements, that there are small other changes will let them be 'justified' changes. I do not know why Fry changed the size; my laptop has a landscape monitor 1 : 1,84 so I see only the upper part of his enlargened files. May be with a portrait format sreen it is the contrary, e.g with a smartphone turned upright. I assume that most people will have the same problem when viewing these files on their screens. I am thinking that SVG drawings should neither be too small nor too large, when there are no reasons to select a special solution, square or round pictures should have a height of 400 to 700 px.

Johannes, are we talking about different things? I always try (with more or less success) to keep simple things simple. And I see no use in enlarging a 600×600 file to a 2147×2147 file - on the contrary, there are disadvantages. I do not want a new rule how sizes of SVG should be, ich bin weit entfernt davon einen neuen Kreuzzug zu entfesseln, I just think that some things are more reasonable than others; and normally I prefer the easy and the reasonable way. ​-- sarang♥사랑 15:32, 30 December 2021 (UTC)

So it looks to me

I try to explain Fry's argument to you, so I take an example where I think it is easier to understand what is Fry's intention. So I think we are not talinkg about different things. Reading your responce, it seems that I was not able to explain it to you. If you understand me, you know how it is related and you know Fry's intention. As long as you don't understand Fry's intention you are not allowed to blame him that he did (intentionally) not follow your rule, because it is their intention.

File:A_size_illustration.svg is now a plan in scale. A A0-Paper is 841mm x 1189mm and not ????px x ???px it must use mm as units and not px.

Don't say someone enlarged a file from blabla to blablabla, otherwise "you are using just the old wrong ignorant arguments". (Using your words simmilar as in Special:Diff/592391392, otherwise I would not be so harsh.)

You first have to understand Fry's intention. You can dissagree on my/Fry's arguents, but please don't argument why you think differently before understanding the other side. Otherwise it is a lost discussion.

 — Johannes Kalliauer - Talk | Contributions 16:15, 30 December 2021 (UTC)

Removal of unused embedded raster

​​ As an example, Fourcault process for flat glass forming.svg contains an embedding; the file is 529 748 bytes large. When the raster is removed from the source code it displays exactly the same image, which means that the embedding is superfluous. Many cleaning of the source code could be done, e.g. the unused gradient definitions; but when only the raster is removed without touching other code the resulting file size is 51 688.

• A smaller file size would not help anybody and is no argument.
• Raster removal normally is requested, but in this case it does not perform any visible change.

Therefore a replacement is in a gray zone, and I will not do it. -- sarang♥사랑 08:44, 27 September 2021 (UTC)

@Sarang: Daher ergänzte ich "If a file can be reduced by more than a factor of 10.", das ist bei dir der Fall. Wobei der Faktor 10 auch diskutierbar ist.

Hier sind jedoch zwei andere Argumente wichtiger:

1. Wenn es eine Urheberrechtsverletzung ist, muss das Rasterbild im SVG entfernt werden. Eventuell ist selbst das abzeichnen eine Urheberrechtsverletzung insbesondere von der 3D-Ansicht, weil da die Perspektive, sofern keine Standardperspektive, ist nicht technisch vorgegeben. Der Rest hat wenig gestalterische Freiheit und ist somit mMn nicht geschützt.
2. Wenn man die Rasterbilder als Referenz/Beleg/Quelle, bzw. zum Nachbearbeiten verwenden kann/soll, dann sollte man es drinnen lassen.

 — Johannes Kalliauer - Talk | Contributions 09:19, 27 September 2021 (UTC)

xml-Prolog

@Glrx:

1. User:Jarvisa removes <?xml version="1.0" encoding="UTF-8"?> in SVG-files, see Special:ListFiles/Jarvisa. I think actively removing xml-prolog should be forbidden, since file-recognition and sytax-highlighting will break.
2. You have a slightly different viewpoint on DTD. Can you remove everything what you consider as unimportant or controversial (or both) in Help:SVG_guidelines#DTD_or_no_DTD. (It got imho too much focus.)

@Jarvisa: Please read Help:SVG_guidelines#SVG_sourcecode_edits_without_visual_change

 — Johannes Kalliauer - Talk | Contributions 20:54, 11 October 2021 (UTC)

@JoKalliauer:

1. The <?xml version="1.0" encoding="UTF-8"> should never be removed. For quite some time, MediaWiki needed that line to serve the file as an XML document (MediaWiki no longer requires the XML prolog). There is an SVG file category that contained files that confused the W3C verifier; most of those files lack an XML prolog. In general, all XML files should have an XML prolog. In practice, most applications do not need it because v1.0 and UTF-8 are used. In theory, a file might be <?xml version="1.0" encoding="Shift-JIS">.
2. I will look later. Generally, an SVG file does not need a DTD, so I would not add a DTD. However, I would not go on a hunt to remove DTDs. If I were editing a file for other reasons, I would remove a DTD if the DTD is causing unreasonable verification errors. (The general idea is if an XML document has a DTD, then that XML document should verify using that DTD. If the document does not verify, then the DTD does not describe the document. If I use the default settings in Java runtime, reading such a document will throw an error.)

Glrx (talk) 00:11, 12 October 2021 (UTC)

AFAIK code like <?xml version="1.0" encoding="UTF-8" standalone="no"?> can be reduced to <?xml version="1.0"?>, the librsvg needs neither encoding nor standalone – but other renderers may need it. It should never be removed totally, even when it can be rendered without. -- sarang♥사랑 07:26, 16 October 2021 (UTC)

@Sarang:

The encoding attribute should not be removed. Most files will be UTF-8 or a compatible subset, but there are other, less common, encodings. There are many ISO character encodings. The XML spec makes the encoding explicit, so the consumer need not puzzle out the character set later when mojibake text appears.

The standalone attribute is more subtle. A DTD may set default values for attributes, and document evaluators could obtain the default values directly from the DTD. The Boolean attribute is not that important for SVG files, and I have no problem with it disappearing. One could argue that the librsvg SVG style element bug that required an explicit type="text/css" attribute should not happen if standalone="no".

Glrx (talk) 17:54, 16 October 2021 (UTC)

Fake SVG

(a proposal)
Tools such as Inkscape can create a "true SVG" or a "fake SVG" - an SVG file containing a bitmap but no SVG vector commands. If a drawing is made with vector commands, then it is best uploaded as an SVG file. Other tools may allow the use of vector commands, but they may not be capable of saving the file in SVG format. For example, Microsoft Paint allows users to draw lines, polygons, ellipses, and text, but it does not allow the user to save the result as an SVG file. GIMP is a popular drawing program; it allows users to import SVG files, but its ability to export SVG is very limited.

There is a consensus that some fakes are undesired.

There is no consensus that uploads of fake SVG files should be blocked.

Three is no consensus that fakes should be replaced as soon as possible by either a true SVG or its embedded raster image.
00A weak consensus holds that very highly used images should be improved, and that seldom used images may be left alone.

At the moment all detected fakes are tagged and categorized; their creator is advised to create true SVG files in the future.

• Comment. I want a more bilateral view. The current viewpoint is some SVG files should be bitmap/PNG/JPEG files. There's also the notion that some bitmap files should be SVG files: {{Convert to SVG}}. The test for a fake SVG files should not only be a wrapper test, but also that the image should not be a vector file. Glrx (talk) 18:08, 5 January 2022 (UTC)

It may also point to instructions how to get the bitmap out of the SVG, for uploading it as a bitmap replacing the fake. -- sarang♥사랑

How to create 'true SVG' instead of fakes

(a proposal) Instructions for use e.g. Inkscape

Possible substitutions

​​ A paragraph should explain that standard SVG are not always the best solution. Users looking at this help page should get informational links to other possibilities as

• Wikimedia parliament diagram creator
• {{Chart}} (Pie chart, Bar chart) creator (online)
• Template:{{Graph:Chart}} creator for charts of different styles (online) where changes can be updated swiftly - without any file upload
• Simple images substitutable by HTML
• and more. -- sarang♥사랑 11:49, 15 January 2022 (UTC)

Please change name of this file

Could this file be renamed something that more clearly reflects this is more advisory than policy? I'm aware of the large box at the top that clearly states that, yet folks keep pointing me here stating I'm in violation of WM rules (also named "guidelines"), which these aren't. It'd help people who can somehow read minutiæ deep into the doc, but clearly have no clue it's not enforceable. TSamuel (talk) 12:52, 26 March 2022 (UTC)

@TSamuel: You are imho violating unwritten WM rules, and this can lead to a block. This page is an written advice how to interpret the unwritten rules. Even unwritten rules are enforceable! If you act according to this advice, you could still get blocked, but it is unlikely since this advice has some consensus. If you repeatable violate this advices you will get reported, warned and blocked. I've never seen a user that got so many warnings on the same topic from different users without any block.

in short => Edits without visual change are illegal.

Since you imho get warnings/advices by several users @Reseletti, Watchduck, Curious Walrus, Tuvalkin, and OmenBreeze: @Cmglee, Erik Baas, and FreeCorp: :

I warn you: If you keep on repeatedly violating this advice (or however you might call it) you might get blocked, maybe without even any further warnings.

I did not check carefully, maybe I missed something and I'm wrong. See my reply as a friendly advice to avoid trouble.

PS: I also optimized several svg-files with svgo, and I know the border of allowed edits is somehow gayish, but be aware that (i) useless traffic should be avoided (e.g. watchlist-tickeling), (ii) readability/editability is more important than file-size and most important (iii) if the community (users/authors/admins/...) don't like your edits your edits are undesired (i.e. illegal) on commons.

 — Johannes Kalliauer - Talk | Contributions 00:08, 14 April 2022 (UTC)

Please check

Hi Johannes​​, you are the creator of this useful help page, therefore I ask you whether my additions to this item, depending watermarks, will agree with your intentions. Thank you! -- sarang♥사랑 07:44, 31 July 2022 (UTC)

@Sarang: I totally agree to this point, but I would not differenciate between in-use and not-in-use, since a picture might not be in-use because it has a watermark/timestamp. So removing watermarks might be "necesarry" for using an image. Commons does imho not make a difference between COM:INUSE and not used, it is only about if a file is educational usefull. If a file is not-in-use, it might be out-of-scope. If a file is out-of-scope it might should get deleted, for housekeeping reasons.  — Johannes Kalliauer - Talk | Contributions 11:52, 31 July 2022 (UTC)

@Sarang: I agree that watermarks are not desired, so the addition is fine (I might remove the bold and). In general, working on files that are not used is not a priority task. If a file is used or it has potential to be used, then editors should go ahead and improve it. It's a guideline, so it is not policy. Glrx (talk) 17:20, 31 July 2022 (UTC)

Relation to Help:SVG

This pages feels like it overlaps quite significantly with Help:SVG. Is there any idea to merge the two? mfx ^Q&A 14:14, 28 September 2022 (UTC)

I doubt there are plans to merge the two articles. Both articles could use substantial updates and rewrites. Both articles have been the result of recognizing problems and then recording that information so others can find it. Generally, I think the purpose of the articles are:

• Help:SVG wants to help users who ran into problems uploading their SVG files. Consequently, it addresses problems such as the outright rejection of an upload (e.g., script elements) and unexpected appearance (e.g., font selection issues and some librsvg bugs). A missing XML used to prevent display of SVG files.
• Help:SVG guidelines is more about overwriting SVG files that have been successfully uploaded. Should a DTD be added to SVG files that do not have one? Should an SVG file that fails to validate be overwritten? Which validation errors are significant? Should an SVG file be overwritten by an optimized version? Which optimizations are reasonable? (The article also addresses JPEG and PDF optimizations, but that is due to the article's historical origins.) The guidelines article is a summary of several debates about overwriting files. There is not complete agreement, and it is a work in progress. The general goal is agreement about which overwrites are reasonable and which are not.

Glrx (talk) 16:07, 28 September 2022 (UTC)

official guideline

@Glrx and Sarang: Should this be an official Guideline, listed on Commons:Policies and guidelines?  — Johannes Kalliauer - Talk | Contributions 13:03, 21 November 2022 (UTC)

 Agree Because the guidelines are best common sense (and seem needed) they should get a 'more official' state.

This makes it easier to react against people violating against them, without having a good reason -- sarang♥사랑 13:24, 21 November 2022 (UTC)

•  Mostly agree. We might make some additions to COM:OVERWRITE and link to them. OVERWRITE is a guideline, and it allows minor improvements. We are arguing that optimizations without a visual change are not minor improvements, but we are also willing to allow some such improvements. The important limitation is preventing mass editing that merely optimizes the SVG or makes the SVG valid. Glrx (talk) 20:51, 22 November 2022 (UTC)

Bad examples of mass-"optimizing" where only a complete redraw (with readable, simple SVG code) makes the file better (just a small selection) :

• 
  Shield Trinity (blank).svg
• 
  Etoile à quatre branches.svg
• 
  Noun Policy 1320312 4380c9.svg
• 
  Heraldic Shield Brunâtre.svg
• 
  Tor Snowflake logo.svg
• 
  Required raster.svg

— Preceding unsigned comment added by Sarang (talk • contribs) 16:15, 26 February 2023 (UTC)