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

Map of state highlighting a county

Something has happened to the Wikimedia Commons state maps highlighting a county. The maps used to show the entire state and its counties, with the highlighted county in red. Now, the map of the state, and all the counties except the highlighted county, is gone. Examples are the maps in the Wikipedia InfoBoxes for Battle of Charleston (1862), Battle of Cove Mountain, and Battle of Fayetteville (1862). There are others. All of these maps used to show the entire state divided by county. The state was white with borders in black. The highlighted county was a solid red. Now, the only thing that appears is the red part. Looking at only the file "Map of West Virginia highlighting Fayette County.svg" in WikiMedia, it says the English version is used in over 40 pages. What happened? Will it be restored? TwoScarsUp (talk) 19:36, 21 June 2024 (UTC)[reply]

The SVG is flawed. I get the same display using Chrome.

id="West Virginia" is not a valid XML id attribute.
a clipPath may contain a use, but the use may not reference g element. See SVG clipPath Element which states, "If a use element is a child of a clipPath element, it must directly reference path, text or basic shapes elements. Indirect references are an error and the clipPath element must be ignored."

Furthermore, the id="state_outline" is not stroked. The code is

<use xlink:href="#state_outline" fill="white" stroke-width="298" />

Although it supplies a stroke-width, it does not supply stroke="black". A use element does not acquire the context of the surrounding g group. It does seem to work, though.

Better practice uses the defs element.

It's also simpler to use CSS.

Quick fix just neuters the clip-path="url(#state_clip_path)" attribute so no clipping is done.

Category:Locator maps of counties of West Virginia is full of problem maps.

Glrx (talk) 23:15, 21 June 2024 (UTC)[reply]

Yeah, I'm seeing the same thing in basically all the states. Was there a change to the SVG to PNG interpreter rolled out recently? Van Isaac (en.wiki) 04:29, 22 June 2024 (UTC)[reply]
Yes, but that is not the problem. The SVG source does not validate and does not work on modern browsers. Glrx (talk) 04:38, 22 June 2024 (UTC)[reply]

Is there anything I can do to fix individual files on my watchlist? The coding discussion is "over my head". TwoScarsUp (talk) 15:50, 22 June 2024 (UTC)[reply]

Looking at Category:Locator maps of counties of the United States by state, these states are affected:

California, Colorado, Florida, Kansas, Kentucky, Louisiana, Maine, Maryland, Massachusetts, Michigan, Minnesota, Mississippi, Missouri, Montana, Nebraska, Nevada, New Hampshire, New Jersey, New Mexico, New York (1 file), North Carolina, Ohio, Oklahoma, Oregon, Pennsylvania, Rhode Island, South Carolina, Tennessee, Texas, Utah, Vermont, Virginia, Washington, West Virginia, Wisconsin, and Wyoming.

That's 1,000 files.

Glrx (talk) 22:29, 22 June 2024 (UTC)[reply]

Converting diagrams.net images to SVG without "http://www.w3.org/1999/xhtml" namespace?

I've created a diagram in diagrams.net (a.k.a. draw.io) and exported it as an SVG. However, MediaWiki rejects the file due to http://www.w3.org/1999/xhtml being an "illegal namespace." It is my understanding that this is due to phab:T62771. I tried to remove the namespace declarations from the SVG file, but this completely breaks the image.

Is there a tool or script that can convert .drawio files to SVG without the disallowed namespaces? Ixfd64 (talk) 23:31, 24 June 2024 (UTC)[reply]

I posted about this issue earlier this year, and the solution at the time was to select "Convert labels to SVG" under Text Settings. However, the Text Settings option seems to have been removed. One of the maintainers said it has been replaced by the "Embed Fonts" option, but the SVG file now contains the blocked namespace whether or not "Embed Fonts" has been checked. Ixfd64 (talk) 21:29, 28 June 2024 (UTC)[reply]

Ability to distinguish "D" on map on cell phones

I am requesting more replies here:

Wikipedia talk:WikiProject Maps#Ability to distinguish "D" on map on cell phones

--Timeshifter (talk) 00:27, 29 June 2024 (UTC)[reply]

Resources for accessible color palettes?

I've found several places where Wikipedia and Wikimedia docs stress using color palettes that are high-contrast and not problematic for color-blind users, but aside from a link to the Visicheck tool (which FWIW is not working ATM) I've struggled to find any concrete resources for creating an accesible palette. Aside from simply trying something and subjectively interpreting the Visicheck rendering, is there a good starting point anyone could recommend, or relevant docs I've overlooked? I am trying to improve an existing SVG infographic with a problematic color palette, and as the current colors are not semantically relevant it would be nice to just fix everything rather than changing the most problematic couple colors and hoping it's good enough! Walkersam (talk) 05:21, 3 July 2024 (UTC)[reply]

