Commons:Graphics village pump

From Wikimedia Commons, the free media repository
(Redirected from Commons:GVP)
Jump to navigation Jump to search

Community portal
introduction		Help deskVillage pump
copyright • proposals		Administrators' noticeboard
vandalism • user problems • blocks and protections
Shortcut
COM:GVP

color palette logo Welcome to the Graphics village pump!

A village pump

Hello and Welcome to this Graphics village pump of Commons. This Graphics village pump aims to provide help and information about the several Graphic Labs spread in the Wikipedias, and to be the technical support forum for all the local Labs, graphists (graphic artists), and users interested in graphic works, and is a page where graphists and users from all the Labs can talk about graphics, tutorials, graphic software, help to build new Graphic Labs, etc. Also for exchanging opinions, ideas, protocols, and ways of improvement.

See also: Other graphic community pages (list on top) | Graphics abilities page | Graphic Tool | Project Insignia | Stroke Order Project | Current requests/discussions

Commons discussion pages (index)
Start a new topic

Graphics village pump archives
Monthly archives
2007 – – – Apr May Jun Jul Aug Sep Oct Nov Dec
2008 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2009 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2010 Jan Feb – Apr May Jun Jul Aug Sep Oct Nov Dec
2011 Jan Feb Mar Apr May Jun Jul Aug Sep Oct – Dec
2012 Jan Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2013 Jan Feb Mar Apr May Jun Jul Aug Sep Oct – Dec
2014 Jan Feb Mar Apr May – Jul Aug Sep Oct Nov Dec
2015 Jan – Mar Apr May Jun Jul – Sep Oct Nov Dec
2016 Jan Feb Mar Apr May Jun Jul Aug Sep – Nov Dec
2017 – Feb Mar Apr May Jun Jul Aug Sep Oct Nov Dec
2018 Jan Feb Mar – May Jun Jul Aug Sep Oct Nov Dec
Topic-specific archives

Diagonally striped pattern on svg country map[edit]

Hello guys,

I'm trying to fill countries with a diagonally striped pattern on a svg world map in this kind of style, however, just filling countries instead of regions would be fine. Colors should be able to be determined with the ability to create transparent stripes. There are instructions on how to entirely fill and circle countries, but the above feature is missing. Anyone here who could extend the instructions or comment? Would like to use this map outside of Wikipedia in case there are different rendering requirements.
— Preceding unsigned comment added by MiMoHo (talk • contribs) 09:42, 11 April 2018 (UTC)

Need for a way to add metadata without making the markup of an SVG invalid[edit]

I have, up until today, not found any SVG uploaded to Wikimedia Commons that both:

Is anyone aware of a file uploaded to Wikimedia Commons which satisfies both of these conditions? I would be most interested in checking it out. If there is no such file, would anyone be interested in developing a guideline for new users to include structured metadata into an SVG while not thus making the file's markup invalid? Kind regards, Vincent Mia Edie Verheyen (talk) 21:02, 11 July 2018 (UTC).

The best (probably yet the only) way would be to modify "our" validator. Unfortunately Rillke is inactive since 2 years (on Wikimedia).[2] -- User: Perhelion 07:42, 12 July 2018 (UTC)
@Perhelion: I just got the idea of putting the meta-data in a block-comment: 
<!--
metadata here
-->
Of course, we couldn't really call that "structured" metadata ... but we could create a small coding guideline on what to structurally include in this manner. At least it keeps the SVG valid. Kind regards, Vincent Mia Edie Verheyen (talk) 14:49, 12 July 2018 (UTC).
Please do not embed metadata in comments. Comments are not data.
Adding metadata does not make the markup SVG invalid. The SVG 1.1 DTD is just too strict for metadata.
Instead of using W3C's old validator (https://validator.w3.org/), use its nu (non DTD-based) validator (https://validator.w3.org/nu/).
Document Type Definitions (DTDs) are difficult to extend with metadata or other schemes. Previously, one could DTD validate metadata by using an internal subset to extend (subset) the SVG DTD (example skeleton): 
<?xml version="1.0" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"
[
<!ELEMENT rdf:RDF ANY>
<!ELEMENT rdf:Description ANY>
<!ATTLIST rdf:Description dc:title       CDATA #IMPLIED
                          dc:description CDATA #IMPLIED
                          dc:publisher   CDATA #IMPLIED
                          about          CDATA #IMPLIED
                          dc:format      CDATA #IMPLIED
                          dc:language    CDATA #IMPLIED
                          dc:date        CDATA #IMPLIED>
<!ELEMENT rdf:Bag ANY>
<!ELEMENT rdf:li ANY>

<!ELEMENT dc:creator ANY>

<!-- and the trick... first definition wins -->
<!ENTITY % SVG.metadata.extra.content "| rdf:RDF" >
]>
That made the DTD validators happy, but IIRC a couple years ago MediaWiki started rejecting uploads that had parameter entities (% entities; only-within-the-DTD entities), so it is no longer an option for Commons. (The Document Object Model (DOM) has also shifted away from ordinary entities.)
So the situation today is W3C DTD validation will fail for Commons SVG files with DOCTYPE and metadata:
and W3C nu (non-DTD) validation will succeed
So do not include a DOCTYPE in your SVG and use the W3C nu validator.
As stated above, W3C has been given a bug report because its DTD validator now fails when it tries to pass an SVG without DOCTYPE file to its nu validator.
Glrx (talk) 18:03, 12 July 2018 (UTC)
@Glrx: I see that you are objecting against including DOCTYPE in an SVG due to what I and @Perhelion: have described at https://commons.wikimedia.org/wiki/File_talk:Test.svg/Description#Possible_objection_to_change_in_markup_validation_service_from_%E2%80%9CMarkup_Validation_Service_(W3C_Markup_Validator)%E2%80%9D_to_%E2%80%9CValidator.nu%E2%80%9D. I wonder though, if it perhaps does not make more sense to update the link generated by the valid svg template (see an example, above, at https://commons.wikimedia.org/wiki/Commons:Graphics_village_pump#Template:Valid_SVG_creates_a_link_to_the_Markup_Validation_Service_(W3C_Markup_Validator), i.e. change the auto-generated link from the red link to the green link), rather than deleting the DOCTYPE declaration. If this is a road to take, I have now identified three ways to include at least somewhat structured, or unstructured (pseudo, if you will), meta-data in an SVG with a DOCTYPE declaration, that will still be valid using the canonical Markup Validation Service (W3C Markup Validator):
  1. <metadata>
Metadata here.
</metadata>

  2. <title id="title">
Title here.
</title>

<desc id="author">
Author here.
</desc>

<desc id="more_info">
More info:
________________________________________
More info here.
</desc>


<desc id="...">
...:
________________________________________
... here.
</desc>

  3. <!--
