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)

Getting full resolution from Apple Photos on OS-X

I have been trying to upload photos taken with my iPhone X. I used to use the Commons app, but that is no longer supported. The method I am now using is to import the photos using Apple's Photos application on OS-X (everything up to date). I then export the photos from Photos as jpg files, which I then upload to Commons using the standard upload tool. Even at Photo's maximum jpg export setting I get reduced resolution. For example in File:Differential Analyzer CHM.agr.jpg, which I recently uploaded, the labels on the various controls appear crisp and fully legible on my Photos screen, but are somewhat blurry on Commons even when selecting full resolution. Is there another way to upload the file at the full resolution the iPhone produces? I have many more photos that I would like to upload at full resolution.--agr (talk) 15:47, 30 May 2018 (UTC)

@ArnoldReinhold: Have you tried backing up your iPhone to iCloud and then downloading the photos from icloud.com using a web browser?   — Jeff G. ツ _{please ping or talk to me} 06:06, 31 May 2018 (UTC)

@Jeff G.: Thanks for your suggestion. I looked at the same Differential Analyzer CHM.agr.jpg Commons file again today and it looks fine. There must have been some database delay in updating the higher resolution image I uploaded. It's a relief actually as I have a number of photos to upload and there are too many steps as is.--agr (talk) 16:25, 31 May 2018 (UTC)

@ArnoldReinhold: You're welcome.   — Jeff G. ツ _{please ping or talk to me} 17:55, 31 May 2018 (UTC)

SVG text rendered incorrectly despite using officially supported fonts

Hi,

meta:SVG fonts explicitly mentions DejaVu Sans and Liberation Sans. Also, Wikimedia pages themselves use the "Linux Libertine" font for section headings. The heading of this section is rendered in Linux Libertine!

I have created four SVGs containing text in Inkscape. The text should be easily editable using a text editor, the file should stay PD-ineligible, and the file size should not increase too much. For these three reasons, I do not want the text to be replaced by paths. Instead, I would like to use a font that allows correct rendering of thumbnails. I tried the three fonts mentioned above and failed.

The four SVGs: File:Smartscreen-warning-1.svg, File:Smartscreen-warning-1-arrow.svg, File:Smartscreen-warning-2.svg, File:Smartscreen-warning-2-arrow.svg

The text in these images has characters which overlap each other for no apparent reason. Instead of a normal text flow, characters are incorrectly moved to the left/right, causing them to stick together visually. It almost looks as if these characters are stored in the SVG one-by-one, each with a specific (wrong) position. This, however, does not actually seem to be the case, as opening the SVG with a text editor shows.

I tried searching the village pump archive and the Help:SVG page, but I might have overlooked something. If the issue is known, I would be happy about someone pointing me to a relevant FAQ entry or previously solved case. ~ ToBeFree (talk) 16:15, 6 June 2018 (UTC)

Additional note: The "more info" text has a "text-decoration: underline;" CSS attribute, which is rendered correctly in Firefox when opening the SVG. The MediaWiki thumbnail renderer, however, appears to completely ignore it. ~ ToBeFree (talk) 16:19, 6 June 2018 (UTC)

You've run into the librsvg small font-size quantization bug: Phab:T36947. Small font escapement and baseline placement have problems. For example, one of your files (File:Smartscreen-warning-2-arrow.svg) uses font sizes of 2.82222223px, 4.23333311px, 6.3499999px, 10.58333302px, 16.93333244px. That's small enough to tickle the bug.

For font-families, the list of supported fonts is not always right. I think your fonts can be found by librsvg, but they may not be found by other user agents (such as my browser). In any event, the font-family should include a generic font such as serif, sans-serif, or monospace.

The coordinate system used in the diagram is contorted (viewBox="0 0 132.29166 66.145833", translate(0,-230.85417)).

See also Help:SVG, Commons:Commons SVG Checker.

Glrx (talk) 02:03, 7 June 2018 (UTC)

Wow Glrx, this is amazing. Thank you very much for taking the time to explain all these points; I would probably never have found out!

I'm copying this to my talk page on en.wikipedia to remind myself of fixing these issues as soon as I can. The contorted coordinate system is a really strange thing. I was already surprised that Inkscape's SVG coordinate system seems to begin at the bottom left, but it made sense to me (mathematical x-y-coordinate systems do look like that). I have no idea where the crazy value of "-230.85417" comes from, and I will have a look at SVG manuals to learn what this "translate" attribute does. I'll inspect the source code and do a lot of cleanup there. The phabricator bug is also very nice to know. About the font-families, strange, I would have expected Inkscape to do that sort of thing automatically, at least for the very basic "serif" or "sans-serif" or "monospace" fallback. I wasn't aware that this is likely missing from all SVGs I have ever created!

The Commons SVG checker seems to be an awesome tool and just what I have been looking for, too. Thanks again! ~ ToBeFree (talk) 04:10, 7 June 2018 (UTC)

White space around SVG image

I uploaded a SVG file and did not notice it had a large white space around it. Do I start over or can I edit in Commons?

@BrucePL

— Preceding unsigned comment added by BrucePL (talk • contribs) 19:48, 6 June 2018 (UTC)

Hi @BrucePL:! You can overwrite existing files. If you don't have access to the original file anymore, you can download it from Commons. Edit it, possibly using a text editor or your SVG editing tool, correct the whitespace, and then feel free to "Upload a new version of this file". The link for that is available on the image page. ~ ToBeFree (talk) 21:19, 6 June 2018 (UTC)

Stripping metadata

Tracked in Phabricator
Task T20871

Wikimedia Commons strips IPTC metadata - descriptions, attribution, copyright management information and that sort of thing - from all but its “full resolution” downloads.

Note that I’m not talking about Exif camera logging information here. I’m talking about information that creators deliberately attach to their work to enhance its cultural value and to protect its copyright. (The same information that we require of all contributors, actually.) And note also, that we DO respect that information on ONE of the offered renditions of a photo.

Clearly, this is a bad thing. Karmically, it’s an unkind thing to do to contributors’ works. Legally, decisions are slowly marching toward the day when penalties for the removal of copyright management information will be applied specifically to the removal of embedded metadata. (And regardless of Terms of Use or Safe Harbor defenses.) At scale, those penalties can be ghastly. (As penalties should be, really. That’s the point of them.)

I doubt there would be any argument that we shouldn’t fix this. So, the question is: HOW do we fix this? WHO, exactly, needs to fix this, for that matter?

On most tiny little websites like mine, it’s a matter of a few minutes effort and it’s all fine. For a site this big, it could be a whole different kettle of fish. Or not, it could actually be easier. The first step is to figure out how to proceed.

Now, I’m also not addressing the fairly obvious question of why people - in droves - who are sharing works that depend on attribution would post them without taking the effort to write their names on them. (Ah, because they didn’t know that they could, let alone should?) That’s an education issue. But prerequisite to educating, scolding, and cajoling, we should make sure that we don’t delete contributors’ good efforts.

Education and encouragement is a conversation that we absolutely should have, but later, IMHO.

I advocate on this issue. I have a blog that’s full of sometimes-nerdy information on the subject: metadatamatters.blog

I’ll help in any way I can.

— Preceding unsigned comment added by Carlseibert (talk • contribs) 19:01, 21 June 2018 (UTC)

Hi @Carlseibert:, thanks for posting here. This particular feature has been debated for years now − you may see some historical information on phab:T20871.

To answer your question « would there be any argument against this », my understanding of why it’s being done is because EXIF take up a lot of space (in some cases bigger than the thumbnail itself).

Hope that helps, Jean-Fred (talk) 07:02, 22 June 2018 (UTC)

Ok, so I checked and there are some EXIF fields preserved in Thumbnails, including Author and Copyright.

@Carlseibert:, could you clarify which fields you would like to see preserved? I realise you said IPTC and I read EXIF :) but it would be helpful nonetheless to understand which fields matter and which not.

Jean-Fred (talk) 07:17, 22 June 2018 (UTC)

Hi @Jean-Fred,

Let me first do a little bit of background here for the benefit of anybody following along.

Descriptive metadata - IPTC metadata - is stored in two data blocks in an image file (JPEG here, but others are similar). This is the data that I would argue we're karmically and, almost certainly in the near future if not already, legally, obliged to protect.

