Open main menu

Wikimedia Commons β

Commons:Graphics village pump

(Redirected from Commons:GVP)

Community portal
Help deskVillage pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

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)

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

Diagonally striped pattern on svg country mapEdit

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-XEdit

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 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 fontsEdit


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. Face-smile.svg ~ 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! Face-smile.svg
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 imageEdit

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?

— 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. Face-smile.svg ~ ToBeFree (talk) 21:19, 6 June 2018 (UTC)

Stripping metadataEdit

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:

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.

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


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)Edit

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

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 (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" "">" 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 invalidEdit

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).[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 (, use its nu (non DTD-based) validator (
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" ""
<!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)

Font issueEdit

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)
Checkmark 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)