Commons:Graphics village pump

COM:GVP

WELCOME TO THE GRAPHICS VILLAGE PUMP!

This Graphics village pump aims to be technical support forum for all the local Labs, graphists (graphic artists), and volunteers 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.

To have the opinion of graphists check

Illustration Workshop

Map Workshop

Photography Workshop

Video and Sound Workshop

Start a new topic

**Graphics village pump archives**
Monthly archives
2007	–	–	–	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2008	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2009	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2010	Jan	Feb	–	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2011	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	–	Dec
2012	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2013	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	–	Dec
2014	Jan	Feb	Mar	Apr	May	–	Jul	Aug	Sep	Oct	Nov	Dec
2015	Jan	–	Mar	Apr	May	Jun	Jul	–	Sep	Oct	Nov	Dec
2016	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	–	Nov	Dec
2017	–	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2018	Jan	Feb	Mar	–	May	Jun	Jul	Aug	Sep	–	Nov	Dec
2019	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	–	Nov	Dec
2020	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	–	–	–
2021	–	–	Mar	Apr	–	Jun	Jul	Aug	Sep	–	–	–
2022	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
2023	Jan	Feb	Mar	Apr	May	Jun	Jul	Aug	Sep	Oct	Nov	Dec
Topic-specific archives /GIF thread

Issues with E-road shields (Tabliczka set)

Tracked in Phabricator
Task T370044

The text of the E-road shields that use the "Tabliczka" format have suddenly become offset to the left: they used to be centred until recently. I wonder what is causing the error, and I also ask who has time to correct the alignment of all 263 shields in the set? (I am currently busy on other parts of Wikipedia) Best, --Minoa (talk) 02:51, 30 July 2024 (UTC)[reply]

@Minoa: Apparently the SVG renderer doesn't position non-uniformly scaled text correctly. I.e. there is a transform="scale(0.907522,1.101902)" attribute in the <text> node and removing it makes the text render in the same location as in Inkscape or in the browser.

I don't remember whether this is a known bug and I don't see an elegant way to fix this. If we simply move the text to the right, it'll be too far to the right once the bug is fixed. If we do remove the transform and adjust the position, the characters will have a less narrow shape. Converting the text to paths would solve the rendering issue, but it's just not elegant. TilmannR (talk) 15:41, 30 July 2024 (UTC)[reply]

The svg code could be greatly shortened to basic rectangle and text elements, avoiding the sodipodi and other declarations and complications that Inkscape introduced. But with 263 member files in this category, avoiding the rendering problem would be a grueling task. I'd be willing to do a prototype/model file for someone with more time and patience, though I'm not sure which font I should use in place of the disfavored fond-family, Arial. You might also seek advice at WP:SVG help] at en.WP. RCraig09 (talk) 16:47, 30 July 2024 (UTC)[reply]

For the record, I tried to reduce the size of the file and successfully validate the SVG code at File:Tabliczka E75.svg and File:Tabliczka E951.svg, but it appears that rsvg is scaling the text towards the left despite the text-anchor="middle" instruction. While it may be tempting to suggest modifying the view-box to have (0,0) at the middle, such a workaround is not possible for something like File:Integral image application example.svg. --Minoa (talk) 08:22, 31 July 2024 (UTC)[reply]

I believe TilmannR has diagnosed the issue. I believe the mechanism is as follows. RSVG is asked to center the text. It calculates the width of the text without scaling. Say that is 400 pixels. It then takes 1/2 that value to compute the starting point; the starting point is then 200 pixels left of the anchor point. Then it paints the text, but the scaling is applied while painting. If the scale factor is 0.9, then the text will be 360 pixels wide. The text will appear shifted to the left by 20 pixels. (If the scaling is 1.1, then the text would appear shifted to the right.)

It is a bug in the renderer, so I would ask WMF to fix the renderer rather than tweak the SVG. Fix stuff where it is broken. One check would be whether this bug is present in the most recent version of RSVG.

If the SVG is worked around, I suspect using an x scale factor of 1.0 would avoid the bug; the y scale factor could be different from unity.

Glrx (talk) 14:58, 31 July 2024 (UTC)[reply]

x scale > 1, y scale = 1 does shift to the right. x scale = 1, y scale > 1 does not do as I expect (shifts to the left!).

Glrx (talk) 15:32, 31 July 2024 (UTC)[reply]

I wish to ask if there is already a Phabricator report for this issue? --Minoa (talk) 15:36, 31 July 2024 (UTC)[reply]

