Wikipedia talk:Collaboration to convert graphs to SVG

Style guidelines

Colour
I'd like to see a rationale for any of the style guidelines. In particular I don't agree with either of the following statements.

"Avoid colour as much as possible. The graph should still be useable when printed then photocopied."
"Try to use the smallest discernible difference – e.g., clearly different shades of grey are better than red, green, and blue."

Since SVG can include media-specific CSS stylesheets, printable versions of graphs can be tailored to that medium. I don't know how MediaWiki implements SVG rasterisation but there's no reason it couldn't support that in the future.

It's particularly contradictory to juxtapose a point about accessibility for print with a point which is contrary to accessibility: people with poor eyesight may need very high contrast to discern differences when displayed in black and white. Careful use of colour could be very helpful.

Dates

"It's good form to contract the X-axis values where possible, so use, for example, "1996, '98, 2000, ' '04" rather than spelling each year out in full."

No, it's not. It's ugly. It's also contrary to the official guidelines for dates.

I'd also suggest some additional guidelines:

The source should be optimised for editability. For example, group elements intelligently, such as pie slices with captions, and do not rely on one element obscuring another to convey statistical information.

—The preceding unsigned comment was added by 81.179.70.169 (talk • contribs) 22:58, 3 July 2006.

Although I prefer using abbreviated dates ("1994, '96, '98, 2000, '02..."), for the sake of consistency, we should definitely change the format to Wikipedia's recommendation. (I do note, however, that the recommendation was more intended for article text, not graph labels.) El T 15:48, 21 July 2006 (UTC)[reply]

I was always told never *ever* to use contractions or "ditto" symbols in tables, charts or graphs (my area is math/CS), so I was rather surprised to read that bit about contractions being "good form". Phils 11:46, 25 July 2006 (UTC)[reply]

It's more a rule of thumb than a "never ever" thing. There's a lot of potential for confusion if you start abbreviating things, especially in tables. However, in the limited scope of the x-axis where the pattern is perfectly clear (especially if the contraction is marked with an apostrophe), then it lessens clutter on the graph, which makes the graph far neater. Using contractions and ditto marks has always been good form in well-designed graphs and tables. Spelling things out fully often creates clutter and conceals meaningful data. El T 14:25, 26 July 2006 (UTC)[reply]

Optimisation

Should the image look good in an application like Firefox or should it look good in an application like Inkscape? The example graph of Netscape use looks good in Firefox but the line widths look bad in Inkscape. —The preceding unsigned comment was added by 24.20.211.228 (talk • contribs) 04:42, 20 July 2006.

