[edit] How can black boxes have color FFFFFF?
At Wikipedia:SVG Help#Rendering files,
- If black boxes still appear after converting all objects appropriately, it may be necessary to hand-edit the XML to remove any rectangles with color FFFFFF (black), this can be easily done using the search tool of a text editor to locate rectangles or black objects.
In an RGB color model, wouldn't FFFFFF be white, rather than black? So should one look for rectangles with color 000000 instead? 85.23.33.52 (talk) 10:37, 10 August 2008 (UTC)
Indeed, this is true. Still it's what you do! User A1 (talk) 11:44, 10 August 2008 (UTC)
[edit] SVG Validity
Commons has two (new?) templates: commons:Template:ValidSVG and commons:Template:InvalidSVG. I just opposed an FPC because of invalid SVG... mostly due to sodipodi / inkspace additions... but, can anyone discuss the importance of validity? Are there certain invalid features which should be accepted? If there are acceptable invalid features then how should those templates be used and are they misleading? (Although Image:Sodipodi-logo squirrel.svg was created with sodipodi and doesn't contain the errors of Image:Caucasus-ethnic en.svg) Thanks --gren グレン 05:29, 29 August 2008 (UTC)
- Hello, here is my two cents:
- I am unconvinced of the usefulness of this. I would hesitate to make any decisions purely on the basis of this tag -- what it represents is a very complex analysis of the document, and invalid code should not be considered to be a problem provided it renders as a PNG on wikipedia i.e. through RSVG.
- Whilst it is a good fight to ensure interoperability by standards compliance, unless one has the expertise required to fully understand the issues involved, then you should not use this information in decision making. This is probably something that you want to take up with the inkscape developers, if you are of a technical bent. Otherwise marking this up is simply hyping something that people don't understand and compressing it down into a "yes" "no" result, which loses all the context of the arguments. I for one would oppose the use of this tag.
- Any appropriate understanding of this "invalid" document would come from an understanding of the SVG specification, as well as how it allows for extensions to the base SVG structure. I am in no position to comment on this.
- From a practical perspective, you can probably make these "errors" go away by saving inkscape files as "plain SVG". User A1 (talk) 07:32, 29 August 2008 (UTC)
- From the commons SVG page SVG#Tagging_SVGs: "Unfortunately this validator cannot handle RDF or other metadata, should you wish to include it, but it can still find errors in your SVG. It also wants a Doctype declaration, which is not a requirement in SVG and may actually cause problems." If this is true, then the validator may not be perfect either ^_^ so again, my opinion -- don't use this as a decision making tool. User A1 (talk) 07:38, 29 August 2008 (UTC)
-
- Thanks. When I originally posted my no at FPC I had only seen 51 errors and not gone through them. When I took a glance most of them seemed to be sodipodi / inkscape elements. My worry about this started when I would see the Media Wiki plugin render PNGs differently than Firefox's SVG support. Some of the cases turned out to be that Firefox had now properly implemented support for some things. Still, it is a general worry of mine that data can be distorted depending on which SVG component is used. I think we do need to come up with better standards for what is 'Wikipedia Valid' but the fact that an SVG made with inkspace/sodipodi gets 50+ errors just from that will make it more difficult track down real issues of SVG compliance. I generally agree with your idea... I have far less of a grasp on SVG validity than I do on HTML validity issues. Thanks for your input. :) gren グレン 08:19, 29 August 2008 (UTC)
[edit] Font issues understated
The Font issues section addresses the availability of fonts at Mediawiki. It speaks to what is only a symptom of a larger issue. The section says nothing about the need for a referenced font file to exist on a visitor's machine. The presence of a font file at Mediawiki does not guarantee that the file will exist on every visitor's machine. A visitor may be clueless as to why the appearance of text on their screen looks nothing like the preview PNG displayed by Mediawiki. "Substituting the font with an available font" is a Wiki-centric solution. The font may be available at Mediawiki, but it may not be "available" on every visitor's machine.
The list in the Available Fonts page says nothing about how likely a visitor is to have that font installed on their machine. One might gain a false sense of security when picking a font from that list, expecting every visitor to see the font as intended. If it shows up as expected in Mediawiki's PNG preview, the creator of the SVG image may have no reason to suspect that their image will appear as anything other than what their machine and Mediawiki's preview PNG have shown them.
In images where the appearance or placement of text is important, there may be significant portability issues if one chooses to use an SVG image instead of a raster image. -Ac44ck (talk) 19:33, 15 January 2009 (UTC)
- Whilst this is indeed true, I would expect that fewer people actually look at the SVGs, and instead probably only look at the pre-rastered images. User A1 (talk) 00:49, 16 January 2009 (UTC)
-
- Perhaps so. Then wholesale conversion of images from PNG to SVG for those exceptional cases would seem to be largely wasted effort. And server space would seem to be wasted by the only-used-once files being stored along with the multiple rasterized previews made therefrom.
-
- I tweaked the text in the article again to mention the possibility that it isn't a concern in some cases, but remains a PITA in others. My first attempt to upload an SVG image to Wikipedia got me PO'd. That the vectors scale so well is seductive. Finding that the text handling can be unpredictable was an unwelcome surprise. If someone finds this page (which I didn't know existed) before they try making an SVG image — and they find this caveat in the sea of other text here — then they might be forewarned. - Ac44ck (talk) 01:46, 16 January 2009 (UTC)
-
-
- I understand and appreciate the situation, I think the current wording that you have inserted is quite good and explains the situation clearly. As an aside to other users who may not be familiar with our discussion -- all Mediawiki fonts are freely available, and can be downloaded. (I don't say where from :) ) 'nix users probably have them all by default. User A1 (talk) 03:24, 16 January 2009 (UTC)
[edit] SVG Logos
Can fair-use logos on Wikipedia be in SVG? Thanks. Leujohn (talk) 12:45, 10 February 2009 (UTC)
- This has been the subject of some debate in wikipedia, with no clear consensus either way, but the general feel is no there shouldn't be fair use SVGs. This is due to the fact that SVG provides infinite scalability, and thus is not fair-use worthy.
- As a contrived example, if it were allowed, one could use autotracing of any non-free logo at a large scale (to minimise algorithmic errors), then shrink down the default SVG presentation to small scale -- which would effectively allow arbitrary sizing of these logos, at a rate as fast as you can chuck the non-free logos into your tracing program.
- For the record, I am in favour the removal/replacement of non-free SVGs. However if you wan't to remove existing fair use SVGs, you may have to engage in some lengthy debates.
Some various bits of reading:
User A1 (talk) 13:43, 10 February 2009 (UTC)
