Commons:Graphics village pump

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Community portal
Help desk
Village pump
Administrators' noticeboard
vandalismuser problemsblocks and protections

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

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 Aug Sep Oct Nov Dec
Topic-specific archives

Request for feedback on map series[edit]

I've just uploaded this series of maps as part of w:NACIS' MapLift 2015 event. They're meant for the wiki pages of each island in the w:San Juan Islands archipelago, to replace the .pngs that are currently there.

I've had a hell of a time learning the quirks of SVG and librsvg rendering, and I'm not sure I'm entirely satisfied with the result. I'm also a little unsure if I've used the correct set of conventions for the subject. I'd like to gather critiques of these maps if they need improvement.

Hotshot977 (talk) 02:24, 2 September 2015 (UTC)

@Hotshot977: I'm not a map maker, but here are some things I noticed:
  • The blue of the coast lines is a bit intense for my taste – I'd try using the same color as for the "Haro Strait" etc.
  • The north arrow and scale bar are a bit too prominent for my taste
  • Please specify the source(s) of the geographic data you used. You surely didn't walk along all those coastlines with a GPS-tracker yourself, right?
--El Grafo (talk) 13:31, 11 September 2015 (UTC)

SVG not loading[edit]

Hi, I noted this SVG file I've created using an online tool years ago stopped rendering, or at least is not rendering in my machine. Does anyone have a clue about what is causing this? Note: I only know the most elementary basics about SVG, this was not meant to be a professional work, just a rapid workaround to vectorize that lettering. Thanks,--- Darwin Ahoy! 15:55, 8 September 2015 (UTC)

The image hasn't actually been vectorized; the file is an SVG containing a raster image. See {{BadSVG}}. That shouldn't stop it from rendering though; it displays normally for me. SiBr4 (talk) 17:02, 8 September 2015 (UTC)
It is also rendering for me (both the mediawiki PNG preview and the SVG itself) in Chromium on Linux. Storkk (talk) 20:25, 8 September 2015 (UTC)
I see, I also could render it on Chrome, the problem could be with FireFox (running in Windows10). I understand that what I've done is not the best practice, but I would like to clarify, is there any advantage at all in using that svg, instead of the original format (png I seem to recall, or a small jpg)? — Preceding unsigned comment added by Darwinius (talk • contribs) 11:49, 9 September 2015 (UTC)
FWIW, it renders fine for me in Firefox 41.0b7 in Windows 7. To answer your question, there is no advantage (that I know of) and some disadvantages. If I zoom in on your file, it pixellates - whereas a traced "native" SVG wouldn't. Storkk (talk) 12:58, 9 September 2015 (UTC)
IMO, SVGs with embedded rasters are worse than raster images, since the former are not anti-aliased by MediaWiki's SVG renderer, causing scaled-down versions to look really pixelled. Compare Flag of the Canadian Army.png (PNG) with Flag of the Canadian Army.svg (SVG with embedded PNG for emblem). Of course the best solution would be to create a real SVG version, though for now, replacing with the original raster would be best. SiBr4 (talk) 18:23, 9 September 2015 (UTC)
Thank you very much for your explanations, I'll replace the falsely vectorized image with the original raster version. I wish I could do a vectorized version of it, but I don't know how. I tentatively produced a truly vectorized image with Inkscape, which is now rendering in my machine. It's not the best looking thing in the world, but it's not ugly either, and seems to be nicer than the raster image, anyway.--- Darwin Ahoy! 08:30, 10 September 2015 (UTC)

Proposal SVG help button[edit]


I'm trying to improve usability of SVG contribution to Wikipedia. For that reason I suggested a SVG help button. See my proposal for details.

--Menner (talk) 07:26, 19 September 2015 (UTC)

