Commons talk:SVG guidelines

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

The proposal itself has been moved to the accompanying Project page instead of this talk page.

Discussion[edit]

As a diagram creator myself, I am very familiar with these issues and I wholeheartedly support the implementation of these guidelines. SVG diagrams are fundamentally different from photographs, and truly require a different set of standards by which they can be evaluated. Commons is replete with photographs, and that is great... But photographs of whatever technical quality or interesting composition are always created in an instant. An SVG diagram can take days, even weeks of deliberate and meticulous work to finally create, and to evaluate the second in the terms of the first is downright foolish. Let's give people the right tools to properly evaluate SVG diagram work— these guidelines will do just that! KDS444 (talk) 04:04, 5 August 2013 (UTC)[reply]

+1 Very cogent points, great overview, this was needed a long time ago already. -- Tuválkin ✉ 02:57, 6 August 2013 (UTC)[reply]

Breathtaking imagery Kelvinsong, this is wonderful work. Awesome. ! absolutely brilliant. Penyulap ☏ 22:29, 5 August 2013 (UTC)[reply]

A very good idea, thanks for that! I agree with most of the points mentioned, so here are just some thoughts:

  • Fonts: Converting text to paths and adding an invisible text layer is probably a good idea for drawings with huge amounts of text, but in general should be avoided if possible for the reasons given at Help:SVG#Fonts / text. For example, there's no good reason to convert the little bit of text in this ugly diagram to paths. If text is not converted to paths, fonts from this list should be used to make sure mediawiki can create proper thumbnails.
  • Validation: What about Help:SVG#Validation? Should {{Valid SVG}} be mandatory? There seem to be some problems associated with that …
  • Might be a good idea to re-read Help:SVG – just to avoid contradictions.

Cheers, --El Grafo (talk) 09:52, 6 August 2013 (UTC)[reply]

{{Valid SVG}} should definitely be mandatory, anything that isn't doesn't represent our best work. darkweasel94 11:57, 6 August 2013 (UTC)[reply]
About validation—My test has always been "if it renders, it passes". I ran some of my Featured pictures through the validator, and it gave me a bunch of cryptic errors like Inkscape element grid not allowed as child of Sodipodi element namedview in this context. (Suppressing further errors from this subtree.) or SVG element g not allowed as child of SVG element clipPath in this context. (Suppressing further errors from this subtree.). There are very few resources on how to deal with these problems—a google search on 'invalid svg' mostly returns bug reports and complaints about Adobe Illustrator SVG export. I am not convinced that there even exists a tool that outputs 100% valid code 100% of the time.—Love, Kelvinsong talk 16:46, 6 August 2013 (UTC)[reply]
Now if the only validation errors come from the validator trying to validate non-SVG namespaces such as inkscape:, sodipodi: or ooo:, I think we can tolerate those. But if it's actual SVG errors, we shouldn't. darkweasel94 17:08, 6 August 2013 (UTC)[reply]
Then what counts as an 'actual SVG error'? I guess the 'Inkscape element grid' doesn't count, but what about the clipPath error? It was generated by inkscape, but not an Inkscape specific feature.—Love, Kelvinsong talk 20:00, 6 August 2013 (UTC)[reply]
The clipPath error is an actual SVG error because a clipPath can only contain paths, texts, basic shapes, and clones referencing those elements, not groups. If Inkscape generates that, it's a bug in Inkscape and should be reported if it hasn't already been - but imagine if a photo with ugly artefacts or whatever were put up for FPC with the excuse "the software I used created that, it's not my fault". (That actually happened recently, it was about color spaces.) The author can relatively easily remove most invalid code using a text editor, and an SVG that isn't valid definitely doesn't represent our best work, which is the point of FPC. darkweasel94 20:28, 6 August 2013 (UTC)[reply]
Agreed. I'll add this to the technical section.—Love, Kelvinsong talk 20:49, 6 August 2013 (UTC)[reply]

Fonts[edit]

