Commons:Graphics village pump/November 2007

I hate redlinks, don't you?

Especially when it's supposed to contain wonderfully informative converation. Cary Bass ^demandez 21:46, 2 November 2007 (UTC)

SVG Metadata

I have an SVG diagram I want to upload (my first).

I am probably looking in the wrong place but I can't find any guidance on what metadata to include in an SVG file: description, copyright etc?

Is it correct, as I have read, that files containing a <title> tag are rejected, and if so why? Where is the page that tells me this?

I notice that a lot of SVG files in Commons have a fixed width and height. Would not viewBox="0 0 <width> <height>" be more flexible?

Globbet 17:50, 7 November 2007 (UTC)

Personally, I always delete that metadata crap. It doesn't do anything to the image and only makes the file size unnecessarily bigger. This information it's useful sometimes, but on Commons it's definitely not needed because you get a whole page to describe your image. Anyone wanting to know the "title", author, or whatever just has to click on the image to find the description page. If you're worried about non-Wikimedia use of your images (i.e. where people don't have a handy link to the Commons page), then release them under a license that requires documentation to be included (like the old BSD license with the "advertising clause"). Keep in mind, any (allowed) images on Commons can be modified however anyone sees fit, including the removal of metadata. Many users (including myself) will remove this info anyway, when tweaking/converting/fixing the image. With high-use images, sometimes the only change is removing this junk, which the smaller file size justifies.

As for your question about width and height, usually it's preferred for SVGs to have a "fixed" ratio, so when scaling, the image is not distorted. For example, if width/height are made disproportional to the image, the image is cropped or whitespace is added. However, if you use viewBox and set it disproportionally to the image, the image will be stretched. I'm not too familiar with this, because Inkscape has always saved using "width"/"height" (plain SVG) , so I'm not even sure if this is how it's suppose to be, but it is (at least in Firefox).

I hope that answers your questions. Rocket000 10:13, 14 November 2007 (UTC)

I on the other hand always add metadata to my images, title, author and license. For the same reason that metadata can be useful in a photograph I'd find it useful in an svg image. As for file-size difference mine differ by exactly 1KB when I add my metadata so that's not really an argument. Rather I think that it's a good method for keeping the info in the image without it intefering with the looks of it. Also for use outside Commons having the info in the file would be useful. Whenever I tweak an existing svg file I tend to check if there is any (relevant) metadata and then put that in using a text editor afterwards. /Lokal_Profil 20:55, 14 November 2007 (UTC)

To me, <title> is totally unnecessary. I have yet seen or heard a good reason for including it. Author is not a good idea to include, as some have many authors. (By the way, I don't think you should add an author's name to a file, if they didn't themselves. They may not wish for their name to be associated with certain uses or derivatives). Specifically with SVGs, because of the open human-readable format, an image can be treated much like a program or a Wikipedia article. There can be an enormous amount of metadata (history, diffs, all the authors, licensing which requires being present). A separate document is absolutely needed to contain all this info, and is much easier to access and edit than metadata embedded in the file. (No need to download the file, edit it, and re-upload, all the while assuming the user has the right tools and/or knowledge to do it manually.) That's not even mention Commons is multilingual. The licensing, for example, won't be translated like it is on the description page. Including translations would start to become ridiculous.

> "As for file-size difference mine differ by exactly 1KB when I add my metadata so that's not really an argument."

Actually, 1KB is a lot. Think about if every image on Commons increased by 1KB (or more for the images that have multiple authors or multiple licenses). If this had to be sent with every usage of the image on every wiki with all the traffic they get... all of it totally useless to editors and readers of any Wikimedia project (only some which can understand your language).

> "Rather I think that it's a good method for keeping the info in the image without it interfering with the looks of it."

What's wrong our current system of image description pages? Personally, I think storing metadata in files is a terrible method for Commons images (excluding camera-generated EXIF data). It's way too hard to track and maintain. It just not needed. Personally, I wouldn't want to have to check both the image's description page and the embedded metadata, just to see if an editor has the right author(s) and license(s). Maybe the two sources contradict - what would we do there? What if someone comes along and uses your image to make a derivative work you really really don't want to be associated with, but the deriv author forgot or didn't know to change the file's metadata, and here you are falsely getting credit for something you don't want anything to do with.

This way of recording metadata may be useful outside of Wikimedia's projects, but if anything, it has negative effects here, and if you're uploading images to Commons, you should put this community first. For the record, I'm not against metadata itself, as image description pages are metadata; I just feel it's unnecessary and impractical on Commons or any wiki to also include it inside the file. Rocket000 17:58, 15 November 2007 (UTC)

So, we have no definitive answers yet, but some trenchant views on the subject from Rocket000; others may or may not agree. I need to think a bit more about the argument that any derivative work can mess about with the metadata in unpredictable ways, or completely ignore it. I don't see the modest additional file size as an issue. ISTR there is existing guidance somewhere that Wikimedia is big enough.

On the question of preserving aspect ratio, have a look at http://www.w3.org/TR/SVG11/coords.html#PreserveAspectRatioAttribute.

I suspect that there is as yet no Commons (or other Wikimedia) page offering any level of detailed guidance on how best to present SVG files, and I want to suggest that it is time we had one. There is an embryonic FAQ at http://commons.wikimedia.org/wiki/Commons:Transition_to_SVG but that is not really the place for an SVG how-to. With an SVG guidance page we could have holy wars thrash out guidance on what we think constitutes good practice, in an effort to encourage consistency. SVG is a complicated specification and it is easy to 'misunderestimate' its potentialities. Metadata, for example, can be used in an infinity of useful ways by XML processing tools and I think it just needs to be thought about a bit before being dismissed as pointless.

On the other hand, the level of traffic here suggests that there may not be enough interest for it to be worth the bother. Globbet 23:44, 15 November 2007 (UTC)

I think that's a good idea. SVGs will only become more and more popular. It's just getting started. A simple guidance page would be fairly easy to create with what we already have (with nothing potentially controversial like metadata). This would at least consolidate the info onto a more appropriate page and give us a talk page to discuss things like this. I say, let's wait a bit and see there's enough interest in creating this page.

Utilizing metadata with tools can be extremely beneficial, but again, are you talking about for here or "out there"? Is there any such case Mediawiki's software makes use of things like title, author, ect? No, the only time they access it, is to strip it out. Like I said, I don't think all metadata is pointless, it's just a different story with SVGs. For example, I absolutely support keeping camera-generated EXIF data in photos (rather than user-generated EXIF that's more prone to error and laziness).

To get any real useful function out of SVG metadata on Commons, all (most) images would need to include something. We already have a full working system, whatever can be done with metadata, can be done with description pages. (don't forget categories, relevant links, diffs for reviewing/tracking, user- and bot-friendly access, UI, accountable history, dedicated programmers... It's pretty good system and we can implement anything new that may be useful.) We have no system for dealing with metadata. My guess is because one system is enough and ours is better.

By the way, I wasn't talking about storage being an issue, as that's nothing. I was talking about bandwidth. As of now, the severs can barely keep up. Yes, we're told not to worry about that and to put quality first, but it does affect the user's experience and it's not like I'm suggesting we start cutting SVG whitespace, rounding all units to nearest hundredth, or anything like that. This doesn't effect quality image-wise and actually cleans-up the code. Rocket000 09:48, 17 November 2007 (UTC)

May I add my thoughts on this issue. I think Commons should parse the SVG metadata like it does with EXIF, so it shows up as another (automatically generated) section on the page. That way, the SVG metadata shows up automatically... However, this is probably an issue for Meta-Wiki. ButterStick 22:49, 18 November 2007 (UTC)

Can I ask why? -Rocket000 15:29, 19 November 2007 (UTC)

Well, I agree that metadata inflates the file size, which we all try to avoid, and that for the purposes of Commons, the image desc. page is sufficient for communicating authorship, etc. So I guess for our current purposes, the SVG file should contain only the actual image to be rendered.

I have to apologize for the comment of 18 Nov, since it was a bit vague---1. I did not mean that feature should be implemented in the current situation, but was meant to be for some unspecified time in the future; and 2. the XML structure allows the metadata to be inserted: While I see that for our (Commons') purposes SVG is being used as just another image format, and that RSVG's render time (is this really significant?) and bandwidth are the most imporant factors, I take the point of view that perhaps SVG's capabilities should be fully utilized. In the same vein as Globbet's comments above, I would like to say that metadata should not merely be dismissed.

I also appreciate that user-written metadata is not comparable with automatically generated metadata from cameras and scanners. In that respect I agree that if the metadata is going to be typed in anyway, why do it to the SVG rather than to the image page itself.

(At the core of my post, I think it is just my confusion between "for Commons' purposes" and "for 'out there'". I agree that at the moment putting data inside the file is just an exercise in redundancy, but perhaps somewhere along the line image desc. pages will be generated automatically from the file, continuing the theme of fully utilizing SVG's capabilites. Nonetheless this is purely conjecture, and you can freely ignore this point :D )

I'm sorry if my response did not directly address the query, I had a late night last night. ButterStick 00:14, 20 November 2007 (UTC)

Thanks for replying. I think I get what you're saying. SVG's potential is no where close to being realized yet; we have a long way to go. I mean, we're just starting to see the use of filters (though not online - browsers need to catch up). Right now there's not much need for optimization, but there will be. With these new special effects, the render time will start to matter. The bandwidth issue, unfortunately, I don't see subsiding anytime soon. Just like all web content, SVG's will continue to become more advanced (i.e. resource hungry). If the bandwidth is there, we will use it (see also: Wirth's law). Again, I'm not saying we should dismiss metadata altogether, it's just right now it's not a good idea. Any manually inputted data is redundant, and any machine-generated metadata is utterly useless as it's program specific and user defined settings (every user has their own preferences). Unlike camera settings and such, none of this info. is useful to others. It doesn't matter what program or settings you used to create the image. In the future, I'm sure they'll be some good reasons to use metadata on Commons, but now there's nothing Mediawiki should parse. I'm big fan of automation but to what your suggesting, we would have to totally redesign the wiki software. It could happen, but editing would become less accessible. It would kinda lose the whole openness/wikiness.

You gave me an idea though. What about the converse? Metadata being generated from the description page. The metadata could be automatically inserted when the images are downloaded (either to be edited or used elsewhere). That way, images leaving Commons retain the info., while images on Commons don't unnecessarily repeat the description page and waste bandwidth! This could also overcome one of the worries with using the GPL by making sure all necessary licensing accompanies the images after they're detached from their description page. The data can be viewed, expanded, and updated much easier, too. Editors wouldn't need to download the files to edit them. They wouldn't need to have the right software or know anything about a given format. Actually with templates like {{Information}}, very little would need to change interface-wise... I'm really starting to like this idea. Thanks, ButterStick :) Rocket000 02:25, 20 November 2007 (UTC)

This is a really good dialog... unfortunately not many websites have quite as good discussion! Anyway, I'd like to say, given those reasons I'd come to the same conclusion (esp. SVG at the moment being just the tip of the iceberg) and that there's a tradeoff between wiki-style openness and automation.

That said, the automatically generated SVG metadata idea is really good, and it shows originality in the sense of "how do we make it better for reusers of our material" rather than just actual readers of the website. One question though: Does this mean that I'm right in thinking that Commons' use of SVG is restricted (for the time being) to the actual image to be rendered? I am starting to think that as far as SVG goes, the "file" that is uploaded could be thought of as the "image stream", and the image desc. page as the "data stream", to toss that terminology quite loosely. This might, in fact, make data organization more efficient! This would mean, as a consequence, that the "SVG image" on the Commons server would be, in fact, just the code describing the image, no more and no less (which I think has been the idea all along), and that it should theoretically be possible to input SVG code, as text, right into an edit page. Then Mediawiki could merge the two streams on image download into a "well-formed"* SVG (*not really, since well-formedness does not require metadata), while RSVG sees only the image stream, which is by now as lean as it can be.

As far as I can tell, this might not be such a difficult idea to implement. Mediawiki can parse the page layout, where text falling under specially-named section headers may be "executed" by the software. E.g., one would start with an empty page, with no text. One can then edit, to include a section called "XML Source: SVG" and another called "Summary". Any text found under the first heading then can be taken as the source code while text falling under the second can be taken as metadata. The served Image: page the end-user sees then can look like a regular image page like we have now, except that maybe there would be an extra section, or in the corner there might be link to show the source. Obviously there are practicalities which need to be addressed, but this is starting to sound good.

Image:Flag of the United States.svg shows exactly what I mean: the software would generate the image on the fly by reading the text in the section "Image source", with the metadata in the section "Licence" and the template at the top.

I think its you, not me, who deserves the credit. ButterStick 10:07, 20 November 2007 (UTC)

Embedding the license info in metadata for 'outside' use was just the kind of thing I had in mind. Because this discussion has turned out to follow one of my initial themes in some length, I want to separate out the suggestion of an SVG how-to page to a different topic so that it does not get lost in the metadata discussion... Globbet 17:43, 20 November 2007 (UTC) :Go for it---I'd do it myself, but I have no idea what to call it :D ButterStick 02:07, 21 November 2007 (UTC)Whoops, didn't see below! ButterStick 02:09, 21 November 2007 (UTC)

A bizarre example SVG metadata in action is that here in Wikimedia we cannot use the SVG logos at http://www.root2art.co.uk/svg_logo_download/simple_svg_logos.php because the metadata of the SVG file says the licence is: http://creativecommons.org/licenses/by-nd/2.5/ which, of course, is forbidden. So far, I am not getting far with trying to get this resolved. Globbet 01:27, 22 November 2007 (UTC)

Yeah, why is that? It's not like it's a company's logo or anything that could be misrepresented. I sent an email to the creator questioning the purpose of this. It seems to contradict what his goal is. According to his site, "I personally would like to see this logo evolve in the true spirit of Open Source and welcome ideas for improvements from graphic artists and developers alike." Kinda hard to evolve if it can't be modified. You said you're not getting far with this - did you mean you tried emailing him too? And thanks for creating a the new section. I am currently looking into some of the finer details of SVGs and there's a lot I still don't know. Rocket000 02:53, 22 November 2007 (UTC)

"title" tags in SVG files

Sorry I didn't see this conversation before; to answer the original question, title tags are now allowed in Wikimedia SVG uploads, since Bug 4388 was fixed. You can also include "Dublin Core" metadata tags within a "meta" section within the SVG file; see, for example, the text source of Image:Blason_Sainte-Mère-Eglise_50-solid.svg . However, it's inconvenient to try to insert such metadata without having a program generate the necessary code for you.... AnonMoos 23:30, 29 November 2007 (UTC)

Obviously I don't use metadata, so sorry if this is a dumb question, but what's the purpose of having a <title> tag in addition to the whole <metadata> part? Isn't one title sufficient? Rocket000 10:20, 30 November 2007 (UTC)

The title tag is immediately understood by a number of programs without more elaborate metadata capacity (for example, it's displayed in the top window titlebar if you view an SVG file with Adobe SVG plug-in), and it's part of the SVG standard's "content accessibility guidelines" for providing some description of an SVG file's content when the SVG file can't be viewed visually (according to the SVG standard, internal sub-parts of an SVG document can also have title tags). The Dublic Core information in a "meta" tag is more like formal structured library cataloging data, than just a quick title caption... AnonMoos 12:19, 30 November 2007 (UTC)

Proposal: an SVG How-to page

I would like to suggest a page that builds on the FAQ in Transition_to_SVG to give specific guidance for contributions in SVG form, indicating, for example, peculiarities of Wikimedia, common problems, recommendations on details of coding, presentation etc. It might be a bit difficult to keep questions off the talk page, but that is nothing new. Globbet 17:43, 20 November 2007 (UTC)

Well, for a start, I think contributions should pass W3C's SVG validator ( http://validator.w3.org/ ) which allows Template:ValidSVG to be used. Also, something about saving in plain SVG rather than Adobe or Inkscape's own SVG implementations.

Since most contributors will not be coding by hand but will be using wsywig tools, I think some advice on common mistakes (such as removing references to bitmaps, making the page border the right size, etc) might be useful. (My two cents.) ButterStick 07:41, 24 November 2007 (UTC)

There might be some useful stuf at Commons:Tutorial for Vectorial graphism /Lokal_Profil 15:33, 24 November 2007 (UTC)

Cool, I didn't know we had something like that. Here's a few more places where there's SVG info.:

Template:Translation possible/Learn more - Deals with translating SVGs (diagram labels).

Commons:File types#SVG - A couple of tips on saving for Commons.

m:SVG fonts - A list of supported fonts.

Commons:Software#SVG - SVG software.

If you know of anymore places with SVG information, please add to this list. Having all these links together will give us a good start. Talk pages are also a good place to get ideas (commonly occurring SVG questions).

And I agree with ButterStick, those things are very important. I find the most common rendering problems are caused by not saving in plain SVG format. This site has some other things we might want to talk about. Rocket000 19:28, 24 November 2007 (UTC)

Hey, I just found this page after opening a conversation at Category talk:Pictures showing a librsvg bug... I really don't know what I'm doing wrong, but all my SVG images are always rendering wrong. I even tried to save this one in "Plain SVG" instead of "Inkscape SVG" which is the default. My current problematic image is Image:PageRank-example.svg. Any suggestions? ZeroOne 17:04, 26 November 2007 (UTC)

At the risk of turning this into a general SVG help topic, which would be a shame, I take it that your problem is that the text is floating leftward and upwards out of the blobs. Why do you have ViewBox ="4 3 47 39"? In particular, why the first two parameters? I suspect (from my own experience) that the MickiWackiWikiWhatever (I'm learning too) does not do viewBox, or at least not very well. I suggest you try removing the viewBox attribute, but this is really just the blind leading the blind. Globbet 21:11, 26 November 2007 (UTC)

Thanks, but removing the viewBox or parts of it did no good. It just shrank the picture into a miniature into the upper left corner. Both Inkscape and Firefox render this image correctly. Wikipedia and Opera fail, both in different ways. I guess further discussion should be directed into Image talk:PageRank-example.svg. ZeroOne 23:51, 27 November 2007 (UTC)

Continuing the main discussion... I agree that creating a one-stop-shop for all things SVG would be a good idea, and I know I'll be having fun while I learn, too. Perhaps this thread could be moved to the talk page of this new SVG page once it starts; I would not like this discussion to expire with November. ButterStick 09:15, 28 November 2007 (UTC)

How about COM:SVG, ok probably we should figure out a long name before a shortcut but... /Lokal_Profil 23:22, 28 November 2007 (UTC)

It looks as if we should use the 'Help:' namspace not 'Com:'. Commons:Help_page_maintenance says:

"3 Name of pages(namespace): Tutorials and technical help articles should be placed in the Help-namespace. Policy pages, project pages, legal pages, Commons maintenance pages and other pages that don't fit elsewhere should be placed in the Commons-namespace."

See also Help:Namespaces which makes sense; and then there's Category:Commons_help (btw: how do I edit this to get a proper link?) which doesn't, or not to me anyway. Sigh. Globbet 23:43, 29 November 2007 (UTC)

True Help-namespace seems better. Just write [[:Category:Commons help]] to link to a category (note the initial colon). I fixed the above link./Lokal_Profil 01:00, 30 November 2007 (UTC)

So, Help:SVG it is then? I think the page should at least list some common mistakes and their solutions, such as saving the file in Inkscape SVG when it should be saved in Plain SVG — at least I guess that can cause some problems, can it not? ZeroOne 09:58, 30 November 2007 (UTC)

The name sounds good. I think "inkscape svg" (and probably Adobe illustrator svg etc.) used to cause problems but I'm not if they still do. Anyhow it's a good way of cleaning out unnecessary code. /Lokal_Profil 17:05, 30 November 2007 (UTC)

At Commons:Graphic Lab is a suggestion to "Write step by step your protocols;". Would guidance such as this belong there also? (SEWilco 17:30, 29 November 2007 (UTC))

If I knew what it to meant, I might think it belonged. Improving help pages generally seems to be sorely needed. Globbet 23:43, 29 November 2007 (UTC)

I'm guessing they mean explain your procedure for creating the image. Rocket000 10:28, 30 November 2007 (UTC)

SVG help

Image:Map of New Mexico highlighting Dona Ana County.svg is used on the English Wikipedia, but the county's actual name is "Doña Ana". As a result, some coding is messed up, because it expects Doña Ana. Could someone please upload this file (keeping the file with the current name) as Image:Map of New Mexico highlighting Doña Ana County.svg? I'd do it myself, but my computer doesn't have software to work with SVGs. Nyttend 16:13, 13 November 2007 (UTC)

 Done I uploaded it.--Ahonc 21:45, 13 November 2007 (UTC)

Problem with SVG image

I create SVG-image Image:Old Coat of Arms of Artemivsk (Donetsk Oblast).svg and upload it, but it is not displayed in articles. Why it is not displayed?--Ahonc 17:18, 13 November 2007 (UTC)

I noticed you saved in the Inkscape format instead of plain SVG (an option when saving). This sometimes causes problems with thumbnails/image previews. I uploaded a plain version for you. Rocket000 08:58, 14 November 2007 (UTC)

P.S. I cut out a locally linked image (D:\Img\GIF\ua-arta.gif) as this wouldn't show up anyway. It was layered underneath the SVG part, so I'm guessing it was used merely as a guide or model for creating the SVG. Whatever the case, it's no longer needed. I also scaled it down a bit for the preview. (Since it's an SVG, scaling doesn't affect the image visually or the file size! Size is important, however, when viewing the image directly. SVGs should usually be around 600px by 600px, this gives a good preview and anything larger may go off the screen on lower resolution monitors.) Rocket000 09:18, 14 November 2007 (UTC)

Thanks.--Ahonc 21:28, 14 November 2007 (UTC)

A way to merge JPEGs with decompressing and recompressing?

Is there a way to merge JPEGs without decompressing and recompressing? I was thinking something analogous to jpegcrop. --Iamunknown 00:54, 19 November 2007 (UTC)

http://jpegclub.org/jpegtran/ It's call jpegjoin. Cheers, Rocket000 22:06, 19 November 2007 (UTC)

However, I have doubts that this can be truly lossless if the source images have different compression parameters. The Jpegjoin source seems to admit this when it speaks of "quantization adaption"... AnonMoos 18:38, 30 November 2007 (UTC)

New Project: Commons:Pearson Scott Foresman

Cross posting from Commons:Village Pump:

Here's a project for all you who have a lot of free time, good graphics skills and want to easily improve your image and edit count: Commons:Pearson Scott Foresman could use some talent.

And to the rest of you, if you think that page could use some refactoring to help the process along, by all means, it's a wiki! Edit :) Cary Bass ^demandez 17:21, 29 November 2007 (UTC)