User:JoKalliauer diagnosed this problem in Phab:T370044. Glrx (talk) 17:14, 31 July 2024 (UTC)[reply]

See also: https://gitlab.gnome.org/GNOME/librsvg/-/issues/1109 (titled: transform of Text in Pattern with text-anchor="middle" not centered). I hope that they will correct the issue soon because I have a plan to compact and validate the SVGs in the Tabliczka set. --Minoa (talk) 09:24, 4 August 2024 (UTC)[reply]

For the record, I have marked this topic as active (using {{DNAU}}) until the issue is fixed. The impact of the bug is substantial, because my plan to upload optimised SVG E-road shields has been postponed until I know for sure how the Wikimedia Commons will render them. --Minoa (talk) 07:41, 24 August 2024 (UTC)[reply]

@Minoa: Support for condensed fonts is mixed, but I got a reasonable result with

  <text
     style="font-size:84px;font-weight:bold;font-stretch:condensed;text-align:center;text-anchor:middle;fill:#ffffff;font-family:sans-serif"
     x="105"
     y="95"><tspan>E002</tspan></text>

See File:Test.svg 2024-08-24 15:45

Glrx (talk) 15:56, 24 August 2024 (UTC)[reply]

Note: Similar issues have been reported on

cmɢʟee ⋅τaʟκ 00:59, 31 July 2024 (UTC)[reply]

Tartan namespace

There are so many files in Tartan images that should use vector graphics that I've been building a toolforge application to edit them: adjustyoursett.toolforge.org. (This is an example of its output.) (This is the repo.)

Here is my problem. I figured it would be a sensible plan to have the SVG files be machine-readable, so you could load a tartan SVG back into the tool and make changes. Therefore, I invented a tartan namespace. But then I discovered that Commons blocks namespaces it doesn't know about. This is fair enough, but is there any way of adding to the namespaces allowed? It would be possible to go back and change this to a microformat, but I think using a separate namespace for annotation is closer to the spirit of XML.

Thanks for listening. Marnanel (talk) 21:29, 12 January 2025 (UTC)[reply]

@Marnanel: So WMF has a meta:Community Wishlist for proposing those sorts of things. I kind of think that a proposal for an XML namespace might be more likely to elicit a broader community support. The idea would be that it recognizes , allowing for WMF to create interpreters to allow direct display of things like graphs, or text documents in one of the XML document formats. But users could also build novel XML formats, like ‎<tartan>...‎</tartan>, and then there would be ways of building interpreters for converting novel XML formats to supported media types. One of my pandemic ideas was to do this exact type of project, and I even created with a javascript interpreter for creating SVG tartans. I was able to create some valid SVG tartans in the process, but I realized the process was going to be pretty onerous. But if you are in this for the long run, and this seems like an idea you'd be willing to pursue this kind of broad idea, I would absolutely support it and love to be involved. Van Isaac (en.wiki) 06:21, 9 February 2025 (UTC)[reply]

Some old Inkscape files shrunk

Some old SVG files are displayed too small, so they have a right and bottom margin.

Example from 2010 (and non-example from 2011)

Left: inkscape:document-units="mm", width="307.28000pt"

Right: inkscape:document-units="px", width="200"
(When I choose "physical output" for this image, I will introduce the wrong margin.)

Probably this has to do with the change from 90 to 96 DPI in Inkscape version 0.92, which happended in 2017.
When such a file is opened in Inkscape, one has to choose a method to scale it.

When "digital artwork" is chosen, one has then to resize to content. (I did that for File:Flagge Rastow.svg.)
When "physical output" is chosen, the size is automatically corrected. (I did that for File:POL Świętochłowice flag.svg.)

Inscape message

[This file] was created in an older version of Inkscape (90 DPI) and we need to make it compatible with newer versions (96 DPI).
Tell us about this file:

[ ] This file contains digital artwork for screen display.
[ ] This file is intended for physical output, such as paper or 3D prints.

[ ] The appearance of elements such as clips, masks, filters, and clones is most important.

[ ] The accuracy of the physical unit size and position values of objects in the file is most important.

We've updated Inkscape to follow the CSS standard of 96 DPI for better browser compatibility; we used to use 90 DPI.
Digital artwork for screen display will be converted to 96 DPI without scaling and should be unaffected.
Artwork drawn at 90 DPI for a specific physical size will be too small if converted to 96 DPI without any scaling.
There are two scaling methods:

Scaling the whole document: The least error-prone method, this preserves the appearance of the artwork, including filters and the position of masks, etc.
The scale of the artwork relative to the document size may not be accurate.