I see that examples concerning fonts have been added. In fact, what do you think is preferable: "font-family:'DejaVu Sans';" or "font-family:sans-serif;"? I tend to prefer the latter but some tools, such as Inkscape, have problems creating that so it sometimes needs to be done in a text editor. (Inkscape totally messes up "font-family:'DejaVu Sans,sans-serif' so that's not an option.) darkweasel94 18:22, 6 August 2013 (UTC)[reply]

What are you talking about? You can just type in "sans-serif" in the Inkscape font box, and it will use the default sans font on your computer. However, I would strongly recommend "font-family: "DejaVu Sans"" because bad stuff happens when you're not specific with fonts, like colliding text, overflow, etc.—Love, Kelvinsong talk 20:00, 6 August 2013 (UTC)[reply]
Yes that works, but there are some bugs when you do that - for example, try making the font bold after doing that. There are various degrees of this not working depending on your OS. See Inkscape bug 1088475. darkweasel94 20:28, 6 August 2013 (UTC)[reply]
Ok, then I don't think we should add this because there is no single good solution other than text to paths.—Love, Kelvinsong talk 20:49, 6 August 2013 (UTC)[reply]
Man, I just know that back when I tried to submit my first diagram for featured picture candidacy on Wikipedia, the thing I got slammed on was that it wasn't an SVG. I then learned to use Illustrator CS6 (I had been using Photoshop for my entire life before that) and resubmitted the image as an SVG but damned if the font wasn't Arial, a copyrighted fontface, and so wouldn't pass muster. I then tried to modify the SVG code manually by removing every instance of "Arial" or "ArialMT" or any of the other variations on the Arial font, and adding font family: sans serif in its place, but doing this would not actually produce a sans serif font and I would have my text come out with whatever the browser liked best that day. Weeks and weeks later I figured out how to correctly utilize Deja vu sans, which was a good substitute for Arial and isn't copyrighted, and I have now settled on that for any/ all future diagrams (unless I can be convinced otherwise). I am not enough of a technical expert to explain exactly why font family: sans serif wouldn't work for me, but I spent hours and hours messing with it and got nowhere and eventually gave up and switched fonts. God forbid some other hapless soul should someday wander where I did. It was a morass. I wonder to this day if I would have been saved so much headache if someone had just pointed me to Deja vu sans at the outset. KDS444 (talk) 07:25, 8 August 2013 (UTC)[reply]
So do you think it's worth adding a section recommending specificity in font referencing?—Love, Kelvinsong talk 20:29, 8 August 2013 (UTC)[reply]
Yes, I think it is worth telling diagram-creators a specific font to use— not that other fonts aren't just as viable or aesthetic, but so that when someone just wants to be told what font to use, he/ she can pick one and be done with it. It should be a copyright-free font, and it should be a sans-serif font, and it should be a readily available font. That would have been sooooo very helpful! XO, KDS444 (talk) 07:25, 15 August 2013 (UTC)[reply]
Well, I am a huge fan of open source libre software in general, but I've never really liked libre typography. Nothing can beat Frutiger, Univers, etc. That being said, my fav free fonts are Roboto, Open Sans, Ubuntu, Liberation Serif, and Helvetica (apparently that's also a free font).
Roboto I haven't used this font much but it seems pretty. Its the standard "Android font". However, it seems to be hated by the typographical community on a scale near that of Comic Sans. So the only problem is risking out reputations b using this font. Also it's free, but not installed on the Wikimedia servers. It has lots of weights available.
Open Sans This font has been gaining popularity on a disturbing scale. Google and Mozilla have both picked it up, so anything using it may be subconsciously associated with Google. Its Light weights are pretty but the bold weights are poor. This font is not installed on Wikimedia's servers. It has lots of weights available, but not on Wikimedia's servers.
Ubuntu Anyone with an Ubuntu operating system has this font. It is a very pretty font and Wikimedia has it, but it may be "too exotic" for heavy duty use. It only has four weights I think (Light, Regular, Medium, Bold).
Liberation Serif I love this font, it's sooo beautiful. Unfortunately it's a serif font, so its not good for screen display nor science-stuff. It also only has two weights (Bold and regular) severely decreasing its usefulness.
Helvetica I think Wikimedia has this font, but it didn't render right. It's cliché yet still seems to have maintained its reputation as a "professional font". Anyone with an iDevice has this font (albeit hard to extract).
—Love, Kelvinsong talk 14:40, 15 August 2013 (UTC)[reply]

"Wow" factor[edit]

Evidently we disagree about whether a "wow" factor should be required for FP. This has long been a criteria which sets FPs apart from QIs, and it is not specific to photographs, so I expect that voters will use it, whether or not you put it on a technical instruction list. I'd prefer to acknowledge upfront that this is commonly understood to be in the desirable criteria for all FP. --99of9 (talk) 07:30, 7 August 2013 (UTC)[reply]