Metadata here.
-->
Each on of these options can be used, or, alternatively, one can choose to include all of these in the same document, i.e. without any validation problems. Vincent Mia Edie Verheyen (talk) 11:28, 16 July 2018 (UTC).
I'm not sure how to respond to your comments.
I am not objecting to DOCTYPE for the reasons you give. Quite simply, DOCTYPE DTDs that do not describe the syntactic contents of the XML file should not be used. If the DTD does not match the file, it should not be present.
Including a DOCTYPE in an XML file implies that the XML file will validate with the supplied DTD. That works for plain SVG files, but it does not work if the SVG file has extensions such as <metadata> or sodipodi elements and attributes. The DTD checks for strict conformance, and any extensions violate that conformance. SVG files with extensions will not validate against the SVG 1.1 DTD. If your SVG file includes metadata, then do not use a DOCTYPE.
Many graphics programs insert the SVG 1.1 DOCTYPE but include extensions and metadata. Although those programs generate usable SVG, they automatically produce "invalid" XML documents. In some XML environments, programmers must explicitly turn off validation to read non-conforming documents.
DTDs do not understand namespaces. The strings svg:path and path are not the same to a DTD validator. Although DTDs were a selling feature of XML, XML namespaces have sidelined DTDs. The modern viewpoint is to not use a DOCTYPE. DOCTYPEs are no longer recommended for HTML, and SVG has followed suit. (Namespace-aware alternatives such as xsi:schemaLocation are possible.)
So if your file is only SVG and nothing else, include a DOCTYPE, and the file will validate. If you add anything else and use the standard DTD, then the file is not valid and will not validate. If you want to include metadata, then do not include a DOCTYPE.
W3C was aware in 2006 that its SVG validator should not expect a DOCTYPE. See https://www.w3.org/Bugs/Public/show_bug.cgi?id=3663 and expecially "namespace awareness is needed and DTDs are either suboptimal or clearly inappropriate".
You gave 3 options for metadata. The first is the appropriate one. Information about the file should be in metadata elements. Current practice is to use Resource Description Framework (RDF) with vocabularies from Dublin Core and Creative Commons.
Your options 2 and 3 have problems because there is no common syntax for such data. Metadata should be understandable by a machine. Option 2 abuses the id attribute, so it has problems. It cannot specify the author of another work: that would create two title elements (which is legal) but there would be two elements with id="author" (which is illegal). Option 3, putting important information in comments, is a poor practice. Comments are notes that machines are supposed to ignore. Furthermore, options 2 and 3 would have to reinvent RDF.
For Commons, the goal of validation is to make it more likely that the file will display correctly on several user agents. Commons recognizes that many of its submissions were made with Adobe Illustrator or with Inkscape. W3C also recognized that reality. Consequently, Commons is OK with SVG files that have extensions used by those tools.
Up until a few months ago, the template on Commons could validate against the stated DOCTYPE or (if no DOCTYPE) validate against a reasonably extended SVG specification (one that tolerates Adobe and Inkscape extensions). Then things broke at W3C. Files that used to validate would hang the validator. A reasonable workaround was done, but it had an unwelcome side-effect of saying files that used to validate were no longer valid. Somebody would click the link produced by {{ValidSVG}} and be told the file had 32 errors; that's confusing. Modifying the template to use the nu validator (which ignores an existing DOCTYPE) is an improvement. Most files that had SVG 1.0 or SVG 1.1 DOCTYPEs should still validate (files that subset the DTD could have problems), and files without a DOCTYPE will validate if they validated before.
Perhelion and other's work on Commons has been good if not stellar. If W3C fixed its bug today, the templates could go back to their old definitions tomorrow. But further work at Commons is not indicated yet. Commons could set up its own validator, but why do that if others provide the service? W3C has a strong incentive to provide the service and keep it up to date. (Take an en.WP page and run it through W3C's validator.) Commons could do a hack where it scans the SVG file; if it finds a DOCTYPE, then it could send the file to the DTD validator; otherwise, it could send the file to the nu Validator. That's more work, and it has little payback; direct to nu validator is a reasonable fix (it may mess up options, but that should be minor). And if W3C fixes its front-door validator, the work would be obsolete. The best place to fix the issue is at W3C. Encourage them at https://www.w3.org/Bugs/Public/show_bug.cgi?id=30257
To put it another way, the Commons template can reasonably use the results of the nu validator to measure the validity of all SVG files. If somebody wants to check a file against a strict DOCTYPE, then use W3C's other tools.
Glrx (talk) 17:42, 16 July 2018 (UTC)
@Glrx: You wrote ' That made the DTD validators happy,' . Can you please make an SVG-example were the W3C-DTD-Based-Validatior is happy with metadata?
I tried:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"
[
<!ELEMENT rdf:RDF ANY>
<!ELEMENT rdf:Description ANY>
<!ATTLIST rdf:Description dc:title       CDATA #IMPLIED
                          dc:description CDATA #IMPLIED
                          dc:publisher   CDATA #IMPLIED
                          about          CDATA #IMPLIED
                          dc:format      CDATA #IMPLIED
                          dc:language    CDATA #IMPLIED
                          dc:date        CDATA #IMPLIED>
<!ELEMENT rdf:Bag ANY>
<!ELEMENT rdf:li ANY>

<!ELEMENT dc:creator ANY>

<!-- and the trick... first definition wins -->
<!ENTITY % SVG.metadata.extra.content "| rdf:RDF" >
]>
<svg
  version="1.1"
  baseProfile="full"
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  viewBox="0 0 1200 600"
  overflow="visible"
  enable-background="new 0 0 1200 600">

<metadata>
  <rdf:RDF xmlns:cc="http://web.resource.org/cc/"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <cc:Work rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <cc:license rdf:resource="http://creativecommons.org/licenses/by-sa/3.0/" />
        <cc:attributionName rdf:resource="https://commons.wikimedia.org/wiki/User:Glrx"/>
        <cc:attributionURL rdf:resource="https://commons.wikimedia.org/w/index.php?title=File:SVG_Test_TextAlign.svg"/>
      </cc:Work>
    </rdf:RDF>
  </metadata>

<title>SVG Text Alignment Tests</title>
<desc>Test of several SVG text aligment issues.</desc>

  <!-- try some vertical text -->

</svg>
But this file has 11 errors on W3C. Maybe I missunderstood you?  — Johannes Kalliauer - Talk | Contributions 19:38, 16 July 2018 (UTC)
@JoKalliauer: Hmm. Turnabout is fair play; you pulled some RDF from one of my files. There are many ways to express statements in RDF, and the subset above was only showing how to validate one of those ways.
The subset I gave was only a skeleton to get a simple example to work. You can run this code (the above skeleton modified to use rdf:about instead of about (the RDF spec changed)) through W3C the validator:
<?xml version="1.0" ?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"
[
<!ELEMENT rdf:RDF ANY>
<!ELEMENT rdf:Description ANY>
<!ATTLIST rdf:Description dc:title       CDATA #IMPLIED
                          dc:description CDATA #IMPLIED
                          dc:publisher   CDATA #IMPLIED
                          rdf:about      CDATA #IMPLIED
                          dc:format      CDATA #IMPLIED
                          dc:language    CDATA #IMPLIED
                          dc:date        CDATA #IMPLIED>
<!ELEMENT rdf:Bag ANY>
<!ELEMENT rdf:li ANY>

<!ELEMENT dc:creator ANY>

<!-- and the trick... first definition wins -->
<!ENTITY % SVG.metadata.extra.content "| rdf:RDF" >

]>
<svg width="4in" height="3in" version="1.1"
    xmlns = 'http://www.w3.org/2000/svg'>
    <desc>Just some simple text</desc>
    <metadata>
      <rdf:RDF
           xmlns:rdf = "http://www.w3.org/1999/02/22-rdf-syntax-ns#"
           xmlns:rdfs = "http://www.w3.org/2000/01/rdf-schema#"
           xmlns:dc = "http://purl.org/dc/elements/1.1/" >
        <rdf:Description rdf:about="http://example.org/myfoo"
             dc:title="MyFoo Financial Report"
             dc:description="$three $bar $thousands $dollars $from 1998 $through 2000"
             dc:publisher="Example Organization"
             dc:date="2000-04-11"
             dc:format="image/svg+xml"
             dc:language="en" >
          <dc:creator>
            <rdf:Bag>
              <rdf:li>Irving Bird</rdf:li>
              <rdf:li>Mary Lambert</rdf:li>
            </rdf:Bag>
          </dc:creator>
        </rdf:Description>
      </rdf:RDF>
    </metadata>
</svg>
Your example has validation errors because there are no definitions for elements such as cc:Work. My example subset only defined cc:Creator and it used rdf:Description with Dublin Core attributes instead of DC elements.
Here's your example with additional definitions to validate your RDF example:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"
[
<!ELEMENT rdf:RDF ANY>
<!ELEMENT rdf:Description ANY>
<!ATTLIST rdf:Description dc:title       CDATA #IMPLIED
                          dc:description CDATA #IMPLIED
                          dc:publisher   CDATA #IMPLIED
                          about          CDATA #IMPLIED
                          dc:format      CDATA #IMPLIED
                          dc:language    CDATA #IMPLIED
                          dc:date        CDATA #IMPLIED>
<!ELEMENT rdf:Bag ANY>
<!ELEMENT rdf:li ANY>

<!ELEMENT dc:creator ANY>
<!ELEMENT dc:format ANY>
<!ELEMENT dc:type ANY>
<!ATTLIST dc:type rdf:resource CDATA #IMPLIED>

<!ELEMENT cc:Work (dc:format | dc:type | cc:license | cc:attributionName | cc:attributionURL)+>
<!ATTLIST cc:Work rdf:about CDATA #IMPLIED>
<!ELEMENT cc:license ANY>
<!ATTLIST cc:license rdf:resource CDATA #IMPLIED>
<!ELEMENT cc:attributionName ANY>
<!ATTLIST cc:attributionName rdf:resource CDATA #IMPLIED>
<!ELEMENT cc:attributionURL EMPTY>
<!ATTLIST cc:attributionURL rdf:resource CDATA #REQUIRED>

<!-- and the trick... first definition wins -->
<!ENTITY % SVG.metadata.extra.content "| rdf:RDF" >
]>
<svg
  version="1.1"
  baseProfile="full"
  xmlns="http://www.w3.org/2000/svg"
  xmlns:xlink="http://www.w3.org/1999/xlink"
  viewBox="0 0 1200 600"
  overflow="visible"
  enable-background="new 0 0 1200 600">

