Wikimore

This category is intended to gather SVG-files (and other vector graphic formats available on Wikimedia) which present their image with an easily human-readable format of code reflecting the obvious geometry of the image.

Explanation

Mostly these files were created by skillful users who know what should be presented in the image precisely. They are in principle like good writen articles with a fixed technical syntax. Sometimes these structured SVG-files spring of (semi-)manually drawn and where edited afterwards to simplify the structures. Of course, all the files contained in this category should as well be Valid SVGs and not all images are appropriate for such a structured semantic coding.
By using the appropriate SVG elements, and avoiding all the superfluous garbage and path-heaps typically for tool drawn graphics, the file sizes are kept at a reasonable size. But the sizes to minimize is only a minor aspect, prior takes

the coding reflects semantically the geometry of the picture
the text / code is very readable and easy to edit
embedding of useful comments.

An informative SVG in this sense is like a good technical construction sheet for the image!

The methods of drawing the graphics should be good through-thought (maybe of some educational value), giving hints to other users for solving different levels of complexity. Moreover a short explanation of numerical values (as long as SVG has no coordinate- and transformation-variables and abilities for basic calculations) if needed in parallel is nice.

This category will only be a subcategory of structured graphic code, which contains other graphic formats able of semantic coding of a geometric structur. A prominent example is Postscript, which is much more powerful, not good readable, widely used, but protected by law by Adobe for distributing own PS-renderers.

Hints for good coding philosophy in SVG

Avoid to use <path>-statements overcrowded. Try to use it only for irregular shapes or shapes expensive in execution-time (in current SVG-versions). :-/ Else you could replace e.g. all <line>- and <rect>-statements by <path>-data typically saving a few characters. :-(

For example, this ䷿ graphic can be drawn either with nine independent rectangles, or with one single path statement. With the rectangles it is better structured and has a size of 498 bytes, with one path this SVG-code is quicker when interpreted (but not dirty) and needs 222 bytes, 276 bytes less in source code.

Experienced programmers even see further alternatives in-between. To call two more views: three-times (via the <use>-statement a repetition of <g>-grouping-coding of 3 rectangles or a path consisting of 3 disconnected parts or a mixture of it. The next possibilities spring in mind, if one notice the vertical mirror-symmetry of the pattern. Thus: Always YOUR skill is needed to decide what coding is apropriate in the actual context. :)

You may see the different codes at the talk page of the file, the 3^rd and the 5^th file version.

In general, coding everything with <path>-statements is like coding everything in assembler: (only a bit) faster, maybe much less coding-length, but dirty (much less readable). For two real-world examples of much usage, see the Tekbir in Flag of Iran.svg or the ornament in Flag of Belarus.svg.

Use <g>-statements for grouping of statements you need more than once. E.g. rotation-repetitions.
Explain non-obvious number-monsters by comment. :)
Wisely used whitespaces increase readability strongly, don't worry if the raw file-size grows therefore.
It is nice to have a <title>-element inside.
Don't forget the <viewBox>-element and only use(set) the standalone-attribute (to "no") if there is really a further extern data-file needed for rendering this SVG-image.
Decide whether to use relative coordinates instead of absolute in path-data attributes.

An example of bad coding (you see a string of numbers with a few letters):

<path d="M0-102c-2.2,0-3,3.3-3,6.5 0,8 1,12 3,23.5 2.04-11.5 3-15.6 3-23.5 0-3.3-1-6.5-3-6.5"/>

better (now you recognize at a glance what x- and what y-coordinates are):

<path d="M 0,-102 c -2.2,0 -3,3.3 -3,6.5 0,8 1,12 3,23.5 2.04,-11.5 3,-15.6 3,-23.5 0,-3.3 -1,-6.5 -3,-6.5"/>

and better (now you can recognize immediately what each single Bézier-curve triple is):

<path d="M 0,-102

c -2.2,0 -3,3.3 -3,6.5

c 0,8 1,12 3,23.5

c 2.04,-11.5 3,-15.6 3,-23.5

c 0,-3.3 -1,-6.5 -3,-6.5"/>

Files generated by SVG-tools

In contrast tools cannot recognize when simple geometric structures are needed, nor do they give attribution to centering, symmetry, parallelism, not to mention semantic structures in a graphic resp. image! Here your skill is demanded!

Tool drawn graphics often

contain a lot of unnecessary prologue preamble,
use very complex path structures for drawing the simplest elements,
perform transformations (sometimes cascades of 5 or more) where they can easily avoided,
specify up to 8 (sometimes 40!) decimal fractions, in most cases without any need (where integers will do well),
specify style attributes redundantly because the values are implied,
specify sometimes all the text-attributes where no text is anywhere, and
create a lot of unreferenced IDs and groupings, comments and more.

By manually redrawing such a graphic it becomes easily a tenth or twentieth of the former file size.
Have also a look for simple example in the category Simplified SVG discussions.

Templates usage to mark high quality semanticly structured graphics

This can be done by two templates:

You may use template {{Created with Text Editor}} or simply {{HandSVG}} with the parameter 3=H to add your page to this category and to indicate how the SVG was made.
As well you may use {{SimplSVG}} with the parameter 5=H, especially when you replace another version, providing more possibilities to describe file size reduction.

Both templates can be equipped with more parameters for further category diffusion, as sc=flag|gl=SVG with the parameter sc indicating a subcategory and gl a certain graphic language with the default to be SVG.

Both templates generate via {{ValidSVG}} a link to the W3C validator: