Open main menu

Optimizing SVGEdit

@Glrx, Sarang, Thomas Linard, Habitator terrae, 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)
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)
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)
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 2nd 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 H2SO4. 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)
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
<sodipodi:guide is valid according to
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 or .
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)
  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=""> <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
  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)
  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)
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="">
    <meta charset="utf-8" />
    <h2>Sarang Example</h2>
        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.
    <img style="border: solid black; border-width:medium;" width="358" height="100" src="" />
    <object style="border: solid black; border-width:medium;" width="358" height="100" data=""></object>
        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.
    <img style="border: solid black; border-width:medium;" width="358" height="100" src="" />
    <object style="border: solid black; border-width:medium;" width="358" height="100" data=""></object>

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="">, 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 IgenEdit

(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
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
       id="guide4722" />
You can also remove sodipodi:version="0.32" and sodipodi:docname="Commemorative_Italian-Austrian_war_medal_BAR.svg".
I would not remove xmlns:sodipodi="" 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 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
  • FileSave 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)
Return to the user page of "JoKalliauer/Optimization".