User talk:Peter coxhead
Jump to navigation
Jump to search
Hatiora - Hatiora × graeseri
[edit]Hi,
You are recategorizing some photos. Those Hatiora could be Hatiora × graeseri? Regards. DenesFeri (talk) 11:05, 7 November 2011 (UTC)
- Yes, I think that they almost certainly are. I was mainly interested in getting them out of Schlumbergera! If you want to put them in Hatiora × graeseri I would support you. Peter coxhead (talk) 11:08, 7 November 2011 (UTC)
OK, Thanks! I will rename them too. DenesFeri (talk) 11:16, 7 November 2011 (UTC)
beautiful photograph
[edit]thanks for posting and sharing it. Susan Dunlap (talk) 22:34, 8 December 2013 (UTC)
- Thanks are always appreciated, although you don't say which photo! Peter coxhead (talk) 13:51, 9 December 2013 (UTC)
misidentified photo - how do I flag?
[edit]Hi Peter, just came across this photo purporting to be Silene acaulis. Looks like a Primula (glutinosa?) to me. How do I flag this>
Thanks Tristan--Tristan He (talk) 20:55, 10 September 2015 (UTC)
@Tristan He: I agree with you that it's not Silene acaulis, and looks to be a Primula. The photographer was fooled, I suspect, by the way it's growing though other plants. What you are supposed to do "officially", I'm not sure. I'm not really active on Commons. In the past when I've found mis-identified photos, I've just been bold and (a) changed the category to the correct one (b) added a note to the description. No-one seems to read the talk pages on Commons, so starting a discussion there doesn't work, in my experience. Peter coxhead (talk) 09:14, 14 September 2015 (UTC)
Araneus quadratus
[edit]Thanks for this. --DPC (talk) 18:11, 22 April 2016 (UTC)
- And, is this A. quadratus too? --DPC (talk) 18:15, 22 April 2016 (UTC)
- Well, all the experts say that you shouldn't rely on patterns, but look at the genitalia of mature specimens, but this isn't much use here. In my geographically limited experience, the background colour is very variable, so not significant. Both species can look as if they have a cross shape on the abdomen, but when A quadratus looks to have a cross pattern, the central line is interrupted or weak, and the second pair of spots larger than the first. The central part of the pattern (folium) is notably darker than the surrounding colour in A. diadematus but much the same colour in A. quadratus. The angle in the queried photo gives a limited view, but I think "01_by-dpc" and "02_by-dpc" are the same. Peter coxhead (talk) 20:03, 24 April 2016 (UTC)
Hi Peter, please don't redirect to not (yet) existing categories because these redirects apppear to be broken and thus might be deleted without further notice. Thank you. --Achim (talk) 15:25, 22 October 2017 (UTC)
- Sorry, this was an error — when I redirected, I thought there was an image which belonged at the target category, but it turned out that there wasn’t and I forgot to go back and sort it out. Peter coxhead (talk) 21:06, 22 October 2017 (UTC)
Euphorbia lamarckii
[edit]I determined it as E. obtusifolia by Peter and Ingrid Schönefelder: Die Kosmos Kanarenflora, Kosmos-Verlag Germany, and according to that book this plant occurs on all Canary Islands,inclusive Fuerteventura. See also here, here, it is also listed in Gelandeliste zur Erfassung der Flora von Fuerteventura as well as in Gefährdete endemische Blütenpflanzen der Trockeninsel Fuerteventura. As E. obtusifolia is a synonym of E. lamarckii (it means the same species) and E. lamarckii is the valid name (not E. obtusifolia), this species occurs in Fuerteventura very well. So please remove back the pictures to the category "Euphorbia lamarckii". --Llez (talk) 17:21, 27 January 2018 (UTC)
- It's not so simple. The problem is that names have been changed. Some species have been split up. The most "scientific" of the online sources you give is the 2013 Gefährdete endemische Blütenpflanzen der Trockeninsel Fuerteventura. Besides just the name E. obtusifolia, this also mentions E. obtusifolia subsp. regis-jubae. If you look here, you will see that Euphorbia obtusifolia subsp. regis-jubae and Euphorbia lamarckii subsp. regis-jubae are both synonyms of E. regis-jubae, which does occur in Fuerteventura. I think that the sources that list E. obtusifolia and/or E. lamarckii as occurring in Fuerteventura are referring to subsp. regis-jubae, now known as E. regis-jubae. Look at the images in Category:Euphorbia regis-jubae. This is what I think your plants probably are. Peter coxhead (talk) 18:09, 27 January 2018 (UTC)
- The specialist website for Euphorbia agrees that E. lamarckii is not found in Fuerteventura – see here. This paper explains the controversy over some Euphorbia names, confirming that as the name is used now, E. lamarckii does not occur in Fuerteventura. Peter coxhead (talk) 09:32, 28 January 2018 (UTC)
- @Llez: see also here for a clear explanation of the issues if you can read Spanish. Peter coxhead (talk) 19:59, 28 January 2018 (UTC)
Source of derivative work is not properly indicated: File:David Bowie Mural Edited.jpg
[edit]
|
| This file may be deleted. |
A file that you have uploaded to Wikimedia Commons, File:David Bowie Mural Edited.jpg, is a derivative work, containing an "image within an image". Examples of such works would include a photograph of a sculpture, a scan of a magazine cover, or a map that has been altered from the original. In each of these cases, the rights of the creator of the original must be considered, as well as those of the creator of the derivative work.
While the description page states who made this derivative work, it currently doesn't specify who created the original work, so the overall copyright status is unclear. If you did not create the original work depicted in this image, you will need to specify the owner of the copyright. Please edit the file description and add the missing information, or the file may be deleted. If you created the original content yourself, enter this information as the source. If someone else created the content, the source should be the address to the web page where you found it, the name and ISBN of the book you scanned it from, or similar. You should also name the author, provide verifiable information to show that the content is in the public domain or has been published under a free license by its author, and add an appropriate template identifying the public domain or licensing status, if you have not already done so. Please add the required information for this and other files you have uploaded before adding more files. If you need assistance, please ask at the help desk. Thank you! |
Crop of image sourced to a file since deleted as copyvio BevinKacon (talk) 20:28, 25 March 2019 (UTC)
- @BevinKacon: as you say, this file was a modification of a file since deleted as a copyvio, so it should have been deleted too. Peter coxhead (talk) 23:19, 25 March 2019 (UTC)
Google Code-In 2019 is coming - please mentor some documentation tasks!
[edit]Hello,
Google Code-In, Google-organized contest in which the Wikimedia Foundation participates, starts in a few weeks. This contest is about taking high school students into the world of opensource. I'm sending you this message because you recently edited a documentation page at Wikimedia Commons.
I would like to ask you to take part in Google Code-In as a mentor. That would mean to prepare at least one task (it can be documentation related, or something else - the other categories are Code, Design, Quality Assurance and Outreach) for the participants, and help the student to complete it. Please sign up at the contest page and send us your Google account address to google-code-in-admins@lists.wikimedia.org, so we can invite you in!
From my own experience, Google Code-In can be fun, you can make several new friends, attract new people to your wiki and make them part of your community.
If you have any questions, please let us know at google-code-in-admins@lists.wikimedia.org.
Thank you!
--User:Martin Urbanec (talk) 22:05, 23 November 2019 (UTC)
EazyDraw
[edit]Hi Peter, thank you for your diagrams. As you can see et e.g. Historically recognized plant categories.svg something had been done to establish the {{Created with EazyDraw}}.
You say that a tool did not find W3C-errors? The validator finds a lot, because of the many formally wrong IDs created by EasyDraw. Never mind, that does not reduce the quality of your drawings! It would be "eazy" to remove all the unused IDs, making your drawings W3C-valid; but the mere W3C-validity is not such an important matter, that it will be worth the effort to change uploaded files – it might just be a possibility before uploading. Anyway, you shouldn't tag W3C-invalid files as valid. Good further success! -- sarang♥사랑 13:45, 5 September 2020 (UTC)
- @Sarang: I am confident that I did check the file before adding the "valid" template. There is something odd about the validator. I prepared a new SVG file from the same EazyDraw source file, as there's a new version of EazyDraw now. I checked this file on the validator website by browsing and uploading from my computer. The file was declared fully valid. I then uploaded it to Commons as a newer version. The validator then claims there are 24 errors. So either there's a bug in the validator or the upload mechanism introduces errors.
- I've put the file before uploading at
http://www.pxc.me.uk/misc/Historically%20recognized%20plant%20categories.svg; you can check that this is valid. Peter coxhead (talk) 08:35, 15 September 2020 (UTC)- Hi Peter, we are using at least three validators, and they have often different error counts - some ignore minor "violations" of the SVG syntax rules. The script uses another background validator than the two which I am using online. The fourth one is the Commons:Commons SVG Checker, with other results. In the case of Historically recognized plant categories.svg, all of them, even the Nu Validatot, are consistent with 24 times "Bad value ... for attribute id... Not a valid XML 1.0 name". But as said before, you should not take that too serious, that EazyDraw likes such IDs which are unfortunately not in the mind of our validators. -- sarang♥사랑 11:31, 15 September 2020 (UTC)
@Sarang: what you say is only true for the uploaded file in Commons. If I go to Commons:Commons SVG Checker and use the "Browse" button to check the the SVG file on my computer that I uploaded, it does not report the 24 errors. I do not understand why the checkers say that the file on my computer and the file I copied to [removed] are ok, whereas they say that the file in Commons is not. This still bothers me, since the time to check for SVG errors is before uploading, not afterwards. I would like to understand why this is the case. Peter coxhead (talk) 09:28, 17 September 2020 (UTC)
- Hi Peter, we are using at least three validators, and they have often different error counts - some ignore minor "violations" of the SVG syntax rules. The script uses another background validator than the two which I am using online. The fourth one is the Commons:Commons SVG Checker, with other results. In the case of Historically recognized plant categories.svg, all of them, even the Nu Validatot, are consistent with 24 times "Bad value ... for attribute id... Not a valid XML 1.0 name". But as said before, you should not take that too serious, that EazyDraw likes such IDs which are unfortunately not in the mind of our validators. -- sarang♥사랑 11:31, 15 September 2020 (UTC)
- It is a matter of fact that the different validators have different tolerance of syntactical rule violations, and that the Commons:Commons SVG Checker checks other things - not the syntax. In this problem, we have to chose on of them, and that is AFAIK the W3C-nu-validator used by the script.
- When another validator says that there are zero errors, that is not true because EazyDraw does not obey to the rules for building IDs (starting with a letter, consisting only of letters, numbers and understrokes). When there is no option for Eazydraw about the IDs, you may write a small programm or just edit afterwards the source code, either removing all the useless IDs or adding a leading letter. If there are no other inconveniencies, the SVG source will then be fine.
- As I said, you should not care for the error count as long as the image shows what you want. On the other hand, I can understand that you liked more to upload valid SVG. That will need more effort: you will have to clean the EazyDraw-output prior to upload. -- sarang♥사랑 10:58, 17 September 2020 (UTC)
To show it with an example, with e.g. Microphyll evolution.svg:
| EazyDraw SVG code (original) |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<svg
version="1.1"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg"
width="691"
height="337"
viewBox="0, 0, 691, 337"
preserveAspectRatio="none"
id="svg2">
<defs
id="defs_FA9D7EBA"/>
<font horiz-adv-x="3073">
<font-face font-family="Helvetica" units-per-em="2048" underline-thickness="101" underline-position="-155"/>
<missing-glyph horiz-adv-x="500" d="M0,0 L500,0 L500,700 L0,700 M250,395 L80,650 L420,650 M280,350 L450,605 L450,95 M80,50 L250,305 L420,50 M50,605 L220,350 L50,95 z"/>
<glyph unicode="1" horiz-adv-x="1139" d="M196,1014 L196,1152 C326.00065,1164.66673 416.66641,1185.833185 468,1215.5 C519.33359,1245.166815 557.66654,1315.33278 583,1426 L725,1426 L725,0 L533,0 L533,1014 z"/>
<glyph unicode="2" horiz-adv-x="1139" d="M140.5,322 C184.833555,413.33379 271.33269,496.33296 400,571 L592,682 C678.00043,732.00025 738.33316,774.66649 773,810 C827.66694,865.33361 855,928.66631 855,1000 C855,1083.33375 830.00025,1149.499755 780,1198.5
C729.99975,1247.500245 663.33375,1272 580,1272 C456.66605,1272 371.33357,1225.3338 324,1132 C298.66654,1081.99975 284.66668,1012.66711 282,924 L99,924 C101.00001,1048.66729 123.99978,1150.33294 168,1229
C246.00039,1367.66736 383.66568,1437 581,1437 C745.00082,1437 864.832955,1392.66711 940.5,1304 C1016.167045,1215.33289 1054,1116.66721 1054,1008 C1054,893.33276 1013.66707,795.33374 933,714 C886.3331,666.66643 802.66727,609.33367 682,542
L545,466 C479.66634,429.99982 428.33352,395.66683 391,363 C324.333,304.99971 282.33342,240.66702 265,170 L1047,170 L1047,0 L64,0 C70.6667,123.33395 96.166445,230.66621 140.5,322 z"/>
<glyph unicode="3" horiz-adv-x="1139" d="M163.5,100.5 C87.166285,193.500465 49,306.666 49,440 L237,440 C245.00004,347.33287 262.3332,280.00021 289,238 C335.6669,162.66629 419.99939,125 542,125 C636.66714,125 712.66638,150.33308 770,201 C827.33362,251.66692 856,316.9996 856,397
C856,495.66716 825.833635,564.66647 765.5,604 C705.166365,643.33353 621.33387,663 514,663 C501.99994,663 489.833395,662.833335 477.5,662.5 C465.166605,662.166665 452.66673,661.66667 440,661 L440,820 C458.66676,817.99999 474.33327,816.66667 487,816
C499.66673,815.33333 513.33326,815 528,815 C595.33367,815 650.66645,825.66656 694,847 C770.00038,884.33352 808,950.99952 808,1047 C808,1118.33369 782.66692,1173.33314 732,1212 C681.33308,1250.66686 622.33367,1270 555,1270
C434.9994,1270 352.00023,1230.0004 306,1150 C280.66654,1105.99978 266.33335,1043.33374 263,962 L85,962 C85,1068.6672 106.33312,1159.33296 149,1234 C222.3337,1367.334 351.33241,1434 536,1434 C682.00073,1434 794.9996,1401.500325 875,1336.5
C955.0004,1271.499675 995,1177.33395 995,1054 C995,965.99956 971.33357,894.66694 924,840 C894.66652,805.99983 856.6669,779.33343 810,760 C885.33371,739.33323 944.166455,699.500295 986.5,640.5 C1028.833545,581.499705 1050,509.33376 1050,424
C1050,287.33265 1005.00045,176.00043 915,90 C824.99955,3.99957 697.33416,-39 532,-39 C362.66582,-39 239.833715,7.499535 163.5,100.5 z"/>
<glyph unicode=" " horiz-adv-x="569" d="M569,0"/>
</font>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
id="layer_Paper"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;fill-rule:nonzero;stroke-linecap:square;stroke-linejoin:miter;stroke-width:1;stroke-miterlimit:10">
<rect
style="fill:#FFFFFF;stroke:#FFFFFF"
id="B8CDE09A"
x="0.5"
y="0.5"
width="690"
height="336"/>
</g>
<g
id="Layer--1"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;fill-rule:nonzero;stroke-linecap:square;stroke-linejoin:miter;stroke-width:1;stroke-miterlimit:10">
<g
id="522D209A">
<rect
style="fill:#1EFF00"
id="E12D209A"
x="450.5"
y="18.5"
width="72"
height="264"/>
<path
style="fill:#1EFF00"
id="F12D209A"
d="M664.571486608,35.4876321691 C594.959404658,45.9642763204 540.6648714,76.9712109527 522.500000001,116.622896328"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00"
id="022D209A"
points="522.5,114.5 600.5,72.5 522.5,222.5 504.5,168.5"/>
<path
style="fill:#FFFFFF"
id="122D209A"
d="M666.019391048,35.5873652121 C578.001152935,70.3501533042 521.658833238,147.857966553 522.509490522,233.008036372"/>
<path
style="fill:none;stroke:#C04800;stroke-width:3.6"
id="222D209A"
d="M628.639863246,47.4137117743 C560.221388586,82.6791796595 508.458259086,149.524496372 486.499999999,230.968768588"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="322D209A"
x1="486.5"
y1="24.5"
x2="486.5"
y2="276.5"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="422D209A"
x1="486.5"
y1="24.5"
x2="486.5"
y2="276.5"/>
</g>
<rect
style="fill:#1EFF00"
id="622D209A"
x="240.5"
y="18.5"
width="72"
height="264"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="722D209A"
x1="276.5"
y1="24.5"
x2="276.5"
y2="276.5"/>
<path
style="fill:#1EFF00"
id="822D209A"
d="M383.535743303,126.5 C348.729702328,131.738322075 321.582435699,147.241789392 312.499999999,167.067632079"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00;stroke-width:0.5"
id="922D209A"
points="315.5,165.5 354.5,144.5 315.5,219.5 306.5,192.5"/>
<path
style="fill:#FFFFFF"
id="A22D209A"
d="M384.259700103,126.499999999 C340.250581046,143.881394045 312.079421198,182.63530067 312.50474984,225.210335579"/>
<path
style="fill:none;stroke:#C04800;stroke-width:3.6"
id="B22D209A"
d="M302.945293873,186.499999999 C290.88112594,202.217909697 281.870874831,220.635650274 276.499999999,240.556491455"/>
<g
id="132D209A">
<rect
style="fill:#1EFF00"
id="C22D209A"
x="42.5"
y="18.5"
width="72"
height="264"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="D22D209A"
x1="78.5"
y1="24.5"
x2="78.5"
y2="276.5"/>
<path
style="fill:#1EFF00"
id="E22D209A"
d="M149.867681354,160.746908041 C132.464660867,163.366069079 118.891027552,171.117802737 114.349809703,181.030724081"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00;stroke-width:0.5"
id="F22D209A"
points="114.349809703,180.5 133.849809703,170 114.349809703,207.5 109.849809703,194"/>
<path
style="fill:#FFFFFF"
id="032D209A"
d="M150.229657465,160.771841303 C128.225097936,169.462538326 114.139518012,188.839491638 114.352182333,210.127009093"/>
</g>
<text
id="50DA8ABA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="71.826171875" y="317.5">1</tspan>
</text>
<text
id="6E4A5CBA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="269.826171875" y="317.5">2</tspan>
</text>
<text
id="FCC4CCBA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="479.826171875" y="317.5">3</tspan>
</text>
</g>
</svg>
|
There are 29 IDs with 14 occurrencies of erroneous writing.
When all the 29 IDs are removed the SVG will be valid. A small program can do it eazily.
As all tools, EazyDraw generates a lot of useless code which can be removed without any change.
Another possibility is to just make the 14 IDs valid, as I did by prefixing them with the letter "A":
| EazyDraw validated SVG code (modified) |
|---|
<?xml version="1.0" encoding="UTF-8"?>
<svg
version="1.1"
xmlns:dc="http://purl.org/dc/elements/1.1/"
xmlns:cc="http://creativecommons.org/ns#"
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
xmlns:svg="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
xmlns="http://www.w3.org/2000/svg"
width="691"
height="337"
viewBox="0, 0, 691, 337"
preserveAspectRatio="none"
id="svg2">
<defs
id="defs_FA9D7EBA"/>
<font horiz-adv-x="3073">
<font-face font-family="Helvetica" units-per-em="2048" underline-thickness="101" underline-position="-155"/>
<missing-glyph horiz-adv-x="500" d="M0,0 L500,0 L500,700 L0,700 M250,395 L80,650 L420,650 M280,350 L450,605 L450,95 M80,50 L250,305 L420,50 M50,605 L220,350 L50,95 z"/>
<glyph unicode="1" horiz-adv-x="1139" d="M196,1014 L196,1152 C326.00065,1164.66673 416.66641,1185.833185 468,1215.5 C519.33359,1245.166815 557.66654,1315.33278 583,1426 L725,1426 L725,0 L533,0 L533,1014 z"/>
<glyph unicode="2" horiz-adv-x="1139" d="M140.5,322 C184.833555,413.33379 271.33269,496.33296 400,571 L592,682 C678.00043,732.00025 738.33316,774.66649 773,810 C827.66694,865.33361 855,928.66631 855,1000 C855,1083.33375 830.00025,1149.499755 780,1198.5
C729.99975,1247.500245 663.33375,1272 580,1272 C456.66605,1272 371.33357,1225.3338 324,1132 C298.66654,1081.99975 284.66668,1012.66711 282,924 L99,924 C101.00001,1048.66729 123.99978,1150.33294 168,1229
C246.00039,1367.66736 383.66568,1437 581,1437 C745.00082,1437 864.832955,1392.66711 940.5,1304 C1016.167045,1215.33289 1054,1116.66721 1054,1008 C1054,893.33276 1013.66707,795.33374 933,714 C886.3331,666.66643 802.66727,609.33367 682,542
L545,466 C479.66634,429.99982 428.33352,395.66683 391,363 C324.333,304.99971 282.33342,240.66702 265,170 L1047,170 L1047,0 L64,0 C70.6667,123.33395 96.166445,230.66621 140.5,322 z"/>
<glyph unicode="3" horiz-adv-x="1139" d="M163.5,100.5 C87.166285,193.500465 49,306.666 49,440 L237,440 C245.00004,347.33287 262.3332,280.00021 289,238 C335.6669,162.66629 419.99939,125 542,125 C636.66714,125 712.66638,150.33308 770,201 C827.33362,251.66692 856,316.9996 856,397
C856,495.66716 825.833635,564.66647 765.5,604 C705.166365,643.33353 621.33387,663 514,663 C501.99994,663 489.833395,662.833335 477.5,662.5 C465.166605,662.166665 452.66673,661.66667 440,661 L440,820 C458.66676,817.99999 474.33327,816.66667 487,816
C499.66673,815.33333 513.33326,815 528,815 C595.33367,815 650.66645,825.66656 694,847 C770.00038,884.33352 808,950.99952 808,1047 C808,1118.33369 782.66692,1173.33314 732,1212 C681.33308,1250.66686 622.33367,1270 555,1270
C434.9994,1270 352.00023,1230.0004 306,1150 C280.66654,1105.99978 266.33335,1043.33374 263,962 L85,962 C85,1068.6672 106.33312,1159.33296 149,1234 C222.3337,1367.334 351.33241,1434 536,1434 C682.00073,1434 794.9996,1401.500325 875,1336.5
C955.0004,1271.499675 995,1177.33395 995,1054 C995,965.99956 971.33357,894.66694 924,840 C894.66652,805.99983 856.6669,779.33343 810,760 C885.33371,739.33323 944.166455,699.500295 986.5,640.5 C1028.833545,581.499705 1050,509.33376 1050,424
C1050,287.33265 1005.00045,176.00043 915,90 C824.99955,3.99957 697.33416,-39 532,-39 C362.66582,-39 239.833715,7.499535 163.5,100.5 z"/>
<glyph unicode=" " horiz-adv-x="569" d="M569,0"/>
</font>
<metadata
id="metadata7">
<rdf:RDF>
<cc:Work
rdf:about="">
<dc:format>image/svg+xml</dc:format>
<dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
<dc:title></dc:title>
</cc:Work>
</rdf:RDF>
</metadata>
<g
id="layer_Paper"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;fill-rule:nonzero;stroke-linecap:square;stroke-linejoin:miter;stroke-width:1;stroke-miterlimit:10">
<rect
style="fill:#FFFFFF;stroke:#FFFFFF"
id="B8CDE09A"
x="0.5"
y="0.5"
width="690"
height="336"/>
</g>
<g
id="Layer--1"
style="fill:#000000;fill-opacity:1;stroke:#000000;stroke-opacity:1;fill-rule:nonzero;stroke-linecap:square;stroke-linejoin:miter;stroke-width:1;stroke-miterlimit:10">
<g
id="A522D209A">
<rect
style="fill:#1EFF00"
id="E12D209A"
x="450.5"
y="18.5"
width="72"
height="264"/>
<path
style="fill:#1EFF00"
id="F12D209A"
d="M664.571486608,35.4876321691 C594.959404658,45.9642763204 540.6648714,76.9712109527 522.500000001,116.622896328"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00"
id="A022D209A"
points="522.5,114.5 600.5,72.5 522.5,222.5 504.5,168.5"/>
<path
style="fill:#FFFFFF"
id="A122D209A"
d="M666.019391048,35.5873652121 C578.001152935,70.3501533042 521.658833238,147.857966553 522.509490522,233.008036372"/>
<path
style="fill:none;stroke:#C04800;stroke-width:3.6"
id="A222D209A"
d="M628.639863246,47.4137117743 C560.221388586,82.6791796595 508.458259086,149.524496372 486.499999999,230.968768588"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="A322D209A"
x1="486.5"
y1="24.5"
x2="486.5"
y2="276.5"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="A422D209A"
x1="486.5"
y1="24.5"
x2="486.5"
y2="276.5"/>
</g>
<rect
style="fill:#1EFF00"
id="A622D209A"
x="240.5"
y="18.5"
width="72"
height="264"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="A722D209A"
x1="276.5"
y1="24.5"
x2="276.5"
y2="276.5"/>
<path
style="fill:#1EFF00"
id="A822D209A"
d="M383.535743303,126.5 C348.729702328,131.738322075 321.582435699,147.241789392 312.499999999,167.067632079"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00;stroke-width:0.5"
id="A922D209A"
points="315.5,165.5 354.5,144.5 315.5,219.5 306.5,192.5"/>
<path
style="fill:#FFFFFF"
id="A22D209A"
d="M384.259700103,126.499999999 C340.250581046,143.881394045 312.079421198,182.63530067 312.50474984,225.210335579"/>
<path
style="fill:none;stroke:#C04800;stroke-width:3.6"
id="B22D209A"
d="M302.945293873,186.499999999 C290.88112594,202.217909697 281.870874831,220.635650274 276.499999999,240.556491455"/>
<g
id="A132D209A">
<rect
style="fill:#1EFF00"
id="C22D209A"
x="42.5"
y="18.5"
width="72"
height="264"/>
<line
style="fill:none;stroke:#C04800;stroke-width:7.2"
id="D22D209A"
x1="78.5"
y1="24.5"
x2="78.5"
y2="276.5"/>
<path
style="fill:#1EFF00"
id="E22D209A"
d="M149.867681354,160.746908041 C132.464660867,163.366069079 118.891027552,171.117802737 114.349809703,181.030724081"/>
<polygon
style="fill:#1EFF00;stroke:#1EFF00;stroke-width:0.5"
id="F22D209A"
points="114.349809703,180.5 133.849809703,170 114.349809703,207.5 109.849809703,194"/>
<path
style="fill:#FFFFFF"
id="A032D209A"
d="M150.229657465,160.771841303 C128.225097936,169.462538326 114.139518012,188.839491638 114.352182333,210.127009093"/>
</g>
<text
id="A50DA8ABA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="71.826171875" y="317.5">1</tspan>
</text>
<text
id="A6E4A5CBA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="269.826171875" y="317.5">2</tspan>
</text>
<text
id="FCC4CCBA"
style="stroke:none"
font-family="Helvetica"
font-size="24"
font-weight="normal"
font-style="normal">
<tspan x="479.826171875" y="317.5">3</tspan>
</text>
</g>
</svg>
|
When the error tag really disturbs you so much, write a small procedure which can reduce the SVG code to 20% or 10% of its current size, and makes it valid.
But do not change the drawings that are successfully uploaded to commons - just alter future files. -- sarang♥사랑 13:53, 17 September 2020 (UTC)
When you do not want to edit this sources by hand, or to create kind of a program, there are existing tools for that purpose: SVGcleaner can change the wrong IDs, and clean much more. Also exists a tool Scour that can clean SVG source code. These tools had been developed because other tools (not only EazyDraw!) are making a lot of nonsense. You will find these tools in the internet. -- sarang♥사랑 18:51, 17 September 2020 (UTC)
- @Sarang: thanks for the information and the time you have spent. Actually, I've discovered that EazyDraw does have an option not to output DOM IDs when exporting to SVG. The files produced in this way by the latest version of EazyDraw appear to be compliant. I won't bother to upload revised versions, as you suggest, but will try to ensure that in future SVG files I upload are compliant. (In the past I taught software engineering to undergraduates, and have been a member of national standards subcommittees, so I'm a strong believer in following standards.) Peter coxhead (talk) 18:59, 18 September 2020 (UTC)
To give you an example, I uploaded the cleaned version Microphyll evolution cleaned.svg which is now containing the code
| EazyDraw valid SVG code (cleaned) |
|---|
<svg xmlns="http://www.w3.org/2000/svg" width="691" height="337">
<font horiz-adv-x="3073">
<font-face font-family="Helvetica" underline-position="-155" underline-thickness="101" units-per-em="2048"/>
<missing-glyph d="M0 0 500 0 500 700 0 700M250 395 80 650 420 650M280 350 450 605 450 95M80 50 250 305 420 50M50 605 220 350 50 95z" horiz-adv-x="500"/>
<glyph d="M196 1014 196 1152C326.00065 1164.66673 416.66641 1185.833185 468 1215.5 519.33359 1245.166815 557.66654 1315.33278 583 1426L725 1426 725 0 533 0 533 1014z" horiz-adv-x="1139" unicode="1"/>
<glyph d="M140.5 322C184.833555 413.33379 271.33269 496.33296 400 571L592 682C678.00043 732.00025 738.33316 774.66649 773 810 827.66694 865.33361 855 928.66631 855 1000 855 1083.33375 830.00025 1149.499755 780 1198.5 729.99975 1247.500245 663.33375 1272 580 1272 456.66605 1272 371.33357 1225.3338 324 1132 298.66654 1081.99975 284.66668 1012.66711 282 924L99 924C101.00001 1048.66729 123.99978 1150.33294 168 1229 246.00039 1367.66736 383.66568 1437 581 1437 745.00082 1437 864.832955 1392.66711 940.5 1304 1016.167045 1215.33289 1054 1116.66721 1054 1008 1054 893.33276 1013.66707 795.33374 933 714 886.3331 666.66643 802.66727 609.33367 682 542L545 466C479.66634 429.99982 428.33352 395.66683 391 363 324.333 304.99971 282.33342 240.66702 265 170L1047 170 1047 0 64 0C70.6667 123.33395 96.166445 230.66621 140.5 322z" horiz-adv-x="1139" unicode="2"/>
<glyph d="M163.5 100.5C87.166285 193.500465 49 306.666 49 440L237 440C245.00004 347.33287 262.3332 280.00021 289 238 335.6669 162.66629 419.99939 125 542 125 636.66714 125 712.66638 150.33308 770 201 827.33362 251.66692 856 316.9996 856 397 856 495.66716 825.833635 564.66647 765.5 604 705.166365 643.33353 621.33387 663 514 663 501.99994 663 489.833395 662.833335 477.5 662.5 465.166605 662.166665 452.66673 661.66667 440 661L440 820C458.66676 817.99999 474.33327 816.66667 487 816 499.66673 815.33333 513.33326 815 528 815 595.33367 815 650.66645 825.66656 694 847 770.00038 884.33352 808 950.99952 808 1047 808 1118.33369 782.66692 1173.33314 732 1212 681.33308 1250.66686 622.33367 1270 555 1270 434.9994 1270 352.00023 1230.0004 306 1150 280.66654 1105.99978 266.33335 1043.33374 263 962L85 962C85 1068.6672 106.33312 1159.33296 149 1234 222.3337 1367.334 351.33241 1434 536 1434 682.00073 1434 794.9996 1401.500325 875 1336.5 955.0004 1271.499675 995 1177.33395 995 1054 995 965.99956 971.33357 894.66694 924 840 894.66652 805.99983 856.6669 779.33343 810 760 885.33371 739.33323 944.166455 699.500295 986.5 640.5 1028.833545 581.499705 1050 509.33376 1050 424 1050 287.33265 1005.00045 176.00043 915 90 824.99955 3.99957 697.33416-39 532-39 362.66582-39 239.833715 7.499535 163.5 100.5z" horiz-adv-x="1139" unicode="3"/>
<glyph d="M569 0" horiz-adv-x="569" unicode=" "/>
</font>
<g stroke-linecap="square" stroke-miterlimit="10">
<path d="m.5.5h690v336h-690z" fill="#fff" stroke="#fff"/>
<g stroke="#000">
<g fill="#1eff00">
<path d="m240.5 18.5h72v264h-72zm210,0h72v264h-72z"/>
<path d="m664.57148661 35.48763217c-69.61208195 10.47664415-123.90661521 41.48357878-142.07148661 81.13526416"/>
<path d="m522.5 114.5 78-42-78 150-18-54z" stroke="#1eff00"/>
<path d="m666.01939105 35.58736521c-88.01823811 34.76278809-144.36055781 112.27060134-143.50990053 197.42067116" fill="#fff"/>
</g>
<path d="m383.5357433 126.5c-34.80604097 5.23832208-61.9533076 20.74178939-71.0357433 40.56763208" fill="#1eff00"/>
<path d="m315.5 165.5 39-21-39 75-9-27z" fill="#1eff00" stroke="#1eff00" stroke-width=".5"/>
<path d="m384.2597001 126.5c-44.00911905 17.38139405-72.1802789 56.13530067-71.75495026 98.71033558" fill="#fff"/>
<path d="m302.94529387 186.5c-12.06416793 15.7179097-21.07441904 34.13565027-26.44529387 54.05649146" fill="none" stroke="#c04800" stroke-width="3.6"/>
<path d="m42.5 18.5h72v264h-72z" fill="#1eff00"/>
<path d="m149.86768135 160.74690804c-17.40302048 2.61916104-30.9766538 10.3708947-35.51787165 20.28381604" fill="#1eff00"/>
<path d="m114.3498097 180.5 19.5-10.5-19.5 37.5-4.5-13.5z" fill="#1eff00" stroke="#1eff00" stroke-width=".5"/>
<path d="m150.22965747 160.7718413c-22.00455953 8.69069703-36.09013946 28.06765034-35.87747514 49.35516779" fill="#fff"/>
<g fill="none" stroke="#C04800">
<path d="m628.63986325 47.41371177c-68.41847466 35.26546789-120.18160416 102.1107846-142.13986325 183.55505682" stroke-width="3.6"/>
<path d="m78.5 24.5v252m198,0V24.5m210,0v252" stroke="#c04800" stroke-width="7.2"/>
</g></g>
<text font-family="Helvetica" font-size="24">
<tspan x="71.826172" y="317.5">1</tspan>
<tspan x="269.826172" y="317.5">2</tspan>
<tspan x="479.826172" y="317.5">3</tspan>
</text>
</g>
</svg>
|
As you can see, it is much smaller (54%) and does not contain W3C-errors, all the redundant IDs have been removed.
Still it contains a lot of nonsense, that the cleaner did not clean away!
It is unnecessary and pure bloating the file to define coordinates in that simple diagram with 8 decimal fractions - it would be sufficient to define coordinates in integers, without any fractional part. AFAIK it is an option of the tool Scour to round such values to less or no fractions; after such rounding the image may look slightly different, but at such a simple diagram that would not matter.
To perform that test, I downloaded the SVGcleaner from the internet, it is easy to handle; with Scour I have no experience, but it is used often by other users. I recommend that you clean the EazyDraw-output of your future files. -- sarang♥사랑 09:31, 19 September 2020 (UTC)
If I may summarize finally:
- W3C-errors are not bad, in most cases they are just minor formal unpleasantnesses against W3C- and HTML-rules.
- They will not reduce the display appearance and the quality of an image.
- If there is any fault, it is not yours, it is the behavior of the used tool.
- It will be of no use for wikipedia to make such files valid by uploading another version.
- (but when it is of use for you, when you feel better with valid SVGs, you may invest the effort)
- Of course valid new uploads are nicer than invalid ones. Cleaning tools (SVGcleaner,
ScourSVGomg and others) can help.
Good further success! -- sarang♥사랑 10:25, 19 September 2020 (UTC)
Now I got it
[edit]I could make a treating of the Microphyll evolution cleaned.svg with the tool https://jakearchibald.github.io/svgomg/ and got a file of 2922 bytes; I can really recommend that tool!
The output code from that tool is now
| EazyDraw validated SVG code (cleaned) and reduced |
|---|
<svg xmlns="http://www.w3.org/2000/svg" width="691" height="337">
<font horiz-adv-x="3073">
<font-face font-family="Helvetica" underline-position="-155" underline-thickness="101" units-per-em="2048"/>
<glyph d="M196 1014v138c130 12.7 220.7 33.8 272 63.5 51.3 29.7 89.7 99.8 115 210.5h142V0H533v1014z" horiz-adv-x="1139" unicode="1"/>
<glyph d="M140.5 322c44.3 91.3 130.8 174.3 259.5 249l192 111c86 50 146.3 92.7 181 128 54.7 55.3 82 118.7 82 190 0 83.3-25 149.5-75 198.5S663.3 1272 580 1272c-123.3 0-208.7-46.7-256-140-25.3-50-39.3-119.3-42-208H99c2 124.7 25 226.3 69 305 78 138.7 215.7 208 413 208 164 0 283.8-44.3 359.5-133 75.7-88.7 113.5-187.3 113.5-296 0-114.7-40.3-212.7-121-294-46.7-47.3-130.3-104.7-251-172l-137-76c-65.3-36-116.7-70.3-154-103-66.7-58-108.7-122.3-126-193h782V0H64c6.7 123.3 32.2 230.7 76.5 322z" horiz-adv-x="1139" unicode="2"/>
<glyph d="M163.5 100.5C87.2 193.5 49 306.7 49 440h188c8-92.7 25.3-160 52-202 46.7-75.3 131-113 253-113 94.7 0 170.7 25.3 228 76 57.3 50.7 86 116 86 196 0 98.7-30.2 167.7-90.5 207-60.3 39.3-144.2 59-251.5 59a1351.1 1351.1 0 01-74-2v159a783 783 0 0188-5c67.3 0 122.7 10.7 166 32 76 37.3 114 104 114 200 0 71.3-25.3 126.3-76 165s-109.7 58-177 58c-120 0-203-40-249-120-25.3-44-39.7-106.7-43-188H85c0 106.7 21.3 197.3 64 272 73.3 133.3 202.3 200 387 200 146 0 259-32.5 339-97.5s120-159.2 120-282.5c0-88-23.7-159.3-71-214a298.2 298.2 0 00-114-80c75.3-20.7 134.2-60.5 176.5-119.5 42.3-59 63.5-131.2 63.5-216.5 0-136.7-45-248-135-334S697.3-39 532-39C362.7-39 239.8 7.5 163.5 100.5z" horiz-adv-x="1139" unicode="3"/>
<glyph d="M569 0" horiz-adv-x="569"/></font>
<g stroke-linecap="square" stroke-miterlimit="10">
<path d="M.5.5h690v336H.5z" fill="#fff" stroke="#fff"/>
<g stroke="#000"><g fill="#1eff00">
<path d="M240.5 18.5h72v264h-72zm210 0h72v264h-72zM664.6 35.5C595 46 540.6 77 522.5 116.6"/>
<path d="M522.5 114.5l78-42-78 150-18-54z" stroke="#1eff00"/>
<path d="M666 35.6C578 70.4 521.7 147.9 522.5 233" fill="#fff"/>
</g>
<path d="M383.5 126.5c-34.8 5.2-62 20.7-71 40.6" fill="#1eff00"/>
<path d="M315.5 165.5l39-21-39 75-9-27z" fill="#1eff00" stroke="#1eff00" stroke-width=".5"/>
<path d="M384.3 126.5c-44 17.4-72.2 56.1-71.8 98.7" fill="#fff"/>
<path d="M303 186.5a155 155 0 00-26.5 54" fill="none" stroke="#c04800" stroke-width="3.6"/>
<path d="M42.5 18.5h72v264h-72zM149.9 160.7c-17.4 2.7-31 10.4-35.6 20.3" fill="#1eff00"/>
<path d="M114.3 180.5l19.5-10.5-19.5 37.5-4.5-13.5z" fill="#1eff00" stroke="#1eff00" stroke-width=".5"/>
<path d="M150.2 160.8c-22 8.7-36 28-35.8 49.3" fill="#fff"/>
<g fill="none" stroke="#C04800">
<path d="M628.6 47.4C560.2 82.7 508.5 149.5 486.5 231" stroke-width="3.6"/>
<path d="M78.5 24.5v252m198 0v-252m210 0v252" stroke="#c04800" stroke-width="7.2"/>
</g></g>
<text font-family="Helvetica" font-size="24">
<tspan x="71.8" y="317.5">1</tspan> <tspan x="269.8" y="317.5">2</tspan> <tspan x="479.8" y="317.5">3</tspan></text>
</g></svg>
|
When you compare this W3C-valid code against the EazyDraw output (8617 bytes), you see the advantage of that tool. -- sarang♥사랑 17:03, 24 September 2020 (UTC)
Now the version from the SVGOMG cleaner
[edit]Hi Peter, I told you about another cleaner, and now I could test it. It is easy to use, when you are able to set its many parameters. When the code was cleaned I could see that Eazydraw made not only the embedded text (near the end of the code) but also the same text converted to path (near the top of the code) - removed the redundant path text of more than 1500 bytes (all between <font and </font>). The SVG code of Microphyll evolution omygod.svg looks now as it should be:
<svg xmlns="http://www.w3.org/2000/svg" width="691" height="337" stroke="#000">
<path d="m0-1h692v339H0" fill="#fff"/>
<path fill="#1eff00" d="M42.5 18.5h72v264h-72zM240.5 18.5h72v264h-72zM450.5
18.5h72v264h-72zM664.6 35.5C595 46 540.6 77 522.5 116.6"/>
<path fill="#1eff00" stroke="#1eff00" d="M522.5 114.5l78-42-78 150-18-54z"/>
<path d="M666 35.6C578 70.4 521.7 147.9 522.5 233" fill="#fff"/>
<path fill="#1eff00" d="M383.5 126.5c-34.8 5.2-62 20.7-71 40.6"/>
<path fill="#1eff00" stroke="none" d="M315.5 165.5l39-21-39 75-9-27z"/>
<path d="M384.3 126.5c-44 17.4-72.2 56.1-71.8 98.7" fill="#fFF"/>
<g stroke="#c04800"><path fill="none" stroke-width="3.6"
d="M304 186a155 155 0 0 0-27 55M628.6 47.4C560.2 82.7 508.5 149.5 487 232"/>
<path stroke-width="7.2" d="m78.5 22v257m198,0V22m210,0v257"/></g>
<path fill="#1eff00" d="M149.9 160.7c-17.4 2.7-31 10.4-35.6 20.3"/>
<path fill="#1eff00" stroke="none" d="M114.3 180.5l19.5-10.5-19.5 37.5-4.5-13.5z"/>
<path d="M150.2 160.8c-22 8.7-36 28-35.8 49.3" fill="#fff"/>
<text font-family="Helvetica" font-size="24" stroke="none" x="72" y="317">1
<tspan x="270">2</tspan><tspan x="480">3</tspan></text>
</svg>
I made some of the disgarbaging "by hand" but the most of it is done by the tool. I can really recommend it for your future work! -- sarang♥사랑 12:30, 25 September 2020 (UTC)
Wisteria sinensis anatomia rev en.svg
[edit]If someone could brighten the colours of this illustration it could be much better. It is so dark that I cannot easily see the different parts. I don't have the software to do it. JMK (talk) 21:20, 17 April 2023 (UTC)
- @JMK: I agree that it's too dark. As it's an SVG drawing, it's not as easy to fix as an image would be; each section needs its colour changed. I think that File:Wisteria sinensis nobackground labels.jpg might be better. Peter coxhead (talk) 19:57, 18 April 2023 (UTC)
