Invalid SVGs

[dunnoob]

All flags are now also available as SVGs on the wiki in Category:SVG flags. Known issues:

1. Hong Kong is not yet submitted, it existed as suggested PNG on the Wiki.
2. Likewise Danzig is not yet submitted, I found it in a Gna! incoming patch or another obscure Gna! folder.
3. Dryad.svg is a hard case, various trivial "broken SVG fix" tricks failed.
4. Hre.svg is a hard case for lawyers, a valid version exists, but it's CC BY-SA, and IIRC share alike isn't GPL compatible. A trivial fix in patch #7464 would make it worse (but valid).
5. Jaffna.svg might be a fake or a copyright violation, IANAL.
6. In some cases the latest and greatest and (typically) valid version from MediaWiki commons changed the colours, and there's a good chance that the newer colours are also correct or better. In other words, some flag PNGs have to recreated, how is that normally handled?
7. There are still 200 broken (=invalid) SVGs in Category:Broken SVG.

Apart from the obnoxious Dryads all visually broken SVGs are already patched, the rest are mostly harmless validation issues not confusing Chrome, Wikia, or a SVG shell extension for Windows explorer.

In many cases Google finds a given flag in enwiki, from enwiki to commons is two clicks (after disabling their horrible media viewer), a third click to check that it is still valid (or edit the description page adding a validator link), download from commons, upload (=overwrite) on Wikia, submit patch on Gna!, update Wikia SVG page as "now valid" with a link to the patch. Plan B, convert invalid SVG with rsvg-convert.exe (e.g., the version distributed with crosser) or rsvg-convert (Linux) to valid SVG, submit patch, update page.

[louis94]

Dryad.svg is a hard case, various trivial "broken SVG fix" tricks failed.

W3C's own validator says it's valid : http://validator.w3.org/check?uri=http% ... 0708060958
Maybe the tools you use don't like svg 1.1 (I think other flags are 1.0).

Louis

[dunnoob]

Maybe the tools you use don't like svg 1.1

SVG 1.1 (or 1.2, if it's tiny) are fine, 1.0 was obsoleted by 1.1. Tiny 1.1 still makes sense (no scripting), tiny 1.2 supports scripts.

The failing tools are a Windows explorer extension displaying thumbnails (screenshot on the talk page) and SVG-edit, something with the viewBox might be wrong, the image is off-centre.

Chrome + Wikia are not confused. Testing phpBB:
Works.

[louis94]

I found out that Qt's SVG renderer didn't support it either. Here is a version without path clipping, which fixed the issue for me. It required modifying the SVG tree manually.

dryad2.svg

Renamed to dryad2 for easier comparison.

(3.66 KiB) Downloaded 331 times

Louis

[dunnoob]

It required modifying the SVG tree manually.

Thanks, works also for me, submitted, stamped, all visual oddities are now okay from my POV.

Of course some invisible validation nits when refreshed with the latest and greatest from commons could turn out to be very visible (fixed colours or similar), but most of the remaining 199 broken SVGs should be fast + simple: Get SVG from commons, make sure that it's valid, update SVG + license + source on Wikia, submit as patch, note patch number on Wikia.

[louis94]

There are still 200 broken (=invalid) SVGs in Category:Broken SVG.

The following procedure seems to create clean SVGs in all but a few cases.

1. Load and save all flags with Inkscape :

   Code: Select all

   mkdir clean
   find *.svg -execdir inkscape -z -l clean/\{\}-clean.svg \{\} \; &> aa-log.txt
   

2. Clean all files in the flags/clean folder with SVGCleaner.

Unfortunately, this modifies all flags, not just the invalid ones. A lot of data is also stripped by SVGCleaner. Inkscape has problems loading some files, see aa-log.txt (running the script will create a version for your system).

Louis

[dunnoob]

Clean all files in the flags/clean folder with SVGCleaner.

That's a possibility, but I wouldn't use it based on Rillke's law: Iff inkscape somehow managed to create a valid SVG its proprietary inkscape/sodipodi namespaces + mostly pointless "still image" metadata needing rdf/dc namespaces + other cruft might be useful for a contributor also working with inkscape (not me, I hate its invalid SVGs). Disclaimer, I made this wannabe-"law" up, but so far nobody reverted it.

Similar plan, let rsvg-convert convert invalid to valid SVG with any fonts replaced by vector graphics, and either add a basic 1.1 SVG header for validation as basic 1.1, or add a tiny 1.1 SVG header for validation as tiny 1.1, i.e., guaranteed to contain no scripts and no styles working on devices with minimal SVG support (incl. GPAC): Unfortunately the "valid tiny" can be a black rectangle, and the "valid basic" can be huge despite of losing all proprietary cruft.

For hre.svg the rsvg-convert trick produced valid 688 KB instead of 145 KB. A valid 173 KB version exists, but it's GFDL 1.2 or CC BY-SA 3.0 (attribution: N3MO), and AFAIK CC BY-SA 3.0 is not GPLv2-compatible, unlike CC BY-SA 4.0 and GPLv3.

[dunnoob]

see aa-log.txt

• Chiapas is covered by patch #7436, the validator refuses to check the attached SVG over https (Gna! certificate issue), http works.
• West papua is covered by patch #7394.
• Avar, chiuvashia, golden horde, volga german are in the (still) broken category, and if they also failed with your tools it's not only an esoteric validation issue.
• Liberia was a low hanging fruit eaten by patch #7479 while typing this: down to 198.

Google Chrome found no issue with the Gna! certificate, robots.txt permits access, bug on the side of the W3C, not Gna!

Updates:

1. Avar patch #7480 (but the flag is apparently fictional with all "official" FOTW-sources down)
2. Chuvashia patch #7481 (refresh from commons)
3. Golden horde patch #7482 (but FOTW + Marco Polo + pl.wikipedia.org disagree)
4. Volga german patch #7483 (source domain noted in patch #2944 for sale)

Down to 194 broken SVGs, all aa-log.txt entries patched, but from some older patches I fear that submitted SVGs also require new PNGs.

[dunnoob]

For the hairy hre.svg check out hre-2.svg suggested as possible alternative in patch #7464. The general procedure is now also discussed in patch #7393 (usa.svg).

The total number of still invalid (unfixed) SVGs incl. the hre issue in the broken SVG category is at 193. I tried to keep it below 200, because Wikia shows only 200 images per page of an image category; more than 200 could be (mis-)interpreted as hopeless.

New category SVG sources (fixed in patch #7629) with sub-categories SVG tech (patch #7637) and SVG wonders (patch #7636).

One special SVG case with an embedded raster image is unavailable on the Wiki, see patch #7235. Something is odd with this SVG, it does not have the motto 'cause civilzation should be free in the upper left arc, visible on the intro PNGs (one for GTK, another for SDL), or also visible on the Freeciv main page. For the purposes of the Wiki I'd really like to get a valid SVG logo with the motto, without obscure fonts, and if there must be an embedded raster image it should be given as inline data: URL, not as separate object. The MediaWiki mechanism to access external objects would be shaky, and maybe it's not allowed.