Consider w:ColorBrewer palettes, which include colors designed for use in maps, and used in other applications such as w:Warming stripes (see File:20180522 Color palette for warming stripes - ColorBrewer 9-class single hue.svg). Warmng stripes originator w:Ed Hawkins (climatologist) has been concerned with accessibility for the colorblind. RCraig09 (talk) 05:35, 3 July 2024 (UTC)[reply]

Coat of Arms not rendering correctly

File:SmithArms (of Thomas Smith II (1682-1728), of Broxtowe, Nottinghamshire).svg is rendering for me as a blank white (or transparent) shield, instead of "Or, a chevron cotised sable between three demi-griffins couped of the last the two in chief respecting each other", which appears if I open the file in Inkscape. All png preview renders seem to be affected by this. I guess it was working fine when it was uploaded (in 2020) by @Lobsterthermidor. Has the SVG renderer changed since then? ‑‑Yodin^T 22:23, 8 July 2024 (UTC)[reply]

The SVG file is bad.

The SVG renderer on Commons has changed — it has become more standards compliant.

The SVG file has many clipPath elements such as

    <clipPath clipPathUnits="userSpaceOnUse" id="clipPath5758">
      <g id="g5762" inkscape:label="Layer 1"
         transform="matrix(0.28222223,0,0,0.28222223,-4.1791951,15.378085)" style="fill:none">
        <path sodipodi:nodetypes="ccscssc" inkscape:connector-curvature="0" id="path5760"
           d="M 79.678451,149.81749 H 646.03583 v 258.58398 c 0,285.48607 -283.17773,397.82031 -283.17773,397.82031 0,0 -196.71555,-78.03561 -262.23435,-269.31836 C 87.532751,498.68407 79.678451,455.94392 79.678451,408.40147 Z"
           style="opacity:1;fill:none;fill-opacity:1;fill-rule:nonzero;stroke:#000000;stroke-width:3;stroke-linecap:round;stroke-miterlimit:4;stroke-dasharray:none;stroke-opacity:1" />
      </g>
    </clipPath>

The problem is clipPath elements may not have g elements in their contents. Only simple shapes such as rect and path or a use that references a simple shape.

https://www.w3.org/TR/SVG11/masking.html#EstablishingANewClippingPath

https://developer.mozilla.org/en-US/docs/Web/SVG/Element/clipPath

Inkscape should know better.

Glrx (talk) 03:21, 9 July 2024 (UTC)[reply]

Thanks 👍 I've uploaded a new version removing the clipPaths and it's now rendering as expected. I also tried to find other files affected by this, but CirrusSearch doesn't seem to allow searching within text files. Do you know if there any bots that might be able to find others like this? (I'm surprised the SVG renderer doesn't keep track of errors, and put broken files into a category.) ‑‑Yodin^T 08:19, 9 July 2024 (UTC)[reply]

There are many other files. Many maps have the issue.

Other files can be found by running a validator on the SVG and looking for a similar error:

W3C nuValidator on original (broken) SVG shows the errors

A validator will find SVG syntax errors, but that does not necessarily mean the SVG will display incorrectly.

It is also easy to find these errors using JavaScript and the SVG DOM. Commons SVG Checker might also look for this problem.

Glrx (talk) 14:09, 9 July 2024 (UTC)[reply]

SVG Grafik wird nicht angezeigt

Hallo zusammen, könnte sich bitte einmal jemand diese SVG ansehen? In mehreren Browsern wird diese nicht dargerstellt. Ein Reset auf die Version vom 13.10.2018 war nicht erfolgreich, obwohl in der Versionsgeschichte das noch erfolgversprechend aussah. Ich danke euch! --An-d (talk) 20:09, 25 July 2024 (UTC)[reply]

1 April 2019 version uses an undefined namespace (xlink). The SVG is broken. I added the xlink namespace. Glrx (talk) 20:34, 25 July 2024 (UTC)[reply]

Now the file displays sometimes but not others. I'm getting "too many requests" errors, so it may be transient. Glrx (talk) 20:52, 25 July 2024 (UTC)[reply]

FYI: The 20:35 and 20:37 versions do not display for me, either, even after flushing cache and refreshing. (Chrome Version 126.0.6478.183) RCraig09 (talk) 21:19, 25 July 2024 (UTC)[reply]

Yes, now they are consistently not displaying after flushing wiki and local caches. Glrx (talk) 21:35, 25 July 2024 (UTC)[reply]

Agreed. Though I'm not sure what "flushing wiki (cache?)" means... not just my browser cache. RCraig09 (talk) 22:19, 25 July 2024 (UTC)[reply]

Flush wiki cache: file?action=purge. Tell the servers to purge their cached PNGs. Force the wiki servers to recreate PNGs. Glrx (talk) 22:35, 25 July 2024 (UTC)[reply]

PNGs seem to be working now. For instance,

https://upload.wikimedia.org/wikipedia/commons/thumb/f/f1/DEU_Landkreis_Mueritz_Flag.svg/1280px-DEU_Landkreis_Mueritz_Flag.svg.png

