This is an archive of past discussions for the period January 2013 to September 2017. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the
current talk page.
Recently I modified an image for
Radioactive decay (today, in 2013). Apparently some users can't view the modified form in the article
in this section (only the old version from 2009, or the new 2013 version on the
actual file page). Can others see the new or old one in the main article? How to fix? I can see the new version perfectly (on Windows 7, Internet explorer 8), there can't be any internal problems with the image... Thanks, if this is the wrong place just point to the right one...
M∧Ŝc2ħεИτlk22:21, 3 January 2013 (UTC)
Probably a caching problem (Wikimedia has been having several problems with this during recent weeks). People in Europe have been having fewer problems seeing updated image thumbnails than those elsewhere. If purging and reloading doesn't work, then you may have to just wait a few days. However, one trick that sometimes works is to change the width slightly to a size which hasn't been generated before (e.g. 221px instead of 220px, etc.).
AnonMoos (
talk)
09:08, 4 January 2013 (UTC)
Now I see the correct version. So it seems that we just need to wait until all of the servers sync up, and purging can't always be relied upon to speed things up. Forcing the creation of a new image just a little bit different in size is a good trick to remember.
Stigmatella aurantiaca (
talk)
21:35, 5 January 2013 (UTC)
Downloading svg->png transparent color becomes black
Resolved
Hi; when I want to download an svg image in png format, the downloaded image's transparent (i think at least it is) color (white) becomes black, which is very bad because the already black texts thus disappear. For example in this image:
http://en.wikipedia.org/wiki/File:Wiens_law.svg all white becomes black; but in all others as well. What am I doing wrong? Thanks
Hoemaco (
talk)
10:40, 23 February 2013 (UTC)
The transparent parts stay transparent when saved to PNG. Most software either recognize the transparency or convert it to white, but some may not. So what software are you using to open/edit the png? And what exactly do you want to do with it? More details will help us pinpoint your problem. Cheers! --
Orionist ★
talk11:41, 23 February 2013 (UTC)
I tried opening it in Irfanview, Acdsee, Neopaint and Powerpoint. Curiously, it only worked in Powerpoint (just realized I have to check it), even though it's the 2001 version. I know Neopaint is a very old software, but it can actually do transparent png, but says for these new images that they aren't transparent. Did they change the format of png some time ago?
Hoemaco (
talk)
12:07, 23 February 2013 (UTC)
Well, when inserted in PowerPoint and all other MS Office programs it's working perfectly and keeping the transparency. Irfanview has its default bkgd color set to black, you can change that be going to Options-->Properties/Settings-->Viewing then changing "Main window color" to white, while making sure the first option "Show PNG/TIF/TGA/DDS alpha/transparent color" is checked, then close and reopen the program and it should work just fine. I tried to download NePaint but it's timing out so I can't help with that. The Acdsee Pro 3 I tried converts it to white, but as you might have a different/older version keep in mind that in general, image viewing software have a background color option similar to Irfanview and that may cause such a problem. You can also use Firefox or Chrome to open and view all kinds of images, if all you want is viewing. If editing is what you want to do, I recommend that you check out
GIMP which is a very good free software. And if you tell me exactly what you want to do with the image I can recommend you a workaround. Cheers! --
Orionist ★
talk13:41, 23 February 2013 (UTC)
Hoemaco -- Your programs probably can handle palette-based or indexed transparency; it's an
alpha channel that they're having problems with. In late 2006, I added opaque white backgrounds to many of my SVG uploads which consisted solely of black on transparent because of various then-persisting difficulties and inconsistencies (see
File:Hebrew Chai Symbol.svg and many others). But nowadays most of the glitches seem to have been ironed out, as long as you're not using completely out of date software...
AnonMoos (
talk)
14:43, 23 February 2013 (UTC)
Thanks folks! I stick with my old software because I know how to use them :D I tried Gimp once, but for me it was similarly complicated as Photoshop etc; a bit too much for me. Of acdsee I'm also using a very old version - a few MB only, but it's fast and easy to use; unlike the new versions. For editing I'm just using some enhanced paintbrush stuff :) I'll try and find some newer ones, also look up this alpha channel.
188.6.71.34 (
talk)
18:32, 23 February 2013 (UTC)
Ghost path in BlankMap-World-Microstates.svg
Resolved
BlankMap-World-Microstates.svg
I noticed a ghost path id="path11370" in the file BlankMap-World-Microstates.svg
Is this a mislabeled territory or something else?
I looked at the file history and that path was introduced when one user edited the shape of the Aral Sea in the 7 December 2012 edit, most probably by mistake. I'll go on and delete it. --
Orionist ★
talk20:50, 14 March 2013 (UTC)
Lines with rgba values do not rasterize correctly
Resolved
Lines with an alpha channel in stroke colour render as solid opaque lines in thumbnails and PNG versions, instead of the expected transparent appearance.
Due to this bug, it is hard to see that significantly more lines are clustered under the robot and not under the other two doors.
I'm sorry if this has been asked before. I don't expect that Wikimedia servers will change the SVG rasterization engine any time soon so I'll appreciate any suggestions for making these lines using a way that will be rendered correctly.
dllu(t,
c)08:40, 24 March 2013 (UTC)
The alpha channel in your file is not only causing issues with our thumbnail engine, but also when opened in both Inkscape and Illustrator, neither of which recognized it. I guess it's not yet universally supported. I fixed it by removing the rgba values and using instead the "opacity" property by adding opacity="0.2" to each line. I've uploaded this version to your file and it's working now. Cheers! --
Orionist ★
talk09:47, 24 March 2013 (UTC)
Notice the subscript in in the PNG versions of these files.
My SVG diagram contains some subscripts for . However, in the rasterised version, the baseline seems to be not aligned to subscript even though I specified
<tspan baseline-shift="sub">0</tspan>
which should shift the zero lower regardless of font.
Don't feel like downloading and looking through the source code of these SVG files at the moment (may do so later), but it sounds like a fairly frequently encountered incompatibility with text in an element not all being at the same tagging level. E.g. in <text>TEXT<tspan>SUBSCRIPT</tspan>OTHERTEXT</text> the "SUBSCRIPT" text has an additional layer of tag embedding with respect to "TEXT" and "OTHERTEXT", and the Wikimedia SVG rendering software doesn't like this....
AnonMoos (
talk)
23:01, 27 March 2013 (UTC)
Oh, it is true that I used nested elements. Here's one of the 31 lines:
In that one, it's the " = 3.1" text which is not in a tspan, while the rest is. Adding a dummy "tspan" around this (i.e. <tspan> = 3.1</tspan>) will probably help (though I can't absolutely guarantee that it will fix the problem).
AnonMoos (
talk)
01:58, 28 March 2013 (UTC)
After doing some research, I found that baseline-shift="sub" doesn't work in some programs (e.g. Firefox). I've changed that code to:
after being inspired by the superscript in
File:US Natural Gas Production.svg. But it still seems to be not rasterising correctly (it is the case for the natural gas graph too). Oh well, nobody can read the text in the image in the thumbnail anyway.
dllu(t,
c)08:08, 28 March 2013 (UTC)
I pulled it into CorelDraw, did a trace detailed logo, and readded the text. Colors are a bit off, and I cannot get Commons Upload Wizard to respond right now.
Glrx (
talk)
20:23, 3 April 2013 (UTC)
Finally uploaded, but text placement on generated PNG different from my Corel and FireFox SVG rendering....
Glrx (
talk)
20:45, 3 April 2013 (UTC)
It seems to me that in the current version, the text does not even show up on
Google Chrome Version 26.0.1410.43 m on Windows. I tried fixing it but the situation with the text in the PNG
got even worse. Anyway, I prefer the new set of colours... the contrast between black and the new shade of blue is much easier to read.
dllu(t,
c)18:33, 4 April 2013 (UTC)
Yes, the letters don't show up in Chrome. I think what is happening is CorelDraw spits out dimensions in inches; usually it appends the units (such as for the bounding box), but for the font sizes its seems to have neglected to specify inches. Firefox renders OK but Chrome does not. I suspect that Chrome is assuming the text-height is a fraction of a pixel rather than a fraction of an inch. I have not looked at the SVG spec to see if there is a default unit spec. I will try adding units to the SVG file to see if it renders correctly in Chrome.
The other issue is the text baseline alignment. The svg-to-png converter apparently assumes a top of the text alignment where CorelDraw and Firefox are using a baseline alignment. That means the svg-to-png rendered text is below what I see in CorelDraw and Firefox. I looked briefly at the SVG 1.1 spec, got the impression that baseline alignment is the default, but I did not see a firm statement. I've had svg-to-png baseline issues on other images.
In my experience, Firefox rendering follows the spec. I've reported a number of Chrome SVG problems, but the last time I checked they had not been fixed.
CorelDraw did not map the colors as given in the PNG. I don't know if that is a colorspace issue or not. A light green went to saturated green. I tried to match the colors within CorelDraw, but when I viewed the resulting SVG in Firefox, the colors were again skewed (light green went to yellow). I then jimmied the colors to come out reasonably in Firefox. I chose lighter colors to make the text stand out.
BTW, I was pleased with how CorelDraw did the bitmap to vector conversion. My previous attempts using bitmap-to-vector conversion have been failures.
Yes, the CorelDraw vectorisation of the diagram is quite good. The SVG output is surprisingly clean and readable (compared to horribly verbose things created by Inkscape). It seems that many things about text baseline alignment is poorly interpreted by RSVG. One way to mitigate the issue is to make the text smaller so that no matter where the baseline is, it will still stay within borders. Unfortunately that makes it hard to read in a thumbnail.
dllu(t,
c)07:21, 5 April 2013 (UTC)
Yes, I was pleased with the clean CorelDraw SVG. I expected a lot of useless trash.
I looked at Google SVG rendering, and the issue is not clear to me. The text instead of being super small may be super large (and therefore off screen).
I'm leery of uploading SVG with explicit baseline instructions because I think RSVG ignores them. I should make an SVG test image that addresses text alignment.
Uploaded an SVG 1.1 text alignment test that uses alignment-baseline and text-anchor. Firefox does not do baseline alignment; Google does.
Glrx (
talk)
20:59, 8 April 2013 (UTC)
Any automated approach to internationalization/localization?
I've created an SVG file that uses switch to internationalize text for EN/DE. Of course, the PNG conversion drops the DE.
Is there some WP mechanism for generating localized PNG for separate WP?
Is there some WP mechanism for generating localized SVG? (For example, using an XLIFF file?)
My impression is the current method is copy a file to a new name and then manually localize -- which means subsequent corrections are not propagated to other files.
This has been discussed several times on Commons, but I haven't heard that any implementation is imminent. There's an SVG text caption translation tool for people who don't know SVG on the toolserver, but the last time I looked at it it had some strange bugs...
AnonMoos (
talk)
19:06, 5 May 2013 (UTC)
Status report. Other editors had added ionization energy figure to other WPs. I added some translations gleaned from wiktionary and other feeble sources and added the lang= field into several other WPs; I also added the figure to other WPs. Recently, a user added significant Chinese dialects and added the image to the Chinese WP. It warms my heart.
Glrx (
talk)
23:25, 27 January 2014 (UTC)
Purge doesn't always successfully sync all of the servers on the server farm. So it is possible to upload to one server and view your image from another server which hasn't been sync'ed with the upload server.
Hello, it may be a well-known issue but it is pretty new to me and a bit frustrating. I have translated
this map turning the text of the original into real, editable text. I tried keeping the curves in the original text and so used inkscape "Text->Put on path" option and uploaded
the result. Unfortunately, the text that has been forced to follow a certain path does not show up (actually, it seems only to show up in inkscape itself, it is missing from geeqie or display as well, though I can see it in the SVG file if I open it with vi...). My goal is to keep the new text as text (not an image, so that it can be easily translated into other languages) and at the same time, keep the curved effect if at all possible. Is it? Any option I can use to achieve this? Thanks in advance.--
Rowanwindwhistler (
talk)
17:07, 22 April 2013 (UTC)
Looks like text on a patch is a feature that WP's RSVG does not support.
Viewing your SVG file in Google Chrome (v 26.0.1410.64 m) shows the text on curved lines works as expected.
Viewing your SVG file in FireFox (v 11.0) renders the text on curved lines as horizontal text (not a bad fallback).
WP's RSVG PNG file renders ordinary horizontal text but throws away all text on curved lines.
RSVG does not claim to support all SVG 1.1 text options ("http://www.w3.org/TR/SVG11/feature#Text"). See
Feature strings and
file:SVG Test TextAlign.svg. Since RSVG does not claim feature#Text, then RSVG need not support text on a path.
I don't know what WP recommends in this situation. To first order, supplying the SVG file with curved text seems appropriate. When RSVG gets upgraded, then the image will work. What to do until then is not clear. Your SVG could be used, but viewers would have to click through to the actual SVG file to view most of the labels in the map. Not an attractive option.
For the time being, you could render the text as curves; I don't know if Inkscape has that option, but it would be expedient. That's probably why the original SVG file does not use text. The modified file could be used until WP supports text on a path; then the file could be reverted to your current version. It would work, but it would make further localization awkward.
Alternatively, edit the file so all the text is on straight lines. The picture won't be as pretty, but further localization would be simple.
An exotic workaround is to include a switch within the SVG file that tests for feature#Text; if present, then the curved text is used; if absent, then render as horizontal text. The problem with that approach is the file may become impossible to maintain as I doubt most SVG editors handle the conditional editing. (I'm ignorant of Inkscape's abilities.) The next person who tries to edit the SVG file would probably quietly delete the conditional code. Consequently, this option would be a lot of work with little advantage.
As Glrx said: RSVG doesn't support text paths. The best solution until this is fixed (if it will be ever fixed) is probably to upload the original version with editable text (which is easily translatable) and then upload a second version were you convert the text to path (Path -> Object to path in Inkscape). Clearly state in the upload comment that you converted text to path for one version and that the original version should be used for creating derivative works / translations. --
Patrick87 (
talk)
18:32, 22 April 2013 (UTC)
Thanks a lot for the clarifications and the very thorough testing! In the end I chose an intermediate solution: I removed the curving text and tried to mimic it as closely as possible by rotating straight text labels. Not as nice looking as the original but similar and the text remains as real text. Let us hope the feature will be implemented some time in the future so that these maps can look as well in SVG as they do in older formats.--
Rowanwindwhistler (
talk)
19:42, 22 April 2013 (UTC)
Help editing an SVG file. Not a real SVG?
Hello, I was trying to translate
this file (using inkscape but I also tried using a text editor with no luck at all) but it does not seem to be a real SVG (I cannot select any points, any text, etc). It seems to be a mere container of the original png map. Am I missing something here (some sort of file protection that may prevent the editing of the file...) or it is really a "fake" SVG? Just asking in case I may be overlooking something. Thanks in advance for your opinions and advice.--
Rowanwindwhistler (
talk)
20:06, 3 May 2013 (UTC)
You are right, this SVG only contains an embedded PNG raster graphics. There's no vector data included. The PNG should be extracted and reuploaded with the correct extension. --
Patrick87 (
talk)
20:16, 3 May 2013 (UTC)
I think the PNG is the one mentioned as the source of this derivative file. It does not seem to be much of an improvement from the original I suppose. Thanks for confirming there is no such thing as a quick translation for this map.--
Rowanwindwhistler (
talk)
20:59, 3 May 2013 (UTC)
I actually overlooked the source file initially since it wasn't linked correctly. It's identical. Therefore I marked the SVG version as duplicate and changed articles to use the PNG version instead. --
Patrick87 (
talk)
22:58, 3 May 2013 (UTC)
SVG versions of technical bitmaps
The
QR code article has several two-dimensional barcodes (which are fundamentally bitmaps: square pixels with no text) that have been converted to vector SVG (and thus turning pixels into verbose vectors). For example,
My sense is that the transformation is pointless (except for a possible additional metadata issue). I'm tempted to propose deletion of the SVG files, but want a sanity check.
Glrx (
talk)
15:27, 4 May 2013 (UTC)
This SVG has multiple issues:
It's only a traced SVG. Therefore a rectangular pixel is a path with many nodes instead of a simple rectangle. That blows up the size of the SVG and makes the quality worse than the original.
QR codes should be displayed pixel perfect since every pixel carries binary information (black or white). The raster graphics allows this if displayed in it's native size. The SVG version is scalable in theory but produces grey pixels if a black rectangle happens to be aligned somewhere between two pixels of the rendered graphics.
1. could be solved by doing a proper vectorization (that would be very time consuming). 2. would still be an issue, though. Pixel perfect rendering could be achieved for a given size (and multiples of this widht/height) but there wouldn't be a notable advantage over a raster graphics in the end. --
Patrick87 (
talk)
01:13, 5 May 2013 (UTC)
The only real advantage is being able to scale up smoothly. The pre-existing SVG was rather loose and inexact (the minute you see a bezier curve you know something has gone wrong, and there are thousands in the file); I uploaded a better conversion...
AnonMoos (
talk)
19:00, 5 May 2013 (UTC)
Your SVG conversion is OK now (although it's file size is still about 20 times larger than the PNG version's!). Howewer I still have to disagree with you regarding scalability. Consider the following scaled examples:
219px
220px (native size)
221px
When rendered only 1 pixel smaller or larger than the original size, scaling breaks the QR code (no matter whether the image is an SVG or not). --
Patrick87 (
talk)
23:04, 6 May 2013 (UTC)
I see no inherent scaling advantage for SVG. Bitmaps can be scaled, too. Scaling either with a non-integal factor will produce artifacts.
Glrx (
talk)
01:29, 7 May 2013 (UTC)
When I spoke of "scaling up", I really did not have 221px in mind (and definitely not 219px, which is scaling down!), but something more like 500px or 800px... Since 221px and 219px are artificially-chosen worst cases, I'm not sure they have much to say about the general situation.
As for filesizes, SVG is an uncompressed text format, while PNG is a compressed binary format, so any SVG file which codes individual pixels will always be at a filesize disadvantage.
AnonMoos (
talk)
16:02, 7 May 2013 (UTC)
And that's exactly what I was saying in the beginning: As long as we do not want to render the file at really large sizes (and we certainly do not want to do that in articles) there's absolutely no benefit in using SVG compared to PNG in this case. There are even some disadvantages like file size that can never be brought down to comparable values for the reason you mentioned.
However this discussion doesn't really lead somewhere and is more or less academic, since QR codes are quite a special case. For most other uses SVG is far superior (and I'll never claim anything else). --
Patrick87 (
talk)
16:55, 7 May 2013 (UTC)
my questionable svg editing techniques
I was recently informed that a series of maps I made (all the maps in
Category:SVG maps of Tibet) had an error relating to a prefecture level boundary. As there are 9 maps in total based on the same original svg, and they all had the same error (only effecting 2 paths) I wanted to expidite the editing of the images. Here's what I did:
opened one of the maps in inkscape made the edit
found the path id of the paths in question
opened the file in a text editor, and copied the paths
opened the other SVGs in a text editor
pasted in the new version of the two paths replacing the unedited version of the paths
saved and uploaded the new versions of the files.
This seems to have worked for all the SVGs, as they are rendering without issue (with one exception -- not uploaded), however I'm wondering if I may have messed up the SVGs. The originally uploaded in 2008, and I'm pasting the paths in after editing with version 0.48.3.1 of inkscape. That is, I'm only changing 2 paths in a text editor, without updating any of the metadata. When I ran one of the updated files through a svg optimiser it produced a version that was missing those paths.
You don't have to worry. Every thing looks fine. It's valid SVG and renders correctly in Wikipedias SVG renderer
librsvg. Probably the SVG optimizer you talked about is broken (maybe it doesn't handle the <desc> tags correctly you put in that path).
I made this image with linking on the svg:
http://www.micropedia.asia/wiki/File:Roads.png
I want to make my article on the wiki as detailed as possible but I need linking working on the page.
I added links for all roads, And if you click on it, It will go to the page of the road.
But I need this working on the page.
I would thank anyone for helping me. :) -- 14:49, 8 June 2013 62.234.104.86
If you created an SVG please provide us with the link and try to describe as close as possible what you want to do with it, and what doesn't work.
If you're talking about links included in the SVG I'm afraid it won't work on Wikipedia. The SVG is pre-rendered as PNG, therefore all potential links are lost. You could use
image annotations however to include descriptive links in the image. -- 14:38, 11 June 2013
User:Patrick87
Sorry, you uploaded a raster graphics, embedded in an SVG. There's no vector data included. That's why the scaled image looks "too sharp". Just upload the image as PNG or search for real vector data. --
Patrick87 (
talk)
21:16, 22 June 2013 (UTC)
Hello, I am trying to create a translation of
Indian Rashtrakuta Empire map.svg for the Spanish wikipedia using inkscape but I am running into a series of problems I would need the community's help with if at all possible:
I cannot open the original file using inkscape. I get an error saying: Indian_Rashtrakuta_Empire_map.svg:12: namespace warning : xmlns: URI &ns_svg; is not absolute xmlns="&ns_svg;" xmlns:xlink="&ns_xlink;" xmlns:a="
http://ns.adobe.com/AdobeSV I managed to open it by running xmllint --noent Indian_Rashtrakuta_Empire_map.svg > Indian_Rashtrakuta_Empire_map-es.svg, a command I found in the web somewhere (no idea what it really does but it works...).
Then I tried to start translating the map that seems to have no layers, but once I try to add one to put all the text there, a layer magically turns up. It seems my new layer becomes a sublayer of the hidden one and I cannot raise or lower mine from that one. Any idea where this layer comes from and how to turn it into a regular layer I can move up and down?
I then try to change some text in the upper right hand legend (Modern India...) but if I delete the last word of the first line of that text box the wrapping of lines breaks and I get the second line on top of the first one... Could this be the particular font (ArialMT) this text was using? Is it the text box itself? Inkscape? Any logical reason you see in this?
Then I tried forgetting about the old text, removing it and creating a new one. No luck, the new one was created beneath the map so it was invisible. I tried the "Object/Raise to the top" option but I had no luck, the text remained below the yellow background...
I finally tried moving the yellow background into a new bottom layer. No luck either, even if I tried to create a new lower layer the background covered all other layers (the hidden one I cannot move and my new text layer) so I ended up with a yellow "map"...
My main goal is to know if there is an easy way to turn this map into something I can easily edit under inskape, tame it into behaving like most maps do... Anything you can think of? Many thanks in advance!--
Rowanwindwhistler (
talk)
07:20, 6 July 2013 (UTC)
The SVG file is depressing large at 450 kB. I haven't looked at the file because I'm on a lousy internet connection.
The problems with xmlns="&ns_svg;" suggest that there was a DOCTYPE tag at the head of the file, but the DOCTYPE was removed or some ENTITY definitions within the DOCTYPE were removed. Consequently, the entities ns_svg and ns_xlink are undefined. Typically one might see definitions such as
Those are the first lines of the file and it seems to me the lines you suggested are indeed in the DOCTYPE part or are they incorrect? Thanks again.--
Rowanwindwhistler (
talk)
18:12, 8 July 2013 (UTC)
Rowanwindwhistler -- I removed most of the Adobe Illustrator garbage, so now there should be a better chance of opening the file with another program. The lack of layers is because what structure there is is through plain unadorned "<g>" elements, without the additional tagging that Inkscape uses to identify layers...
AnonMoos (
talk)
02:55, 9 July 2013 (UTC)
Right you are, it works in inkscape now so it must be some incompatibility between the two programs, thanks a lot. I will try to see if I can start slowly moving objects to separate layers so that I can handle them easier. I still wonder about the reason for the non-wrapping text...--
Rowanwindwhistler (
talk)
07:12, 9 July 2013 (UTC)
Inkscape "flowed text" is based on an old draft of the SVG standard which was not formally adopted, and is completely incompatible with the software on Wikipedia/Commons. "Flowed text" should be stringently avoided in all SVG files uploaded here...
AnonMoos (
talk)
09:27, 9 July 2013 (UTC)
The header lines look fine, so then my guess would be Inkscape either does not process ENTITY definitions or got confused in processing them.
Glrx (
talk)
17:43, 9 July 2013 (UTC)
Doing a bit of cut and paste (using the new image) I managed to do the translation and get the different parts into different layers so that you can put some objects out of the way when editing. Thanks!--
Rowanwindwhistler (
talk)
21:08, 10 July 2013 (UTC)
clipping issue from matplotlib graph
Shouldn't have the curves' tails sticking outside of the axes. And indeed when the original SVG is viewed in Inkscape, Firefox, Chrome it looks good. Is rsvg known for having problems with clipping? --
Nanite (
talk)
21:58, 1 August 2013 (UTC)
RSVG is known for its random bugs. I fixed it by unclipping and reclipping (but some of the thumbnails have yet to update.)—Love, Kelvinsongtalk00:22, 2 August 2013 (UTC)
The file has text along a curve, which the SVG rendering software here doesn't understand; you need to "convert text to paths"...
AnonMoos (
talk)
16:32, 5 September 2013 (UTC)
I don't know how.. I'm trying 'object to path' but getting message 'no objects to convert to path in selection', whether the letters are grouped or not. I'm not such a pro with SVGs. Rcsprinter(rap) @
16:56, 5 September 2013 (UTC)
That's more of an Inkscape question than an SVG question, so I can't really help you (I only use Inkscape to test and convert SVGs, not really to edit SVGs)...
AnonMoos (
talk)
02:38, 6 September 2013 (UTC)
Actually two questions:
(1) Is there any way to increase the maximum output size to more than 2000 pixels width? At that size the text of the communities, cities and villages is not yet readable.
(2) Under some circumstances the file is outputted with different fonts, any way to prevent that from happening?
I need to update the gay marriage world map, to reflect Vietnam's co-habitat status. I need help please.
How does one go about filling in blue for Vietnam?
— Preceding
unsigned comment added by
Samsamcat (
talk •
contribs) 14 October 2013 (UTC)
SVG text languages (internationalization)
A single SVG file can contain the picture texts for many languages in layers called e.g. nnn.language=ll. Displaying a particular language is a matter of its layers visibility. The [[File: syntax could contain "|language=ll" to make the relevant SVG layers visible. The daring ones could even switch the layers on automatically according to the page language (as such a name would hardly be used for anything else). The feature would probably become a standard. While waiting for renderer support of this feature, the SVG file could be passed through a simple filter to switch on/off or even remove the layers before passing it to the renderer. --
A Pirard (
talk)
00:00, 16 October 2013 (UTC)
This was done in Inkscape. I achieved the glow effect by placing copies of the objects underneath and setting their fills to blur. For some reason I can't understand, the two blurred curly brackets on the left are coming out with a sort of smudge, as you can see. This is only evident in Wikipedia's PNG renders, as Firefox renders the actual SVG perfectly (click the image on its description page to see it raw). I can't figure out what's different about those two elements. I think what might be happening is that the blur is only occurring vertically and not horizontally on those elements (although I have no idea why). PS. All text elements are already converted to paths.
I've tried a bunch of things to fix this, as you can see in the file history. I re-produced the two gitching elements by copying and mirroring the "good" ones, but the same thing is happening. I also tried going into the XML code and copying the style attributes from the "good" blurred elements and copying them over, but no dice. Anyone have any suggestions?
equazcion→11:45, 18 Oct 2013 (UTC)
So apparently if you blur something that's been mirror-flipped, it renders with these smudges in MediaWiki. I re-created objects from scratch and blurred them, and they're now fine. Thanks anyway.
equazcion→14:22, 18 Oct 2013 (UTC)
Black box when viewed as PNG (I didn't understand the above explanation)
I know that above, there was an explanation of how to fix this, but I don't understand SVGs and I don't have any vector editing software. I found this image while browsing and I do not know how to fix it. It shows up fine when I Open the SVG but when I open the PNGs, they all have a big black box on one of the keys. Thank you.
Joshua1995 (
talk)
21:39, 20 December 2013 (UTC)
I'm getting consistent bugs with my (
matplotlib) SVGs figures in which drawing is not being clipped to stay within the axes of the figure. Points within the figure are not clipped, and points outside the figure are drawn in full, as illustrated in this figure:
In all other tools I use (including the SVG itself here on Commons),
points are clipped to the axes, but the Commons PNG renderings draw outside the bounds of the axes. What can I do to prevent this? -- 02:54, 21 December 2013
User:Aldaron
I don't know, but I looked at the SVG file and didn't like what I saw. Characters are flattened, and definition sections are scattered throughout the file instead of being at the top; some defs are inside graphics constructs. There's a lot of cruft. It turns out the definition of the clip-path is at the very end of the svg file -- after all the uses:
Thanks. So This means that matplotlob is generating bad SVG. Any thoughts on how I might get matplotlib to do a better job? Or is there a *simple* SVG repairer I could post-process my matplotlib-generated SVGs with before uploading them? —
Aldaron •
T/
C12:26, 21 December 2013 (UTC)
It's generating incompatible SVG (not sure what the formal standard is). I opened the file in a text editor and consolidated the lower <defs> area with the upper one, which seems simple enough (unless you have a large number of SVGs to upload).
AnonMoos (
talk)
13:09, 21 December 2013 (UTC)
Thanks. I hope I'm not reduced to that as a standard part of my workflow. It seems none of the tools I've tried generate SVG that's bug-free though, so perhaps such repairs are an inescapable part of the SVG workflow. —
Aldaron •
T/
C14:20, 21 December 2013 (UTC)
Wikimedia uses
RSVG to render SVG file which is different than other SVG standard. The reason that loading the link of the SVG file clip the axes is because you're opening the SVG in your browser natively instead of opening PNG rendered by Wikimedia. You can't blame matplotlib for generating "bad" SVG, but you could say it's unconventional to have defs after the object which applies its content. According to W3 SVG specification, clippath data doesn't have to be contained within defs.
[3] If you want more accurate SVG preview before uploading to Wikimedia, try
SVGcheck. --
Sameboat - 同舟 (
talk)
14:54, 21 December 2013 (UTC)
I've uploaded a version generated with a different matplotlib backend (Agg) as EPS, which then convert to SVG. Can someone have a look at the SVG now and see if it still has the issues raised by
Glrx? —
Aldaron •
T/
C15:36, 21 December 2013 (UTC)
I haven't been able to look at the whole file (network problems), but it looks like a bloated, flattened file. It's sad when an SVG file loses to an uncompressed bitmap. Somebody should start grading SVG output....
Glrx (
talk)
02:35, 22 December 2013 (UTC)
Thanks for taking a look. I'd appreciate it if you could have a look at another file I'm experimenting with (closer to the ones I'll be contributing) and tell me what you can about the SVG you see there:
I'm not experienced with SVG issues, so I'd be grateful for a bit of explanation of what the issues are that you see (for example, what do "bloated" and "flattened" mean), and what I might do about them without editing the text directly — for example in Adobe Illustrator I have quite a range of export options to choose from (font embedding, export formats, etc.) as well as the ability to do some grouping and ungrouping of content before exporting, that might improve the resulting export. —
Aldaron •
T/
C14:56, 23 December 2013 (UTC)
It also appears bloated and flattened. I haven't been able to load the file to look at how the point plotting was done, but I expect drawing primitives rather than using symbols.
Bloated means the file is huge for what it's trying to do. The file is 470 kB.
Flattened means the hierarchy of the original source has been removed. Instead of displaying a text string such as "Hello world." in a particular font at a specific location, the individual characters have been converted to filled curves (each character is drawn as a geometric figure rather than text). That takes a lot more space; one character gets turned into hundreds of bytes of curve information. It makes the file immune to font substitution, but it also means the file cannot be easily edited or translated to another language. Hierarchy is lost in other places, too. SVG objects can inherit properties such as stroke-width from an ancestor; if there's no hierarchy, then there's no ancestor, therefore all the relevant properties must be specified in the SVG object. Flattening the hierarchy helps bloat a file.
I don't have any recommendations about what to do because there are advantages and disadvantages. Font embedding would make the file larger because the font is stored in the file; it makes the actual appearance of the figure more repeatable because there's no font substitution (font height and character spacing are troublesome issues). Font embedding can also mean a couple of different things; it may imply converting characters to curves rather than supplying an honest-to-god font. Grouping may help retain some hierarchy, but then it may not; I'd guess that it has little practical effect with most applications.
Generally, I've used pedestrian Unicode fonts. I don't embed fonts, and I don't convert characters to curves. I allocate plenty of space for the displayed strings so there's room for some font size and spacing variations, but I still get burned. Left, center, and right text alignments work in most renderers, but baseline alignment does not. I use the baseline alignment that I think is best for the illustration, and then I hope the renderer does a passable job. I live with the failings and hope that they are fixed in the next release.
Unless you're making fine art, for graph like this there is absolutely no advantage by converting text to path shape. Technically speaking there is no "
font embedding" in the said SVG files as each glyph object contains path data individually, so for example, the path data of the glyph "2" is repeated 8 times in Exo_Test.svg. The small color dots also share the same problem with text for repeating the same path data whenever the shape duplicates at different position. The source shape should be contained within defs and
used outside to reduce the repeated path data. Also I am amazed at the dot shape that is created by a fiddly path data like this: "c 0.796,0 ,1.559 -0.316,2.121 -0.879 c 0.563 -0.563,0.879 -1.326,0.879 -2.121 c 0 -0.796 -0.316 -1.559 -0.879 -2.121 c -0.563 -0.563 -1.326 -0.879 -2.121 -0.879s -1.559,0.316 -2.121,0.879 c -0.563,0.563 -0.879,1.326 -0.879,2.121 c 0,0.796,0.316, 1.559, 0.879,2.121 C 384.1,325.767, 384.863,326.083, 385.659,326.083 L 385.659,326.083 z", which can be easily replaced by the circle element. I've seen enough SVG files created by Illustrator which defeat the purpose of using this format. --
Sameboat - 同舟 (
talk)
13:27, 1 January 2014 (UTC)
Agreed. Unfortunately, I don't have control over what Ai does. It seems to take no advantage whatsoever of the semantics of the objects in the file — or perhaps the problem is with the EPS or PDF that I start with? —
Aldaron •
T/
C23:23, 1 January 2014 (UTC)
An idea that may work is opening the file in Inkscape, and then resaving as a plain SVG. I believe Inkscape will automatically consolidate and put defs up at the top. For me, at least, that would be less tedious than editing the files by hand. —
trlkly18:36, 13 January 2014 (UTC)
Best practice for "upgrading" to an SVG
What is the best practice for replacing a PNG on commons with an SVG version? For example, ideally it would be possible for all uses of somefile.PNG to be automatically replaced by a new somefile.SVG without having to edit all the articles where the PNG is used. Can a redirect or move be used for this purpose? What are the correct steps to accomplish this? —
Aldaron •
T/
C18:53, 24 December 2013 (UTC)
My understanding is limited, but here's how I understand the practice. Redirects are not used. On the PNG page, the template {{vector version available}} is used to tell editors that there is a replacement SVG file. (Also see instructions at {{Should be SVG}}.) For example,
File:Erste Ionisierungsenergie PSE color coded.png uses that template to point to
File:First Ionization Energy.svg. If the SVG file is a suitable replacement, then the pages that link to the PNG may be edited to link to the new SVG file. I believe that is a manual process now, but there is some assistance now and there may be more robot assistance in the future. The template also puts the PNG in
Commons:Category:Vector version available so editors interested in upgrading images can easily find them. Those editors or editors reading an article may click on the PNG file link, notice there's an SVG, and decide to do the replacement. In the FIE.svg case, I changed some links on the en.WP but left other links alone; other editors then linked the file to articles in six other WPs; a few days ago I changed one PNG link on the de.WP because SVG language localization now works (previously, the original PNG was better there because it had German titles and the SVG would only display English titles).
Glrx (
talk)
19:34, 24 December 2013 (UTC)
Color v. black and white
Can SVG be sensitive to the surface upon which it renders?
Many technical drawings are bilevel images and use cross hatches to show sectioned material. On a color display, it's convenient to use color fills, but if a color-filled image is printed on a black and white printer, the result can be poor. Is there a good SVG method so that color fills are used on color surfaces and pattern fills on black-and-white surfaces? I do not see any appropriate feature for a switch. Is there a reasonable CSS approach?
I also have some oscilloscope illustrations. On a color display, they are white lines on a blue background. For a black-and-white printer, the rendering should switch to black lines on a white/transparent background.
SVG is basically a
"declarative" language, so don't expect too many "imperative" programming constructs. However, SVG does have a switch element, and recently Commons has been set up to allow a single SVG file to have different renderings for different languages. I don't know whether it can do what you want it to do...
AnonMoos (
talk)
01:48, 2 January 2014 (UTC)
My impression is that SVG won't do what I want unless I use scripting or select an alternate CSS. The switch element (which I've used a lot) does not have a feature string for bilevel/grayscale/full color, so it cannot do what I want. Even if it did have an appropriate feature string, it would still be awkward because switch cannot be used to select a def (defs are not in rendering tree). Personally, I don't think images should have eval/imperative; that's a Pandora's box that PostScript has.
Glrx (
talk)
03:08, 2 January 2014 (UTC)
Implications of differing approaches to font handling
My SVG generation workflow gives me three
options for handling fonts in SVGs, each of which produces figures with different shortcomings, and I'm looking for guidance on which approach is "best" from a MediaWiki upload point of view:
'svg.fonttype' = 'none', which "assumes fonts are installed on the machine where the SVG will be viewed" (or rendered in the present case), and results in an "original image" that does not display the correct font;
'svg.fonttype' = 'path', which "embeds characters as paths" and preserves fonts in the original, but, I expect, at the expense of a bloated file; and,
I'm wondering which of these three settings is best for use here. (I also wonder why the gridlines present in the upload, and which appear in the MediaWiki rendered PNGs, don't show up in the "original"). —
Aldaron •
T/
C03:28, 12 January 2014 (UTC)
In my opinion option 1 is the best – you should however pick a font which actually is available on Wikipedia to allow the correct rendering of the file (you can use generic families like sans-serif though, or font stacks like Arial,Liberation Sans,sans-serif if your SVG generation worflow allows for it). If you don't want to care about fonts and need an accurate rendering you have to stick with option 2 (which produces bloated files as you noted and – even worse – makes it impossible for others to modify any text, fix spelling errors, create translations, etc.). Option 3 doesn't work on Wikipedia since the SVG renderer used (
RSVG doesn't support SVG fonts. --
Patrick87 (
talk)
04:15, 12 January 2014 (UTC)
Your svg file specifies "font-family:Bitstream Vera Sans;font-style:normal;"; the font list does not include "normal"; "normal" may be different from "Roman". It's odd that WP's sans-serif font has a "Roman" style.
Glrx (
talk)
20:20, 12 January 2014 (UTC)
Glrx -- sometimes in font names, "roman" can mean non-bold, non-italic...
Aldaron -- as you're discovering, option 2 is the only one which is guaranteed to work all the time with Wikimedia software...
AnonMoos (
talk)
00:22, 13 January 2014 (UTC)
Yes, unfortunately. It seems that to work reliably with Wikimedia rendering, paths (option 2 above, bloated though it may be) are the only way. —
Aldaron •
T/
C01:42, 13 January 2014 (UTC)
Macrons not rendered correctly
I just uploaded . It has macrons in it, but when Wikipedia rendered the image as png they turned into an IPA character. How do I get it to render correctly? The file was declared as UTF-8. Thanks!
Garfieldnate (
talk)
05:29, 15 January 2014 (UTC)
The original version of the SVG file had some issues, but no character encoding problems, so I really don't know where the "fi" ligature nonsense came from. The most-recently uploaded version (as of now) is straight 7-bit ASCII, but still doesn't fully work...
AnonMoos (
talk)
14:59, 15 January 2014 (UTC)
Finally figured it out -- you specified a TeX font, which was apparently using a weird TeX-internal character encoding (not even ASCII-compatible). I changed this to a non-TeX font, and now it works...
AnonMoos (
talk)
16:43, 15 January 2014 (UTC)
I created
this image as a replacement for
this fuzzy one. It has wikilinks embedded in it so if you click an Apple II model, it jumps to the article (just like the original does). But when it displays on wikipedia, as below, the hotspots are disabled and instead, the whole image becomes clickable and it brings the user to the wikipedia page for the image.
Clicking through, the user eventually gets to the raw SVG (
like here), where the hotspots are clickable, but this is not the desired behavior. Is there any way to correct this, so the Apple II models are actually clickable when embedded in an article? —
Frεcklεfσσt |
Talk16:51, 25 February 2014 (UTC)
Mysterious black rectangles in rendered PNGs are almost always due to Inkscape "flowtext" nonsense, which can be diagnosed at
commons:Commons:SVG Check. Sometimes empty "flowtext" elements can be left behind in a file, which can be hard to detect or delete in Inkscape, but which nevertheless still show up as black rectangles in rendered PNGs. I'll take a look at the file in a minute or two.
AnonMoos (
talk)
04:59, 26 February 2014 (UTC)
/info/en/?search=File:Brochosome_model1.svg
This image is not properly shown (invisible or instantly disappears) when viewed in my Chrome browser, although perfectly visible in Internet Explorer v. 11. Please help! -- 22:28, 4 March 2014
User:Roman Rakitov
Actually the linked file is not a vector graphics at all. It's only a raster graphics embedded in SVG. Why it isn't shown in Chrome is not really worth figuring out therefore. As a start it's
not even using valid SVG syntax. Shame on Adobe Illustrator with it's inferior SVG support... You should try to export a real vector version if possible which will possibly also fix the rendering problem. --
Patrick87 (
talk)
00:33, 5 March 2014 (UTC)
Roman Rakitov -- If you don't have a way to make a real vector version, it would be best to upload the 64k JPEG as a JPEG file (filename extension ".jpg")...
AnonMoos (
talk)
00:49, 5 March 2014 (UTC)
Rendering SVG at small sizes
I made this (and other) SVG files by hand and they're definitely valid and simple. However, at small (thumbnail) sizes, I'm getting an all black rectangle:
Funny: Sarang used a straight path with huge width which runs vertically across the image. This path is set to be dashed to create the stripe pattern. Might be a workable workaround then, since the issue you're observing seems to be an RSVG bug after all. P.S.
Here's a template you can use to create the image. --
Patrick87 (
talk)
14:19, 9 March 2014 (UTC)
Hello. I was wondering if anyone can answer me a couple of question. I've downloaded one SVG file recently with intention of doing some minor edits, namely changing the colors. However I noticed that even though I am not changing anything in the files (except replacing one color with another) that the size of the SVG file increases for some reason when I save the changes made, why is that? Also one other "stupid" question, does the SVG file loses quality when copied or edited in any way? Thank you.
Shokatz (
talk)
18:28, 13 April 2014 (UTC)
Most often, such a size increase means that your SVG editor is inserting a lot of constructs specific to that editor, which can help if the file is repeatedly re-edited using the same program, but will have no meaning to other programs (including RSVG on Commons). In Inkscape, you can cut down on some of this by choosing to save as "Plain SVG", not "Inkscape SVG". SVG files can lose quality if edited poorly, but quality loss is by no means mathematically certain (as is the case with JPEG
generation loss)...
AnonMoos (
talk)
08:54, 15 April 2014 (UTC)
P.S. SVG files are actually text files, so you can open them in a text editor to compare before and after versions.
AnonMoos (
talk)
09:01, 15 April 2014 (UTC)
Ok, thank you for answering. That explains it...I was in fact editing the image in Inkscape, seems it's adding some additional info every time I edit, even if very simple and minor edits. Thanks again.
Shokatz (
talk)
08:52, 26 April 2014 (UTC)
font scaling problem at some thumbnail sizes
I recently converted all the path-text in [[:File:]] to proper text. I have had a lot of problems with it, however. Throughout the editing process, I kept having problems with the text being a different relative size in the thumbnails. The text seems to change alignment depending on the image size. I even originally used Liberation Sans, which explicitly is stated to not have scaling problems.
I've never had this much problem with text before. Even right now, the text is not properly aligned on the file page, even though it is perfectly centered on my machine. And I'm afraid to mess with it since it's the first time I've gotten it to look right at 300px--the size used in the articles.
Note, the fact that I used groups to declare common text styles does not seem to be the problem, as I've tested versions that did not use the groups. So I'm not sure what to do. Is it really an rSVG bug, as I assumed when I uploaded, or is there something else that can be done? —
trlkly07:40, 20 April 2014 (UTC)
libRSVG uses
Font hinting. That means the text's relative size slightly varies with rendering size to better align letters on physical pixel boundaries.
Therefore when generating SVGs for Commons/Wikipedia you should a) include some "safety distance" to borders to account for potential changes in text size compared to the rendering of your SVG editor and b) set all text alignment to "centered" (at least in the example above) as it will make sure text will always be positioned in the center of the textboxes, even if it changes size.
Those two hints make also sure the SVGs are rendered well in other software using hinting (e.g. Firefox) and increase compatibility across systems (e.g. if the specified font is not available and a slightly different variant is used). --
Patrick87 (
talk)
00:09, 21 April 2014 (UTC)
Use style="transform:scale(x,y)" in the div element and nest the object (anything within will be affected including text and image). P.S. you can actually add scale(x,y) in the transform attribute of the layer1 "g" element of the SVG file for the similar effect, but it also requires readjusting the translate values to reposition the object within the canvas properly. --
Sameboat - 同舟 (
talk)
15:37, 21 April 2014 (UTC)
Note that the plain transform attribute does only work for current current browsers though! See
[5] for the compatibility list. Older versions support transform attributes only via native extensions, very old browsers not at all. In this case I assume editing the SVG is the best approach (at least if you're aiming for highest compatibility). --
Patrick87 (
talk)
17:20, 21 April 2014 (UTC)
I am preparing an
article to reach the
FA-class. I have created a flowchart to replace an outdated one. The outdated flowchart is the last one in SVG format. I would like to keep one SVG diagram at least, but I am unable to upload the new file. I have checked the file with the SVG Check tool, so further updates are not expected. Is there any chance that such an image from an IP editor could be uploaded?
84.127.80.114 (
talk)
19:22, 23 July 2014 (UTC)
Sorry for belated reply. I suppose you could e-mail the SVG file to somebody who would upload it, but it would probably be easier for everyone all around if you just signed up for a Wikipedia and/or Wikimedia Commons account...
AnonMoos (
talk)
16:42, 13 August 2014 (UTC)
The IP provided the source in its diff. Alternatively, source is at
Talk:Debian#Development flowchart. I think it would be better to obtain a Commons account (one account name can cover all projects) and learn how to upload the image. That way, if you wanted to modify it later, then you could do that, too.
Glrx (
talk)
17:19, 13 August 2014 (UTC)
Problems with switch translation displays
The file
file:First Ionization Energy.svg has several language translations via switch. On Commons, there's a drop down box to display the various languages. That works for most languages, but when I select zh-Hans or zh-Hant, the drop down resets to en and displays the English version. If I modify the URL by appending &lang=zh-hans, then the Chinese version displays.
The light is beginning to dawn. If I append &lang=zh-Hans, then English displays. Looks like the combo box is flexible about capitalization, but another agent is filtering the
IETF language tag for case. I need to check proper capitalization.
Glrx (
talk)
20:25, 20 August 2014 (UTC)
proper script variations are "Hant" (Han traditional) and "Hans" (Han simplified).
regions are all cap CN HK SG TW (but I don't think they are effectively used in the file)
I recently edited the SSM litigation file for the US states, to correct the colour of Florida. In the thumbnail, however, the picture still shows the old version, whereas when it is expanded, the colour is correct. Previewing the edit with the SVG full-sized shows it correctly as well. What is the reason for this, and is there a fix (hopefully a simple one)?
Kumorifox (
talk)
21:23, 23 August 2014 (UTC)
This is about
Same-sex marriage in the United States#In litigation (I had no idea what SSM litigation was) and
File:SSM litigation.svg and Brenner. If I display it here, then it shows as ruled against ban but stayed; in the article (thumb size), it shows as Litigation in US District Court. I suspect it is a synchronization problem that will fix itself. I cannot find the resync command, but it should be somewhere.
Glrx (
talk)
21:56, 23 August 2014 (UTC)
I changed the viewport and made the file ValidSVG (W3C). Download the file again from Wikimedia Commons and you can make a png file of it using Inkscape. Everything should be fine.
Wereldburger758 (
talk)
04:54, 21 October 2014 (UTC)
Erroneous SVG code
Resolved
Hi! I am trying to upload a new version of
File:Transperth railway map.svg. When I did, I usually received this error message: This file contains HTML or script code that may be erroneously interpreted by a web browser.
I could not determine what is wrong with the code. Could anyone please help? I would gladly appreciate it! The supposedly new version can be seen
here. —
Philtro Talk 13:44, 6 September 2014 (UTC)
The error is triggerred by the bitmap image you have (or had) included in your SVG ("southwestWA.bmp"). The file link you have there (file:///C:/Users/Jacko/Pictures/southwestWA.bmp) is not allowed. Just remove the image element and you're good to go (see
File:Test.svg for the changed code). --
Patrick87 (
talk)
13:53, 6 September 2014 (UTC)
Hello,
I exported this chart:
https://commons.wikimedia.org/wiki/File:Methanol-use.svg
from LO and did the final editing in Inkscape. The output looks fine in Firefox, but unfortunately the png's rendered by Wikipedia, totally screw the y-label. Can someone fix this please?
Done. Because Inkscape applied transform property in tspan element which is not supported in SVG v1.1 (but will be there in v2.0). Please bear with me that I really have no love for Inkscape and I'm etching to check and fix its source code. There are lot more (but relatively minor) issues with your SVG source but they will recur if the SVG file is edited and saved by Inkscape again so I don't bother to fix them. I still have to say, please learn the source code of SVG and create your SVG with XML text editor which is far more reliable than with Inkscape or alike. --
Sameboat - 同舟 (
talk)
11:30, 9 September 2014 (UTC)
iPhone 6 SVG Logo
Resolved
I just uploaded a file for the
iPhone 6 Logo. It can be found here:
/info/en/?search=File:Logo_iPhone6.png
It looks a little off, because the background of the logo is white and the background of the infobox isn't. If someone could convert it to .svg, that'd be great (because I don't know how). --
Rayukk (
talk)
16:00, 11 September 2014 (UTC)
Hi!, i was wondering if you could make a flag map of chile, there is one right now but it is incomplete, (the islands are not represented as you can see in the map to the left). Well i hope you have the time, thank you and bye!!--
Alexxxos (
User talk:Alexxxos)
04:30, 23 September 2014 (UTC)
SVG rendering
Hello,
I've been meaning to upload a SVG file onto Commons. I created the work myself using COREL Draw. When I opened the file to see it using Safari, it looked fine, but when I previewed it on commons, a part of it I created using transparency tool is gone. It seems that there are two versions of my file. Please help.
Many thanks,
Leo Crnogorcevic -- 09:31, 26 September 2014
User:LeoC12
I'm quite confused. This file is used at
Cervix and many other articles in many languages. Viewing it through the media viewer, the text labels are way too small to be readable. I'm assuming the size is arbitrary, since the image is strictly vector. Inkscape and my viewing software say the size is 1089x321, which would cause squinting, but would probably be acceptable, while Wikipedia says it's 512×151, which is too small. Is there some way to make this larger in media viewer? I think I could upload a "larger" version, but that seems like a poor solution, since it would either mess up a bunch of pages I couldn't competently fix, or create a completely redundant branch file.
Grayfell (
talk)
05:46, 26 October 2014 (UTC)
The illustration should have used a larger font size; that choice is an underlying problem.
There are arguments to the file inclusion; see
WP:MARKUP#Image and
WP:Picture tutorial. Setting an explicit size or |upright= can make the picture larger.
Neither of those formatting adjustments solve the problem, at least on my browser. The size in articles is fine and can be easily adjusted there. The problem is the size in media viewer. When I click on any of the above images, the image displayed is still the 512px wide one, which is unreadable. I want to make the image larger in media viewer so they can be read if clicked on. I'm still very new to vector graphics, so I don't trust myself to properly enlarge the file.
Grayfell (
talk)
21:59, 26 October 2014 (UTC)
The case of the disappearing earth
Resolved
We're having a problem with an image and maybe someone can help. It started as a
request in the Graphics Lab. If you have any insights, please comment over there. Thanks. –
JBarta (
talk)
22:47, 31 October 2014 (UTC)
"This file contains HTML or script code that may be erroneously interpreted by a web browser" error
I'm trying to upload a new version of a svg file but I'm getting "This file contains HTML or script code that may be erroneously interpreted by a web browser" error. Can someone please check the file
here and tell me the parts I need to remove? Thanks
Gezginrocker (
talk)
14:44, 1 November 2014 (UTC)
Try to remove the references to all raster graphics you had embedded at some point: "D:\Desktop\thailand_pol_2002.jpg", "D:\Desktop\thailand_admin_2005.jpg". Those are not supported by the MediaWiki SVG renderer because you could load potentially fallacious content. --
Patrick87 (
talk)
17:43, 1 November 2014 (UTC)
I'm trying to put together a road sign
File:National Cycle Route sign 6.svg on Commons. Clearly I have no idea what I'm doing with Inkscape and there is some hidden masking which I simply cannot see- not even in outline view. Could someone just help by fixing this image and I can take it from there. Many thanks in advance.
Cnbrb (
talk)
12:38, 25 November 2014 (UTC)
Done. Nothing to do with clippath, it's the
flowed text function to render the text "6" in Inkscape is no longer supported by any standard SVG library around. So I just removed the flowed text frame and replace "flowPara" element to "text" element which renders "6" and reposition it properly. --
Sameboat - 同舟 (
talk ·
contri.)
13:29, 25 November 2014 (UTC)
Thank you very much! Very quick reply too. I really need to learn more about Inkscape - I do find it very difficult to use
!
Cnbrb (
talk)
13:39, 25 November 2014 (UTC)
@
Cnbrb: No. I seriously recommend you to learn use text editor (e.g.
Notepad++) to create or edit SVG which in my opinion is far more reliable. SVG file created by Inkscape nearly always has problem when uploaded to Wikimedia. --
Sameboat - 同舟 (
talk ·
contri.)
14:00, 25 November 2014 (UTC)
Are you seriously suggesting that all SVG imges can and should be created and edited with nothing more than a text editor? Stick you in a room with nothing but a text editor and you could whip up something like
this? –
JBarta (
talk)
19:24, 25 November 2014 (UTC)
I see. I would love to see a few SVG images that you created entirely from scratch and entirely with a text editor. Can you point to some examples of your work? –
JBarta (
talk)
23:03, 25 November 2014 (UTC)
Nice work, very impressive. The other info on the page is impressive as well. Based on that, I now have no doubt you could probably whip up that bike pictogram without too much effort. –
JBarta (
talk)
00:27, 26 November 2014 (UTC)
Well I managed to make a few improvements in EditPad without subjecting myself to the agonies of Inkscape. It was a bit tricky to pick apart the syntax but I sussed it out at a very basic level. Cheers. 13:09, 26 November 2014 (UTC)
Texts in boxes shifted to the right
I uploaded
File:Roemenie_bestuur.svg.
When you go there you will see the page Roemenie bestuur.svg whith texts shifted right, some even outside the boxes.
When you click on the image you will see the original svg (I suppose) where texts all fit good.
When I drag the svg file on my PC into my browser it also shows good.
The uploaded svg was created from LibreOffice Impress version 4.1.3.2 after import from MsPowerpoint pptx format.
Who can help by improving the image or giving a clue?
I assume you hand-wrote all SVG/XML codes. I recommend you to replace all "text" element with "g" element then replace all "tspan" element with "text" because there is no instance in your SVG file must rely on tspan. Also for most text inside the box except for "Kamer van afgevaardigden", add text-anchor="middle" to either g or text element to align the text to the center of the x position, obviously you will need to adjust the x position of all centered text again but it guarantees the text aligns to center in most circumstances. Most text in the box doesn't align correctly because their default text-anchor is "start" (left) (btw, "end" means align to right), they may look like aligned to center in browser but not so centered when you change font or SVG renderer. As for "Kamer van afgevaardigden", I think the culprit is the "Calibri" font which isn't available in Wikimedia font library so it fell back to another font. I recommend you download the complete
Liberation fonts set which is totally free and then change the font-family in your SVG file from "Calibri" to "Liberation Sans", so the browser preview looks closer to the result on Wikimedia. (Can't guarantee they will look exactly the same, but close enough for local adjustment.) --
Sameboat - 同舟 (
talk ·
contri.)
01:42, 26 January 2015 (UTC)
University of Oregon infobox signature
Resolved
The signature in the university of oregon infobox was recently updated. However, unfortunately the background doesn't match the color of the infobox. Would someone be willing to correct this issue?
This is a section geared for SVG help,
the image you're referring to is listed as fair use, so I doubt we could convert it to a SVG based on the license alone. I've gone ahead and removed the background from the PNG though and uploaded it.-
Offnfopt (
talk)
08:00, 7 April 2015 (UTC)
PraeceptorIP created a table like structure in the article, which I deleted. It can be seen at
User:PraeceptorIP/sandbox#DDR. It is very hard to read and acts different depending on what platform you are viewing it from. I suggested an SVG image would be a better route for a more consistent feel. Would an SVG be a better route and if so, could we get some help in creating it.
Bgwhite (
talk)
04:45, 1 May 2015 (UTC)
I'd like to relate text size to the image size so that scaling the image would also scale the text. It currently has fixed font size and I'm not sure on how to change that without breaking the image.
Ivo (
talk)
19:48, 15 July 2015 (UTC)
text element is
<textxml:space="preserve"style="font-size:64px;font-style:normal;font-weight:normal;line-height:125%;letter-spacing:0px;word-spacing:0px;fill:#000000;fill-opacity:1;stroke:none;font-family:Bitstream Vera Sans"x="29.448669"y="898.12555"id="text2985-1"sodipodi:linespacing="125%"><tspansodipodi:role="line"id="tspan2987-7"x="29.448669"y="898.12555"style="font-size:84px;font-style:normal;font-variant:normal;font-weight:normal;font-stretch:normal;font-family:Swis721 Th BT;-inkscape-font-specification:Swis721 Th BT">e-Science</tspan></text>
I don't know, but I doubt WP has the font "Swis721 Th BT". It looks like "Bitstream Vera Sans" (which WP has) was overridden. I expect a font substitution. Use a font that WP knows. See
https://meta.wikimedia.org/wiki/SVG_fonts
I don't like the tspan buried in the text.
I don't like the linespacing=125% attribute either.
The text should be centered. I think it is left justified.
If you are desperate and want that font, then convert the text to curves.
I can open it in text editor and Inkscape without any issue. It also passes the W3 validation check with few non-consequential warnings.
[6] If you mean you can't open it in Adobe Illustrator or Affinity Designer then that's beyond my ability to tell. --
Sameboat - 同舟 (
talk ·
contri.)
02:31, 17 July 2015 (UTC)
I don't actually use Inkscape, but you can open its
layer dialog and it shows that all layers are "locked" by the author which can be easily unlocked by clicking the lock icon of each layer once. In the XML source, the layer lock is enabled by this meta property: sodipodi:insensitive="true" in the g element. --
Sameboat - 同舟 (
talk ·
contri.)
11:06, 17 July 2015 (UTC)
Hello,
File:Flag_of_Hawaii_(1896).svg doesn't seem to render properly... Anybody got an idea why it's like this? Also, if somebody feels bothered, can they optimise the svg for me? The svg of the current flag is less than 600 bytes which is impressive...
Reepy1 (
talk)
00:55, 24 October 2015 (UTC)
Hi, I saw this image
here was pixelated, so I decided to make a vectorized version by modifying a similar file with my very limited
Adobe Illustrator knowledge. To my surprise, it was still pixelated when I uploaded it to wikimedia commons. Any ideas on what I need to do? Thanks — Preceding
unsigned comment added by
Bluesoju (
talk •
contribs) 11:42, 20 November 2015
It is a wolf in sheep's clothing: the SVG just has an embedded bitmap and is not a vector file:
<?xml version="1.0" encoding="UTF-8" standalone="no"?><!-- Created with Inkscape (http://www.inkscape.org/) --><svgxmlns:svg="http://www.w3.org/2000/svg"xmlns="http://www.w3.org/2000/svg"xmlns:xlink="http://www.w3.org/1999/xlink"version="1.0"width="511"height="301"id="svg2465"><defsid="defs2468"/><imagexlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAf8A[...snip...]QmCC"x="0"y="0"width="511"height="301"id="image2474"/></svg>
Actually, it looks like a sync error; Commons is still delivering the 46 kB raster file; your SVG is 12 kB. It should sort itself out in a few hours.
Glrx (
talk)
15:53, 20 November 2015 (UTC)
Strange, perhaps my settings are off in adobe illustrator? I saved it as a svg and it is still a vector image. Not sure what's wrong.
Bluesoju (
talk)
15:06, 22 November 2015 (UTC)
@
Bluesoju: No, you did it exactly right. It just took a long time for the WP servers to get copies of your vector image. It was a cache problem; the old version had to be flushed/purged.
Glrx (
talk)
16:24, 22 November 2015 (UTC)
Image with arrows missed, but they appears in old file.
Hi, I upload a svg image but I missed put the arrows. I put it and re-upload, but the image has not the arrows. I re-re-upload and they appear in the old file. I tried once and once again, but it's the same. Help me if you can, please. Thanks.
It was nothing more than a caching issue (meaning your new file was stored to the server, but caching servers continued to send you the old file). It should be fine now (I
WP:Purged the file). If you still continue to see the old version remember to also renew your browsers cache! --
Patrick87 (
talk)
15:27, 26 November 2015 (UTC)
Bad preview
I've just uploaded my svg file to test.svg and I see that png preview looks bad (for example quotation marks in Umanyar), but when I open it as svg it's just fine. Can you help me with this problem?
Check out
Test.svg for this preview that I'm talking about. PS It's in polish but I got the same problem with eng version.— Preceding
unsigned comment added by
Agnaton (
talk •
contribs)
11:47, 15 December 2015 (UTC)
This is a known issue. Because Wikimedia uses librsvg to render SVG to PNG raster format, it will look different than browser or other graphic software because all applications interpret SVG differently. Librsvg simply is imperfect when the scaled PNG dimension isn't the same as the file's native resolution (1066px wide of your SVG). You simply have to let it go or use the native resolution in the article. --
Sameboat - 同舟 (
talk ·
contri.)
13:01, 15 December 2015 (UTC)
On 10 December, I went to Commons, chose the language dropdown for the above image, and selected Chinese (zh-Hant), but it would revert the dropdown to English when I asked for a display. The language tag in the dropdown was "zh-Hant" and the language tag in the Commons-generated URL was "zh-Hant", but the language tag in the SVG file at that time was "zh-hant".
I conclude the WP tools have gone for the preferred capitalization of language tags.
I edited the SVG file to use the preferred "zh-Hant" and uploaded it to Commons, but the problem persisted. Thinking it was a cache problem, I left it alone for a week. Problem is still there today. Is the cache still a problem or is the Commons dropbox converting tags to their preferred case (even if different in the SVG) and RSVG downcasing tags? The last seems to be the case: I also added language tag "zh-cmn-Hant" to the new version of the file, and I can get it to display with "zh-cmn-hant" in the URL, so WP appears to be using the new file. In any event, something is screwy.
Glrx (
talk)
23:14, 20 December 2015 (UTC)
@
Elisfkc: Looking at the SVG source, there are no explicit settings for stroke on any element, and none for fill on most elements - only the second-last <path /> has this, in the form of a class= attribute which refers back to a rule in the <style>...</style> element. This method should be valid SVG, but I rather think that the utility that converts SVG to PNG doesn't recognise it - perhaps because the fill: property isn't part of CSS.
My suggestion: remove the whole <style>...</style> element and replace the attribute class="cls-1" with either of the attributes style="fill:#ee703a;" or fill="#ee703a". You could make better SVG by explicitly setting the colours for all of the other elements: after the </title> tag but before the first <polygon> tag, insert either of the tags <g style="fill:black; stroke:none;"> or <g fill="black" stroke="none"> - and after the last <path /> tag but before the </svg> tag, insert a </g> tag. --
Redrose64 (
talk)
16:23, 2 February 2016 (UTC)
CSS stylesheets in SVG work as expected on MediaWiki, in my experience (
this map, for example, relies entirely on one). Using
the SVG check, I've found that the problem is the <style> element lacking the type="text/css" attribute, which, unlike in HTML, is required in SVG.
SiBr4 (
talk)
17:11, 2 February 2016 (UTC)
@
Elisfkc: SVG files may be edited using any plain text editor. Don't use a word processor like MS Word, it screws it up. Open the SVG file that you downloaded, you'll see what looks like a lot of HTML except that most of the tags are not actually HTML. If you find that it's all run together on one line making it difficult to examine, you can put newlines and/or spaces between any two consecutive tags without harm:
fill is used in a stylesheet example, so it should be OK. In the example, the embedded style is put inside the <defs> element, and the <style ...> element does have type="text/css". I haven't tried rsvg on it.
Why do you say that?
The SVG spec that you mentioned describes it in detail, without mentioning deprecation (except once, in the section concerning the contentStyleType= attribute). In general, the SVG spec describes the various styling properties as if they were CSS, and
elsewhere in the same doc we find that each styling property defined in the specification has a corresponding XML attribute (the presentation attribute) with the same name. It uses fill as an example. --
Redrose64 (
talk)
19:58, 2 February 2016 (UTC)
Sorry, "deprecated" is the wrong word; the standard is not deprecating it. See
https://jwatt.org/svg/authoring/ which states "Avoid the 'style' attribute where possible" and complains that many uses of style attributes are ill considered because they do not separate content and presentation. In the above logo, everything is a constant (even the characters are presented as curves. Nobody can use a style sheet to change the font, and it's unlikely that anypone would intend to change the red path to blue. Well, maybe there's a variation for black and white presentation....
Glrx (
talk)
22:38, 2 February 2016 (UTC)
I don't see any. I do notice that it was created with Inkscape, which often adds unnecessary elements, some of which have strange effects with some SVG viewers. --
Redrose64 (
talk)
22:31, 2 February 2016 (UTC)
The path data of this logo is divided into segments horizontally which is very unusual. I did a Boolean merge (Ctrl++) in Inkscape but not until I had moved the path points so the separated shapes overlapped each other, otherwise they wouldn't merge correctly. --
Sameboat - 同舟 (
talk ·
contri.)
07:49, 5 February 2016 (UTC)
Best way to make an SVG thumbnail version of a wiki page ?
[[File:Aelfgifu theories thumbnail.svg|thumb|upright=1.20|right|Two genealogical hypotheses (green and blue) for the connection between Ælfgifu and Eadwig, combined in a diagram.
Click here for a version with clickable wikilinks.]]
Hi. What's the best way to make an SVG thumbnail of a wiki page?
I have been having a stab at it, to try to display the chart on the right
on this page. What I'm trying to do is to make a thumbnail of
this wikitext family tree, by creating
an SVG file from it, which I can then show in the article as an image alongside the article text.
I want to do this to get round the issue that (on the plus side) the wikitext tree is easy to edit, and lets me include wikilinks; but (on the minus side) it becomes far too large to view alongside the article that's describing it. With this sort of thumbnail, I hope people will be able to read the text and relate it to a thumbnailed outline of the family tree; while also being able to easily click through to a version that's large enough to be read, to read the actual detail.
I'm actually reasonably happy with what I've got -- I think it's good enough to be workable for the purpose I wanted. But it would be nice to actually get it right, so that's why I thought I should look for suggestions here.
For this first attempt, I simply printed the template page (
this revision) to PDF from the Chrome browser (version 47.0.2526.111 m), then used Inkscape to extract a cropped version of that PDF to SVG.
As I say, I think it's worked reasonably well, and it has the huge advantage of being easy and quick to repeat, if the template gets updated at some point.
But it has introduced some rendering oddities:
the spacing between the first and second columns of boxes is less than the rest, also the last two;
the lines on the chart from Edward the Elder's marriages down to Athelstan and Eadred have breaks in them, whereas they appear solid on the template;
some of the m-dashes and n-dashes in the dates have disappeared (as have hyphens in the word Anglo-Saxon);
the kerning of the top line is atrocious;
the kerning of Ælfstan and Æthelwine in the lower two rows of the chart is pretty odd, too;
plus, at 1.45 MB, the file would seem to be far far larger than it really ought to be.
The first two are issues with the PDF generated by the printing stage, so I'm guessing there are issues with the page renderer for printing. But I'm not sure what to do about that, or where to take it.
The next two (I am guessing) may be that Inkscape's extraction (version 0.48.2 r9819) as the characters appear to be missing even in Inkscape when I look at the image, even though they are present in the PDF. I'm guessing Inkscape may have done a font conversion, and not picked up glyphs for those characters. The kerning issue may be because in the PDF the header text was in bold, which Inkscape seems to have missed.
"Ælfstan" and "Æthelwine" seem to be kerned all right when viewed in Inkscape, so that may be an issue with the Wikipedia font metrics.
Finally, as to why the SVG has become so huge, I'm really not sure. The PDF was only 156 K.
Sadly, also, the SVG doesn't get included as a vector graphic -- only as a screen-res PNG -- if somebody tries to print the page it's used on; which is a bit of a pity, really. It would be good if printing pulled in a 300dpi or 600dpi render (or the original SVG code; or a distillation of it). But I guess that is one for the longer-term wishlist.
Jheald (
talk)
20:12, 6 February 2016 (UTC)
Including a SVG image file on any page will actually display a PNG file, this is done server-side and cannot be overridden. This is because not all browsers can display SVG directly; Opera has done it for many years, Chrome, Safari and Firefox for several years, IE not at all until IE9 and then only partially - IE10 was the first to do it reasonably properly. --
Redrose64 (
talk)
22:16, 6 February 2016 (UTC)
I understand that. But when you print a page, what you get is quite a lot different from what is displayed on screen -- eg no sidebar, URLs added for external links, probably more things. It would be nice if the printing code could also request higher-resolution alternate versions of the images (not just for SVG - though SVG diagrams would gain a lot - but this would be good for JPGs and PNGs too).
Jheald (
talk)
22:42, 6 February 2016 (UTC)
I rather think you should consider a different conversion utility. The one that you used has produced some horrible SVG - consider the line of text at the top. No, just consider the first two words. Here's the SVG used to generate that:
<textid="text5343"transform="translate(277,90)"><tspanid="tspan5345"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">F</tspan></text><textid="text5347"transform="translate(286,90)"><tspanid="tspan5349"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">a</tspan></text><textid="text5351"transform="translate(293,90)"><tspanid="tspan5353"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">m</tspan></text><textid="text5355"transform="translate(305,90)"><tspanid="tspan5357"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">i</tspan></text><textid="text5359"transform="translate(309,90)"><tspanid="tspan5361"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">l</tspan></text><textid="text5363"transform="translate(313,90)"><tspanid="tspan5365"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">y</tspan></text><textid="text5367"transform="translate(320,90)"><tspanid="tspan5369"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New"></tspan></text><textid="text5371"transform="translate(324,90)"><tspanid="tspan5373"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">t</tspan></text><textid="text5375"transform="translate(329,90)"><tspanid="tspan5377"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">r</tspan></text><textid="text5379"transform="translate(335,90)"><tspanid="tspan5381"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">e</tspan></text><textid="text5383"transform="translate(341,90)"><tspanid="tspan5385"y="0"x="0"style="font-size:14.07999992px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;-inkscape-font-specification:Times New">e</tspan></text>
For each individual letter, and the space between the two words, there are two SVG elements - a <tspan>...</tspan> with four attributes inside a <text>...</text> that has two attributes - 22 elements and 66 attributes for just two words and a space. The whole line, from "Family" to "England", could have been done using a single <text>...</text> element with three attributes (x=y= and either style= or class=):
<textx="512"y="90"style="text-anchor:middle;font-size:14.08px;font-variant:normal;font-weight:normal;writing-mode:lr-tb;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;font-family:Times New Roman;">Familytree,showing...KingofEngland</text>
Some of the declarations in the style= would be better set at a more encompassing scope, such as writing-mode:lr-tb; and those relating to the font. --
Redrose64 (
talk)
23:47, 6 February 2016 (UTC)
Thanks for the suggestion!
I have now tried the
PDF2SVG converter on tool-labs instead, using the same PDF. (Though I still needed to do the cropping in Inkscape). I also was slightly more careful about the right-hand edge of the crop. Compared to the Inkscape conversion, this produced a slightly smaller file (909 K before cropping; 1308 K after cropping). The text appears to have been systematically converted to Times New Roman, with much better kerning, and accurate inclusion of all the hyphens and dashes; also the boxes outlines come out more strongly coloured, which I think probably is more true to the original... however... looking at the file as a thumbnail on the article page, and also on the file page, I found I actually preferred the first conversion -- I found the font more readable (for all its issues); and also the less prominent boxes in the first version I found I thought gave a more even less distracting consistent weight across the image. So thanks very much for the suggestion, which I think is very much worth considering if anybody else is trying something similar and reading this; but for this particular case I actually reverted back to the first version. But thank you so much for the tip. The different versions are both file page is you'd like to take a look, and see what you think.
Jheald (
talk)
00:52, 7 February 2016 (UTC)
I also see that Inkscape's latest version is 0.91, rather than 0.48 which I was using; so that might be worth me testing out as well.
Jheald (
talk)
00:59, 7 February 2016 (UTC)
Your second version doesn't use any <text>...</text> elements at all. It draws each individual letter as a <path /> element, and that's bound to increase the size. In addition to that, Inkscape's crop will always increase the file size, since it doesn't actually remove anything - it merely masks it out so that it's not displayed. --
Redrose64 (
talk)
16:17, 7 February 2016 (UTC)
User:Perhelion has just managed to reduce the size of the file by re-writing it in a text editor from 1.45 MB down to 8K -- and cleared up the rendering bugs. Seriously impressive!
Jheald (
talk)
18:48, 11 February 2016 (UTC)
Thanks for approval. I first thought the problem comes from the PDF2SVG, but the problem (separating letters) appears already in the PDF, so I take another PDF converter.
[7] I tested some other, but there are all near similar (but have not the problem of the Chrome PDF feature). The boxes get all different size, so to answer your question, yes unfortunately I done most with hand (using SVG optimizer at end). (@Code size: could maybe 2kB smaller if using clones, but I thought it's fully sufficient ;-)) PS: If you update the file, the code-size is is of course less important to the functionality.
Yes, the current version has 143 SVG elements, broken down as follows: <g>...</g> - 6; <path /> - 10; <svg>...</svg> - 1; <text>...</text> - 126. Hand-crafted SVG is always more efficient, since you only include what is necessary, and none of the filler that utilities like Inkscape stuff in for no benefit. --
Redrose64 (
talk)
00:51, 12 February 2016 (UTC)
I assume because it's so huge. The
File history doesn't list one from 23:48, February 10, 2016 but there is only one broken one, from 04:48, 11 February 2016. This one is apparently 33.03 MB, as opposed to the 310 KB of the other two, so it's more than a hundred times as large. I tried downloading it to my PC, and it terminated after 2,608,242 bytes had been downloaded, part-way through a <path /> element. If the actual file similarly stops dead in the middle of an element, it won't render on anything: unlike HTML, all elements in SVG must be properly closed. --
Redrose64 (
talk)
17:32, 11 February 2016 (UTC)
This SVG is quite straightforward for modification in text editor (Notepad). I fear someone has already updated it as we speak. Anyway. First you save and open the
source SVG in both browser and text editor. I use Firefox and it provides the inspector view by pressing F12, same for Chrome. Use the "pick and element from the page" (square with a mouse pointer icon) to select your target state and it will highlight the source code. Remember/copy the highlighted id value (e.g. id="KS") and search it in the text editor, change the fill value which means the color and save it. (For reference you can look for the state of the desired color in the inspector view). Preview it in
SVG check before upload. Once you're in the "What it will render like" page, you can simply F5/refresh-resend the page whenever you have modified and saved the SVG for another quick preview. Obviously you can F5/refresh the source SVG already loaded in your browser, but remember browser and Wikimedia use different SVG rendering engines and the results may differ, so check in both sides to be safe. --
Sameboat - 同舟 (
talk ·
contri.)
02:58, 3 March 2016 (UTC)
Double checking using your browser (but not IE, please) together with SVG Check is good, but both of those rely on interpretations of the SVG standard. I like to triple check, using a validator produced by the same organisation that writes the standards: have a look at
c:Template:Valid SVG; near the top of the documentation of that it says "English: This template is used for marking
SVGs to be valid. This can be checked with the
validator of the
W3C." If it succeeds you can do
something like this - other templates are available. --
Redrose64 (
talk)
12:48, 3 March 2016 (UTC)
New Sacramento Kings logo
To whom it may concern: I am requesting that some other editor more knowledgeable/skilled/experienced with converting .PNG image files to .SVG files help me with my request. My request is to convert
File:SacramentoKings.png to an .SVG image. I don't know how to do it; hence this message.
Charlesaaronthompson (
talk)
04:17, 29 April 2016 (UTC)
I don't know what the problem is, compared to
[8] (screenshot of orignal file). Could anyone help me, please? Thanks. --
Idh0854 (
talk)
17:43, 3 May 2016 (UTC)
Asking for help to add more details on the Coat of Arms Of Hong Kong
Recently I am studying on the historical flag and Coat of Arms Of Hong Kong. In fact, the SVG File of the Coat of Arms Of Hong Kong have some mistakes that related to the completion of the emblem. I found an official document with the original emblem with pretty high resolution in pdf format. Due to my skills on constructing a SVG File is not enough to finish this project, so I am seeking for help in this board.
Momocalbee (
talk)
14:40, 14 May 2016 (UTC)
From above: As of February 2014, the objects that must be modified to render correctly by libsrvg include: Lines with arrow heads (the arrows need to be converted).
I think that's been fixed. I had a problem with some arrows rendering backwards in 2015, and WikiMedia was rebuilt with a later version of the SVG renderer to fix that. See
File:Adservingfull.svg, which has lots of arrows and now renders properly.
John Nagle (
talk)
18:55, 24 May 2016 (UTC)
From that report, middle markers are apparently broken, while arrows at the ends are OK. Did someone file a Wikimedia bug report for that?
John Nagle (
talk)
06:58, 25 May 2016 (UTC)
This is a non-free image, part of the requirement to having a non-free image hosted on wikipedia is it being a low-resolution image. Because of these two points (non-free image, low-resolution requirement) there is no rationality to spend the time and effort in creating a SVG image. A SVG image is for vector images which means it can be scaled to any size without distortion, meaning going against the requirements of having a "low-resolution image". If the image were a free or open licensed image I can see taking the time to make a SVG but since this is not the case I don't think anyone will take up this request.
Offnfopt(talk)10:52, 10 June 2016 (UTC)
I fail to see how this logo is any different from any other sports logo on the wiki.
They'reallnon-
free. The Panthers' new logo should be brought into line with the other sports logos. --Kevin W. -
Talk19:54, 11 June 2016 (UTC)
I think the rationale is a bit contorted/obscure.
The basic argument is non-free images should be low resolution, therefore if we grab a high res bitmap from a company's website, then that bitmap is downsampled to get a low-res bitmap for non-free use.
If, however, the team's website has an SVG file of its logo, then I've been told WP just borrows the SVG file and doesn't do anything to diminish its resolution.
I don't know where rationale is written down, I have never see it.
However, if you look at
File:NewYorkYankees PrimaryLogo.svg and the fair use box at "Low resolution?", it says that WP should use the SVG only at low resolution. The trick appears to be that WP won't use the file at high resolution and (since WP stole the SVG file), WP didn't violate any copyright by producing a high resolution SVG of the logo. If some other infringer wants a high res SVG file, they could borrow it from the company website just like WP did.
The concepts of "high resolution" and "low resolution" are meaningless when discussing SVG files. The S in SVG stands for Scalable, and the point about SVG is that you can scale it to any size that you like and the edges remain sharp. Curves remain curves, diagonal lines remain diagonals - you never reach a point where edges become
pixelated. It is possible to define a SVG file to have a nominal resolution of 1px by 1px - let's do exactly that, and draw a circle inside it:
If you upload this image, you can then use the
normal file syntax to display it 250px wide, and this will scale it up to a very visible circle with none of the crap that you get when scaling up a JPEG. --
Redrose64 (
talk)
22:56, 16 June 2016 (UTC)
File:Open street map central dublin.svg
I created an updated version of this SVG -
see here - but it fails to render properly when used within Wikipedia templates, on account of the file size. Can someone who is familiar with SVG optimization process the new version of the image for me? I have tried web-based interfaces like
Peter Collingridge's tool, but again I think it fails due to the file size. --
Kwekubo (
talk)
09:54, 16 July 2016 (UTC)
All SVG exported from OpenStreetMap always contain raster image data which causes error on Wikimedia. Removing the raster data helps a bit, but OpenStreetMap is generally not meant to be edited in vector editor again so it is actually better to upload and use the PNG version. While not ruling or policy in any sense, SVG file bigger than 10 MB usually does not do the format justice because rendering it in real-time even slows down desktop computer of up-to-date specs. --
Sameboat - 同舟 (
talk ·
contri.)
12:33, 16 July 2016 (UTC)
I went ahead and ran the file through
scour and uploaded it. Check to see if that corrected the issue you were seeing, if not then revert my edit.
Offnfopt(talk)19:17, 16 July 2016 (UTC)
I am trying to find a font that looks exactly the same in Inkscape where I edit the SVG files as in Commons/Wikipedia (I do not want to use a path for text, I want it to be real text). I thought DejaVu Sans was it till I saw the result of using it in
this map. Most of the text is in the same place where I put it in Inkscape, but some is not. You can see Castellón de la Plana (Eastern coast, halfway down the map). In Inkscape or when opening the file in the browser, the text is removed from the coastline. However, when seen in Commons or opera, the text overlaps the coast. If I use the mobile interface to check the map in
here, the result is even more puzzling then when using the desktop: the map is used twice in the article, at the top of the page, where it looks correct, and at the bottom, where the overlapping of text & coast is seen again...
My question is actually twofold:
1.-Why would this particular piece of text (and some others, not many), get moved from its original position? Why this piece of text and not all the text? I tried moving it manually, saving the file and uploading it again but the problem remains...
2.-Is there a particular font that is supported by both Commons and the Wikipedias that preserves the position of text? I checked
the list of fonts but DejaVu Sans is tehre and does not seem to work well and I would rather not go down the list font by font to see if any of them works...
For text that includes diacritics, such as Castellón de la Plana, the diacritic might be misinterpreted, so it's best to use a
numeric character reference - for ó, which is Unicode U+00F3, that would be ó which displays as ó or ó which displays as ó.
For a font to look identical on your machine and in our PNG conversions from the SVG original, identical fonts must be installed on your machine and our servers. This is not always possible. The recommended fonts (see
c:Help:SVG#Fonts / text) are the Liberation group, however these may not be installed on your machine. --
Redrose64 (
talk)
13:02, 11 August 2016 (UTC)
Thank you for your suggestions. I have not tried replacing the characters by their codes yet but I found something strange even when using Liberation fonts: the same file shows up differently in Commons and a Wikipedia (I used the Spanish one but the German one shows it the same way). I may be wrong but I thought for some obscure reason the files are turned into PNG instead of using SVG directly but at least did so the same way everywhere... Not so:
this PNG differs from
this one. I wonder why because the first one shows the text in their right positions, while the second one does not... Different code doing the SVG to PNG conversion maybe?--
Rowanwindwhistler (
talk)
20:29, 11 August 2016 (UTC)
Even after the last SVG rendering engine update, SVG on Wikimedia still looks relatively misplaced when the resultant PNG is scaled which I have already explained in
c:Help:SVG#Text transform limitations. For better result, you should use the correct text-anchor (similar to CSS "text-align" but it's not for SVG) value (start[default]/middle/end) for your text, e.g. "Elche" is placed to the left side of its dot, you used "middle" text-anchor for it which should be "end" instead. If you don't change it, "Elche" would overlap its dot or move away from the dot. --
Sameboat - 同舟 (
talk ·
contri.)
01:16, 12 August 2016 (UTC)
The SVG (PNG) in Commons does look the same as the
one in the Spanish Wikipedia. Which means the problem may lie in the MediaViewer (whose SVG/PNG is indeed different from the others). This means that all users that have the MediaViewer enabled (as I had for some reason), will see the mangled version... Not nice.
The SVG/PNG shown in the article itself seems to show the offset (I am always checking Castellón de la Plana, to make comparisons easier) but, if the size of the map is increased (I did a preview setting the image size to 400px), the shifting of the text is gone! Should the position of the text change with the size used for the Image element in Wikipedia? I hope not!
I will have to go over "c:Help:SVG#Text transform limitations" again as I am afraid I had a hard time understanding it so far (a bit too technical for me probably). Anyhow, if I understood correctly, the best rendering results are achieved if the font size is around 80px, am I right? I may have made the mistake of creating a map with small fonts (<6 units in Inkscape) and then changing the side of the map to make it bigger (usually when making SVG versions of already small raster maps) which I understand can cause issues with texts. If I understood correctly fonts should be bigger than 10px at all times and, if possible, around 80px. Am I right?
I did not know about the text-anchor parameter but I am not sure I fully understand how it works. I seems to mean that, if the width of the text has to change from what I see in inkscape (I still do not understand why it should if, say, I am using Liberation Sans in Inkscape and Commons/Wikipedia supports the font), it will keep the chosen position of the text (start, middle point or end) and expand the text as necessary along the other ends (end, start & end or start, respectively). So, if we have a piece of text related to a dot that is placed to the right of the text, we want to ensure the end (right side) of the text is not moved so we choose text-anchor=end. Did I get it right?
At the risk of asking a very silly question: if Commons encourages the creation of SVG files, even for existing raster ones, why does it turn SVG files into PNG afterwards? Why not render the SVGs directly? I apologize in advance as I sense I am asking something basic but I do not quite get the point of creating a SVG version of a PNG if Commons/Wikipedia will end up turning it into PNG again...--
Rowanwindwhistler (
talk)
14:24, 12 August 2016 (UTC)
MediaViewer is not the reason of the text issue, it's just that MediaViewer uses a different resolution of the source SVG. You can render your SVG on Wikimedia in different resolution to your heart's content by changing the numeric value before "px" in the
PNG render URL to the target width, but the more PNG renders you generate, the more resources of Wikimedia server it costs.
The issue with text dislocation is somehow related to how SVG is rendered to PNG on Wikimedia. Because there is a limitation to the precision of font size value, e.g. 20.5px font-size value is truncated to 20, also the resize of the resultant PNG render isn't in the more ideal process of "source SVG->PNG in source SVG's native resolution->PNG resized from PNG in native resolution". I suspect this has something to do with server performance.
I have removed the "80px font-size" claim. Just make you SVG in the reasonable resolution so it doesn't require the user to zoom in or out.
text-anchor:end is literally text-align:right, nothing magical.
Rendering SVG in real-time can be performance-taxing especially for complicated or animated SVG. PNG loads faster but lacks the flexibility to be edited for complex image. The point of uploading SVG is that our contributors can easily fix a typo of the image without some tricky image editing skill, e.g. if I spot a misspelled name in your SVG, I just download it, open it in Notepad, search the wrong word and correct the text, save and re-upload, done! If your image was only in PNG and the typo occurs on complex background, I would have to erase the text pixels, redraw the background so it appeared to be text-free, type the new text and pray that I didn't make another typo again. --
Sameboat - 同舟 (
talk ·
contri.)
14:50, 12 August 2016 (UTC)
If MediaViewer is not the source of the problem but shows a different result from Commons and the Spanish Wikipedia, would the difference be due to the size of the rendered map then?
If the precision of font size value plays a part in distorting the way the font is shown, then I gather that turning that value into an integer should help minimize the distortion?
If
this is correct, then it does seem that the size of the font matters when it comes to font distortion? Or would this be valid for Dejavu only and not affect Liberation fonts?
I think I understand how aligning text works when we have several lines, but I fail to see how it affects a single word like Elche. If we say we want it align to the right (text-anchor:end), to the right of what if we have just 1 line with 1 word?--
Rowanwindwhistler (
talk)
21:19, 12 August 2016 (UTC)
To add to Sameboat's comments: SVGs are fully scalable to any level, PNGs are not. For any given file, our servers hold one original and several scaled copies, one for each different size that's displayed in pages. When a new size for an existing PNG image is set in a page, our servers make a copy of the original, scale it to the desired new size, and save it: something is always lost during scaling, whether it be enlargement or reduction. When a new size for an existing SVG image is set in a page, our servers make a copy of the original, scale it to the desired new size, convert it to PNG and save that: nothing is lost at the scaling stage, and all that is lost at the conversion is the crispness of a diagonal or curve - but the jagged edges are pixel-sized, so hardly noticeable. We convert SVGs to PNGs server-side because not all browsers support SVG files (Microsoft browsers are worst for this), whereas there is pretty much universal support for PNG. --
Redrose64 (
talk)
22:51, 12 August 2016 (UTC)
I have already answered you and yes, it's the resize of SVG-PNG causing the problem. Also keep in mind that MediaViewer regenerates a new thumbnail relative to your current browser window size, so everyone with different browser size sees different size of the PNG render, IOW different dislocation of the text.
You should use integer font-size value, but another issue is that there is no guarantee the font-size value would remain integer after uncontrolled resizing.
All fonts are affected by this issue.
Text-anchor just helps fixate the "anchor point" of the text. It doesn't solve the text issue on Wikimedia. It's just that you don't need to position all text again when you change font-size, font-family or font-weight which all affect the virtual length of the text/glyph. --
Sameboat - 同舟 (
talk ·
contri.)
23:07, 12 August 2016 (UTC)
@
Perhelion: Regarding
File:Fonttest-Kerning.svg, there is a practical issue of scaling down a big font-size value (80px) to the actual desirable size. For example, if you want 16px font-size from 80px, you will have to include the transform="translate(x,y)scale(0.2)" in every <text> element, this will unnecessarily bloat the SVG file size especially if there are tons of text scattered in the image arbitrarily which is usually the case with most diagrams. To me this practice is not justifiable JUST for dealing with the font issue on Wikimedia when most browsers (except IE) can already handle SVG text properly. If you group all text and only apply the transform-scale to that <g> element, you will have a funny time to re-calculate the x/y coordinates of all text which are not intuitively related to their effective positions in the canvas.
You CAN start with an extraordinarily big
viewBox dimension and scale down with width and height attributes in the <SVG> element (e.g. <svg viewBox="0 0 4000 4000" wdith="800" height="800">), it's just that all the x/y coordinates values in the SVG will have to be multiplied as well in an unnecessarily unusual way. --
Sameboat - 同舟 (
talk ·
contri.)
03:56, 13 August 2016 (UTC)
Hello
Sameboat, thanks for pinging, but I'm not fully sure what is going on here (especially why you removed the fact of the 80px issue). You are right what you saying, but unfortunately this is the workaround and so you can't prioritize a small file-size (if better text rendering is the goal). And yes the viewBox issue don't bloat the file-size but needs some rework (especially if different text-anchor are used) that's why I called it "unfortunately". → User: Perhelion12:32, 13 August 2016 (UTC)
Text alignment on WP
Comment. I'll throw in a test image of text alignments. Notice that WP does text-anchor left/center/right, but does not do the alignment-baseline variations yet.
Glrx (
talk)
01:09, 18 August 2016 (UTC)
Help need with an svg map
Hi,
I have created this svg map of italian comuni (cities) and I uploaded it on commons. The upload was successfull and the map is seeable in a wiki page, but when passing to the original source, problems arise. I then tried with another version not processed with SVGcleaner but there are still problems even if different. I have done the test Markup Validation Service and both failed with one error but I am a beginner and I do not know how to correct properly the error. I tried in some way to correct the error of the second upload version and now the validator says it is ok but the original source has still the problem (it does not zoom) and maybe it is a problem of my map more than a source code error. Is it possible? If so, how can I fix it?
I think I have solved the problem using another compressor instead of SVGcleaner. The validator still gives me an error but the zooming problem is fixed.
I've created
a vector image I'd like to use in a Wikipedia article and uploaded it as an SVG - although I don't know much about the format. It's not displaying properly in the rendered PNGs - black box covers the main diagram body - but seems fine when viewed as an SVG in-browser; what's the best way to fix this?
AliShug (
talk)
17:35, 3 October 2016 (UTC)
@
AliShug: There is something wrong with the way the program you used saved some of the elements in the SVG. I was able to edit the file to get it to render properly but it took drastic changes to get it to that point. I wasn't able to open the SVG properly at first so I ended up recreating some parts of the rockets (some parts may be a bit more simplified than before). Hopefully the end result works at relaying the information properly.
Offnfopt(talk)09:45, 4 October 2016 (UTC)
Regarding "I wasn't able to open the SVG properly at first", it's probably because there are no newlines in the original version of the file - everything is on a single line, i.e.
- some editors have a maximum line length and won't process beyond that, for Microsoft Wordpad (as bundled with Windows XP) it's several thousand characters, but well short of the 89,839 bytes for this one. Another problem is that there's no
I'm using Adobe Illustrator CC which does seem to have a few glaring issues; probably the biggest is that it doesn't tag the style as "text/css", so all of the styling information gets ignored. I'd exported as minified which will be why it was a single line - I assumed the export would be good-to-go from the start! @
Redrose64: thanks for the tips, and I'll make sure not to minify SVG files in the future. Might be a good idea to add some of this stuff to this page? @
Offnfopt: thanks for trying to fix it up! And sorry I overwrote it. I'll try and sort it out myself now
AliShug (
talk)
13:18, 4 October 2016 (UTC)
@
In Correct: Go to the file description pages on Commons (I've modified the links above accordingly), and at the top of each you should find a "Download" link, which will allow you to save the SVG source to your machine. You can then edit it using a plain-text editor, or with suitable software such as
Inkscape. If you don't feel confident, you can put a request at
WP:GL/MAP. --
Redrose64 🌹 (
talk)
15:28, 2 February 2017 (UTC)
Problems with the PNG renderer?
There seem to be some issues with the PNG render (though obviously we could be missing something) (
discussion here). The text on
this automatically converted SVG does not display properly when rendered into PNG (there are/were problems with the text placement, kerning, etc.). Some work has been done to mitigate the issue, (by manually retyping the text) though this of course isn't ideal since it isn't totally fixed and will need to be done again every time the image needs to be updated (which is regularly).
Is this a known issue? What can we do about it? Is there a more specific place I can direct this technical question?
Fonts have been a long-standing issue. To some degree you can mitigate layout problems by downloading to your own computer free fonts which you know are on the Wikimedia RSVG server, and using such fonts in your vector editor (Inkscape etc.), though that's by no means guaranteed to fix all font-related problems. The one quick-and-dirty fix which almost always works is "convert text to paths" (though at the expense of reuseability/translatability)...
AnonMoos (
talk)
01:17, 9 February 2017 (UTC)
The issue is not only with how fonts get rendered (which could potentially explain kerning issues), but also with text placement (which has nothing to do with actual font rendering, which should affect shape, but not position).
cherkash (
talk)
05:08, 9 February 2017 (UTC)
I have seen SVGs converted from PDFs where the "text" contained no words at all. Each individual letter had its own <tspan>...</tspan> element, each of these in turn was wrapped its own <text>...</text> element. One of these (I forget which) had the x= and y= attributes to position the letter concerned. It wasn't the fault of the PDF→SVG conversion, since the PDF also positioned each letter separately. Very inefficient. --
Redrose64 🌹 (
talk)
11:22, 9 February 2017 (UTC)
Another example of an SVG image that is improperly rendered:
File:Triangle_in_Z13.svg. The numbers along the sides are mis-aligned and the entire bottom row is rendered outside the bounding box.
SamRushing (
talk)
I think that problem may be due to font-size="0.75px"; libsrvg font handling has some buggy interpretation that does not scale appropriately. The numbers along the side have a large spacing (i.e., "12" looks like "1 2"). The baseline calculation is off by "1 pixel" scaled to one square, so the left side numbers are 1 square too low, and the bottom row of number is 1 square below and outside the clip region.
Glrx (
talk)
23:17, 25 August 2017 (UTC)
Problems with subtitles
Hello everyone! I translated tow maps (
file:Polska 992 - 1025-pt.svg and
file:Kabyle-Roman camp-pt.svg) and I'm having the same problem with both. The subtitles of them are wrong, always when I try to fix them they continue appearing as you see now (the letters are unreadable and unconfigured). I tried many times and for the first one I asked
Rowanwindwhistler (
talk·contribs)'s help, but even him could't find the problem. If one of you could help with it I will appreciate very much.
Something is odd, I played around with the second file and tried opening it directly in a browser (which in firefox produced some really odd results). I do note that the font-size is very small according to the actual file, e.g, "font-size:0.27726999px" and transformed. --
Erp (
talk)
04:42, 24 February 2017 (UTC)
I really don't know what the author of the second map did because I can't even erase parts of the map. It's like there is a kind of "protection" against such edition. About the text, I tried many times copy and past my subtitles thinking that the problem could be that the text was in a wrong layer, but the map has one layer anyway.--
Renato de carvalho ferreira (
talk)
05:11, 24 February 2017 (UTC)
As Erp has said, the problem is really the font-size being is too small.
Librsvg on Wikimedia for rasterizing SVG into PNG is extremely inaccurate (to the point erroneous) to upscale text. Do not attempt to use transform="scale(x,y)" to upscale the text, the result is exactly the same. You need to restore the font-size to like 20px and then downscale with transform/scale and reposition all text manually.
The first file is simply huge, unnecessarily so, since there is not enough detail to require that, and the font size to small; you could simply rescale the file to something smaller and at the same time increase the font size. After that, I'd also suggest converting the text to paths for better scaling. I've edited the second file in Inkscape, and with a few tweaks it has worked fine.
Constantine ✍ 07:18, 24 February 2017 (UTC)
For my edification, what tweaks did you use? --
Erp (
talk) 16:40, 24 February 2017 (UTC) Followup: I handedited the file to remove the width, height, and viewbox at the beginning. Opened in Inkscape, select all, scaled to a reasonable size, reset page size under document properties to match size of drawing, and reset all the text to a font and font-size combo. --
Erp (
talk)
17:15, 24 February 2017 (UTC)
Could there be a problem with the SVG file? I looked at the SVG file code but did not see anything that I understood. Thanks. –
Jonesey95 (
talk)
19:54, 28 February 2017 (UTC)
I've just uploaded an SVG image but it is not displaying properly when a thumbnail is generated. It is displaying as black when scaled. Can anyone help?
but it lacks the type="text/css" attribute which (although not required by
the SVG spec) is necessary for some agents to correctly process the enclosed rules. I'd also put in some newlines and spaces for clarity, giving
I've been trying to create some SVGs in order to make it easier to translate images. I've used the object to path function to convert the text into shapes, but this does not seem to be helping.
@
CFCF: The thread that you link to misdescribes the problem ("flowtext" should have read "flowRoot" throughout), but looking at old versions of the image discussed there, it is the same problem that you are having. Your image contains the following structure:
Once uploaded on commons, black square appears. See
this archive.
Cause 1
The element <flowRoot...></flowRoot> is not supported. It was proposed in a svg 1.2 draft documentation, but never became standard. Inkscape use it (but it's not valid).
How it happen
When you create a text-box by clicking and dragging the text tool in inkscape, you create a flowroot box.
Please get the attribution right. The original artist was
User:jeremykemp; he put it in the public domain, but it is still appropriate to give attribution.
User:Jado did nothing. All
User:Jalo did was transfer the file to Commons.
The only reason I converted them to curves was because of this persistant bug. As for Jalo, that is from the old file description — that it was inadequate is not my fault — even if I now will go ahead and change the description. Please try to be less adversarial, and if you find that there are errors in the attribution page, just fix them. :)
Carl Fredrik talk06:14, 14 June 2017 (UTC)
We (French wiki graphists) where doing the same, converting text to curve in order to avoid this black square / flowRoot bug.
The W3C validator checks SVG 1.1. It can be run by including {{
Invalid SVG}} on the Commons file page and clicking the hyperlink. The validator complains about the flowRoot at line 73:
Commons:Commons SVG Checker should also find this error (and other problems). The code at
Commons:MediaWiki:CommonsSvgChecker.js looks for flowRoot, but don't believe the result unless it prints the termination message "Check Finished!". The code may quietly throw an exception; check the F12 console log.
Hello, may I ask for your experience in resolving a problem I am having? A .svg country map contains the numbers 1 to 14. However, a certain number, the number 7, has a minus (-) displayed before it, (it shows like -7 on the map) which is not intended and has no purpose in that map and it must be removed.
I could edit the .svg myself and remove that minus (-) symbol from number 7, however, I can't, because the minus symbol is not present when opening the .svg with an editor.
Lets say, when I am editing that .svg file with Incscape (an .svg editor - I have tried both online programs and desktop programs), but the minus (-) is not present in the .svg editor at all, not even next to number 7. However, when the .svg file is viewed through Wikipedia, the minus symbol is still there, next to number 7.
What is causing this visual glitch?
I do not know what else to do. I am at a loss, because this map is really beautiful, and yet, it is ruined by the minus symbol which was not meant to be there at all.
In the SVG source code, remove the following block:
<flowRootstyle="font-style:normal;font-weight:normal;line-height:0.01%;font-family:'Bitstream Vera Sans';fill:#000000;fill-opacity:1;stroke:none"id="flowRoot9791"xml:space="preserve"><flowRegionid="flowRegion9793"><recty="3013.1572"x="200"height="75"width="262.5"id="rect9795"/></flowRegion><flowParaid="flowPara9797"style="font-size:40px;line-height:1.25"></flowPara></flowRoot><textid="text5962"y="625.65692"x="4556.25"style="font-style:normal;font-weight:normal;line-height:0%;font-family:'Bitstream Vera Sans';fill:#000000;fill-opacity:1;stroke:none"xml:space="preserve"><tspany="625.65692"x="4556.25"id="tspan5964"sodipodi:role="line"style="font-size:40px;line-height:1.25"></tspan></text>
It's the "rect" element in the middle of this block that gets rendered as a rectangle by the Wikimedia renderer (but remains invisible in Inkscape).
Fut.Perf.☼21:09, 20 June 2017 (UTC)
By the way, it happens to be the same technical issue as the "black boxes" problem treated in the thread immediately above.
Fut.Perf.☼21:13, 20 June 2017 (UTC)
Hello everyone. I was trying to translate
file:Indian_Kanauj_triangle_map.svg, but when I want to upload my map the system says that it is not possible to analyze the XML from the image. I thought that it might be something with my image so I tried to upload using the original image, but when I try appears something like this: "This SVG file has a nominal space forbidden -"
http://iptc.org/std/iptc4xmpcore/1.0/xmlns/" (this is a free translation because I use the system in Portuguese and I don't know exactly what says in English). Does anyone know what to do?--
Renato de carvalho ferreira (
talk)
00:34, 23 July 2017 (UTC)
I would not translate this file. The file is a piggish 389 kB. It has embedded copyrighted fonts. Wikimedia does not handle textpath, but the file has simulated text on a path by individually placing characters instead of easily parsable text. For example, "Godavari" is made with:
A program trying to analyze the text might see the (x,y,θ) coordinates and give up.
The SVG also sets xml:space="preserve". That's not the default space setting, and some browsers do not render preserve correctly, but it should not throw off parsing character strings (they would just have missing and extra spaces).
The map needs a lot of remediation before it would be a good candidate for translation.
However, Wikimedia Commons will not upload SVG with internal scripts. What's the status on this? If scripted SVG is prohibited, is there any expectation that that will change in the future?
— Preceding
unsigned comment added by
Wes Kyle (
talk •
contribs) 17 August 2017 (UTC)
Scripting is not allowed, and that will not change anytime soon. If the wiki servers detect SVG with JavaScript or ECMAScript, then they will not upload the file. SVG with CSS can be uploaded, but I think some CSS will be blocked.
MediaWiki does not serve SVG files directly. Instead, it converts them to PNG files and then serves the PNG. Consequently, scripts would never have a chance to run when the file is included in an article for the simple reason that the SVG is not there in the first place. The benefits of your scripting would not make it to an article page.
If the SVG file were served, then CSS would be available to change colors on hover.
If the SVG file were served, then title elements could be used to make tooltip popups.
If the SVG file were served, then a elements could be used to follow links. The element may contain graphics; see
example. Clicking on a polygon should follow the link.
If the SVG file were served, then SVG's SMIL animation would be available.
So much of what you do in your picture can be done in SVG without JavaScript/ECMAScript.
At some point, MediaWiki will probably serve SVG, but I doubt that will be anytime soon. Many SVG files on Commons are not yet ready for prime time. They may be bloated, they may not specify fonts reasonably, they may misuse svg element attributes, and they may not be valid SVG. In addition, many browsers have SVG bugs that cause valid SVG to display incorrectly. Right now, an SVG file need only work with librsvg (which also does not do many things right; it does not do text on a path at all) to display correctly on any browser. There's no guarantee that an SVG that works with librsvg (many files don't) will also work with other browsers. Chrome, the dominant browser, does not handle systemLanguage correctly; neither does Edge. Edge's rtl BIDI algorithm is more broken that librsvg's. Not all browsers handle xml:space="preserve", but Inkscape (the dominant graphic editor on wiki) uses that mode.
I have redrawn a svg logo for the Bloem City Blazers cricket team. I uploaded the svg file here, but it was soon deleted:
commons:File:Bloem_City_Blazers_logo.svg
I guess my question is what is the ideal method to upload my svg file I drew to this Wikipedia page:
Bloem_City_Blazers
What are the requirements to upload logos for sports teams without infringing on copyright?
Any advice would be appreciated as I want to upload more svg files for other cricket teams.
Most logos will have copyright protection. Consequently, they cannot be uploaded to Commons unless the creator has provided a Wikimedia-compatible license to use the art. For a logo, such a release is unlikely.
Copyrighted logos can be uploaded to en.Wikipedia under a fair-use exception. That exception requires that the uploaded image be low-resolution. Consequently, many logos exist on en.Wikipedia as low-res PNG images.
Now we get into sticky business. SVG files are inherently high resolution, so SVG files are not compatible with the low-res restriction and should not be uploaded to en.Wikipedia.
In another twist, en.Wiki will allow copyrighted SVG logos to be uploaded if the SVG file came from the company's website. I think that is a little squirrelly, but there is some logic to it. See the logo for
Super Bowl 50 at
File:Super Bowl 50 Logo.svg.
Since you converted the logo to SVG, it is a high resolution image. It's not from the company's website, so it would not be an acceptable image on en.Wikipedia.
A solution might be to upload a low-resolution bitmap to use in the
Bloem City Blazers article, but that may still not succeed because the team is in South Africa. I don't know if fair use applies to images from foreign jurisdictions.
The color
here (correct color) is different from
here. I tried looking at the code, but could not figure out what is wrong. Why is it shown differently? It is shown correctly in the program and the browser, but not in Wikipedia. –
Sabbatino (
talk)
15:02, 24 September 2017 (UTC)
Sabbatino It appears the rendering software (RSVG) is having problems properly rendering the mix-blend-mode:multiply property. When I remove the mix-blend-mode properties I get a similar rendering to the PNG image. Best that can be done at this point is to remove those properties and change the gradient colors to better match the intended colors as a work around. -
Offnfopt(talk)16:13, 24 September 2017 (UTC)
Looking carefully at the file source, I have found three elements that give me concern:
In these, the isolation: and mix-blend-mode: styling properties are not part of SVG 1.1 at all. Hunting around the specs for CSS 3 (both agreed and proposed), I find that both are part of
Compositing and Blending Level 1 which being a W3C Candidate Recommendation is not yet accepted as a standard, so our tool that converts a SVG source to a PNG is not obliged to recognise it. I am pretty sure that it is the mix-blend-mode: property is the main problem here, and that the isolation: property has little (if anything) to do with it. --
Redrose64 🌹 (
talk)
16:41, 24 September 2017 (UTC)