For graphics with a limited color palette, such as maps, flags, logotypes, coats of arms etc., SVG files are generally preferred over bitmap files not only because they scale better, but also because they are easier to edit.The most important thing is that SVG files are rendered correctly, so SVG elements which are not supported bylibrsvg (MediaWiki's SVG rendering engine) should be avoided. For example,librsvg does not support the SVGtextPath (text painted along a path) element. In addition, SVG files should be usable in other SVG environments, so SVG files should avoid uncommon SVG elements such asflowRoot.[1]
SVG is an abbreviation of scalable vector graphics. SVG is an XML (extensible markup language) file format, so it must follow XML as well as SVG standards. The SVG standard has XML elements that will draw lines, curves, rectangles, circles, text, and other graphic shapes. SVG can specify fill colors, fill patterns, gradient fills, and filter effects such blurring. Font sizes, styles, and families may also be specified.
If an SVG file is viewed in a browser, then the browser has the task of converting the SVG description to a visible image. For the most part, the browser will produce a reasonable image, but there can be some issues. Some SVG files may need specific fonts to show the intended image. If the browser does not have the appropriate font, then the result may be odd: the spacing may be off or the characters may not display. The same problem can happen with HTML. Your browser may or may not have a font for Egyptian hieroglyphs (𓀀𓀐𓀠) or Siddham script (𑖎𑖚𑖕𑖿𑖧𑖲𑖨𑖿𑖎𑖜𑖿𑖧𑖯).
Wikipedia pages do not serve SVG files directly. Instead of sending an SVG file to the browser, the wiki software (called MediaWiki) first converts the SVG file to a PNG bitmap and then sends the PNG file to the browser. The wiki servers do the job of converting the SVG file to an image. That has some benefits. The displayed image will be the same on any platform: it will not depend on which fonts the user has but rather which fonts are on the wiki servers. In addition, the PNG image is often much smaller than the SVG file, so the network bandwidth required to serve the image is smaller.[2]
Where the SVG file is converted to an image is often confusing or frustrating to users. A user can have an image that looks fine on her local system, but it looks much different or even horrible when uploaded to Commons. For example, the SVG file may use a commercial Adobe font such as "Stone Serif". That font is not available on the wiki servers (which use non-commercial / free fonts), so the serif font may be replaced by a sans-serif font — not what the user expected. In addition, the character widths of the substituted font may be much different. A text string may no longer fit in the allotted space and now collides with other features in the image. The user may have carefully lined up several text strings, but that alignment may now be lost.
Similarly, an SVG file that looks great on Commons may look much different when downloaded and displayed on a browser. The SVG may use the font "Liberation Sans"; when that sans-serif font is not available on the local machine, then the serif font "Times New Roman" may be substituted for it, and the different font metrics may produce an unwanted result.
Although SVG means scalable vector graphics, that does not mean that the scaling is linear for all objects. Geometric objects such as lines, curves, and circles will be scaled linearly. Reducing a circle to 50 percent will reduce the radius to one half. Fonts, however, are scaled differently; they may not be scaled linearly. SeePostScript § Font handling.
Text should be easy to read. That is easy to do with big characters and high-resolution displays, but it becomes difficult as the character size gets close to the display resolution. Adobe developedPostScript to have the ability to display readable fonts at small sizes. TrueType and OpenType fonts also have that ability. Consider a fixed-width typewriter font such as "Courier". At a fixed resolution, each character in the font will be an integer number of pixels wide. Say, for example, that each character is 6 pixels wide. Now say the SVG image is scaled down to 95% of its original size. Although the lines, curves, and other distances scale down, the font may stay 6 pixels wide — in other words, the text may stay the same absolute size even though the rest of the image is reduced. Even with the right font, an SVG file will not scale linearly.
The user may see this issue when SVG images are displayed at different sizes. An image that is 300 pixels wide may look fine, but it may not look right at 275 pixels. Some text may start overlapping other parts of the image.
When some users confront this problem, they simply convert the text to artistic curves so it will scale linearly. The better alternative is to understand the problem and leave extra space for the text. Generally, shoehorning some text into a tight space will not work at all resolutions. Leaving more space has other benefits. Not only will the image look right when scaled, it may also look OK when a different font is substituted. With extra room, language translations are simpler.
There are a few versions of the SVG specification, and those versions impact available features.
SVG 1.0 has many features, but not all of those features were implemented by user agents. In fact, SVG 1.0 expected user agents to implement only a subset of the specification's features. For example, an agent may display basic text strings but may not handle font baseline adjustments. An agent may or may not support text on a path. A mechanism (requiredFeatures attribute) allowed SVG code to test whether certain features such as extended text, filters, or animation are available.
SVG 1.1 (and its second edition) differs little from SVG 1.0. TherequiredFeatures strings were changed,[3] but some agents did not give accurate reports of the available features. It is also unwieldy for SVG code to test for features and have alternate ways to draw the desired image. Instead, artists would use widely implemented SVG subsets. W3C developed a notion of which features SVG mobile implementations should support: SVG Tiny and SVG Basic.[4]
SVG 1.2 was a candidate recommendation that was never adopted. SVG 1.2 has new graphics elements, but they are seldom supported. Nevertheless, some user agents have implemented some features of SVG 1.2. For example, previous versions of SVG did not have flowed text (essentially paragraph text that the SVG agent automatically broke into lines). Inkscape implemented SVG 1.2 flowed text, but most other agents have not. Consequently, SVG with flowed text will not display correctly on most SVG agents.
SVG 2.0 brings many changes. It keeps a substantial portion of SVG 1.1, but it has removed some features. The SVG 1.0tref element was seldom (if ever) implemented, so it has been removed. SVG 2.0 has also dropped support for using internally defined glyphs. SVG 2.0 has also dropped some DOM support. Consequently, a small number of SVG files that would display in SVG 1.1 agents may not display correctly in modern SVG agents. SVG 2.0 has added support for SVG 1.1 compatible flowed text.
For best compatibility, SVG files should use simple SVG 1.1 features. Even then, some agents (such aslibrsvg used by MediaWiki) do not support SVG elements such as text on a path. Even common SVG agents such as Firefox do not support font baseline shifts.
SVG is an XML format, and one of the goals of XML was to encourage that XML files have valid syntax. There are several benefits of standardization and validation.
The basic level of validity is the file is well-formedXML. Well-formed XML requires that the file contains oneroot element (e.g., the<svg> element) and every XML opentag (e.g.,<tspan>) is matched with a closing tag (e.g.,</tspan>). Well-formed XML does not impose other restrictions such as the root must be the<svg>element, elements must be in a certain order, an element may only be a child of a specific element, or an element may have only a small set ofattributes.
MediaWiki does not allow uploading of all valid XML/SVG files.[5] Some XML may be syntactically valid, but MediaWiki may refuse to upload it.
MediaWiki restricts the valid character encodings to a small set listed in$safeXmlEncodings. Those encodings are essentially ASCII, UTF-8, UTF-16, UTF-32, and several Windows encodings. The encodings are declared in the XML processing instructionencoding attribute. The restriction limits uploads to character encodings that MediaWiki understands, and it prevents malicious SVG being hidden in unusual character encodings.
MediaWiki does not allow the upload of files with anxml-stylesheet processing instruction. Such instructions may refer to external files or may modify the XML to have malicious content.
MediaWiki also whitelists the allowable namespaces in an uploaded document. In general, it allows some namespaces from Adobe, Creative Commons, Inkscape, W3C RDF, and W3C SVG. It does not allow uploads that reference the XHTML namespace.
SVG validity goes beyond well-formed XML because SVG has more constraints that just XML. The root is ansvg element. Atext element may havetitle,desc, ortspan elements as children, but it may not have ag element child. Certain elements are permitted to have particular attributes.
These extra constraints may be defined by a document type definition (DTD) file. DTD files were developed before XML namespaces, so DTDs do not handle XML namespaces well. The problem is a DTD treatsxlink:href as an attribute name rather than thehref name in thexlink namespace. In general, a DTD validator will complain about attributes in unexpected namespaces (such asinkscape:role="line") because the validator sees an unexpected attribute.
More recentXML schema definitions can handle XML namespaces. Two common schemas areW3C XML Schema andRELAX NG.
To do SVG validation, the validation program needs an appropriate SVG DTD or SVG schema. The SVG file may identify a DTD by using the XMLDOCTYPE declaration. Similarly, an SVG file may have a schema definition attribute on itssvg element (much less common).[6] The validation program may learn what definition to use by guessing, by looking at the HTTP header, or by being told by the user.
Even if an SVG file is valid, MediaWiki may not allow it to be uploaded.[5]
MediaWiki rejects SVG files withDOCTYPE declarations it does not recognize. The declaration must have aSYSTEM keyword, the public identifier must start with-//W3C//, and the system identifier must be one of
In other words, theDOCTYPE must identify one of the standard SVG 1.0 or SVG 1.1 DTDs. This restriction prevents a script injection attack using private DTDs.
MediaWiki also restricts SVG files that havescript elements or attributes that may contain scripts, such as theonload attribute.
MediaWiki restricts how SVG files may use URLs. In most cases, a URL reference must be an internal reference to the SVG file rather than an external reference;a elements may usehttp:// orhttps:// schemes to refer to external resources;data schemes must be a PNG or JPEG resource.
Even if an SVG file is valid, that does not mean an SVG agent such aslibrsvg will render the file correctly. SVG agents have limitations and bugs. For example,librsvg does not support thetextPath element. In addition,librsvg may not have access to some particular fonts, so it cannot display those fonts. For security reasons,librsvg is not allowed to access external files. On top of all of that, `librsvg` has some rendering bugs such as misspacing text strings.
There are tools to detect some of those issues and warn the user about them.
DTD is short foren:Document type definition.
In SVG 1.1 it's this line:<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
There is imho no simple answer for SVG 1.1 (and SVG 1.0), generally as written onHelp:SVG#cite ref-noDTD 5-0, DTD is not required nor is it recommended[7][8][9].
Beyond the specificities of (X)HTML processing, Doctype declarations in XML languages are only useful to declare named entities and to facilitate the validation of documents based on DTDs. This means that in many XML languages, doctype declarations are not necessarily useful.
— https://www.w3.org/QA/2002/04/valid-dtd-list.html#DTD below "Optional doctype declarations"
It is controversal if DTD should be added or removed, and in the end it is not very important
How to add DTD is explained here:de:Benutzer:Marsupilami/Inkscape-FAQ#Wie erstelle ich eine Datei die dem Standard SVG 1.1 entspricht? (German); in short: Add it as second line after the XML declaration, together the beginning of a file would look like this:
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
For upcoming Versions of SVG DTD is deprecated. SVG 1.2 and SVG 2.0 features are currently unsupported; seeCategory:Images with SVG 1.2 features,Category:Images with SVG 2.0 features.
If a file is xml-invalid (not only svg-invalid), that would actually be bad, but such files imho cannot be uploaded (any more), because of the xml-parser of MediaWiki checks that and blocks such images (e.g.phab:T279240). If a file contains invalid attributes and/or elements that is often desired, some examples can be found at#Invalid elements that should be kept (grides,guides,labels,layer,...), they are often necessary for editing the file, and only a few of them influence rendering (such as e.g. SVG2.0-features such asvector-effect), and also should imho not be removed because they are ignored anyway if not understood.
Validity is non-objective, it depends on thevalidator, and
line-height="1.25" (common for non-inkscape-files) as error, however the validators do not recognize the identical commandstyle="line-height:1.25 (inkscape uses), therefore validity should imho not get so much attention as it seems.id tokens are claimed, e.g. starting with a number, containing a space, doublewise specified. Some tools specify uselessids for evereything! Any unreferencedid is obsolete, and formal errors about don't care.If the file is already uploaded please read:#Optimizing SVGs that have already been uploaded
Before you upload a file for the first time please remove
seeHelp:Inkscape#Advantages of uploading Inkscape images to Commons
xml:space="preserve", seehttps://gitlab.com/inkscape/inbox/issues/247<!--,<title – comments and descriptions\n,\r,\t – linebreaks and indentations for better readability[10][11]<g – groups are often used to group some parts together, which you want to edit/move together; in general neither grouping nor ungrouping should be done to foreign files, seeFile:Medellin Kartell.svg
visibility="hidden",opacity="0",display="none" hidden layers can be used to store real text, but since you use a fancy font you only display the PathtextrequiredFeatures=", can be used to enable features according to the render/editor seeFile:Grafikworkshop Kalliauer.svg
<?xml version="1.0" encoding="UTF-8"?>, XML declaration – removal leads to a warning inCommons:Commons SVG Checker, and other problems:https://github.com/RazrFalcon/svgcleaner/issues/121#issuecomment-354525426phab:T327446<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">, doctype declaration (decision of the main author), necessary forhttp://validator.w3.org/, see#DTD or no DTD; extreme example:File:Ways of St-2. James in Europe.svg
<defs> sometimes you want to hide all defs in a texteditor and therefore you need to group them togetherFile:Hematopoiesis_(human)_diagram_en.svg_diagram_en.svg){kind=link}
<rect objects should in general not be converted to path-data, since it changes editing such files, and some older Inkscape version only handle<rect-data but not path-data in flowRoot, which makes converting difficult, seeFile:Medellin Kartell.svg<style type="text/css",mw-heading mw-heading3">Invalid elements that should be kept
[edit]data-name=,inkscape:label is used to label/find/name a specific element (id in contrast is used for addressing/referring).<rdf:RDF is used for metadata, seeFile:SVG Test TextAlign.svg, otherwise it might be a copyright violation.
aria-label= is used when a text is converted to path, and for keeping the text searchable.<inkscape:grid,<sodipodi:guide are used in editors to align elements, seeFile:Medellin Kartell.svgsodipodi:cx=,sodipodi:cy=,sodipodi:rx=,sodipodi:ry=,sodipodi:type="arc" are used for circular segments saved in path, since circular segments are not supported by the standard, seeFile:Sodipodi-type="arc".svg
vector-effect=,https://developer.mozilla.org/en-US/docs/Web/SVG/Attribute/vector-effect, seeFile:Municipalities of Italy.svg
inkscape:groupmode="layer",inkscape:label= – layer definition in Inkscape (seeUser_talk:JoKalliauer/Archiv#SVG_Layers_und_svgcleaner)sodipodi:role="line",https://gitlab.com/inkscape/inbox/issues/427<flowRoot, seeUser:JoKalliauer/RepairFlowRoot#replace notempty flow-text using (Inkscape)id=: a) Spaces can be replaced with "_". b) If the id starts with a number add a letter or a word before. c) If there is multiple times the same id, add a numbering or use data-name.<sodipodi:namedview pagecolor="#ffffff" inkscape:pageopacity="1", might be replaced by <rect width="100%" height="100%" fill="#ffffff"/> or <circle r="1e4" fill="#ffffff"/>If a file renders correctly, thenit is generally undesirable to reupload it without visible changes.Reducing the precision or quality of an image or removing visible raster data should not be done.
Do not remove metadata that identifies authors and/or licenses.
There are some cases where uploading a new version may bedesired:
metadata (e.g., adding author and license information).metadata element.There are some cases where uploading a new version istolerated: (some might be controversial or case-dependent)
Mass-uploading of 'optimized' files, just to make file valid or reduce the code, is in general undesired, since reuploading
Generally every reupload should contain a visible change (with someexceptions).If you just want to rerender a new thumbnail please checkHelp:Purge (?action=purge).Dummy edits should generally not be done to the file (except for changing metadata), only to the description page.
Generally it is always file dependent, but this options should be chosen to minimize bugs created by the optimizer.
Optimizing can be done (seehttps://css-tricks.com/tools-for-optimizing-svg/ for more options)
Optimized SVG (.svg), seeHelp:Inkscape#Inkscape SVG vs. Plain SVG
--keep-unreferenced-defs--set-precision=6--indent=space --nindent=1--renderer-workaround--disable-style-to-xml--set-c-precision=6--protect-ids-noninkscape--disable-simplify-colors--keep-editor-data
--indent 1--resolve-use no--convert-shapes no--group-by-style no--join-arcto-flags no--join-style-attributes no--remove-comments no--remove-declarations no--remove-invisible-elements no--remove-metadata no--remove-nonsvg-attributes no--remove-nonsvg-elements no--remove-text-attributes no--remove-title no--remove-unreferenced-ids no --trim-ids no--ungroup-groups no--list-separator comma
--disable=removeMetadata[13]--disable=removeHiddenElems[13]--disable=removeUnknownsAndDefaults[14]--disable=convertPathData[15][16][17][18]--disable=removeXMLProcInst[19][20]--disable=cleanupIDs[21][22]--disable=cleanupNumericValues[23]--disable=convertShapeToPath[24]--disable=inlineStyles[25][26]--disable=minifyStyles[27]--disable=removeComments[28]--disable=removeEditorsNSData[29]--disable=removeRasterImages[30]--disable=removeTitle[31]--disable=removeDoctype[32]--disable=collapseGroups[33][34]--disable=removeStyleElement[35]--disable=removeOffCanvasPaths[36]--disable=removeEmptyContainers[37][38]--disable=removeElementsByAttr[39]--disable=convertStyleToAttrs[40]--disable=convertTransform[41][42][43][44]--disable=cleanupNumericValues[45]--disable=cleanupListOfValues[46]--disable=reusePaths[47]
Different files need a different minimum number of precision.
There are many tools, this seems to be convincing (filesize/quality):
There are many tools, this seems to be convincing (filesize/quality):
.svg){kind=link}
.svg){kind=link}
flowRoot was part of the 2004 SVG 1.2 draft (https://www.w3.org/TR/2004/WD-SVG12-20041027/flow.html); it never achieved wide acceptance.xsi:schemaLocation. MediaWiki blocks uploads that reference thexsi namespace.