Commons talk:SVG Check

Latest comment: 8 years ago by Perhelion in topic Is this temporary?

MediaWiki compare (feedback) edit

The fonts seams in certain cases not the same as in MediaWiki (if the font is not supported by MediaWiki seams to have a compare list). Also embedded images are not rendered. --Perhelion (talk) 12:25, 9 November 2010 (UTC)Reply

Hmm, interesting. Do you have a specific example? Pretty sure we can get that fixed.
Could you expand on your second point about embedded images? You've got me interested :) Jarry1250 (talk) 18:10, 9 November 2010 (UTC)Reply
Oh* yes but only short, a specific font is Arial which Mediawiki renders as "Liberation Sans". With "embedded" I mean bitmaps (sorry no practical example yet, maybe tomorrow). Can you retrace this? --Perhelion (talk) 21:11, 9 November 2010 (UTC)Reply
Embedded bitmaps can't be fixed. It requires that the bitmap be stored somewhere in which the SVG can grab from (like in your system). ZooFari 17:20, 14 November 2010 (UTC)Reply
Ok here are the more clearly examples (what I mean?) Category:SVG images with embedded raster graphics :). --Perhelion (talk) 20:28, 14 November 2010 (UTC)Reply
Right, but they can't be fixed. The bitmaps would need to be vectorized manually, like any other raster. ZooFari 20:48, 14 November 2010 (UTC)Reply

(outdent)The entire concept of embedded bitmaps is that they are included in the SVG. They are stored as data URLs, usually using Base64. There is no reason you should need a separate file. That would be a linked bitmap. Trlkly (talk) 14:20, 29 January 2012 (UTC)Reply

librsvg-ERROR edit

_rsvg_acquire_xlink_href_resource called for external resource: " base: (null) in WikiMedia, but your „librsvg“ render this image without any problems (see on file:Test.svg). I don't know the fault or the bug. Greetings --Perhelion (talk) 18:32, 14 December 2010 (UTC)Reply

I would also be prosperous if someone can be involved to help or support here Category_talk:Pictures_showing_a_librsvg_bug#This_category_need_a_Template --Perhelion (talk) 19:34, 14 December 2010 (UTC)Reply

I think I found a reason for this bug http://strategy.wikimedia.org/wiki/Proposal_talk:Librsvg_development_funding#Minor rendering bugfix --Perhelion (talk) 20:24, 12 January 2011 (UTC)Reply

Incorrect rendering of text edit

Hi,

I've used this tool to try and resolve a SVG text problem. The tool showed the text rendering correctly, but once I had uploaded it to wiki commons the text issue remained. See below. Pluke (talk) 14:33, 10 July 2011 (UTC) centerReply

Not really, for me JARRY1250'S TOOL does display exactly the same (419 × 527) Maybe you're underlie a cache mistake (current version). This is only a current cache problem (s. COM:HD und COM:VP) PS: Yes you are right to adjust the font ("Condensed" was still too large, as I already mentioned here). -- Perhelion» › 15:40, 10 July 2011 (UTC)Reply
I've added my vote to the bug fix. Thanks for all your help Pluke (talk) 20:50, 10 July 2011 (UTC)Reply

Different results to svg2png edit

Further to previous advice, I've used this tool on a file converted from PDF using misc2svg. Unfortunately the resulting file produces "Not an SVG file" with the SVG Check tool, but the svg2png link I previously referred to does render it. Note also that I'm having the same results with the following files, which are successfully converted by MediaWiki:

Is there further relevant discussion which I've missed? Thanks. --Trevj (talk) 09:09, 26 August 2011 (UTC)Reply

CSS bug is not reproduced edit

File:Wanderwee_symbol_+.svg#filehistory the old file version does not render with a blue background as it should on Commons. https://bugzilla.wikimedia.org/show_bug.cgi?id=31122 But it does render blue with svgcheck (also with the trunk version). Cheers --Saibo (Δ) 18:53, 23 September 2011 (UTC)Reply

Yes I've also some examples that not appear in SVG-Check
  • Most (all now?) specific XML attributes in the root SVG tag self are ignored
  • Some attributes are generally ignored, like: fill-rule:evenodd
Also, you may specify which librsvg version is currently being used? -- -- πϵρήλιο 16:30, 24 September 2011 (UTC)Reply
I now specify which version of (lib)rsvg is being used, so at least it's obvious if there's a difference between TS and MW. Jarry1250 (talk) 22:16, 31 January 2012 (UTC)Reply

Small suggestion edit