I say we should optimise for whatever Wikipedia's rendering engine is. I've seen the SVG graphs rendered at least five different ways (Opera, Firefox, Adobe SVG viewer, Adobe Illustrator, and Wikipedia's engine), and they're all slightly different. Wikipedia is the only common thread between us, so I suggest we optimise for its rendering engine. El T 15:48, 21 July 2006 (UTC)[reply]

Is there a reason not to go to one of the browser standards for svg rendering? At least that would mean that there was always at least one browesr that would always render it correctly. Also, it would probably not be too difficult to determine which browser someone was using and, if it was an open source browser, default to that specific browser's svg renderer. If not open source, then go back to the wiki svg renderer. Also, accepting code contributions for closed source browsers from the browser creator would allow the wikimedia svg renderer to accommodate closed source browsers, in keeping with wikimedia's neutrality policy Kencomer 01:29, 15 January 2007 (UTC)[reply]

Colour

Avoiding colour is a rule of thumb, rather than something cast in stone. There are four reasons to prefer B&W.

It's very hard to tell which colour combinations will be hard for colour-blind users, whereas no colour blindness causes people to mistake shades of black-white-grey. People whose vision is extremely poor can enlarge the image, or any web page.
Using B&W forces people with poor design skills to make graphs that look at least vaguely presentable, because it's quite hard to make something garish when you're avoiding colours.
A print-out of a page or graph (e.g., for personal reference or to hand out to a class) will often be printed in B&W, and will almost certainly be photocopied in B&W. It's much better for end users to be given a reliable form that doesn't require any mucking around to remain useful.
Colour is often used to create an abstract between a key/legend and the actual data when there are better ways of labelling.

Also, note that I did say the smallest clearly discernible difference, so quite similar shades of grey should be avoided. El T 15:48, 21 July 2006 (UTC)[reply]

Comments

Concerning #2. The majority of digital graphs are computer-generated, if not all of them. Someone with "poor design skills" can only ever make the mistake of choosing hues of colors that hurt to look at. There's no reason to enforce a militant look for graphs in lieu of a "might look like crap" safety net. Granted, color and style are not the most important aspects of a graph, but we should at the very least be encouraging individuals to follow guidelines for visual appeal, instead of nixing the aspect altogether. —The preceding unsigned comment was added by 134.174.110.5 (talk • contribs) 11:34, 7 August 2006 . ( User 134.174.110.5 performed a minor copyedit at 11:35, 7 August 2006 . )

Concerning #3. Why not just enforce CMYK-safe color palettes, or offer a Grayscale alternative version for printing? —The preceding unsigned comment was added by 134.174.110.5 (talk • contribs) 11:35, 7 August 2006 (UTC)

Response. Very few people know about CMYK-safe colours, let alone understand them. And print alternatives wouldn't work for most people, who just print the main article page and hope for the best. (El T 13:54, 9 August 2006 (UTC))[reply]

Using just greyscale wastes the hard-wired color perception and matching ability of the majority of the population; this ability can make graphs much easier understand and more appealing to a reader. Use colors that have different lightness, and they will appear different even to a color-blind person, and in a grey-scale printer. Provide a CMYK-safe color palettes and ask people to use them; they are easy to understand and to follow. -Pgan002 (talk) 06:06, 22 December 2008 (UTC)[reply]

Using colours can also add a meaning to a graph which isn't there. See [[1]] for example. The colour suggests some difference over the years which isn't there. I think some colouring can be attractive for readers, but it is easy to suggest things that are not there (Red is often perceived as negative, whereas green seems positive). So preventing colour use is a good thing I think. -Benjamin 15:37, 24 February 2009 (GMT) —Preceding unsigned comment added by 82.75.250.77 (talk)

Editability of code

I definitely agree that the code should be designed for legibility when editing, especially regarding the logical grouping of elements. El T 15:48, 21 July 2006 (UTC)[reply]

Vertivle lines

I noticed that none of the charts have vertical lines, can that be added to the standard? It may not look as nice but it makes the chart more useful. An example: Image:Population_of_the_United_States,_1790-2000.png (not svg but similar style). When did the population flatten out? Without knowing history and without holding a piece of paper to the screen it is very hard to tell which year. -Ravedave ^{(help name my baby)} 17:50, 22 October 2006 (UTC)[reply]

Automatic charts

I just made a suggestion at Wikipedia:Village pump (proposals) to generate chart automatically (in the Automatic charts section). The proposal might not stay there for very long, so here it is again:

We could keep data in separate text files (.dat). Then we could use a template or a special kind of link (just like the one to insert images) to create charts. For example, the world population could be kept in a file called world_population.dat which contains lines like the following:

1995 5674380

2000 6070581

2005 6453628

In the world population article, we would just add the following:

The template would generate an svg file which would then appear in the article.

So when the world population statistics come out for 2010, all we would have to do is add one more line to the .dat file and all the charts that use this data would get updated automatically. Another advantage is that the charts on Wikipedia would have a uniform look. Finally, generating all the charts from the same script makes it very easy to change the look and feel of all of them at once.

I just looked at the types types of charts available in OpenOffice.org Calc. Most charts fall into one of the following eight types:

lines
areas
columns
bars
pies
xy
stock

with a few variants for each type, e.g.:

normal
stacked
symbols

Of course there are many other possible options when you create a chart (e.g. the range of the x axis), but we could get by with a minimal subset at first. 64.229.249.9 22:09, 28 November 2006 (UTC)[reply]

Ugly

These charts are ugly. If we really want people to start moving to this way of doing things they should be something worth looking at. As far as color goes with printers, any modern printer should be able to correctly print a color image in greyscale. Also People with colorblindness aren't totally blind, we just need to pick colors that are separable to them. -Ravedave ^{(help name my baby)} 06:06, 30 November 2006 (UTC)[reply]

Suggestion for guidline

Would it be a good idea to note that you can use OpenOffice.org Calc to make SVG graphs. You just make them there, then copy and past into Draw, and export as SVG. Just seems like a good guidline to give since its quick and easy (although some modification will need to be done - like the text seems to get exported without any fill). I know they might not be particularly modifiable manually, but giving the source data means that they're still quick to regenerate if needed. - ^Рэд_хот^{(t • c • e)} 13:29, 21 January 2007 (UTC)[reply]

Open source tools?

I've made this graph using Ruby and SVG::Graph, and cleaned it up with Inkscape. But it seems clumsy (although I haven't delved too deep as yet). Any feedback welcome (For more details on how it was made, click it).