Scaling individual elements in the artwork: This method is less reliable and can result in a changed appearance,
but is better for physical output that relies on accurate sizes and positions (for example, for 3D printing.)

More information about this change are available in the Inkscape FAQ

For my images I know that they were shown correctly, when I uploaded them. So something has changed on Commons.

What went wrong, and how can this be fixed? Watchduck (quack) 12:52, 6 February 2025 (UTC)[reply]

Looks like the SVG files are in error because they used mixed units.

The first example file specified its size in points (e.g., "307.28000pt"):

<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://creativecommons.org/ns#"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="307.28000pt"
   height="223.89000pt"
   id="svg8621"
   sodipodi:version="0.32"
   inkscape:version="0.46"
   sodipodi:docbase="C:\Programme\Inkscape"
   sodipodi:docname="Relation1011.svg"
   inkscape:output_extension="org.inkscape.output.svg.inkscape">

However, the drawing is done with pixels, a somewhat arbitrary unit. A pixel on a laser printer might be much smaller than a pixel on a screen. For a nominal size of a pixel, SVG adopted the CSS pixel. In SVG 1.1, there were 90 pixels per inch. That definition later changed to follow CSS 2.1 which has 96 CSS pixels per inch (72 points per inch with 1 pixel = 0.75 point → 96 px per inch). Inkscape changed to follow the changed specification. That's why Inkscape issued the message about 90 and 96.

If the width and height had been specified in pixels, there would not be a margin.

If the actual width were to be 307.28 points, then the SVG should have used the viewBox attribute to specify the viewport size in pixels.

Glrx (talk) 16:34, 9 February 2025 (UTC)[reply]

@Glrx: It is no surprise, that there is something wrong with code produced by Inkscape. But it's what most people use to create vector graphics.

People only see and care, how an uploaded graphic looks. And it seems quite reasonable to expect, that graphics will always look the same.

So maybe the PNG rendering on Commons should take the Inkscape version into account?

The alternative would be, to correct all inconsistent SVG code. But how? Could a bot do that? --Watchduck (quack) 18:04, 9 February 2025 (UTC)[reply]

I expect Inkscape to produce reasonable SVG now. You got bit because you made the diagrams when pixels were 90 to the inch.

A robot could identify old Inkscape files from the Inkscape version attribute. inserting a viewBox attribute might fix all files, but I'm not sure.

Glrx (talk) 22:28, 9 February 2025 (UTC)[reply]

I changed mediawiki to be 96dpi instead of 90 dpi a little while ago [1], so probably my fault. Bawolff (talk) 01:45, 12 February 2025 (UTC)[reply]

Searching creators of ribbon bars for medals

See Category:Ribbon bars. This post is also somewhat related to en:Wikipedia:WikiProject Orders, decorations, and medals.

I’m looking for someone (one or more volunteers) that would be interested in creating ribbon bar graphics (preferably SVG). Unfortunately, my own graphic skills are very limited, and I haven’t been able to get my head around SVG software. At least not yet…

I could set up a user sub page where anyone could place requests on the talk page, and those who’d like to participate would follow the talk page and respond if they like to take the job. A request must include one or more external links to photos or illustrations of said medal / ribbon bar along with some info (country, name of award etc.). Of course, as all types of Wiki work, taking a request is based on volunteering.

The vast majority of requests would be "clean" ribbon bars without devices or clasps, and therefore pretty simple tasks, for those who master the graphics software. However, some requests would naturally include such a device too, and some requests could be to modify existing graphics, by adding devices to it.

Creating graphics for the full medals is not on the main scope here, but if someone would like to do that as well, it’s of course perfectly OK.

If I get a few answers here in the Village pump, I will set up the mentioned request board, and post a couple of requests to get it started. If this should be set up elsewhere, for instance related to the WikiProject linked to at the start of the post, I’m open for suggestions. I’ve also put a link to this post on the WikiProject talk page. 1000mm (talk) 16:05, 8 February 2025 (UTC)[reply]

Need help with .svg map

File:2027 AFC Asian Cup qualification map.svg has an incorrect border between Pakistan and India in the north of those 2 countries. The border should look like it does here: File:AFC blank map.svg. I'm new to working with .svg files, and while I've figured out how to change fill colors and make other small modifications, adjusting borders is still beyond my abilities. Is anyone here able to help with that or point me in the direction of where I can find help? Wburrow (talk) 15:49, 17 February 2025 (UTC)[reply]