Glrx (talk) 22:37, 25 July 2024 (UTC)[reply]

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]

Note: Similar issues have been reported on

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

Retouched or wierd artifacts?

File:Катер специального назначения П-474 695 на дне ВМФ 2024.jpg, taken during the annual Russian military parade in Sankt Petersburg 2024 has some ominous stuff going on. The blueshirt crewmen fourth and six from the left seem to have other parts of the image blended over them, same can be spotted near the stern of the ship, where the rigid inflatable boat is stored. I am well aware of an increased need for security measures concerning publications during wartime, but whatever they tried to hide here - it could have been done less sloppy. Or could this just be a technical phenomenon, linked to converting an image file or some graphic software? Alexpl (talk) 13:07, 1 August 2024 (UTC)[reply]

@Alexpl: I cannot imagine that this is a technical problem. Specifically the bit under the crane is not simply a circle, but looks like a lightly feathered stroke with a clone brush. TilmannR (talk) 04:21, 4 August 2024 (UTC)[reply]

@TilmannR: Yes, that seems to be what the uploader used - in a random and incomprehensible fashion. Alexpl (talk) 13:08, 4 August 2024 (UTC)[reply]

The XML in the uploaded file could not be parsed

I'm trying to upload a new version of File:Sieve of Eratosthenes animation.svg, but every time I try to do it I'm getting "The XML in the uploaded file could not be parsed". I'm just adding <text systemLanguage="pt" xml:lang="pt" x="356" y="29" style="font-size:12px">Números primos</text>. Vinickw‍✉ 17:00, 3 August 2024 (UTC)[reply]

xml:lang is not needed, and each string set must be in a switch tag, e.g.

<switch>
 <text systemLanguage="pt" x="356" y="29" style="font-size:12px">Números primos</text>
 <text x="356" y="29" style="font-size:12px">Prime numbers</text>
</switch>

Good luck, cmɢʟee ⋅τaʟκ 17:16, 3 August 2024 (UTC)[reply]

The last file upload was in 2015. If I try to upload the file, I get the same error you did. The SVG validates except for 3 minor errors. I believe the file is being rejected for using set. A security scan (added since 2015) probably sees that element and gives up. It is worried that somebody might do malicious things with it. I will need to look further. Glrx (talk) 18:18, 3 August 2024 (UTC)[reply]

@Glrx: You mean all those 179 sets? I don't even know how asvg works, and the rsvg's thumb doesn't even display as intended, so I think I'm not going to fix this. Just converting it to a gif will do the trick. Even though, thanks. Vinickw‍✉ 19:39, 3 August 2024 (UTC)[reply]

set is a SMIL tag used for interactive SVG and shouldn't cause trouble unless the parser is broken. cmɢʟee ⋅τaʟκ 20:06, 3 August 2024 (UTC)[reply]

P.S. File:Comparison of notable bridges SMIL.svg for example, uses set and works fine. cmɢʟee ⋅τaʟκ 20:14, 3 August 2024 (UTC)[reply]

I've used SMIL animation, too.

I edited the file a little and then tried to upload to File:Test.svg. I get the error "%error_body_content%". Glrx (talk) 23:47, 3 August 2024 (UTC)[reply]

Phab:T371424 for %error_body_content%. Glrx (talk) 23:51, 3 August 2024 (UTC)[reply]

I did some minor cleanup (title and desc elements; remove CDATA; add spaces to CSS; promote some text attributes to the switch) , added pt, and was able to upload the file. Glrx (talk) 00:24, 4 August 2024 (UTC)[reply]

I can upload the previous version (no changes), too. I do not see what was broken. Glrx (talk) 00:33, 4 August 2024 (UTC)[reply]

The file was UTF-16. I wonder if WMF's XML parser cannot handle that or if a BOM was missing. Glrx (talk) 02:55, 4 August 2024 (UTC)[reply]

Well done with the debugging, Glrx!

Some "HS icons" SVG files are broken

Hello, I noticed that some SVG files in Category:HS icons (namely File:HSContribs.svg, File:HSEmail.svg, File:HSHome.svg and File:HSSubpages.svg) are broken. Browser complains about some undefined namespaces. Od1n (talk) 18:22, 3 August 2024 (UTC)[reply]

The SVG files are broken. They must define the namespaces. WMF's old rasterizer used to ignore missing namespaces, but that's the wrong thing. https://www.w3.org/TR/xml-names/ says

Namespace constraint: Prefix Declared

The namespace prefix, unless it is xml or xmlns, MUST have been declared in a namespace declaration attribute in either the start-tag of the element where the prefix is used or in an ancestor element (i.e., an element in whose content the prefixed markup occurs).

Glrx (talk) 18:33, 3 August 2024 (UTC)[reply]

@Od1n: I added

xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd" xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"

to the <svg> tags of the files. Alternatively one could have removed all attributes that start with sodipodi: or inkscape: from the files. TilmannR (talk) 04:07, 4 August 2024 (UTC)[reply]