Writing or editing a ruby program isn't the easiest way to make a static SVG graph, especially when the output isn't quite right. Are there any good open source tools for making SVG graphs? I haven't seen many svg graphs around on Wikipedia. —Pengo 11:28, 22 February 2007 (UTC)[reply]

Template tweak

I've taken the liberty of tweaking your template a little; It now adds tagged images to Category:Images which should be in SVG format in addition to Category:Graphs to convert to SVG format. I thought this best for consistency's sake. If you all disagree, you may of course revert my edit. You might also want to post your rationale for doing so here, in case someone else gets the same idea. Thanks! --MithrandirMage 02:25, 20 March 2007 (UTC)[reply]

EPS to SVG?

Hi there. A couple of plots I've generated have been converted to SVG as part of this collaboration (not by me I should add). Rather than have someone else do it in the future, I thought I'd try myself, but need advice on the software to use. At the moment, I'm creating EPS plots and then converting them to PNG files for upload. Is there something I could use (preferably freeware) that could convert my EPS plots straight to SVG? Cheers, --Plumbago 11:12, 3 April 2007 (UTC)[reply]

pstoedit (http://www.pstoedit.net/) seems to do something, but it didn't work 100% OK for me. Mjancuska (talk) 22:02, 11 January 2008 (UTC)[reply]

You can use pstoedit in combination with Inkscape. which works ok./Lokal _Profil 14:24, 17 June 2008 (UTC)[reply]

The two graphs to convert to SVG categories

There are two different categories for graphs to be converted to SVG: Category:Graphs to convert to SVG format and Category:Graph images that should be in SVG format, are there any differences between these or should they be merged? --Surachit 20:47, 12 November 2007 (UTC)[reply]

Assistance with graph generation

File:Test2.svg

SVG test graph

I'm working on a graph in text for a new version of Image:MM PEF.svg and this is as far as I've got. Please assist with a correct version so that I can look at the changes and learn from it. Thanks. Dhatfield (talk) 14:00, 17 June 2008 (UTC)[reply]

Why not use Inkscape for editing?

It's a SVG editor, after all. Rp (talk) 08:50, 8 February 2010 (UTC)[reply]

I think it's because if the average person uses Inkscape he/she will just tinker around with moving lines around. We want these babies edited just with the code, so they're exact, and so they're easily editable by others who might spot a problem or want to update the graph. All you have to do if download the svg, and drag and drop ito on notepad and you can change any value! It's that easy. I think thats the point. I'm still learning how to tinker with these babies. I wish there was a bit of a tutorial to make things easier, so we could make our own....--Brianann MacAmhlaidh (talk) 09:40, 14 November 2010 (UTC)[reply]

Request

Can someone create a graph that can be used to plot the popularity of American given names? Social Security Online has a feature showing the popularity of names in the US [2]. It lists the Social Security number applications from 1880 to present, and lists the top 1,000 names ever year.

So could someone make a graph with the years 1880-2010 running along the bottom, and the ranking 1-1,000 running along the side (with 1 being at the top, rather than the bottom)? Then we could use that as a template, and with the data online, we can plug graphs for various name articles.--Brianann MacAmhlaidh (talk) 11:07, 14 November 2010 (UTC)[reply]

Graphs and colour blindness

Interesting tips (although, not knowing SVG programs, I was a bit surprised by the note on Inkscape). I see that many of the images to convert contain colours, contrary to the ideal suggested here; removing them where possible is probably good, but for the other cases I'd like to read some suggestion on how to make them readable by colour-blind users. I've asked this at Wikipedia talk:WikiProject Maps#Colour-blind users, please join the discussion there. --Nemo 19:04, 1 January 2013 (UTC)[reply]