Commons talk:Transition to SVG

Please remember that this talk page is not for questions and answers. It is intended for discussing improvements to the Commons:Transition to SVG page.

For general help on SVG see Help:SVG The best place for questions and discussion about SVG is the Graphics village pump

Internationalization

SVG also has the advantage that it is possible to internationalize a picture's text. Now, I don't expect mediawiki supposts SystemLanguage, but it is part of the standard. [1]—Mobius 18:44, 9 December 2007 (UTC)

I expect. It will be very easy to implement. It is possible to use "uselang" attribute to make things happen. But will they? BPK (talk) 01:15, 8 August 2011 (UTC)

There's a patch for this, so yes, it's being worked on, FTR. Jarry1250 (talk) 20:21, 20 July 2012 (UTC)

Blur & Clones

The page claims that the gaussian blur filter is not supported; yet it does render (although rather buggily) in images such as Image:WP CSI image.svg. Stannered 16:17, 27 January 2008 (UTC)

It does not seem that buggy to me; On the other hand I seem t have problems with < use > (clones in inkscape) see Image:Portable Radio.svg for an example of working blur, and failing to render gradient in clones)

--Inkwina (talk • contribs) 16:55, 22 March 2008 (UTC)

It doesn't appear that bad in larger images (or scaled-up images), but in smaller images (or scaled-down images) it's very noticeable - the blurred object is mispositioned upward and to the left (as if it is mistaking the post-blur Left and Top co-ordinates with the pre-blur ones somewhere along the line). It often makes drop shadows invisible and outside glows asymmetric and fugly. Stannered 17:12, 22 March 2008 (UTC)

For example, look at this: Stannered 17:14, 22 March 2008 (UTC)

I too have noticed the bugginess of gaussian blur. One pixel in size makes a huge difference to the outputted image. I think it might be because my gaussian blur has a stddeviation>3. Anyway, here is my example:

Lightsaber Example

-- Tkgd2007 04:24, 9 April 2008 (UTC)