I don't want to add "wow" factor because I'm afraid it will be interpreted as "only stuff that's bright and shiny" will pass and people will oppose on grounds like "this is too boring; make it glossier or something." I think the current guideline is enough—"make the projected shape more interesting but don't go and add unnecessary decorations". The FP File:Phone.svg is a good example of why we should avoid stuff like this. A phone may be boring and easy to photograph, but it's a tricky shape to draw in SVG. No need to make it glowing orange. We're not an advertising agency.—Love, Kelvinsong talk 14:42, 7 August 2013 (UTC)[reply]

Internationalization[edit]

Suggestion: add something about not being language-specific unless you have to. So that the same diagram can be re-used without translation on many language projects. --99of9 (talk) 07:35, 7 August 2013 (UTC)[reply]

Are you talking about using numbers instead of words? Personally I think that significantly reduces the readability of a diagram because you constantly have to look back and forth between the picture and a key and it's easy to get confused that way.—Love, Kelvinsong talk 14:48, 7 August 2013 (UTC)[reply]
I am not sure where I stand on this: I have put together and submitted diagrams with numbers as well as letters with the intent of making them usable in other languages-- this actually has happened more than once as a result-- even an image in which I used colors to indicate different parts got used in a foreign language wikipedia. On the other hand, though they are more recent and haven't had the same opportunity to be used in terms of time, no one has ever used any of my SVG files in a foreign wikipedia. Sure, the option is there, if you just open up and modify the code, but really, the frequency with which an editor in Hungary is going to be willing to bother to do this is, in my experience, virtually nil. We could suggest to potential diagrammers that if they are interested in the likelihood of their work being seen on other wikipedias, then they should consider using numbers or letters instead of full words, but the ability for an English speaker to interpret one of my more complex files would be a nightmare in numbers or letters only. I am torn on this one, and I have struggled with it from both directions with no clear answer so far. That means this probably should not be a criterion for FP status on Commons. KDS444 (talk) 07:52, 8 August 2013 (UTC)[reply]
People who are serious about using your SVGs in a foreign language and who understand the subject generally will open up your file and modify your code. Here are French and German translations of several of my images: File:MMX with optical resonators fr.svg, File:MMX with optical resonators DE.svg, and File:Kundig_experiment_DE.svg. If they aren't serious and/or don't understand the subject, I don't think it makes a difference, as for example this diagram File:Michelson interferometer fringe formation.svg which appears untranslated on the Persian Wikipedia at [this url] with a misleading caption. Using numbers or letters wouldn't have helped in internationalization. If they are going to get it wrong, they are going to get it wrong. On the other hand, I used only letters and numbers in this file, File:Kennedy-Thorndike experiment DE.svg, but the German text accompanying the figure, although very accurate in describing the experiment, doesn't reference my lettering at all! So overall, I'd say this whole thing about using letters and numbers rather than words is a non-issue and should not be a criterion for FP status on Commons. Stigmatella aurantiaca (talk) 07:51, 24 August 2013 (UTC)[reply]

I presume "Clean up Document" is a feature of a specific editing program, which should be noted. --99of9 (talk) 07:37, 7 August 2013 (UTC)[reply]

Yes, I've added a clarification. It's an Inkscape specific function.—Love, Kelvinsong talk 14:48, 7 August 2013 (UTC)[reply]

One neglected internationalization issue that concerns me is that on many Wikipedias, transparent backgrounds in thumbnails render the same shade as the caption area rather than pure white. The result is generally quite ugly. I've had to add opaque white layers to a number of my images, for example File:Kennedy-Thorndike experiment DE.svg on the German Wikipedia. The same thing happens on the English language Wikipedia in image collection groups such as galleries, but I don't really care about tiny gallery images being of lower quality. But there are other image collection groups on the English Wikipedia that have the same issue. Stigmatella aurantiaca (talk) 08:01, 24 August 2013 (UTC)[reply]