<metadata>
  <rdf:RDF xmlns:cc="http://web.resource.org/cc/"
           xmlns:dc="http://purl.org/dc/elements/1.1/"
           xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
    <cc:Work rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
        <cc:license rdf:resource="http://creativecommons.org/licenses/by-sa/3.0/" />
        <cc:attributionName rdf:resource="https://commons.wikimedia.org/wiki/User:Glrx"/>
        <cc:attributionURL rdf:resource="https://commons.wikimedia.org/w/index.php?title=File:SVG_Test_TextAlign.svg"/>
      </cc:Work>
    </rdf:RDF>
  </metadata>

<title>SVG Text Alignment Tests</title>
<desc>Test of several SVG text aligment issues.</desc>

  <!-- try some vertical text -->

</svg>
Glrx (talk) 20:59, 16 July 2018 (UTC)
Thank you very much. I like "happy validators", and keeping metadata is important, now I know a solution to fullfill both. I will take a closer look later on later, maybe in future I will use metadata more often.  — Johannes Kalliauer - Talk | Contributions 21:59, 16 July 2018 (UTC)

Guidelines[edit]

@Glrx: Could you please use your knowledge, as you have demonstrated in this discussion, to formulate a guidelie for metadata in SVGs on Wikimedia Commons? It would be really helpful to know all of the possible metadata categories that could be included. Many thanks for your help, Vincent Mia Edie Verheyen (talk) 09:57, 23 July 2018 (UTC).