Many images have white fill or transparency, most window backgrounds are also white, so you can never really see transparency (before upload). But so you could make your test window-background colored!? -- πϵρήλιο 15:47, 26 October 2011 (UTC)Reply

I've (belatedly, my humble apologies for the delay) added the familiar "checkerboard" background. While I know some people don't like it as a way of showing transparency, I think that's best left for other people to argue over :) Jarry1250 (talk) 22:16, 31 January 2012 (UTC)Reply

Help with SVG edit

An SVG check of this file doesn't show any error, but MediaWiki seems to be having trouble with the clip path. The right half of the central fleur-de-lis should have a black outline, to match the background, and Chrome renders it like that, but MediaWiki doesn't. I tried removing one of the two clips and it still didn't work. Any ideas? NikNaks talk - gallery - wikipedia 16:51, 29 January 2012 (UTC)Reply

I see you've managed to fix this: were there any lessons to be learnt in there? Jarry1250 (talk) 22:16, 31 January 2012 (UTC)Reply
The renderer seems to have trouble clipping multiple objects in a group unless they're individually clipped (and not the group as a whole), whereas it works fine in Inkscape, Firefox and Chrome. Not a huge problem, but interesting to know. NikNaks talk - gallery - wikipedia 07:22, 1 February 2012 (UTC)Reply
That's great, I'll take a look at adding a check for it. Jarry1250 (talk) 11:16, 1 February 2012 (UTC)Reply

Wiki doesn't support CSS styles edit

Your optimizer likes to consolidate all objects with the same style attributes into a class. This, unfortunately, does not work with the renderer, and just makes all objects default to black.

I know it's beta, but I thought you might like the info anyway. --Trlkly (talk) 19:34, 4 May 2012 (UTC)Reply

Do you have an example? I know of plenty where classes do work with librsvg (e.g. with the blue in this file). It's tags (and possible IDs, I can't recall) that don't work, to my knowledge. Jarry1250 (talk) 16:36, 5 May 2012 (UTC)Reply
Weird, as this is a problem I run into all the time. Fortunately, I'm now fixing up a new SVG, so I'll upload the unoptimized version. Try optimizing en:File:Vietnamese Fatherland Front logo.svg. Due to the classes, everything will turn black in your preview.
Also note that running the SVG through the latest version of SCOUR before using your tool usually prevents classes from being made, as it uses groups to consolidate and converts the styles to tag attributes. This is the workaround I've been using on all the SVGs I upload to wikimedia projects. Trlkly (talk) 21:19, 20 May 2012 (UTC)Reply
BTW, when you've read this, please let me know, so I can go back and optimize that SVG. Trlkly (talk) 08:03, 7 June 2012 (UTC)Reply
Weird, I can't work out what the renderer's problem with it is, given that it usually supports classes. Upgrading the version of SCOUR used might help, however. Jarry1250 (talk) 22:13, 8 June 2012 (UTC)Reply
Maybe, but my guess is that there's a bug in the RSVG version used on wiki. I do know that the latest SCOUR has a "Group similar" option that seems fix it, so try that. Trlkly (talk) 17:09, 29 June 2012 (UTC)Reply
I've found an example and and the fix: You must add type="text/css" to the <style> tag. See file:MediaWiki_1.21wmf3_page_history_screenshot.svg (from 00:39, 10 November 2012). Greetings -- ΠЄΡΉΛΙΟ 23:56, 9 November 2012 (UTC)Reply

SVG Check loads files from cache!? edit

I've notice this since your publish this tool (arbitrarily). If you load another file (or the same changed) with the same file-name again it loads alway the old file?!? Maybe its a bit arbitrarily. PS. It seems depending on the browser settings (me has FireFox and Chrome) -- πϵρήλιο 14:22, 21 September 2012 (UTC)Reply

Read error edit

Notice: getimagesize(): Read error! in /home/jarry/public_html/svgcheck/stable/index.php on line 46 

On File:Flottenverband Lütjens bei Weserübung.svg (and some other images, but only some times!?) -- ΠЄΡΉΛΙΟ 21:50, 19 November 2012 (UTC)Reply

Small hint, it's the file name. -- ΠЄΡΉΛΙΟ 18:25, 22 November 2012 (UTC)Reply

Wikitools version is broken edit

You probably should keep at least a backup link to the toolserver version until you can make sure the Wikitools version is always up. It still works well enough for the most common problems, and is better than uploading files multiple times. Trlkly (talk) 19:36, 24 December 2013 (UTC)Reply

