Commons:Graphics village pump

Shortcut
COM:GVP

Graphics community: Graphic Lab · Graphics Village Pump · Picture Requests · Photography Critiques · Photography terms

Welcome to the Graphics 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)

Commons Help desk Community-wide general discussion Copyright Proposals Graphics and photography discussion Image improvement Photography critiques Categories for discussion Deletion requests Undeletion requests OTRS noticeboard Translators' noticeboard Work requests for bots Contact administrators Vandalism User problems (Dispute resolution) Blocks and protections Bureaucrats' noticeboard CheckUser requests #wikimedia-commons webchat Commons mailing list (archive) Commons' bugs on Phabricator

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
Topic-specific archives /GIF thread

Diagonally striped pattern on svg country map

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)

File:Wikipedia15Logo.svg

Hi, hope this is the right place to ask. I need your help. The file is normal but seems bugged in preview.What can be the problem? Tal (רונאלדיניו המלך, talk) 22:50, 8 July 2018 (UTC)

@רונאלדיניו המלך:  Done  — Johannes Kalliauer - Talk | Contributions 07:21, 9 July 2018 (UTC)

Template:Valid SVG creates a link to the Markup Validation Service (W3C Markup Validator)

... which seemingly always generates a DOCTYPE Declaration Warning (if a DOCTYPE declaration is included in a SVG), while using a slightly different base-URL for the same Service does not produce such Warnings.

Take, for instance, an upload of which the source code is valid, such as:

• https://commons.wikimedia.org/wiki/File:Group structure and statistics of “Gourmet Master Co. Ltd.”, as of 31 December 2017 - 「開曼美食達人股份有限公司」的集團架構及統計，截至2017年12月31日.svg

If one uses this link to check the upload using the Markup Validation Service (W3C Markup Validator), then one receives no warnings at all ("Result: Passed").

On the contrary, if one uses the link auto-generated by the template https://commons.wikimedia.org/wiki/Template:Valid_SVG (namely, click on the hyperlink over the word "valid" produced by such a template at the Wikimedia Commons file upload page, and be forwarded to the same service but using a slightly different URL), then one receives the following warning ("Result: Tentatively passed, 1 warning(s)"):

Notes and Potential Issues

The following notes and warnings highlight missing or conflicting information which caused the validator to perform some guesswork prior to validation, or other things affecting the output below. If the guess or fallback is incorrect, it could make validation results entirely incoherent. It is highly recommended to check these potential issues, and, if necessary, fix them and re-validate the document.

DOCTYPE Override in effect!

The detected DOCTYPE Declaration "<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">" has been suppressed and the DOCTYPE for "SVG 1.1" inserted instead, but even if no errors are shown below the document will not be Valid until you update it to reflect this new DOCTYPE.

That is, of course, if one has such a DOCTYPE Declaration in the SVG file.

I am looking forward to your comments on this discrepancy.

P.S.: To specify whether or not any SVG is valid, and to specify the methods used to create any SVG, there are so many different templates, transclusion parameters, and options on Wikimedia Commons that I am close to calling it a mess. If one looks at the usage of those templates, one can also notice that: Commons users paste the boxes all over the place on the File Upload pages, and further more they often claim that some SVG is valid, while in fact it is not when you just check it. I wonder why the checking of the markup validation can not be automatized?

Kind regards, Vincent Mia Edie Verheyen (talk) 13:05, 11 July 2018 (UTC).

Hello Vincent Mia Edie Verheyen, this is because the W3C Markup Validator doesn't recognize SVG without DTD anymore (so the template has the option as default). This is only a warning you can ignore. You don't need to create your own template too, the problem is known and a solution is in search. -- User: Perhelion 13:50, 11 July 2018 (UTC)

@Vincent Mia Edie Verheyen: Thanks for the bug report. The {{Valid SVG}} template worked well until a couple months ago. That's when the W3C validator developed a bug and could no longer handle SVG files that did not have a DOCTYPE. The problem was reported to W3C, but W3C has not fixed the bug yet. Consequently, a workaround was applied to {{Valid SVG}}. The workaround instructs the validator to use the SVG 1.1 DOCTYPE, and that causes the DOCTYPE override message you see. The instruction gets the W3C validator to check all SVG files, but the check may produce warnings and errors that would not have been present a few months back. Ideally, W3C will fix its validator, but other options are possible. Glrx (talk) 14:42, 11 July 2018 (UTC)

@Vincent Mia Edie Verheyen: (I answered your same question on Test.svg too.) On this reason we want replace the W3 Validator with Nu: Special:Diff/310268927, especially phab:T68672#4406895. -- User: Perhelion 07:36, 12 July 2018 (UTC)

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

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

• is valid (checking using the “Markup Validation Service (W3C Markup Validator)”); as well as
• contains structured metadata (for more info, cf. “SVG 1.1 (Second Edition) – 16 August 2011 > Metadata” at “W3C Recommendation”).

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:

• 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

and W3C nu (non-DTD) validation will succeed

• https://validator.w3.org/nu/?showsource=yes&useragent=Validator.nu%2FLV+http%3A%2F%2Fvalidator.w3.org%2Fservices&acceptlanguage=&doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F9%2F9b%2FSVG_Test_TextAlign.svg

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

@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

     • https://validator.w3.org/ (select "Validate by Direct Input" and paste an SVG with internal subset)

   • 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:

     • https://validator.w3.org/check?uri=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F9%2F9b%2FSVG_Test_TextAlign.svg

     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:

   • https://validator.w3.org/nu/?doc=https%3A%2F%2Fupload.wikimedia.org%2Fwikipedia%2Fcommons%2F9%2F9b%2FSVG_Test_TextAlign.svg

   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)

Font issue

I recently made a plan for a stadium File:Northumnerland Development Project.svg to illustrate articles like Tottenham Hotspur Stadium. However I notice that lettering does not come out right in the thumbnail image in the article. I have no idea what the issue is, and as this is the first time I have ever made a svg file with Inkscape (and not a very good attempt at the job), I must have made some mistakes somewhere. Can anyone help? Hzh (talk) 12:05, 14 July 2018 (UTC)

@Hzh: You should use fontsizes above 20px (font-size="20"), see File:Fonttest-Kerning.svg. (You are using font-size="3.5" up to font-size="4.8") Inkscape uses different units and therfore displays different numbers, but if you open the SVG file in any texteditor you will see: font-size:4.12943888px, try to use at least font-size:10px.)  — Johannes Kalliauer - Talk | Contributions 15:28, 14 July 2018 (UTC)

I see that you have fixed the issue, thank you very much. I was learning how to use Inkscape as I go, so everything was done a bit haphazardly, but it's puzzling to me as fontsizes above 20px be seem too big for the figure. (I was also having problem using OpenStreetMap which is why it ended up as it is, but that's another issue). Hzh (talk) 15:54, 14 July 2018 (UTC)

@Hzh: The font-size is not your fault, the render does not work precisely. The Render-Software-Bug is fixed since March, but Updating the software on Commons makes some problems. (It's easier to correct the svg-files).

I increased everything (all lines, the image, the font,...) by a factor of 10.  — Johannes Kalliauer - Talk | Contributions 17:04, 14 July 2018 (UTC)

Excellent, thank you. I guess I need to make everything larger next time. Hzh (talk) 17:59, 14 July 2018 (UTC)

This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 17:04, 14 July 2018 (UTC)

How to fix Blacked SVG

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

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)