It seems that the solution posted above can not be uploaded to Wikimedia Commons, yielding a The XML in the uploaded file could not be parsed.-error, Vincent Mia Edie Verheyen (talk) 10:23, 23 July 2018 (UTC).
@JoKalliauer: Your file https://upload.wikimedia.org/wikipedia/commons/9/9b/SVG_Test_TextAlign.svg still yields 12 errors and one warning when ran through the W3C Validator: https://validator.w3.org/check?uri=https%3A%2F%2Fcommons.wikimedia.org%2Fwiki%2FSpecial%3AFilepath%2FSVG_Test_TextAlign.svg&doctype=SVG+1.1&ss=1#source Kind regards, Vincent Mia Edie Verheyen (talk) 10:30, 23 July 2018 (UTC).
@Vincent Mia Edie Verheyen: I removed the author, the licence and the source, therefore User:Glrx had to revert my Copyright-violation, therefore W3C still reports DTD-errors in the actual file, but they should be ignored. W3C does not recommend Doctype-Definition ( https://www.w3.org/TR/SVG/intro.html#NamespaceAndDTDIdentifiers ), because the W3C-DTD-validator has to many false positives/negatives (too strict), since W3C can only check DTD-validity (which is not recommend by W3C), you should use nu-validator: https://validator.nu/?doc=https://upload.wikimedia.org/wikipedia/commons/9/9b/SVG_Test_TextAlign.svg&group=1&schema=http%3A%2F%2Fs.validator.nu%2Fsvg-xhtml5-rdf-mathml.rnc+http%3A%2F%2Fs.validator.nu%2Fhtml5%2Fassertions.sch+http%3A%2F%2Fc.validator.nu%2Fall%2F&parser=xml, which reports no errors for the actual file.
But if you check the file with the copyright-violation ( https://upload.wikimedia.org/wikipedia/commons/archive/9/9b/20171022142025%21SVG_Test_TextAlign.svg ): it is valid according W3C-SVG-1.1-DTD: https://validator.w3.org/check?uri=https://upload.wikimedia.org/wikipedia/commons/archive/9/9b/20171022142025%21SVG_Test_TextAlign.svg
@Glrx: If I try to add the code you suggested, and upload it, I get the errormessage "The XML in the uploaded file could not be parsed.", which seems to be a bug of WikiMedia. (I did not had any problems on Commons:Commons_SVG_Checker, but uploading to Wikimedia fails.)
@Glrx: In File:Test.svg#filehistory the last file shows still the Test-file (or my cache did not update?), "?action=purge" might crash the sever (since there are too many versions).
 — Johannes Kalliauer - Talk | Contributions 15:49, 23 July 2018 (UTC)
(e/c)
@Vincent Mia Edie Verheyen:
One must distinguish the different validators and recognize their limitations. In addition, one must recognize WMF's security measures prevent the upload of valid SVG files. It is difficult to negotiate all of the problems.
  1. W3C's main validator at https://validator.w3.org is a DTD-based validator.
    • It will validate a simple SVG file with an ordinary DOCTYPE declaration.
    • Files with metadata (e.g., RDF) or extended elements/attributes (e.g., Illustrator, Inkscape) will emit errors
    • It will validate an SVG file with a DOCTYPE that has an internal subset. (the <!ENTITY % SVG.metadata.extra.content …> above)
      Taking one of the above DTD with internal subset examples and pasting it as text input will validate
    • Files without a DOCTYPE are problematic. It used to do something appropriate, but currently it reports a bug. (We want this fixed.)
      SVG_Test_TextAlign.svg (which has no DOCTYPE) fails to complete validation:
      The Commons {{ValidSVG}} template uses this validator, but it currently works around this problem by instructing the validator to always use the SVG 1.1 DTD (no internal subset). Consequently, only simple SVG files will validate and any metadata or extensions are reported as errors. Even if an internal subset could be present, it would be ignored.
  2. W3C's nu validator at https://validator.w3.org/nu and the nu validator at https://validator.nu (they have minor differences)
    • These are schema validators that use RelaxNG schemas (.rng files).
      They can be told to use specific schemas (definition files similar to DTDs) to check a file
    • They ignore DTDs, so any extensions specified in an internal subset are lost.
    • They either check or ignore a limited number of extensions: RDF, sodipodi, inkscape.
      They can be told to ignore elements and attributes in specific namespaces
    • IIRC, the user interface is confusing. It will check SVG files specified with a URI, but it will not check SVG files by pasting the content into a text box. SVG-pasted files are checked as HTML and fail.
    You mentioned File:SVG Test TextAlign.svg. It does not have a DOCTYPE, so one of the nu validators must be used:
    Uploading the file to File:Test.svg will provide a link to the validator.nu engine.
  3. Commons imposes some security measures. For example, an SVG file might contain some malicious JavaScript code, so Commons tries to prevent such files being uploaded and distributed by Commons. Apparently Commons believes that <!ENTITY # …> definitions are evil, and Commons will block them from upload. That's another story.
    @JoKalliauer: I believe the failed to parse "error" is Commons rejecting the parameter entitythe ATTLISTs.
    Actually, the security issue is <!ATTLIST …> used for script injection. See Phab:T151735 Glrx (talk) 03:16, 24 July 2018 (UTC)
So the advice is simple but not consoling. Don't include a DOCTYPE if you add metadata or use extensions. Check the file with a nu validator rather than a DTD validator. If you click the link provided by {{Valid SVG}}, then ignore any errors about RDF, Inkscape, or sodipodi.
I believe the metadata should be RDF that generally follows the Creative Commons guidelines, but that guidance is weak even for simple cases. (CCRel 1.0 gives some background and guidance, but it covers a lot of formats. Sadly, it may offer more confusion than help.) I cannot give specific advice because I'm not sure what is best, and I believe the issue is still in flux. When there is one artist, that artist is the dc:creator, but if there are two artists, should there be two dc:creators or just one creator with the two artists grouped in an rdf:Bag? Or should one of the artists be labelled dc:contributor. Should people be represented as simple strings ("John Q. Public") or should they have a dc:agent wrapper around them? Should the date be of the original work or the most recent modification?
Without stating exactly what the statements should be, here are some statements that I may include (dc is Dublin Core and cc is Creative Commons):
  • . dc:creator "John Q. Public" (or a URI)
  • . dc:contributor "John Doe" (or a URI)
  • . dc:date "2018-07-23"
  • . dc:publisher "Wikimedia Commons" (or a URI)
  • . dc:source URI
  • . cc:license licenseURI (license is complicated; CC0 is not Public Domain)
  • . cc:attributionURL URI on Commons (CC-BY creator may specify a particular URI)
  • . cc:attributionName URI of Commons User (CC-BY creator may specify a particular name)
Glrx (talk) 17:27, 23 July 2018 (UTC)

How to fix Blacked SVG[edit]

SVG file rendered as black. Original file is here[1].

I'm trying to upload svg chromosome images from https://github.com/RCollins13/HumanIdiogramLibrary . But svg file uploaded to Commons is rendered as whole black... How can I fix this? Thanks.--Was a bee (talk) 20:48, 25 July 2018 (UTC)

@Was a bee:. Please use Commons:Commons SVG Checker before uploading if you expect error/problems, more details about the bug can be found: phab:T68672
✓ Done
 — Johannes Kalliauer - Talk | Contributions 22:47, 25 July 2018 (UTC)
@JoKalliauer: I use that checker. Thank you very much! --Was a bee (talk) 21:45, 26 July 2018 (UTC)

Commons is adding a background to PNG[edit]

Tracked in Phabricator
Task T198370

I uploaded File:Povray logo sphere.png. It has an alpha channel and no visible background. When I view the image in [3] there is an added white background behind the image. How can I fix this? Thanks. SharkD  Talk  00:52, 8 August 2018 (UTC)

There's nothing you can do about this, unfortunately. It's a new bug: phab:T198370. --El Grafo (talk) 08:02, 8 August 2018 (UTC)
Thanks. SharkD  Talk  01:21, 9 August 2018 (UTC)

SVG map needed[edit]

File File:Baltic-pipe-mapa-pogladowa.png showing graphics from https://www.baltic-pipe.eu/pl/o-projekcie/ was recently deleted due to copyrights of the underlying map. Can someone recreate the map using existing SGV maps like File:Regenbogen location map.svg + File:Poland location map.svg? A language independent version could be used by multiple articles in d:Q4852713. --Jarekt (talk) 17:44, 16 August 2018 (UTC)

SVG Translate tool revival and improvements[edit]

Hello! As requested in the Community wishlist survey, the SVG Translate tool is being revived and improved by the Community Tech team. I am the product manager for the project and am looking for input from people who work with SVGs on Commons/other projects and have experience with them. I have put together the project page for this project and I have some open questions on the talk page. I'd appreciate if you could take a few minutes to comment on them and point out anything I have missed. Thank you. -- NKohli (WMF) (talk) 17:57, 20 August 2018 (UTC)

Mockups posted[edit]

Hello again. We have posted a few mockups for the new tool on the project page. You can also see them below:

  • Link to tool from wiki

  • Find image on the tool

  • Translation view on the tool

  • Translate from

  • Translate to

  • OAuth login

We're collecting feedback on the proposed solution and the mockups on the talk page. Please comment there. Your feedback is helpful. -- NKohli (WMF) (talk) 23:34, 24 August 2018 (UTC)

Gallery/metadata software[edit]

Question for all you Commons users out there - what sort of gallery software do you use on your machines? By gallery software I mean summarising your collection of photos by date, folder and metadata tags. Currently I use Windows Live Photo Gallery, but it's no longer supported by Microsoft and is rather creaking under the strain of 24MP photos. I also use Geosetter for geocoding.

What I need the software to be able to handle is:

  • Hundreds of thousands of photos
  • Large photos, eg 30MP and above
  • Adding and removing keyword tags
  • Adding and removing people tags
  • Mass date adjustment
  • Filtering by date, folder, tags, camera, etc
  • Simple adjustments like rotating 90 degrees

Does anyone have any suggestions? -mattbuck (Talk) 16:25, 1 September 2018 (UTC)

Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons:Graphics_village_pump&oldid=318302542"