Forgive me if this is the wrong list.
Inkscape is an Open Source authoring program used by some Wikipedians to create SVG files. The author of http://en.wikipedia.org/wiki/Image:M1_Abrams-TUSK.svg placed one such image in the public domain. On examining the image, I found a non-public-domain texture called "Sand". Fortunately, the texture is under Creative Commons Attribution 2.5 . It has an "inkscape:stockid" attribute, so I'm assuming it is a built-in stock image of Inkscape.
It is possible that Inkscape is not informing image authors that their stock textures have a license. Those authors then dedicate the entire image to the public domain on Wikimedia, and do not note the licensing of the contained texture.
Recommended action: parse Wikimedia SVG files to detect <pattern> tags, see how many have this problem, fix information pages to indicate licensing of the textures, delete inappropriately licensed content if necessary.
Thanks
Bruce
Bruce Perens wrote:
Forgive me if this is the wrong list.
It's not.
Recommended action: parse Wikimedia SVG files to detect <pattern> tags, see how many have this problem, fix information pages to indicate licensing of the textures, delete inappropriately licensed content if necessary.
Running search on commons svgs for "<pattern>".
On Tue, Nov 11, 2008 at 7:43 PM, Bruce Perens bruce@perens.com wrote: [snip]
It is possible that Inkscape is not informing image authors that their stock textures have a license. Those authors then dedicate the entire image to the public domain on Wikimedia, and do not note the licensing of the contained texture.
Ugh. Are you following up with Inkscape on this or should we look into it?
Obviously we expect uploaders to do the right thing with respect to any works that they derive from. Since we do not allow raster portions in our SVGs that kills one easy way for third-party rights to sneak in and generally we'd hope users realize that they have obligations when they copy from another SVG. Textures are an obvious way problems might sneak in.
Recommended action: parse Wikimedia SVG files to detect <pattern> tags, see how many have this problem, fix information pages to indicate licensing of the textures, delete inappropriately licensed content if necessary.
In progress.
On Tue, Nov 11, 2008 at 5:50 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Nov 11, 2008 at 7:43 PM, Bruce Perens bruce@perens.com wrote: [snip]
It is possible that Inkscape is not informing image authors that their stock textures have a license. Those authors then dedicate the entire image to the public domain on Wikimedia, and do not note the licensing of the contained texture.
Ugh. Are you following up with Inkscape on this or should we look into it?
Obviously we expect uploaders to do the right thing with respect to any works that they derive from. Since we do not allow raster portions in our SVGs that kills one easy way for third-party rights to sneak in and generally we'd hope users realize that they have obligations when they copy from another SVG. Textures are an obvious way problems might sneak in.
<snip>
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
-Robert Rohde
On Tue, Nov 11, 2008 at 9:47 PM, Robert Rohde rarohde@gmail.com wrote:
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
They're not rendered. Er? unless someone changed that.
On Tue, Nov 11, 2008 at 9:54 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Nov 11, 2008 at 9:47 PM, Robert Rohde rarohde@gmail.com wrote:
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
They're not rendered. Er? unless someone changed that.
Feh. Seems they are now. I guess as the result of some SVG upgrade. Embedding rasters defeats much of the the purpose of SVGs, perhaps we should be stripping these again.
I can imagine scenarios where this functionality would be useful. E.g. when editing a raster image (e.g. of a mainboard) and placing explnanations on it. You could then upload the new image as SVG with the original raster image embedded and only the arrows and explanations in SVG format. This would be much easier to translate into other languages than adding the explanations directly into the raster image.
2008/11/12 Gregory Maxwell gmaxwell@gmail.com:
On Tue, Nov 11, 2008 at 9:54 PM, Gregory Maxwell gmaxwell@gmail.com wrote:
On Tue, Nov 11, 2008 at 9:47 PM, Robert Rohde rarohde@gmail.com wrote:
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
They're not rendered. Er? unless someone changed that.
Feh. Seems they are now. I guess as the result of some SVG upgrade. Embedding rasters defeats much of the the purpose of SVGs, perhaps we should be stripping these again.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Hoi, Great idea :) Thanks, Gerardm
On Wed, Nov 12, 2008 at 7:59 PM, ChrisiPK chrisipk@gmail.com wrote:
I can imagine scenarios where this functionality would be useful. E.g. when editing a raster image (e.g. of a mainboard) and placing explnanations on it. You could then upload the new image as SVG with the original raster image embedded and only the arrows and explanations in SVG format. This would be much easier to translate into other languages than adding the explanations directly into the raster image.
2008/11/12 Gregory Maxwell gmaxwell@gmail.com:
On Tue, Nov 11, 2008 at 9:54 PM, Gregory Maxwell gmaxwell@gmail.com
wrote:
On Tue, Nov 11, 2008 at 9:47 PM, Robert Rohde rarohde@gmail.com
wrote:
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
They're not rendered. Er? unless someone changed that.
Feh. Seems they are now. I guess as the result of some SVG upgrade. Embedding rasters defeats much of the the purpose of SVGs, perhaps we should be stripping these again.
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
Commons-l mailing list Commons-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/commons-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Gregory Maxwell wrote:
On Tue, Nov 11, 2008 at 9:47 PM, Robert Rohde rarohde@gmail.com wrote:
I know it is generally bad form to have raster images embedded in SVGs, but is there actually some rule that says so? Is there a process for identifying them and removing them?
They're not rendered. Er? unless someone changed that.
I think you're thinking of references to *external* images, which we do indeed disable. If a raster image is embedded into the SVG file, it should render just file.
- -- brion
Gregory Maxwell wrote:
Ugh. Are you following up with Inkscape on this or should we look into it?
I can look into it, but it would be useful to know how many of these you find, so that I can tell how big the problem is before I bring it to their attention.
Since we do not allow raster portions in our SVGs
Right now you might not render the textures. But the SVG can be downloaded directly, and the browser will render the texture.
I wouldn't recommend banning paint textures (rather than images) in SVGs. If you don't use them, you're limited to plastic surfaces.
Thanks
Bruce
Total SVG files analyzed: 119158 (84706 current, 34452 old)
SVG files containing "<pattern": 1981 (1050 current, 931 old) SVG files containing "inkscape:stockid": 2594 (1246 current, 1348 old) However, they are mostly false positives. Just an arrow already sets a inkscape:stockid property. There're patterns that look ok, made from simple SVG shapes.
So I then centered on those containing the text 'texture provided'. There were 62 results (28 current), shown below:
http://upload.wikimedia.org/wikipedia/commons/7/7f/M1_Abrams_diagram_num.svg http://upload.wikimedia.org/wikipedia/commons/7/78/Baekryong_location.svg http://upload.wikimedia.org/wikipedia/commons/7/78/Pfeffersche_Zelle.svg http://upload.wikimedia.org/wikipedia/commons/7/7b/MultinationalForce-IraqDU... http://upload.wikimedia.org/wikipedia/commons/6/6d/ArrondissementsMarseille.... http://upload.wikimedia.org/wikipedia/commons/6/6a/Baarle-Nassau_-_Baarle-He... http://upload.wikimedia.org/wikipedia/commons/5/58/Baarle-Nassau_-_Baarle-He... http://upload.wikimedia.org/wikipedia/commons/9/9b/Clapboard.svg http://upload.wikimedia.org/wikipedia/commons/9/91/M1_Abrams-TUSK_hr.svg http://upload.wikimedia.org/wikipedia/commons/9/96/Distance-time_graph_examp... http://upload.wikimedia.org/wikipedia/commons/9/9f/Modele_eye_evolution_Nils... http://upload.wikimedia.org/wikipedia/commons/c/c0/Baarle-Nassau_-_Baarle-He... http://upload.wikimedia.org/wikipedia/commons/0/0f/Legion-esp-oro.svg http://upload.wikimedia.org/wikipedia/commons/3/3c/Baarle-Nassau_-_Baarle-He... http://upload.wikimedia.org/wikipedia/commons/3/34/Legion-esp.svg http://upload.wikimedia.org/wikipedia/commons/3/37/Harpsichord_jack.svg http://upload.wikimedia.org/wikipedia/commons/a/a9/Dinogetia_Garvani-_layout... http://upload.wikimedia.org/wikipedia/commons/1/1e/Nervous_system_organizati... http://upload.wikimedia.org/wikipedia/commons/1/15/MOSFET_Inv-Amp_quasi-line... http://upload.wikimedia.org/wikipedia/commons/8/82/Auzac_noir-blanc.svg http://upload.wikimedia.org/wikipedia/commons/d/dd/Auzac_noir_et_blanc.svg http://upload.wikimedia.org/wikipedia/commons/b/b3/Giro_lombardia_2008.svg http://upload.wikimedia.org/wikipedia/commons/4/42/Cacho_score.svg http://upload.wikimedia.org/wikipedia/commons/4/4a/Croquet_court.svg http://upload.wikimedia.org/wikipedia/commons/4/4b/Carte_de_l%27Yonne.svg http://upload.wikimedia.org/wikipedia/commons/2/22/M1_Abrams-TUSK.svg http://upload.wikimedia.org/wikipedia/commons/2/23/Ausrei%C3%83er.svg http://upload.wikimedia.org/wikipedia/commons/2/2f/Pa%C3%85ac_B%C3%83%C2%ADl... http://upload.wikimedia.org/wikipedia/commons/archive/c/c0/20080415130239!Ba... http://upload.wikimedia.org/wikipedia/commons/archive/9/9d/20071223173634!Er... http://upload.wikimedia.org/wikipedia/commons/archive/9/9d/20071223172538!Er... http://upload.wikimedia.org/wikipedia/commons/archive/9/9f/20081108152043!Mo... http://upload.wikimedia.org/wikipedia/commons/archive/2/23/20080317221713!Au... http://upload.wikimedia.org/wikipedia/commons/archive/2/23/20080316173247!Au... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080617195122!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080617191818!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080611145511!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080610114837!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080610113726!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080610112232!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080610063408!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080609190309!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080609174010!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080609171917!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080609155918!M1... http://upload.wikimedia.org/wikipedia/commons/archive/2/22/20080609155642!M1... http://upload.wikimedia.org/wikipedia/commons/archive/3/3c/20080415125943!Ba... http://upload.wikimedia.org/wikipedia/commons/archive/4/4b/20081022135013!Ca... http://upload.wikimedia.org/wikipedia/commons/archive/4/4b/20080820152318!Ca... http://upload.wikimedia.org/wikipedia/commons/archive/4/4a/20080805212421!Cr... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080829194207!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080803055021!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080802054218!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080801185330!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080801183415!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7b/20080801182909!Mu... http://upload.wikimedia.org/wikipedia/commons/archive/7/7f/20080618064851!M1... http://upload.wikimedia.org/wikipedia/commons/archive/7/7f/20080618060324!M1... http://upload.wikimedia.org/wikipedia/commons/archive/7/7f/20080617093633!M1... http://upload.wikimedia.org/wikipedia/commons/archive/7/78/20080713043930!Ba... http://upload.wikimedia.org/wikipedia/commons/archive/7/78/20080713010927!Ba... http://upload.wikimedia.org/wikipedia/commons/archive/7/78/20080319135013!Pf...
(some multibyte filenames may be wrong)
Now that we have a copy of commons, it can be used to gather more general statistics about our files, not just for format chasing. Which parameters may be appropiate?
They are all that same Sand bitmap. Only two of the files actually reference it. In all of the others, it's there spuriously. Sometimes it's in there twice, and makes the file a lot larger than it should be.
Here are the references:
Cacho_score.svg: xlink:href="#sand_bitmap" Cacho_score.svg: xlink:href="#sand_bitmap" Dinogetia_Garvani-_layout.svg: style="fill:url(#sand_bitmap);fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" /> Dinogetia_Garvani-_layout.svg: style="fill:url(#sand_bitmap);fill-opacity:1;fill-rule:evenodd;stroke:#000000;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;stroke-opacity:1" />
It should be removed from the files except for those two (a SED script would work, or XSLT, or hand editing).
If you want to dig further, you can look for image tags in SVG, reject all lines containing the "provided by" string, and see what the others are.
I'll see if I can make a current version of Inkscape leave them in a file when they aren't referenced.
Thanks
Bruce
Bruce Perens wrote:
If you want to dig further, you can look for image tags in SVG, reject all lines containing the "provided by" string, and see what the others are.
There're 2470 images containing <image (852 current, 1618 old) and 1402 (601 current, 801 old) with a data: url (xlink:href="data).
But not all of them are bad just for having an image. Another use case than translating are maps. http://commons.wikimedia.org/wiki/Image:Arnica_Montana_Culture_In_Scotland-f... is an example, but there're others there using raster images to mark points in the map. What we do not want is a map containing the map as raster.
For now, it'd need to be manually checked case by case (Wiki-Bot can give notices for them) which is quite unpractical. Perhaps we could set some threshold, such as marking for review SVGs containing a raster and less than X svg tags. Another could be rendering them twice, with and without rasters, so a human could check really fast which portion is svg and which not.
Search for "provided by" yields 63 results, which are the same as those with 'texture provided' plus http://upload.wikimedia.org/wikipedia/commons/8/84/8_Meaning_of_Constraint.s..., which is a false positive ("provided by function 1").