It is a nice and useful script to improve file testing. But I doubt that it will "improve the usability of SVG contributions" in general. The usability which means the implication of WMcommons SVG files in Wikipedias, other wikis and third party projects is long time established and proven. -- MaxxL - talk 08:09, 19 September 2015 (UTC)
Simlifying file testing already improves usability of SVG since our SVG renderer has many bugs. Closer promoting of file testing reaches more people and gives them advice without asking. Promoting the village pump encourages people to ask if they can't solve their problems on their own.
-- Menner (talk) 07:32, 20 September 2015 (UTC)

SVG layers and translations[edit]

I would like to raise a few questions regarding SVG files that concern translations:

1.-I understand layers are discouraged in SVG files uploaded onto Commons. Is this correct? If so, is there no way/special format to have layers that can be later seen using the different programs available (I understand the problem with layers is not them per se but that the way each program stores them is different)? Can the SVG file be saved somehow in inskape so that layers are preserved but at the same time this is done in a way that makes those layers compatible with other software and not inkscape-specific?

2.-When it comes to translating SVG files, I find layers most helpful as I can usually hide any non-text objects and concentrate on changing the text layers. When dealing with a plain (i.e. non-layered) file I keep selecting the wrong object all the time as they are all grouped together, making selecting text difficult at times and much more time-consuming. I normally use inkscape for translations and would rather not resort to text editors to carry them out. The web translation tool has failed me quite often lately and I find it a bit unreliable. If my understanding in 1 above is correct and layers are not recommended in Commons SVG files, is there a recommended alternative graphic, fast and easy way to perform translations similar to the one I currently use when layers are in place (i.e. hide non-text layers and translate the test labels using inkspace)?

Thank you in advance for your advice.--Rowanwindwhistler (talk) 20:34, 22 September 2015 (UTC)