Well this sounds like a problem for all the other wikipedias to fix. And didn't we already like discuss this? But for most transparent diagrams, I think the template {{Plain image}} is best, which doesn't have the gray background.—Love, Kelvinsong talk 18:17, 24 August 2013 (UTC)[reply]
{{Plain image}} is nice, but how do you go around informing users that "plain image" is the preferred template for displaying your images if they don't want a gray background? And how many years will it be before the other wikipedias upgrade their software? We have to adapt to the reality that bugs exist in the software that we use and to work around the bugs. Just as we regularly need to convert text to paths and to use a text editor to remove spurious "flow" elements, adding white layers just seems to be one of those annoying steps which really shouldn't be necessary, but we have to do it anyway if we don't want unpleasant things happening to our images. Stigmatella aurantiaca (talk) 03:35, 26 August 2013 (UTC)[reply]

RFC[edit]

(If it wasn't already) I'm starting the Request for comment for adopting these guidelines and listed it at {{Centralized discussion}}.—Love, Kelvinsong talk 16:42, 9 August 2013 (UTC)[reply]

Quality images vs. featured pictures[edit]

This is an issue that's been raised above, but I think it's an important one: what should, for SVGs, be the difference between quality images and featured pictures? The current guidelines say that they are about featured pictures, but then go on to talk mostly about issues of technical quality. If this is to be analogous to COM:IG, I suggest we say something similar to what that page says. The current "Significance" criterion is similar to the "wow factor" criterion for photographs, so it could be taken out of the main guidelines and added somewhere in the top explaining that it's applicable only for FPs but not necessary for QIs. Any thoughts? darkweasel94 23:16, 14 August 2013 (UTC)[reply]

Wait are you talking about the Interest criterion or the Significance one? Cause 99of9 was saying something similar about the Interest criterion. For the difference between FP and QI, I would say that for Quality Image, only the Technical criteria plus 2.2, 2.3, 2.7, 4.1, 4.2, and 4.3 need apply.—Love, Kelvinsong talk 00:16, 15 August 2013 (UTC)[reply]
do you think any of it can be adapted to suit animation or gifs and CGI ? I don't know there is much said about such things. Penyulap ☏ 07:02, 15 August 2013 (UTC)[reply]
No, I've done CGI, and it's radically different from SVG. We would need an entirely different set of guidelines for that regarding stuff like Topology, Texturing, Render quality, Resolution, F-Curves (the time-dimension; if applicable), etc.—Love, Kelvinsong talk 14:02, 15 August 2013 (UTC)[reply]
What is the "Interest" criterion? I didn't find a criterion with that name. The "Significance" criterion is about the work's complexity: a QI could still be a QI if it is very simple but passes the technical tests, an FP would need to be more complex. At first glance at least, your list of criteria to distinguish between FPs and QIs seems ok however. darkweasel94 07:27, 15 August 2013 (UTC)[reply]
(Sorry, I changed "Interest" to "Depth"— I meant well, I did). KDS444 (talk) 07:31, 15 August 2013 (UTC)[reply]

Here's my take on it. I'd say "wow factor" is essentially "Is it publishable in a magazine/journal?" For photos, that would be "Is it National Geographic worthy?" For illustrations, "Could it have plausibly come from a copy of Science (or similar)?" -- King of ♥ ♦ ♣ ♠ 04:48, 24 September 2013 (UTC)[reply]

I like it! KDS444 (talk) 19:39, 24 July 2014 (UTC)[reply]

Illustration critiques[edit]

Somewhat related to this - do we have something analogous to Photography critiques for SVGs? If we don't, we should create it, perhaps together with this guideline. I'm currently working on something to submit there. :) darkweasel94 23:41, 30 August 2013 (UTC)[reply]

Wrong venue[edit]

Were you just trying to get your ducks in a row before presenting this to FPC or was the idea to impose it upon that project. I ask because a discussion here seems out of place and all too isolated from FPC. Saffron Blaze (talk) 04:16, 3 December 2013 (UTC)[reply]

I think you may be assuming bad faith by saying this. If you feel this discussion is isolated from FPC, then how can it be brought closer? I totally support a closer connection between this discussion and the FPC process. Please indicate what steps should be taken to incorporate it and then let's do that. Imposition is not/ was never the goal, the goal was/ is to improve the tools available to others and create a set of criteria for evaluating the quality of SVG images, which I do not think anyone thinks is a bad idea. KDS444 (talk) 19:36, 24 July 2014 (UTC)[reply]
Retrieved from "https://commons.wikimedia.org/w/index.php?title=Commons_talk:SVG_guidelines&oldid=145038340"