BTW, while it appears to be up right now, uploaded files are not rendered. The Wikitools version is apparently not ready for prime time. I'm putting back a link to the toolserver one. Trlkly (talk)
I've since reported this as a bug, and it was subsequently fixed. However, I am leaving the old link just in case there are other problems. I will clarify that it is not the best choice to use. Trlkly (talk) 10:25, 14 January 2014 (UTC)Reply

Option suggestion edit

Some bugs (generally filter effects) only appear in lower (article) resolution ~200-300px. So I suggest an option for output resolution. An example File:ADAC Wahlstruktur.svg (first version). -- Perhelion (talk) 18:53, 24 March 2014 (UTC)Reply


Another small improvement suggestion: could you please add accept="image/svg" to the upload button. This would save time in selecting (and searching) and mistakes during upload. RegardsUser: Perhelion (Commons: = crap?)18:28, 15 November 2014 (UTC)Reply

Problem with Chrome/IE? edit

While I can still get this to work on Firefox, when I try in Chrome, I get an error about saying that any SVG I submit is not a valid SVG file, even files I know are valid and display properly on Wikimedia. Trlkly (talk) 13:04, 15 November 2014 (UTC)Reply

I also get the same error in Internet Explorer. Trlkly (talk) 13:22, 15 November 2014 (UTC)Reply
@Trlkly Can you give the example (also your file name?)? I use Chrome and I can't reproduce this.User: Perhelion (Commons: = crap?)18:22, 15 November 2014 (UTC)Reply
I guess, but it happens with all of them. One I created myself has been uploaded here as anti-aliasing_demo.svg (which is also the name I used in the test). I get the error on Chrome 38.0.2125.111 using Windows 7 Home Premium SP1. It works fine in Firefox, and, of course, on wiki. I suspect it may be linked to your previous comment, and that Chrome is using a different mime-type for SVG files. I'll mention that in the bug report.Trlkly (talk) 08:54, 16 November 2014 (UTC)Reply
Trlkly I guess it is a Windows Registry entry to the .svg file extension (I can only remember vaguely that I had something like a time). Try first to uninstall Chrome and then run a registry cleaner like CCleaner. Helps that?User: Perhelion (Commons: = crap?)12:14, 3 December 2014 (UTC)Reply
Well, I wasn't going to use a registry cleaner, since those can cause more harm than good unless you are careful, but I did check the registry. And apparently that was the problem. SVGs were registered as "application/svg," an older mimetype for SVG. I changed it to "image/svg+xml" and that seems to have fixed the issue. Firefox must not honor the registry entry.
I think this happened when I installed Inkscape. Still, I think it would be a good idea to accept that mimetype, along with your mimetype of image/svg, which is also one that is used. If Inkscape is using that, it needs to be updated. Plus, if users can manipulate the mimetype, that would seem to be a security issue. They should probably test the file the way Wikimedia does. I'll update my bug. 71.31.235.31 03:56, 9 December 2014 (UTC)Reply

Is this temporary? edit

No webservice

The URI you have requested, /svgcheck/, is not currently serviced. If you have reached this page from somewhere else...

This URI is part of the svgcheck tool, maintained by Jarry1250.

That tool might not have a web interface, or it may currently be disabled.

If you're pretty sure this shouldn't be an error, you may wish to notify the tool's maintainers (above) about the error and how you ended up here. If you maintain this tool

You have not enabled a web service for your tool, or it has stopped working because of a fatal error. You may wish to check your logs or common causes for errors in the help documentation.

Gunmhoine (talk) 04:13, 3 February 2015 (UTC)Reply

Hard to tell for others, Bawolff's tools apparently only needed an authorized kick to work again. @Perhelion: reported that the author is missing here, maybe a case for the Abandoned Labs tools RFC on Meta. At least I just learned a new trick, <mark>wikitext</mark> for a wikitext effect is far better than my <strong style="background-color:cyan">wikitext</strong> for wikitext, less typing and guaranteed to get it right for screen readers and other unusual HTML5 scenarios. . –Be..anyone (talk) 23:13, 17 February 2015 (UTC)Reply
If that's the only thing wrong with it, all that is needed is for someone to run webservice start. (Recent tool outages are possibly related to https://lists.wikimedia.org/pipermail/labs-l/2015-February/003383.html. Otoh, tool labs web service seems to die randomly all the time for me without any cause...). Bawolff (talk) 23:24, 17 February 2015 (UTC)Reply
The same again for this new year!? Can Commons:Commons SVG Checker be a replacement? Bawolff, MennerUser: Perhelion (Commons: = crap?)  23:16, 9 January 2016 (UTC)Reply
Return to the project page "SVG Check".