Where did you get the impression layers in SVG files were discouraged on Commons? This is not true! As long as layers are used in a reasonable way (and what you describe sounds reasonable) I don't see any reason not to use them.
There's one caveat though: Don't expect layers you create in one SVG editor to be recognized as such in another editor. The information that a specific group of objects should be a "layer" is often application specific. However in any case the SVG should still be rendered absolutely correctly! --Patrick87 (talk) 22:31, 22 September 2015 (UTC)
I may have misunderstood the paragraph but here it says: "To optimize compatibility across browser platforms it is generally best to save most SVG files in "plain SVG" format whenever possible.[...] In Inkscape, for example, plain SVG format removes layer information. For this reason you may wish to create a plain version just for uploading to Commons and retain an alternative ‘fancy’ master version for your own purposes,...". I understand this to mean "try NOT to upload layered SVG files but plain ones instead". Does it mean something else?
On the other hand I was not worried about a layered SVG nor rendering properly (most of layered files I have seen seem to do so without problems) but about having to choose between breaking a rule (by keeping the layers in place to make changes easier for future editors) and abiding by it and making any change rather cumbersome (at least at times). But if my understanding was incorrect and layers are welcome then there is no problem. Thank you!--Rowanwindwhistler (talk) 04:26, 23 September 2015 (UTC)
I'm not the one who wrote "NOT to upload layered SVG files", but from my experience, it means a "<g>" (group) tag which is defined as "layer" in Inkscape's definition, this is not recognized in W3 SVG specification and could cause miscommunication among SVG graphists. In one occasion, a user was unable to edit an SVG file in Inkscape but other users was unable to in non-Inkscape application. It turned out that Inkscape uses a self-defined attribute in <g> for "locking" that layer from editing in Inkscape (similar to Photoshop's layer lock). -- Sameboat - 同舟 (talk · contri.) 06:32, 23 September 2015 (UTC)
I think most of us agree on that we should try to upload files that are as "open" as possible and not specific to a program e.a Inkscape, Illustrator and so on. We that do graphic work in svg files has all had the same issue as the translators has when we are editing, making a derivative from a plain svg.
  • One can use switch element but to me this way has the same problem as doing it in a text editor. Different languages don't occupy the same length to describe the same thing, as we all know. So from my experience you very very often has to view and edit both the texts, size, placing and surrounding objects to get it all to work from a graphic point of view and to keep the legibility.
  • One way could be that we upload a version where we keep all the program specific information and tag it with the proper template to show this; Inkscape, Illustrator... Then we can create and add a new template "master" to this file. In the "master" template there has to be information on how to save the new language version or derivative work as plain svg ones it's done. It should also NOT be possible to upload a plain svg over the full master svg file. Maybe there also could be a corresponding "master" category where to store them.
  • I do see that this is not a perfect way and that it has disadvantages but I also see and understand the problems that exist now. --Goran tek-en (talk) 10:50, 23 September 2015 (UTC)
I think it's more productive if Inkscape uses a different extension (e.g. ".inkscapesvg") for containing their own metadata rather than messing with the general .svg format. -- Sameboat - 同舟 (talk · contri.) 14:33, 23 September 2015 (UTC)
I'm sorry Sameboat but I don't understand what you mean. We are not talking about changing anything just adding template and category? Please explain more so I (maybe more than me) understand, thanks. --Goran tek-en (talk) 15:17, 23 September 2015 (UTC)
I do not think that one should follow this recommendation blindly. First it says whenever possible, so one can argue when it is possible and when not :-) More seriously, the main reasons for using plain SVG is to avoid program's own information in the file which may give unnecessary information or create issues when decoded by other programs. It increases the size of the file too. However, svg is quite flexible format and using correctly additional namespaces should not be a problem. They can be easily ignored if they are not necessary. In this sense, minimum information can be added with a different namespace and should not be a problem. Personally I keep the Inkscape layer information in plain svg by adding the inkscape: namespace and preserving the attributes inkscape:groupmode="layer" and inkscape:label="layer-name".--Ikonact (talk) 12:24, 30 September 2015 (UTC)
It may be a silly question and I apologize in advance in case everybody else knows but: how exactly can that (I mean "adding the inkscape: namespace and preserving the attributes inkscape:groupmode="layer" and inkscape:label="layer-name"") be done from within inkscape (assuming it is indeed ok to generate a plain SVG AND at the same time preserve layers)? If preserving layers is ok provided they are kept at the same time a plain SVG is generated, that would be ideal for me (and I think for others creating translated SVG files), but I do not know how to do it. So I should say I have 2 questions:
1.-Are layers (or what inkcape calls layers anyway) really ok to keep in the end?
2.-If so, how do you add the namespace and the attributes from within inkscape (I am sure it come be done manually from a text editor, but I would rather not struggle with XML code)?
Thank you.--Rowanwindwhistler (talk) 14:52, 30 September 2015 (UTC)
This is exactly what I also meant by my question to Sameboat above.
I'm a graphic worker and I use a "see what you get" program for my work, I'm not in to code and that stuff more than what I really have to. To work with the xml code all the time is not something for me and I think it will scare of a lot of other graphic workers also. We really have to make things work for as many as possible and not just for a small specialized group of people. So at this stage I think it would be better with a template and category so you easily can find the files that are made for the purpose of easier translating, editing. This way we still can use all the different "standards" that all ready is in use, thanks. --Goran tek-en (talk) 18:29, 30 September 2015 (UTC)
I am not aware of other way than editing the xml. If you think the file will need further editing in Inkscape, then upload it as an Inkscape SVG and tag it with {{Created with Inkscape|IMPORTANT=yes}}. If the only issue is the translation than decide what is more important - layers for hiding any non-text objects or ensure better compatibility with more difficult way of handling translations. :-). --Ikonact (talk) 11:33, 1 October 2015 (UTC)

Problem uploading a derivative SVG map and errors validating the original one[edit]

Hello, I am trying without success to upload this map which is translation of this one. I tried verifying my version here but I get no errors (just warnings). When I try to validate my file as well as the original one here all I get is "That file doesn't appear to be an SVG file." (for both!). I am at at loss on what may be wrong. Could someone check and let me know what needs changing/removing? Thank you!!--Rowanwindwhistler (talk) 09:51, 2 October 2015 (UTC)