The IIM block contains basic information, like the caption, author, copyright, title, and some workflow stuff. The IIM is tiny, usually no more than a few hundred bytes.

The XMP block contains duplicates of all of those fields, plus additional fields like Rights/Usage Terms and contact information for the copyright owner, and potentially a bunch more data about rights and model releases and the like. The XMP is padded to be a (usually) consistent size regardless of what's in it, generally a tad less than 4 KB.

Then there's the Exif block. Exif data is log data from the camera, plus (often) one or more thumbnail images, GPS data, and some image information like orientation and the original capture time. Exif data can often be less than a couple of KB, but because of the thumbnails, it is often in the 12 KB to 20 KB range. And I've seen corner cases that are huge, like hundreds of KB.

As far as I know, we preserve all three blocks on the full-size versions of images.

Most of the time, Exif data is no longer useful after the first couple steps in a workflow. I usually advise readers and clients who are concerned about page load time that they can feel free to delete it. (After first making sure that they've extracted anything they might later need, like maybe GPS data.)

However, Wikimedia Commons does care about Exif data, and we expose some of it on an asset's page. Whether the next person to use the image needs or wants that data in the downloaded file is a matter for consideration.

The XMP block can carry data other than descriptive IPTC data. Applications, like the Adobe programs, might write log data there, for instance. In rare cases, that can make the XMP block exceed 4 KB. Last year, I wrote about a photo where it was over 40 KB. That wasn't an issue in itself, but the information, in that case, was quite unhelpful. But again, that's unusual. Usually, we're looking at 4 KB.

There are three corner case fields in the Exif which are semantically equivalent to three IPTC fields. Cameras rarely write to them, and by the time a photo is ready to post or publish, these fields are normally irrelevant. I suggest for the sake of sanity, we shouldn't worry about them one way or the other.

By the way, some people refer to the IIM as the "IPTC/IIM". That's not incorrect. But it's confusing, so I don't do it. :-)

In general, any or all of the IPTC fields can contain copyright management information, and certainly I would argue that if a creator took the initiative to put certain data on an asset, we should respect it and pass it on. There's no point in picking individual fields to keep or strip anyway, since, barring considerable extra effort, the XMP block is going to be 4 KB regardless.

I'm assuming here that Wikimedia Commons creates the small renditions on ingest and storage is therefore an issue. Many DAM systems create renditions on output. If that's the case, it's a moot point.

I'm also assuming that we do actually want to bother with small renditions. I would never download one myself, but they must be popular, or they wouldn't be here. (I assume)

I see in the other thread you referenced that Wikimedia Commons runs on PHP. That means that there are two main choices for an imaging library: GD or ImageMagick. GD is pretty hopeless. It has barely any metadata functionality at all and by default simply strips the output file clean. ImageMagick by default preserves all the data in all three of those blocks. (And allegedly produces better quality.) On a WordPress or Drupal site, simply enabling ImageMagick makes most metadata stripping problems go away. It's possible that it might be that simple here.

I have encountered systems that use ImageMagick and strip metadata by (usually long forgotten) choice. In that case, changing the arguments for ImageMagick does the trick.

ImageMagick can easily strip the Exif wholesale and leave the IIM and XMP intact. (If we're able to pass arguments to it.) Whether it would be practical to try to address certain fields - like possible XMP application log data or the Exif thumbnails - granularly, is another matter. My guess would be no.

ExifTool can indeed do granular manipulations, but there would be development and server load costs. That said, the notion of appending a note that the image came from Wikimedia Commons to the caption or one in Special Instructions or Rights/Usage Terms explaining that the image is released under Creative Commons would be very attractive.

I guess that's a long-winded way of saying that preserving the metadata that we should preserve would cost about 5 KB per file, or 15 or so KB if we choose to keep all of the Exif data.

Hope this helps. - Carl

— Preceding unsigned comment added by Carlseibert (talk • contribs) 19:27, 28 June 2018 (UTC)

Hi Jean-Fred (Again)

In that referenced thread there was a lot of discussion about legality. I guess I should go ahead and contribute what I know about that. [Insert standard. “I am not a lawyer. This is not legal advice” disclaimer here.]

First, let me get two things off my chest.

In that thread, people were conflating IPTC data with Exif data right and left. That makes me crazy! And it makes it hard to have a meaningful discussion. They are two different things. Please, folks.

Second, this is an Open Source community. Legality here is secondary to moral consideration, IMHO. It’s not “what we can get away with”. For us, it’s “What is the right thing to do.”

That said, here’s what I know:

The Creative Commons license says: 1. If You Share the Licensed Material, You must:

    A.Retain the following if it is supplied by the Licensor with the Licensed Material:
       i.  identification of the creator(s) of the Licensed Material and any others designated to receive attribution, in any reasonable manner 
            requested by the Licensor (including by pseudonym if designated);
        ii. a copyright notice;
       iii. a notice that refers to this Public License;
        iv. a notice that refers to the disclaimer of warranties;
         v. a URI or hyperlink to the Licensed Material to the extent reasonably practicable;
             .....

All subject to the “reasonable to the medium, means, and context” qualification.

Is it “reasonable” to spend 5 KB of storage to retain data supplied by the creator and meet the requirements? My non-lawyer opinion is yes, probably. And my community opinion is that we should bend over backward to comply with our own license, just on general principles.

(If the trade-off had to be eliminating one of the five small renditions to make up the storage space, I would argue that to be a good trade.)

Sections 1202 and 1203 of the US DMCA make it illegal to alter or remove copyright management information conveyed with a work, provide definitions of CMI that look like they wrote the law with a copy of the IPTC standard open before them, and provide statutory damages for violations of $2,500 USD to $25,000 USD “per instance”.

There is no requirement for registration before infringement or infringement after notice to qualify for statutory damages. This is very significant because it means that copyright owners who otherwise wouldn’t qualify for statutory damages and therefore would have no means of compensating a lawyer now have the practical ability to sue.

Lately, there have been more and more infringement suits claiming section 1202 violations. There have been significant judgements.

Following the judgements, it seems clear to me that judges are applying more and more liberal definitions of what CMI is.

I haven’t yet seen a CMI removal judgement that explicitly refers to embedded metadata. Most of the cases so far focus on visible-to-the-naked-eye CMI, like watermarks and even notices printed elsewhere on web pages. But, having read the law, it’s pretty obvious to this non-lawyer that the day is coming.

I have a lawsuit on my laptop as we speak that IS explicitly about embedded metadata CMI and IS about a Creative Commons licensed picture. Downloaded from Wikimedia Commons, now that I think about it.

(That alleged infringer, who absolutely does strip CMI, BTW, could use as a defense that the victim would have to prove that the (ahem, alleged) infringer downloaded the full resolution version of the picture, rather than a CMI-less rendition of the image. Preserving metadata on all renditions would help protect our contributors. That’s a karmic argument, not a legal one)

In the thread, there was a 2015 quote from a Wikipedia lawyer who seemed to be asserting that Safe Harbor protections would apply to Wikimedia Commons here. It’s 2018 now. Safe Harbor has been wildly abused for years. People are sick of it. People apparently including some judges. Safe Harbor defenses have lately been knocked down like dominos. Considering the way Wikimedia Commons works, my layman’s opinion is that claims to Safe Harbor would be pretty weak in the first place. At this point in time, I wouldn’t bet a week-old donut on Safe Harbor, much less the future of my organization.

In the US DMCA - and just about every big country has one - it’s pretty explicit that a copyright owner can grant permission for the stripping of CMI from their works. So the big US social media outfits can hide their CMI stripping behind their terms of use, which extract a very broad license from contributors. In Europe, in Germany at least, apparently not so much. Last year, Facebook suffered an adverse judgement there for embedded metadata CMI stripping, nevermind the TOU.

It seems to me that the legal army is marching on copyright management information stripping. When, or if, it might overrun our village is anybody’s guess.

But, again, that doesn’t matter in my opinion. This website (and every website) should preserve authors’ data is just because it’s the right thing to do.

-Carl

— Preceding unsigned comment added by Carlseibert (talk • contribs) 23:25, 28 June 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).[1] -- 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)

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)