Hmmm, does look funny at those sizes, I was comparing to Firefox which does not seem to render the blur at all :-( But are you seeing the problem with clones in Image:Portable Radio.svg or is it just me? the grid should be black not red! FF renders this correctly. Anyway what can be done about it? I think we should try and collect a couple more examples and submit a few bug reports. --Inkwina (talk • contribs) 07:19, 9 April 2008 (UTC)

Yes, I can see the problem (and it renders properly in Opera, too). Just about any image that uses a visible Gaussian blur can be made to show the Gaussian blur problem (the blur will also disappear at smaller pixel sizes - OK for shadows which you can't see at the smaller sizes, but disastrous for images like Image:Wiki notes.svg where I'd tried to blur the grey treble clef (see the old revisions). Stannered 09:49, 9 April 2008 (UTC)

Mediawiki uses Imagemagick to render SVGs, which in turn uses librsvg. This is an open source project and relies on all of us to report bugs, if bugs are not reported to the developers then they will never be fixed! I have reported the one to do with blurred objects vanishing, please do the same for any other bugs which you come across. Bitplane (talk) 01:16, 2 January 2010 (UTC)

VectorMagic starts charging

See [2]. Should we note this? Suggest something else? Marnanel 02:55, 23 February 2008 (UTC)

Yes, I think we should. Both, if possible. Globbet 09:33, 23 February 2008 (UTC)

Sizing of non-free images and logos under Fair Use Rationale

Some instructions need to be added on how to control the size of thumbnails that doesn't make a mockery of the "low resolution" criterion of the Fair Use Rationale when uploading SVG images of logos, official seals, etc. While it's true that an SVG image can be smoothly scaled to almost any desired size, even big enough to fill a billboard, the default size presented in Wikipedia projects should be kept small to stay within the spirit of the rule. However, I haven't been able to find any information here in the Commons on how to limit the thumbnail preview to a specific size.

Most Infobox templates that I've encountered have a default image size of 220 pixels wide. It seems reasonable that the default size of SVG images that are under Fair Use Rationale should also be constrained to 220 pixel width, or smaller. The way to do this in Inkscape, I recently discovered by experimentation, is to apply a Transform/Scale operation to the entire image, set the units to "px" (pixels), check the "Scale proportionally" box, and then enter the actual pixel width desired in the Width box. Save or save-as the modified SVG file, then upload it to Wikipedia or Wikimedia Commons. As some SVG images are created by tracing a bitmap sample — the bigger the better — they acquire the pixel dimensions of the prototype, which can be HUGE. Once the artwork has been completed, this is a way to get it back down to reasonable preview size. —Quicksilver^@ 20:18, 21 May 2010 (UTC)

Marker-Tag?

Apparently the restriction is no longer present or not in general?

• 
• 
• 
• 

To give just four examples. Who has a bug example? -- Perhelion (talk) 19:05, 15 November 2010 (UTC)

I have complains about this policy

Well, as author of an PNG image that other user forcibly converted to SVG version of poor quality and now attempting to replace original image in some Wikipedia articles, I have complains about this policy. Firstly, I think that SVG maps are bad image format compared to PNG. It is not possible to achieve certain standards with software that is designated for creation of SVG maps. Photoshop that can create PNG maps is undoubtedly superior to Inkscape or similar softwares. Also, there are many problems with SVG images: in original form, they cannot be viewed with some image viewing softwares, and if they are converted to PNG during download, their quality becomes even more bad. So, is there a way that SVG policy is modified a bit? I think that many other authors would be frustrated that PNG maps that they created are converted to crappy SVG versions of low quality. The current policy will prevent many people to draw something for this site. I do not see what problem some of you have with PNG maps? If they are free for use and accurate, I do not see a single reason why they should be converted to SVG. Due to that, is there a way that conversion of existing PNG images to SVG becomes "more difficult" i.e. that the users who would want to "convert" the image should be obligated to discuss whether author/uploader of original PNG image agrees with that conversion? If deletion proposals are discussed like that, why not "conversion to SVG"? The two processes are much similar by my opinion. PANONIAN (talk) 09:04, 22 January 2012 (UTC)

I also disagree with claim from this page that SVG images "could be edited more easily". On the contrary, I find editing of SVG images very difficult especially because they could not be edited with Photoshop software. For me, modification of an PNG, JPG, GIF or any other image compatible with Photoshop is much more easy than modification of an SVG image. PANONIAN (talk) 15:45, 22 January 2012 (UTC)

It's not necessarily easier or harder to create an SVG vs. creating a raster (they just use different skill-sets). However, it's often easier to edit an existing SVG (to translate into a different language, etc.) than it would be for a raster. I can understand not wanting to learn an entirely new way of doing things, but in several ways vector is kind of the wave of the future... Meanwhile, no one can "forcibly" replace a raster without going through a formal deletion nomination. Otherwise, it's really up to the individual Wikipedias which version to use. AnonMoos (talk) 05:27, 27 January 2012 (UTC)

Well, I can agree in one thing: it might be more easy to translate descriptions in SVG maps in other languages. However, this advantage is not a large benefit compared to various disadvantages of the software that is used for creation of SVG maps - there are some things that simply cannot be done with Inkscape and the problem of lower accuracy and lower level of details in SVG files remains (not to mention problem with transparent background of downloaded SVG files and problem of impossibility of viewing of such files with some image viewing softwares). I am only saying that SVG format should not be "imposed" here like this. It is one thing if there is a recommendation for users to use this format, but this recommendation should not be an obligation and we certainly should not replace PNG files of good quality with their SVG versions of much lower quality and accuracy. The second problem is the fact that some users misunderstood the SVG recommendation and they are actually believing that it is an obligation instead recommendation. What is a bad consequence of the pro-SVG policy? There are people who prefer to use PNG files instead of SVG. I am also among those people and it is not only that I prefer to draw maps in PNG format, but I also prefer to download maps created by other people in that format (my favorite image viewing software does not support SVG and therefore I consider SVG files completely non-useful for my collection of 40,000 maps that I collected over the years). Nevertheless, some people who creating maps for Wikipedia in non-SVG formats would be frustrated by the fact that some other users "converted" these files into SVG format (often of lower quality than original file) and are aiming to replace original image with that file. Due to the fact that I released maps that I created into public domain, I am aware of the fact that these files are completely free for further modifications and editing. Usually, I do not object if somebody change these maps in constructive way i.e. if changes that other users made in these maps are obvious improvements. However, if somebody aims to replace original PNG file with its SVG version of lower quality, that certainly cannot be described as an improvement and it is rather something that many other authors would describe as a "spoilage of their work". This will certainly destroy motivation of these authors for further contributions to this project, which certainly would not be a good thing. PANONIAN (talk) 06:51, 30 January 2012 (UTC)

Copying a free picture

I run a Mediawiki site. I like the Creative Commons release. I check the copyright. But if I try to copy a free picture that is SVG, it does not copy. I try to import it into my wiki, but it does not look correct. All I can do is copy the entire page and then crop out the picture. So you have destroyed the Creative Commons free and released to the public. My wiki is informational only. I make no money or any compensation in any form. 26Blue.com kitchen remedies.

Use Cases and Technical Considerations

For consideration and discussion:

1. SVGs are being naively "optimized" using text editors.

2. A significant proportion of "optimized" SVG files cannot be imported into common vector graphics applications.

3. "Optimized" SVG files are missing critical metadata for end users, such as practical object names and usable hierarchies.

3. A file that cannot be imported into common vector graphics applications and further manipulated is useless as a public resource.

4. The primary goal of providing SVG files is to make images available to the public for further manipulation and to be used in their projects, not to optimize the page load times and memory consumption of Wikimedia Commons.

5. Care needs to be taken to ensure correct colors are used for key resources, such as flags. It may be necessary to use Lab color space and wide gamut profiles to achieve this. Optimizing SVGs for use on web pages (sRGB profile) is incompatible with providing them as reference grade graphics resource files.

Evidence for point 2: all versions of "File:Flag of the United States.svg" archived on Wikimedia Commons cannot be imported into Adobe Illustrator CC 2014 (nested groups exceed application limitations) and cannot be manipulated with Inkscape 0.48.5 (incomplete feature set for layers and groups). Therefore, graphics designers using Microsoft Windows-based computers cannot make use of this resource without significant effort to correct errors. "File:Flag of New Zealand.svg" can be imported into Adobe Illustrator CC 2014 but does not have sensible hierarchical structure.

Evidence for point 5: The most recent versions of "Flag of New Zealand.svg" and "Flag of Australia.svg" do not use official colors. I suspect this is also true of "Flag of the United States.svg" and "Flag of Japan.svg", but I need to look deeper into it, especially as the Japanese specification uses the Munsell Color system for which there are no conversion formulae (and commonly available lookup tables are inadequate). — Preceding unsigned comment added by Paul Coddington (talk • contribs) 10:42, 28 September 2014‎ (UTC)

I mainly disagree with this:

1. This must be clarified, "naiv" is not really an argumentation.
2. If the SVG is W3C valid this is a problem of the SVG applications. Hierarchical structure is completely useless for GUI applications. I really don't see how can this be "sensible" in a flag graphic!? This is only for text-editors and they should have XML syntax-highlight (and maybe primitive automatic structure tidyup)
3. Most SVG are bloat of from native own special syntax from the SVG applications, so it is also completely useless for other applications. In some cases SVG can be tagged to protect this special code.

   Metadata can have useful information, but they should always be the same as in the filepage.

4. Completely redundant argument to 3. On the contrary optimization often solves problems and saves expensive (load and) computing time.
5. I could be agree with the "reference grade", but this is always case by case, so we can never make any general assessment. A color-profile could be useful, but an external inclusion is at the moment not possible (general restricted).

↔ User: Perhelion (Commons: = crap?) 11:18, 28 September 2014 (UTC)

I have to say that I'm mostly in agreement with Paul. Text editing rarely helps with images that are going to be manipulated with GUI programs, which of course the vast majority of graphists use. There is a particular mindset currently held by a minimal, but very vocal, number of editors that smaller equals better. I'm afraid that's an illusion. Images exist for two reasons, to be seen, and to be edited. If, by using text editors, one is creating files that can't be reasonably edited on easily available software then it's next to useless. Most graphists are not coders and have no intention of ever being so. As a result their efforts will be concentrated on the visual elements and not on how the browser renders them. When one manually removes a lot of the markup that allows the editing software to function then that is not an "optimal" edit. Basically, what you have done is restrict the number of editors (software and human) who can now utilise that file in their normal workflow.

The fact that manually edited files relieve minor burdens on the server is irrelevant to most graphists. They don't care, and in most cases they shouldn't have to. Perhaps if it's a multi-megabyte, ultra complicated SVG then maybe, but then the chances are that sort of file isn't going to be manually edited anyway. Most manual editing is done on smaller files which makes bugger all difference to the server, especially after the various thumbnails have been cached.

What it boils down to really is that manually editing files is a game. Certain editors like to challenge themselves, and others, to getting a file as small a possible and still be viewable. Totally losing track of the fact that most other people will no longer be able to edit this file unless they break out their favourite text editor. Sorry folks, I hate to burst your bubble, but most graphic artists don't have a favourite text editor. They do, however, have a favourite image editor whether it's Illustrator, Inkscape, CorelDraw or Sodipodi etc. If you deny them the ability to use their favourite software then what's the point? So you can feel superior about how well you know XML markup?

Re: Paul's comments about colour space. Colour spaces were never really given much thought as SVG is basically a vector format designed mainly for the web and its inherent sRGB colour space. Most vector files are either viewed on a standard display or are printed, either way their display target will always have a limited colour gamut. Vector files, including proprietary formats, are not photorealistic and therefore have no real need for the widest gamuts possible. Their benefit is their scalability and resolution, not how many colours can be used. Let's face it gamut is all about the viewing device anyway, not about the container.--Fred the Oyster (talk) 11:57, 28 September 2014 (UTC)

For some previous discussion, see en:Talk:Flag of the United States.

Paul Coddington -- Official flag color specifications are in terms of device-independent color systems, while the RGB color system used in SVG files is inherently device-dependent. There's not really any one single "correct" conversion from device-independent color to device-dependent color. For various reasons (again see en:Talk:Flag of the United States) any conversion which does not transform flag white into RGB #FFFFFF is not practically useful for abstract geometric (non-photographic) SVG flag image files on Commons... AnonMoos (talk) 12:19, 28 September 2014 (UTC)

Some of us can't comment on en.

But regardless of Illustrator's "idiosyncracies", if an SVG file can't be opened in it then by definition it is neither optimal nor improved. And incidentally, for those who decry Illustrator the current CC 2014 version (v18) is very SVG friendly (albeit with some minor hiccups such as missing width/height tags and a propensity to add unnecessary mitre limits). The code it now outputs is efficient, valid and reliable for opening in other applications. It also doesn't add lots of crap as in the past, or like Inkscape's present. And I yes I do manually 'titify' the code afterwards but rarely do I need to do anything of substance.

Have any of you 'optimisers' ever considered leaving the original alone and uploading a separate 'optimised' version? --Fred the Oyster (talk) 12:38, 28 September 2014 (UTC)

It's nice if some of Adobe Illustrator's most annoying past features in SVG generation have now been mitigated, but it's still not going to be the touchstone or reference implementation as far as Commons is concerned. If an SVG file is syntactically valid according to the official standard, and renders correctly in various programs such as RSVG, Inkscape, Mozilla, etc., but not in Adobe Illustrator, then it would appear to be Adobe Illustrator which has the problem. Maybe you should ask Adobe why there are files which work fine in Adobe SVG plugin, but have problems being opened by Adobe Illustrator??? AnonMoos (talk) 23:53, 28 September 2014 (UTC)

(ec) Way to go about missing the point. This is/was never about any one editing software This is about a minority of code obsessed editors screwing around with people's work in the vain hope of impressing their peers with their coding skills. From what I've seen a lot of the loudest 'coders' wouldn't know how to do decent graphic art if someone shoved a Sharpie up their arse. All they can do is create shapes with numbers, and correct me if I'm wrong but ultimately that doesn't help either Commons or the wikiverse. What else is also forgotten is that the diagrams and illustrations on Commons are not just for supplying thumbnails for various wikis. A lot of them are used for all manner of purposes over and above wiki usages. Ergo messing with files and removing useful data (just because it's not useful to you text editor pilots doesn't mean it's not useful to others) is counter productive and does not end up with an optimal file. It may end up with a smaller one, or one that renders a millisecond or two faster on the Wikimedia servers but for the rest of the world they are pretty much useless.

As far as Illustrator is concerned SVG is a limited file format that only has one or two useful purposes. No professional graphics artist in his/her right mind would use it for anything other than simple stuff. The fact it does it at all given Adobe's history of eschewing open standards is quite frankly amazing. The fact of the matter is that Illustrator is the king of the world when it comes to vector illustration work, it has no viable competitor as the majority of the world's illustrators will tell you. To be honest having to work within the limitations of SVG drives me nuts and severely limits the results I can produce for Commons, even so I can still produce in 10 mins artwork that you text editor drivers would take days to produce. I can produce photo realistic shading using gradient meshes and blend modes, but can SVG display them? Hell no. So before you decry the behemoth which you seem to consider as being dysfunctional just remember just how limiting your beloved text editor is when it comes to producing good art. After all, isn't that what vector files are for? Producing good images? Rather than producing small files? Sometimes you left-brained people fail to see outside your own little bubbles and think that 'your' fascination is the be-all-and-end-all. SVG has its uses, but they are few and far between, so further limiting them by removing useful metadata is neither improvement or optimisation. Personally I have no time for people who are more interested in how small the file is and its technical qualities, than how good the picture is. --Fred the Oyster (talk) 00:39, 29 September 2014 (UTC)

I guess Adobe is a badass financial company. I mean they have also not really interest to the free SVG format. They have simply swallowed many useful tools and had let disappear. Also you must now pay (tax) every month for the "new" Photoshop (just as example). ↔ User: Perhelion (Commons: = crap?) 00:16, 29 September 2014 (UTC)

I won't defend their actions with regard to the Creative Cloud as I'm one of the ones who disagreed with the new business model, but ultimately, for the individual, CC does work out cheaper. I was getting sick of having to lay out £1k+ every couple of versions to keep up (as a self-employed layout artist I don't have the luxury of a hipster boss buying a new version every time one comes out. It does also make it much easier to upgrade., eg the other week I went to bed after using v17.1 version and the next day I discovered I was now using version 18.0 (all for £18 per month). But to your point, SVG may well be a free and open format, but it's an extremely limited one. I reckon that may have something to do with why it's not been greeted with Adobe's open arms. There are so many things I cannot use SVG for it's ridiculous. Personally I hate the format and wish I could upload vector artwork in PDF form instead. PDF is far more versatile than SVG will ever be. But yes, you are correct. Adobe are greedy bastards, but then they produce the best graphics software in the world. So they've got us by the short and curlies! --Fred the Oyster (talk) 00:48, 29 September 2014 (UTC)

Fred the Oyster -- Your complaints about how SVG is a toy format which you don't take too seriously as an Adobe Illustrator user would actually appear to reinforce and support the view that some of the things that Adobe Illustrator is best at don't have too much relevance to how SVG files are used on Wikimedia Commons (as I said on en:Talk:Flag of the United States). That's another reason why Adobe Illustrator will not be the touchstone or reference implementation for SVG files on Wikimedia Commons... AnonMoos (talk) 08:12, 29 September 2014 (UTC)

Regardless of how this conversation seems to be turning away from the detriments of manually decimating SVG files with a text editor ultimately Illustrator will always do a better job of producing vector artwork than, say, Notepad++, yes, even SVGs. As such I would recommend that people try AI (or any other GUI) rather than get into the habit of losing track of what SVGs are supposed to achieve, and that those files aren't just there to provide coders with a raison d'etre and bragging rights. --Fred the Oyster (talk) 09:55, 29 September 2014 (UTC)

Inkscape has committed lot of sins of complicating the SVG file to its convenience. One of the gravest sins being converting all curve commands of A~elliptical arc and Q~quadratic Bézier curve into C~cubic Bézier curve[3] once you have touched the path with its own path node editor (not to mention the shorthanded curve commands of T for Q and S for C). A and Q actually make the curve easier to handle and more accurate so we don't need to rely on guesswork by eye. Since Inkscape developers think these curve commands aren't popular in other vector application so they don't bother to fully support them in their path node editor. Without the ability to combine at least A~elliptical arc with C~cubic Bézier curve commands, the graphist is always guessing whether the curve is circular or not or rely on something that is not native to SVG specification, such as "live corner" of Illustrator, which is not helpful to other graphist without AI. To date, there is no vector application that is truly built for creating native SVG that doesn't include any unnecessary craps. For whatever reason, many vector graphists also like to "break" the path apart and/or overlap the broken paths which are supposed to be one single complete path. But most SVG renderers make it very obvious that the path doesn't join well, that's why you always want to make sure the path doesn't break, otherwise hide the joint or ends under other objects in the image. This one issue of SVG has been overlooked by many graphist, probably because the path looks fine in their vector application. -- Sameboat - 同舟 (talk) 16:22, 28 September 2014 (UTC)

Sorry, I don't see anything against general optimization (yes the given examples are bad optimized, but that is no reasoning, and this should be the very exception. Normally, the people they did optimize SVG, have inkling of ​​what they do). Maybe this (aversion) comes from unawareness of how it works. You are right Sameboat I also disagree with somewhat of the Inkscape developers work (sometimes I think that there are some saboteurs of the industry :P). @Sarang: I mean this is interesting for you, can you check (correct without <defs>) optimize really the mentioned File:Flag of the United States.svg (there is something wrong in it)!? ↔ User: Perhelion (Commons: = crap?) 23:37, 28 September 2014 (UTC)

Instead of overwriting it, I created Flag of the USA.svg as an example; just to show how simple and easy it can be drawn sarang♥사랑 13:55, 29 September 2014 (UTC)

Sarang -- I think he was asking about a file version without nested recursive "use xlink:href=" calls, especially those which would involve many levels of nesting of "g" elements (which seems to be a problem for Adobe Illustrator)... AnonMoos (talk) 19:47, 29 September 2014 (UTC)

USA flag SVG broken in AI18

@Sarang: the new file of yours is totally broken in AI CC 2014 (v18). It will open fine, but all that shows is the blue rectangle and the stars. No stripes appear at all. Each star appears under a separate recursive group layer, so by the time you get to the last one there isn't any screen real estate left to see it. So it doesn't sound optimised or compatible to me. Loss of compatibility is not a good price to pay for a small reduction in bytes. YMMV. --Fred the Oyster (talk) 21:02, 29 September 2014 (UTC)

That screenshot reveals an Adobe Illustrator inconsistency, since the red is visible in the icon view at the top of the "layer" listing! However, I'm not enamored of Sarang's use of stroke-dashing which creates stripes which extend outside the bounding box (as Sarang is already aware)... AnonMoos (talk) 08:44, 30 September 2014 (UTC)

Yeah, I noticed that disparity too, between the layer thumbnail and the main view. I'm wondering if it has anything to do with one just being viewable and one being editable so therefore renders differently. It could even be due to limited memory on the laptop I'm using instead of my main machine. As for Sarang's strokes, well I use that technique all the time, but it all depends on whether I'm going to cut into the shape or not. If I am then I outline the stroke, if not I use a straightforward stroke. I cannot see any reason why not to. Though I really don't understand why he extends the stroke beyond the bounding box though when it's simplicity to set an absolute length from an absolute coordinate. Either way, the files is neither optimal nor compatible. All that can be said is that it's small. So to quote you from yesterday, "that doesn't align well with Commons"! :) --Fred the Oyster (talk) 10:09, 30 September 2014 (UTC)

Extending the stroke beyond the bounding box is for safety measure. RSVG is not perfect when rendering raster image of different scale and the edge of the objects may end up shrunk, resulting ugly gap between the canvas edge and the bar. (This is the reason I strongly oppose breaking the path apart which is supposed to look like a single complete path.) -- Sameboat - 同舟 (talk) 13:54, 30 September 2014 (UTC)

Sameboat -- For technical/mathematical reasons, quadratic bezier curves are rather awkward to edit, as discussed on en:Talk:TrueType. Quadratic beziers are fine for a "write-only" final format, but if you're going to re-edit a path containing quadratics, it's easier to convert them to cubics first... AnonMoos (talk) 00:09, 29 September 2014 (UTC)

@Sameboat. Personally I think Inkscape (GIMP too, even more so) is a horrendous piece of software, but then I suppose you get what you pay for. I think I would prefer to use CorelDraw over Inkscape, and CorelDraw makes me shudder! --Fred the Oyster (talk) 00:52, 29 September 2014 (UTC)

Fred the Oyster -- I really don't want to indiscriminately defend Inkscape, which has some distinctly annoying "features" (such as the whole Flowtext nonsense, which the Inkscape developers took from an ephemeral draft document that's never going to be made an official SVG standard, and which they apparently have no interest in fixing, despite being made aware that it causes interoperability programs). But as a whole, Inkscape actually aligns better with the purposes of SVG files on Commons than Adobe Illustrator does (see my comment of "08:12, 29 September 2014" above), and it certainly has much lower barriers to entry than Adobe Illustrator. (On the other hand I can sympathize about GIMP -- I've never really been able to accustom myself to the weird "everything right-click" interface" beyond a few rudimentary basics...) -- AnonMoos (talk) 08:30, 29 September 2014 (UTC)

No graphics package "aligns well" with Commons, they are all just a means to an end, which is to produce artwork. Artwork will always be the poor cousin on Commons and isn't give much priority here. For example, a few weeks ago when I returned to Commons after a long absence I looked at the "Quality Images" nomination page and archive. I'm sure you know what I saw... So just to be ornery I nominated a random illustration of mine (it wouldn't have been fair to nominate someone else's as an experiment) that took me about 20 minutes to create. It sat there for days with none of the reviewers knowing what the hell to do with it. It eventually got a QI with the simple comment "OK". As far as I recall it had been weeks, if not months, since there had been any vector nominations, let alone promotions. In other words the only people who give a shit about illustrations on Commons is us vector graphists. No-one else cares, unless of course they want a diagram for their favoured article. The point being that Illustrator not aligning well with Commons is a myth. In the past week or so I have done in the region of 500 Japanese prefecture symbols (simply because their raster equivalents were erroneously put up for deletion review), not to mention other diagrams and artwork. All were done in AI, all were valid SVG, had minimal cruft and all were useful to Commons. Simply because you don't like it doesn't mean that it doesn't have a perfectly good synergy with Commons. Just because it is expensive, just because it has a very steep learning curve (I've been using it since v1.0 and I'm still learning new ways to do things in it) does not mean it has no place here. However what does have no place here is users tinkering with files that aren't broken rather than spending time creating new artwork that is required. There are 1000s of raster files needing conversion, and what do certain editors spend valuable time doing? They fix files that aren't broken simply so they can see "b" after the filesize instead of "k". Now that, I would say, _is_ something that doesn't align well with Commons. So if people do want to tinker with SVG code I would recommend that they create their own files for doing so and leave other people's work, that may be bloated but works perfectly fine, alone. And yes I know that we don't own the files we create, but, in reality, we all have the same mentality when "our" files are fucked with. None of us like it, not even the code tinkerers. It's bad enough that the photographers think so little of the effort it takes to create our work, but it's even worse when we have factions within our little sub-community that are pissing off the majority by screwing around with work that doesn't need screwing around with. --Fred the Oyster (talk) 09:55, 29 September 2014 (UTC)

We don't need the SVG mug slinging fight to continue. I am tempted to propose a new guideline of SVG optimization, just don't know if this is really a good idea, though. I personally do draw a line on what SVG file desperately needs optimization particularly on diagrammatic graph or any image which only contains absolutely simple yet regular geometries; for trace art like File:Cerne-Abbas-Giant-2.svg I just don't think it's worth anyone's time to bother with because such SVG is likely to be edited in vector application again. I also don't support removing indents/spaces just for saving few "k"s. Yes you can reindent in text editor, but as I've already mentioned in help:SVG#Layout with text and tspan elements, there is some risk the text might not behave as intended after reindentation, so the indents should always be retained as they are. -- Sameboat - 同舟 (talk) 12:18, 29 September 2014 (UTC)

Sometimes it's good to have a vent on things that annoys one :) but yes, I do believe that a re-appraisal of the transition program is overdue. As I've said previously an awful lot of time is being spent (wasted?) "optimising" files that are neither broken nor need optimising. That time would be better spent creating new artwork from the 1000s of images that need converting. Especially so given how few of us there seems to be these days. Files should be left with their metadata (aka "bloat") intact in order to allow artists to edit them in their preferred software regardless of a few extra K or a few extra milliseconds of render time. Please also remember that a lot of these files are also used outside the Wikiverse. The obvious exceptions are badly done machine created files with horrendous duplication that are measured in megabytes rather than kilobytes. Knock yourselves out with those files. Obviously broken or substandard files are also fair game for the tinkerers. But as a rule, files that are accurate for their use and display just fine should be left alone. No matter how much it offends one's coding sensibilities. --Fred the Oyster (talk) 15:33, 29 September 2014 (UTC)

Fred the Oyster -- I agree that we should not be bound by the idiosyncrasies of any one vector editor program. However, the developers of Adobe Illustrator spend a whole lot of time and effort on things which are just not too relevant to Wikimedia Commons SVG files, and the whole SVG thing is pretty much an afterthought for them. Inkscape has a number of its own difficulties, but it's solidly SVG-focused. I agree that the image recognition processes are almost entirely focused on photographs (I tried to nominate File:Shoelace knot.svg as a "Valued Image", less exclusive than a "Quality Image", and got no meaningful feedback of any kind), but I don't see how this is an argument against hand-simplification of SVG files -- and I really don't agree that Adobe Illustrator users are a "majority"[sic]! -- AnonMoos (talk) 13:42, 29 September 2014 (UTC)

You do seem to have a very narrow perspective on these things. I doubt Adobe has any knowledge or interest in Commons. AI is there to create artwork. It's not interested in a container format that can only convey a portion of what AI can output. The designers of SVG probably had no knowledge of, or interest in Commons either. Wikimedia chose to use the only open standard vector file format not because it was a good format, or because it could be all things to all men, but simply because it was the only one. SVG is a very restrictive container file. Inkscape is no different than say Adobe (ex Macromedia) Fireworks using an existing file standard as its base file format. In Inkscape's case it was very similar to Wikimedia's choice, there was only one choice. I fail to understand why you have a thing about AI not being really suitable for Commons. AI is a vector artwork design program. Commons accepts/needs vector artwork. How is that not being suitable? SVG is merely a container, ultimately no different than. txt .jpg .png etc. The file itself does nothing other than carry what was put in it. However SVG cannot carry a lot of things that are available to do with vector art. For example multiple fills or strokes for single objects, or multiple gradients within one object a-la Adobe's gradient mesh function. Or how about gradients within strokes, or gradients that follow strokes. That is not Adobe's fault that SVG cannot support these things, and it doesn't make AI any less suitable for Commons because it can provide things that SVG can't use. To me that says SVG is the culprit, not AI. And as Wikimedia selected SVG as its vector format of choice then they must shoulder some of the blame too for having a restricted capacity for the ultimate in vector artwork. Then throw in the complaint that the 'vector purists' here at Commons throw out at some of the artwork here... it's got a raster effect in it. Again that's the effect of a file format that is restricted in what it can carry, not the fault of the program that can achieve these effects in vector form.

These days most of the the brain work I bring into play when doing artwork for Commons isn't so much how I do it. It's more along the lines of how do I do it for SVG and how do I do it within AI by breaking my normal workflow and not utilising functions I would normally use without thinking. One thing I can guarantee though is that I don't expend a millisecond's thought on "how could I do this with a text editor?", what artist in their right mind would?

As regards my comments about "majority". I was referring to professional vector artists, not not limiting it to Commons users. The majority of vector art in Commons is done with Inkscape. The majority of Inkscape users are hobbyists. The majority of professionals are AI users. The majority of professionals do not contribute to Commons. Personally, I don't know any fellow professional who use (or would even dream of using) Inkscape. AI is the world standard for vector art software unequivocally. And the only reason Commons doesn't benefit from it's facilities is because of SVG, and not the other way round. --Fred the Oyster (talk) 15:21, 29 September 2014 (UTC)

Commons' goal is to provide absolutely free source for the public (not limited to any Wikimedia sister project) to use under either CC-BY-SA or PD. Many professional vector artists refuse not getting paid for their hard work; I don't blame them (partially because Creative Cloud isn't cheap to being with). Then let's face reality: If the majority of our contributors can only rely on free applications, there is a good reason that we should cop with these practices, instead of forcing us/them to cop with the "professional standard" which is unrealistic to our community. -- Sameboat - 同舟 (talk) 15:42, 29 September 2014 (UTC)

Or put another way, the easier we make it for everyone to help regardless of pro or amateur the better, or even for that matter the software used. The end result is what is important, not what created it, not even who created it. I realise I'm one of the few pros here and that isn't likely to change soon, but if more could be attracted then that can only benefit the project surely? Ultimately though it doesn't matter if it's a pro or amateur. I have seen artwork here created by amateurs that is far superior to mine, professional status not withstanding. Really, all that being pro means is that money exchanges hands, not how good we are. Personally I can't draw for shit but it doesn't stop me creating artwork for clients or for Commons. The same should be true for anyone else too. --Fred the Oyster (talk) 16:01, 29 September 2014 (UTC)

Fred the Oyster -- how would you create a graphic with overall transparent background in PDF? And with many PDF-generation tools it's somewhat awkward to generate PDF files whose dimensions are not a standard page size (A4, Letter etc.). The PDF format is allowed on Commons, but we treat it as what it is, a multi-page printer-oriented document format not intended for easy re-editability. It's not a good replacement for a lightweight screen display oriented re-editable vector clip-art type format like SVG... AnonMoos (talk) 09:02, 30 September 2014 (UTC)

That is simplicity. the .ai file format is a PDF. Simply rename a .ai file to .pdf and you have a fully compatible PDF file. Also when you copy and paste within AI it uses a PDF format on the clipboard. A lot of people share your misunderstanding of the PDF format. That may have been true in its early incarnations but for the last few versions you can pretty much use them for anything. The format supports transparency, colour spaces, spot colours, Pantones, font embedding, vector or raster or basically pretty much anything you could want from an image format. With AI you can even create a multi-page PDF simply by having an image on multiple artboards within a single file. I think the only thing PDF doesn't natively support is animation or video, but then you can still embed animations or videos within it instead. --Fred the Oyster (talk) 10:09, 30 September 2014 (UTC)

However, that raises a number of further questions, such as whether the Illustrator extensions to PDF are fully openly and publicly documented, and will be stable in future software versions. If, hypothetically, Commons were to ever host such Illustrator-extended PDF files, then the "ordinary" PDF content would be completely ignored, which would mean that AI files would be handled as a completely separate format from PDF... AnonMoos (talk) 13:11, 30 September 2014 (UTC)

Those further questions needn't be asked if you understood what I said. .ai files aren't 'extended' PDFs, they are bog standard PDF files that can be opened in any PDF compatible program. As I said PDFs are generally underestimated as to what they can do. AI using them as its native format is just a demonstration of how versatile the format is. The added advantage is that AI's functions, that SVG doesn't support, can be made available in PDF form (eg blend modes, gradient meshes etc etc). --Fred the Oyster (talk) 13:47, 30 September 2014 (UTC)

If other programs open AI files in compatibility mode, then for the purposes of those programs, PDF will still be a multi-page printer-oriented document format not intended for easy re-editability or transparent backgrounds, etc. To take advantage of some aspects of your vaunted "versatility", it seems that any program would have to ignore the "bog standard" PDF content, and instead interpret the AI-specific application data in the file. I'm really not indiscriminately opposed to all Adobe products, considering that I used or have used Type Manager, Photoshop, and SVG Plugin for many years (not to mention that almost all the files in Category:Images with PostScript source code are by me), but I just don't see how Illustrator is the future of SVG files on Commons or the solution to SVG problems on Commons... AnonMoos (talk) 14:44, 30 September 2014 (UTC)

You asked me a specific question, I gave you a specific answer. If a program (editor or viewer) can open a PDF then it can open an AI file (renamed), but it would be rather silly to expect a generic raster program to be able to use the vector data (though as far as I'm aware Photoshop can use a lot of it), likewise a generic editing package won't be able to use all the data in the PDF because it was never designed to, not because there's an inherent problem with PDF. As for your comment about me thinking AI is the future for SVG and Commons, well all I can say is that I never said that, never alluded to it don't actually believe it. I am not a big fan of Adobe myself partly because they are the main reason I haven't switched over my desktop to Linux, and partly because they're greedy and have started to bloat applications that I've used for years. I use their programs because they are the best at what they do and there are no serious competitors, and not because I'm a fawning Adobe sycophant. There are aspects of AI that drive me nuts, but then that happens with all programs, none of them are perfect. This is where experience with a program comes in, you know what the faults are and you know how to work round them. This is also another reason why I don't switch to another graphics package. I've been using Adobe stuff for more than 20 years and see no reason to change as there is nothing better on the market. As such I use AI to create SVGs for Commons regardless of the disparagement by Inkscape users. I see absolutely no reason or need for me to learn the intricacies of a secondary (and less functional) program. So no I don't think AI is the future for Commons for everyone, it is however the future for me. In any case you seem to be confusing my comments about AI with my comments about PDF. My belief is that PDF could be used more on Commons for things other than multipage documents. It has the functionality built into the format which is sadly lacking in SVG. It's as simple as that. But we do seem to have strayed quite considerably away from the main topic. But to reiterate a comment I made earlier in this thread, AI will beat any text editor, any time, for producing vector artwork beyond simple shapes. --Fred the Oyster (talk) 15:51, 30 September 2014 (UTC)

Easier methods to upload SVG derivatives

I've hunted everyplace I can think of to find whether there's a simple way to upload SVGs converted from existing Wiki*edia files while keeping all the existing info (licensing, authorship, &c) while simply adding links back to (&, bonus, from) the original file. Is there no simple process, such as a wizard, 1-click "Upload a version of this file in another format", or some such? I myself would upload dozens of these (I've an excellent manual conversion toolchain I employ), but have only navigated all the complex uploading info just once! TSamuel (talk) 22:29, 11 October 2021 (UTC)

I've just found DerivativeFX @ https://derivative.toolforge.org/deri1.php . It's ok, but glitchy. Still, I was able to use it to upload some SVGs. TSamuel (talk) 02:28, 14 October 2021 (UTC)