Open main menu
Filing cabinet icon.svg
SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 7 days. For the archive overview, see User talk:JoKalliauer/Archiv.
TUWien in Snow.jpg



Hi JoKalliauer,

Thanks for uploading a workaround for File:comparison_land_area_units.svg. In case you see this bug in the future, it was because I used an obsolete DOCTYPE. I no longer get question marks after updating it to

<?xml version="1.0" encoding="UTF-8"?>

The squashing of text is another issue: librsvg struggles with very small font sizes (2.5 px in this case). When I have time and inclination, I'll redraw it at 1000% to get sensible sizes.

cmɢʟee ⋅τaʟκ 13:50, 14 December 2017 (UTC)

@Cmglee: I would recommend to use font-sizes of 20px and bigger see File:Fonttest-Kerning.svg. I used Inkscape (free and open source) to make it 10 times bigger, I think you don't need to redraw it.  — Johannes Kalliauer - Talk | Contributions 16:37, 14 December 2017 (UTC)
  Done I didn't realise there was such a large error as the font-size shrinks. Quite insightful! cmɢʟee ⋅τaʟκ 20:16, 14 December 2017 (UTC)
There shouldn't be any error, because it is scalable vector graphics, but it is a bug of the renderer. An even worse example is here: File:StrekenProvincieUtrecht1.svg. (see old fileversions)
Was it on purpose that you made the border now dashed? File:Comparison_land_area_units.svg
I think I will suggest File:Comparison land area units Workaround.svg for deletion, since you fixed it yourself.
 — Johannes Kalliauer - Talk | Contributions 20:46, 14 December 2017 (UTC)
I realise that it should be scalable and is an librsvg bug, but not how large the error was. I thought that a viewer might think that the hectare is only the rectangle above the acre. Making it dashed makes it more obvious it extends all the way to the bottom. I tend not to be a deletionist, so I'll leave it to you whether you think it should be deleted ;-) Cheers, cmɢʟee ⋅τaʟκ 21:20, 14 December 2017 (UTC)
@Cmglee: There is a difference between Doctype and
<?xml version="1.0" encoding="UTF-8"?>
. Many suppose to use both:
  1. SVG_examples
  2. User:Quibik/Cleaning_up_SVG_files_manually
However if you dont use a Doctype-Declation you schould use
<?xml version="1.0" encoding="UTF-8"?>
 — Johannes Kalliauer - Talk | Contributions 23:36, 22 March 2019 (UTC)

SVG restorationEdit


When you (totally) overwrite my fixes with your fixes, then also remove files from my category, please. BTW, where is your category? Incnis Mrsi (talk) 09:05, 14 January 2018 (UTC)

@Incnis Mrsi:
I retouched more than 100files[1]. I don't have a Category:Retouched by editor I only have Category:Uploaded_by_JoKalliauer, I might create it. I created Category:Retouched by JoKalliauer.
The reason why I restore older versions is that you sometimes remove flow text as in File:H-R_diagram_NL.svg, therefore I fix the file on my own.
If you want to remove the black squares: please instead of completely removing <rect>-tag add Transparency-attribution with fill-opacity="0" in the code of the <rect>-tag then the wikiparser does not show the black squares and the flowtext is still existing.
Example of code before:

<flowRoot><flowRegion><rect x="-375" y="182" width="132" height="8"/></flowRegion><flowPara>Absolute Helderheid</flowPara></flowRoot>

solution without removing the flowtext, but removing the black squares in the Wiki-Parser:

<flowRoot><flowRegion><rect x="-375" y="182" width="132" height="8" fill-opacity="0"/></flowRegion><flowPara>Absolute Helderheid</flowPara></flowRoot>

Then you make the rectangle transparent, but it is still needed/available for the size of the flow text (color and transparency is unimportant)
I first wanted to check other problems in Category:Images_restored_by_SVG_cleanup and then tell you a summary.
 — Johannes Kalliauer - Talk | Contributions 09:35, 14 January 2018 (UTC)
Also in File:Модель Клейна геометрии Лобачевского.svg you removed not empty flowting text.
Due to lack of time, I won't add old images to Category:Retouched by JoKalliauer (at least not now).
 — Johannes Kalliauer - Talk | Contributions 10:23, 14 January 2018 (UTC)
In Модель Клейна I also injected (Microsoft Office)-beloved «’» U+2019 (with very distinctively comma-like glyph in the font used) instead of «′». Fortunately you removed my 7-years-old shame out of sight today. Incnis Mrsi (talk) 14:26, 14 January 2018 (UTC)
Found the presumed pitfall. You could read «′» (wikicode and HTML: &prime;) as the typographic apostrophe (HTML: &apos;) and deemed that it describes a change that might be desirable. Incnis Mrsi (talk) 15:52, 14 January 2018 (UTC)
Thanks I didn't notice that. I reverted to your version and added:

 <g font-family="Liberation Sans" font-size="20" font-style="italic">
  <text x="192.43" y="265.93">A</text>
  <text x="268.7" y="186.49">B</text>
  <text x="70.56" y="161.83">O</text>

 — Johannes Kalliauer - Talk | Contributions 15:11, 14 January 2018 (UTC)
It’s waring that we have communication troubles for such a nonce. I know my English grammar is intelligible enough. And there was no visible pretext to interpret my message above as a kind of sarcasm. Incnis Mrsi (talk) 15:18, 14 January 2018 (UTC)
Ups, Sorry I didn't read properly  — Johannes Kalliauer - Talk | Contributions 16:12, 14 January 2018 (UTC)
@Incnis Mrsi:
Because I saw you edited Category:Images_with_SVG_1.2_features, I just wrote 3 solutions how to User:JoKalliauer/RepairFlowRoot, the solution I told you before is the easiest, but the flow-text wont get displayed, the other two solutions are proper solutions.
 — Johannes Kalliauer - Talk | Contributions 19:02, 14 January 2018 (UTC)

Rsvg bugEdit

Hallo Johannes, falls du mit den bugs weitermachen willst: jetzt sollte alles stimmen, incl. der automatischen Kategorisierung: generell sind alle bug-Kategorien aus den Dateibechreibungen zu entfernen. Du sagst mir wenn dir etwas auffällt! -- sarang사랑 09:43, 11 May 2018 (UTC)

@Sarang: Warum wird File:AMPS World Sectors.svg von {{Technically replaced}} in Category:Pictures_showing_a_librsvg_bug_(overwritten_with_a_workaround) einsortiert? JoKalliauer (talk) 14:08, 11 May 2018 (UTC)
Ich habe es jetzt geandert, in Technically replaced/layout, auf den Parameter fur "replaced"; hat sich von 6 auf 7 verschoben weil ich kurzfristig den Grund "compatibility" eingeschoben hatte. Danke fur den Hinweis! -- sarang사랑 16:01, 11 May 2018 (UTC)
Hier ein Hinweis fur dich, ich denke du hast es noch nicht bemerkt: {{Autotranslate}} kann nur unbenannte Parameter (1 bis max. 15) weitergeben/durchreichen, aber keine benannten! -- sarang사랑

Hallo, es scheint nicht so einfach einen Javascript-Kundigen zu finden, der auch aktiv ist... ich habe es mal bei Magnus versucht. Ich hoffe, wir konnen bald statt dem leeren default ein "U" bekommen; an die 10.000 Inkscape-Zuordnungen zu untersuchen um ev. nachtraglich den Leerwert zu ersetzen erscheint viel zu aufwendig - da sollte die Scriptanderung schneller gehen. Hilft klarerweise nur in der Zukunft! -- sarang사랑 06:46, 17 May 2018 (UTC)

Mit Magnus' Hilfe habe ich es hinbekommen, das Unknown tool als default vorzuschlagen (du weisst, dass nun auch alle SVGs von Texteditor da hineinfallen!). Weil das script protected ist brauche ich wieder mal einen Admin, um die Korrektur wirksam werden zu lassen; ich hoffe dass es bald geschieht. -- sarang사랑 16:22, 18 May 2018 (UTC)
Danke! euch beiden
Es war schon so seit dem ich das Skript kenne (Monate), also wenn es noch einige Tage so ist, fände ich es nicht tragisch, auch wenn es nervig ist. JoKalliauer (talk) 17:42, 18 May 2018 (UTC)

Ich habe die bug-Kategorien ein wenig in Ordnung gebracht, und Dateien entkategorisiert. Dabei sah ich, dass du unlängst SVG test text tspan ws.svg kategorisiert hast: Solche "direkten" Kats durfen nicht erfolgen - nur mit der Vorlage, und dann moglichst mit einem Hinweis was denn buggy ist. -- sarang사랑 14:34, 20 May 2018 (UTC)

@Sarang: Das weiß ich prinzipiell, passiert mir aber trotzdem manches-mal, oder irgendetwas ist etwas buggy, aber in dem Fall war es glaub ich Perhelion Oder meinst du etwas anderes? JoKalliauer (talk) 14:45, 20 May 2018 (UTC)
Sorry, du hast recht, er war es - ich weiss nicht was er meinte. Aber ich weiss nun 100% dass du es weisst und richtig machst! -- sarang사랑 14:57, 20 May 2018 (UTC)

Ich glaub es noch nicht ganz: Perhelion ist wieder da! nach ganzen 2 Monaten. -- sarang사랑

Das freut mich sehr.   Ich werde ihm wieder willkommen heißen, aber ich würde ihm mal Zeit lassen, hat sich sicher viel bei ihm aufgestaut, vielleicht brauchte er auch mal eine Wiki-Pause. Ich hoffe, dass er wieder voll zurück ist. JoKalliauer (talk) 20:28, 20 May 2018 (UTC)

Troubling editsEdit

Although I commend your efforts to fix many SVG files, I am troubled by how you implement some fixes. For example, I am troubled by edits that unnecessarily fork new versions of files and characterize the SVG 1.1 librsvg as having bugs because it does not implement SVG 1.2 additions. Failing to conform to a later draft is not a bug.

For example, File:Crossen1650.svg uses (draft) SVG 1.2 flowRoot. Instead of fixing that issue and uploading an SVG 1.1 version of the file, you forked a new file, File:Crossen1650 Workaround.svg, and left an alleged error message ("This SVG map shows a librsvg bug. Bug replaced description: phab:T43424 Flow region error") at the original location.[2] Why didn't you just upload the fix at the original location?

Please upload your SVG 1.1 version to the original file location (File:Crossen1650.svg), remove the technically replaced text, and request deletion of File:Crossen1650 Workaround.svg.

Those steps should be done to other "workaround" file forks. For example, File:Mt Etna system cross section Workaround.svg.

Please do not create "workaround" versions when the problem can be fixed at the original location. Just fix the original file. That keeps a sensible file history and avoids unneeded copies.

Glrx (talk) 17:12, 21 June 2018 (UTC)

I thought, because Category:Pictures_formerly_showing_a_librsvg_bug is a category for "so that we can check them again in future upgrades.", there is a consensus of keeping (and not overwriting) files shows librsvgbugs. For files which have a proper error, I overwrite files. Since Commons:Overwriting_existing_files says you should only overwrite files if you are sure that it is ok, I thought it is the suggested way to replace it with a different version. Replacing flowRoot with Text is in my opinion similar to "Digital restoration" (which should not be overwritten). For example in File:Oxygen480-mimetypes-application-rtf.svg it is in my opinion problematic to overwrite the file, because if you don't have the specified font, the line-break do not look nice, therefore flowRoot should be kept in the file. But since Category:Oxygen_icons_mimetypes are too many files with similar issues, the files should be overwritten as done by User:Thomas Linard.
I would prefer to not create new files, because then I have less administrative work to do.
If you prefer I can ask for a merge of such files, but as said I thought all files containing a librsvgbug should be keept to track render-problems.
In future I will overwrite files more often, and if I am unsure I will ask someone with more experience (like you).
 — Johannes Kalliauer - Talk | Contributions 20:19, 21 June 2018 (UTC)
Category:Pictures formerly showing a librsvg bug is a silly category. If a file is fixed, then it is fixed. One need not check a fixed file later. I do not see a benefit to such a category, and file page annotations that say things such as a previous version has 47 SVG verification errors is not helpful. If the flowRoot (or other problem) has been removed, then what is the point of checking whether flowRoot works?
Eliminating flowRoot should not be objectionable. Almost no user agents support flowRoot, so it should be viewed as a minor mistake by the illustrator/uploader. In most cases, replacing the flowRoot will not significantly change the intended appearance of the image.
The File:Oxygen480-mimetypes-application-rtf.svg is not a good counterexample because it is not about the same issue. Making the background text more visible is probably not objectionable to the original uploader. If the original Oxygen icon has the more visible text, then it is clearly an improvement. In any event, adjusting the background text should be viewed as a minor change. Having two similar images presents problems down the road. If somebody wants to the use the icon, then how does she decide which background to use? Does the background make any semantic difference?
The issue is more that flowRoot is marginal and unsupported rather than trying to preserve flowRoot's line breaking. There are ways to edit flowRoot files to be SVG 1.1 and draft SVG 2.0 compatible (style="inline-size: 200px"), but I am not aware of an SVG agent that currently supports such line breaking.
Digital restoration means something different. Often someone will scan an image from an old book; the scan is the most accurate information about the page and should be preserved. The paper may have yellowed, so it may be sensible to color correct (restore) the image. The digital restoration issue is that the color corrected image should be at a new file name. The issues can get even more involved; see Category:Köhlers Medizinal-Pflanzen. Digital restoration refers to operations such as color correction, dust removal, scratch removal, and unsharp masking.
You have fixed far more files than I.
Glrx (talk) 21:25, 21 June 2018 (UTC)
Category:Pictures formerly showing a librsvg bug is for files which have not been fixed, but the update of the renderer did solve the problem (f.e. with ?action=purge)
File:Oxygen480-mimetypes-application-rtf.svg The font "ScriptS" is a very unknown font, even to google, therefore the textlength will differ on every computer, depending on the fallbackfont, if the font is longer than the page it does not look nice, also the current version, where the text is shorter than the page, does also look strange (correct rendering:
If you work with Inkscape and render pngs on your own, you don't care about useragents. For files as in File:Vergleich_zwischen_Manga_und_Foto_(nur_Zeichnung).svg, or File:Dojikko2.3.svg you will always update SVG and PNG/JPG simultaneously, because the Dojikko2.3.svg contains filters,textPath,... and other thinks librsvg wont be able to render in near future, also big thumbs (larger than ~800px, especially in the larger original version) of Dojikko fails, therefore the PNG always has to be created with Inkscape not with librsvg. So sometimes svgs are just the sourcecode to produce pngs in some Program (similar to source-code for Gnuplot or Matlab), and such svgs should not to be implemented in Wikipedia.
I know what digital restoration is, also I never did it on Wikipedia. (But I wasn't able to find any more proper description for removing librsvgbugs, therefore it was unclear to me, therefore I created new versions.)
Just because I fixed more files, does not compellable mean that I have more experience. (You have a great knowledge about svg-definitions, I just have some experience how to use programs (inkscape,sour,svgcleaner,svgo) to fix bugs on commons, but that could often be even done just with a bot, f.e. adding jpeg or png to xlink:href=\"data:;base64,) But actually I meant you have more experience about commons guidelines.
 — Johannes Kalliauer - Talk | Contributions 22:07, 21 June 2018 (UTC)
Vielen Dank. I misunderstood Category:Pictures formerly showing a librsvg bug.
Yes, there are many files that librsvg cannot handle, so other methods must be used.
Glrx (talk) 15:45, 23 June 2018 (UTC)
Some older viewers have trouble with the version of File:Oxygen480-mimetypes-application-rtf.svg you uploaded 20 June. (same with the "Valid SVG version 1.1." from Thomas) The "Better attempt" version from Thomas doesn't have this issue. - Alexis Jazz ping plz 22:12, 21 June 2018 (UTC)
@Alexis Jazz: The linebreaks are more similar to the png in my version, therefore I undid Thomas version, when removing phab:T55899-Waring from Commons:Commons SVG Checker, but I reverted my edit. Since I try to fix several files: For future-Problems: I would like to know which viewers have which problem with my version.  — Johannes Kalliauer - Talk | Contributions 18:51, 22 June 2018 (UTC)
My two cents: in the case of Oxygen icons, we've the original sources easily available on GitHub, with the original PNG export (we can assume safely that these PNG convoy the authors original intent). So, I don't think we should preserve the original code (flowRoot, for example) with a -Workaround.svg version: I agree with Glrx, we can safely fix the original file. If someone wants the original code: go to GitHub or download an old version. In my view, the primary purpose of hosting SVG icons on Commons is to provide UI icons for the various Wikimedia projects, not to display a museum of old SVG horrors. Furthermore, I hope we'll overcome soon phab:T193352, so we'll need less tricks and workarounds (phab:T55899 is fixed in the latest version of librsvg). Thomas Linard (talk) 15:35, 22 June 2018 (UTC)
For the Oxygen icons, we three agree that they should be overwritten using three different arguments.  — Johannes Kalliauer - Talk | Contributions 18:51, 22 June 2018 (UTC)
As said before, I will more often overwrite files. (I don't have a strong opinion on that therefore i agree with everything the community recommends.)
I think we agreed on the mayor points.
 — Johannes Kalliauer - Talk | Contributions 18:51, 22 June 2018 (UTC)

File:20T superconducting magnet.pngEdit

File:20T superconducting magnet.png has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans | العربية | беларуская (тарашкевіца)‎ | български | বাংলা | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | Zazaki | Ελληνικά | English | Esperanto | español | eesti | فارسی | suomi | français | galego | עברית | hrvatski | magyar | Հայերեն | Bahasa Indonesia | íslenska | italiano | 日本語 | 한국어 | 한국어 (조선) | македонски | മലയാളം | Plattdüütsch | Nederlands | norsk nynorsk | norsk | occitan | polski | پښتو | português | português do Brasil | română | русский | sicilianu | slovenčina | slovenščina | shqip | српски / srpski | svenska | ไทย | Türkçe | українська | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

Glrx (talk) 04:15, 26 June 2018 (UTC)


Hi JoKalliauer,

Can you make wordmarks for Punjabi & Sindhi Wikipedia?— Bukhari (Talk!) 04:54, 16 July 2018 (UTC)

@BukhariSaeed: Sorry for not answering you might ask at: Commons:Graphic_Lab/Illustration_workshop for creating SVGs  — Johannes Kalliauer - Talk | Contributions 23:47, 22 March 2019 (UTC)

Fake SVGEdit

Hallo Johannes, ist jetzt implementiert, per Igen mit !=f (geht auch mit BadSVG 1=f oder 3=f - aber prinzipiell sollte Igen verwendet werden). Gruss -- sarang사랑 11:17, 16 July 2018 (UTC)

@Sarang: Bei File:201802_Human_Female.svg steht Dieses SVG-Bild enthält f eingebettete Rastergrafiken.. Kannst du nachkontrollieren ob das so passt?  — Johannes Kalliauer - Talk | Contributions 19:27, 16 July 2018 (UTC)
Naturlich habe ich vorkontrolliert ehe ich die script-Vorschlage ubernommen habe. Auch bei der Nachkontrolle sehe ich, dass dieses Bild {wie viele von Yayamamo) aus exakt 4 SVG statements besteht: <svg, <title, <image und </svg. Also absolut reines Fake, nach deiner Definition! Der entsprechende Text ist einstweilen nur im englischen environment realisiert, ich weiss nicht ob es dafursteht es in noch ein oder zwei weitere Sprachen einzupflegen (in welcher Sprache verwendest denn du die Commons?) Gruss -- sarang사랑 04:38, 17 July 2018 (UTC)
@Sarang: ich habe mich über die Implementierung auch gerade gewundert. :P Die Vorlage sollte eine eigenständige sein wie BadSVG und mit den üblichen Tools in ALLE Sprachen übersetzbar sein. Für meinen Geschmack ist auch viel zu viel Text drinnen. Ein einziger kurzer Satz sollte reichen (alles weitere per Link, die ganze Erklärung wie bei BadSVG können wir uns sparen). VG -- User: Perhelion 09:46, 17 July 2018 (UTC)
@Perhelion: meintest du "eigenständig", so wie BadSVG-t ohne BadSVG auskommt? Eine Art "BadSVG-f" war nämlich meine urspr. Intention - aber das muss ich dann im Igen realisieren. Kann ich machen, ich bin für alle Anregungen und Verbesserungsvorschläge dankbar. -- sarang사랑 11:00, 17 July 2018 (UTC)
Aja genau, von mir aus auch mit Redirect Template:FakeSVG -- User: Perhelion 11:15, 17 July 2018 (UTC)
@Sarang: Danke, Mein Fehler ich verwende "de-AT...Österreichisches Deutsch". Genau das wollte ich haben. Danke!! Aber es tut sich mir die Frage auf, was wir für nicht vorhandene Sprachversionen wählen: statt "enthält f eingebettete Rastergrafiken" würde ich wählen "enthält 1 eingebettete Rastergrafiken" oder "enthält fake eingebettete Rastergrafiken" (also das Englische Wort "fake" statt der Anzahl) nehmen, ich würde zu "1" tendieren, wenn das sinnvoll machbar ist.  — Johannes Kalliauer - Talk | Contributions 17:39, 17 July 2018 (UTC)
Ich würde die Ergänzung einfach weglassen, alles andere macht nicht wirklich Sinn. -- User: Perhelion 19:50, 17 July 2018 (UTC)
@Perhelion: ich hatte zu BadSVG-f tendiert, in Analogie zu dem -t (-f ist ja wirklich bad/worse, -t hingegen nicht: der Name kann schnell geandert werden, zB TopoSVG?). Das FakeSVG ware vorerst ein stub wie das TopoSVG mit nur englischem Text - das kann ja jederzeit auf ostbayrisch, de-at etc. aufgebohrt werden. Mit eigener Vorlage vermeiden wir, dass bei Nichtenglandern unsinniger Text ausgegeben wird, besser vorerst nur englisch aber das richtig! -- sarang사랑 20:47, 17 July 2018 (UTC)
Hallo Johannes, naturlich kann ich das ganze auch internationalisieren - eingeschrankt, weil ich die meisten Sprachen nicht spreche und mit den "translation admins" habe ich keine positiven Erfahrungen. Fur osterreichisches Deutsch reicht es aber noch. Ich kann neben en noch de (de-at?), es, fr, pt selbst ubersetzen, nicht jedoch alles andere wie zB serbokroatisch, thailandisch und eskimoisch. Vorerst mal kommt die Meldung ausschliesslich in relativ astreinem Englisch, und fur alle nicht vorhandenen Sprachen wird dann sinnvollerweise dieses Englisch als default genommen. Ach ja: wie ubersetze ich denn "Fake-SVG" am besten auf de-at? (ohne pejorativ zu werden!) -- sarang사랑 16:19, 19 July 2018 (UTC) 0 PS: dein Bouncywikilogo.gif nervt schrecklich
Internationalisierung ist nicht notwendig, ich fand nur enthält f eingebette Rastergrafiken etwas verwirrend, dachte ursprünglich es wäre ein codeing-Fehler.
Ich glaube, "de-AT Österreichisches Deutsch" greift standardmäßig auf "de" zu, wenn "de-AT" nicht existiert und "de-AT" macht definitiv keinen Sinn (Wartung,...). Ich kenne auch keinen Unterschied zwischen "de Deutsch" und "de-AT Österreichisches Deutsch" (außer dass in der Kopfzeile "Österreichisches Deutsch" neben den eigenen Benutzernamen steht), man kann es aber jedenfalls in den Special:Preferences wählen. Ich kenne keine Österreichische Vorlage, wüsste auch nicht wo das Sinn hätte, es gibt glaub ich Unterschiede in der Rechtschreibung, jedoch ist mir keiner bekannt (die Schweiz hingegen hat z.B. keine scharfen ss (ß), in Ö und D gibt es seit einem Jahr auch ein de:Großes_ß).
Mir reicht eine englische Version, ich mag es auch dir überlassen ob man andere Sprachen auf die Übersetzung {{Bad SVG}} zurückfallen lässt (mit ev. anderen Layout) oder wie von dir vorgeschlagen auf die Englische zurückfällt.
Ich bin ein kleiner Idealist, deshalb würde ich mir auch eine de:Esperanto-Version (diplomatische Plansprache) wünschen, spricht zwar "keiner" (ich auch nicht), aber bei der aktuellen politischen Weltlage finde ich dass man sich mehr den je zu Europäischen Werten und diplomatischen Werten bekennen soll.
Bezüglich Bouncywikilogo.gif fällt mir nicht mal mehr auf (außerdem verschwindet es eh hinter dem Bearbeitungsfeld, also es schrenkt es mMn nichts wesentliches ein), meistens editiere ich auch nur den Abschnitt (auch um keine Bearbeitungskonflikte zu bekommen), da erscheint es dann nicht in der Vorschau. Ich bin zwar aus moralischer Sicht kein Fan von AdBlockern, aber die geben einen die Möglichkeit bestimme Inhalte (z.B. nervige Bilder) auszufiltern. (Aber werde ich jetzt ohnehin entfernen.)  — Johannes Kalliauer - Talk | Contributions 20:20, 19 July 2018 (UTC)
Ja, at fallt auf de zuruck. Es gibt eine Menge Austriazismen, vielleicht kann man (mit Gewalt) Text so gestalten dass so ein Begriff vorkommt? Oder in Igen/top etwas verwenden? Fur scharfes s sehe ich keine Einsatzmoglichkeit, schon gar nicht als Majuskel; wir sind uns doch einig, dass wir Pejorativa wie zB "SCHEIẞ SVG code" vermeiden wollen.
Esperanto gibt es bereits bei den created with-Vorlagen, zuvor nur ganz wenige aber nun konnen alle Vorlagen auch das; kannst du ausprobieren wenn du willst.
"enthält f eingebette..." war ein Fehler von mir, weil ich schnell mal die "alte" Vorlage nahm und nicht berucksichtigt hatte dass diese zu ubersetzen versucht. Ich habe es einstweilen nicht so eilig die I18n voranzutreiben, um "Fake" in 50 Sprachen zu ubersetzen.
Das Bouncywikilogo ist ja eine recht drollige Variation des WP-Logos, aber wenn standig etwas rumtut und in den Augenwinkeln rumwackelt kann das durchaus irritieren. Wenn oben links die at-Flagge weht stort das ja nicht, aber das GIF-Bild hat mich ja uberall hin verfolgt! Ich hatte damit leben konnen, aber danke, so ist es IMHO besser. -- sarang사랑 07:19, 20 July 2018 (UTC)

Is this a known bug?Edit

See first version of File:2-methylaziridine.svg and the methyl group, H3C. It messes up the text block.

text element sets style for text-anchor:end. The the first tspan element starts a text block because it has absolution position attributes. Librsvg ends the first tspan at the anchor point, but then paints the following tspans after the anchor point. All of the tspans belong to one text block, so the block should have ended at the anchor point.

Glrx (talk) 23:51, 25 July 2018 (UTC)

I don't know any bugreport about this issue, but:
In my option it is an example of unintelligent definition of an SVG, see File:Test.svg. (12:41, 26 July 2018)
I would even say it is rendered correctly, is there a definition how it should be rendered?
 — Johannes Kalliauer - Talk | Contributions 12:45, 26 July 2018 (UTC)
Thanks. Here's your SVG:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' ''>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="">
 <text fill="red"   text-anchor="end"><tspan x="24" y="20">H</tspan>3C</text>
 <text fill="green" text-anchor="end" x="24" y="21"><tspan>H</tspan>3C</text>
 <text fill="blue"  text-anchor="end"><tspan x="24" y="22">H3C</tspan></text>
 <path d="m34.8"/>
I'm surprised it has not turned up before with Inkscape. Inkscape's text elements always put the text in tspans, so the basic pattern in the failing "blue" line should have happened often. Maybe users rarely do text-anchor="end".("red" line fails)
All three SVG lines are legal. I've been saying "text block" where I should have said "text chunk". The text-anchor operates on a text chunk.
where it says "Each text chunk represents a separate block of text for alignment due to ‘text-anchor’ property values."
I tried a few more variations, but don't have a good model of the error.
Sadly, the error has frustrated User:Hbf878 who tried to make text work.
Glrx (talk) 14:03, 26 July 2018 (UTC)
The blue line is rendered correctly? Only the definition of red line is still unclear to me. What is a "text chunk",? everything in <text></text>?
Inkscape uses <text style="text-anchor:end" x="24" y="23"><tspan x="24" y="23">H3C</tspan></text>, so text and tspan have identical koordinates.
@Glrx: Because you correlated it to text-anchor="end": How should the "red line" in the following code be rendered:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' ''>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="">
 <text fill="red"   text-anchor="start">H3<tspan x="24" y="20">C</tspan></text>
 <text fill="green" text-anchor="start" x="24" y="21">H3<tspan>C</tspan></text>
 <text fill="blue"  text-anchor="start"><tspan x="24" y="22">H3C</tspan></text>
 <path d="m34.8"/>
 — Johannes Kalliauer - Talk | Contributions 14:57, 26 July 2018 (UTC)
I have another question: How should the yellow text be rendered:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' ''>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="">
 <text fill="yellow" text-anchor="end"><tspan x="24" y="20">H</tspan><tspan x="24" y="21">3</tspan>C</text>
 <path d="m34.8"/>
I think it is a not defined behavior and therefore everyone is right, and the rendering of librsvg makes more sense to me, than that of common browers or inkscape.  — Johannes Kalliauer - Talk | Contributions 15:08, 26 July 2018 (UTC)
The behavior is defined, and librsvg is wrong. A "text chunk" is all the characters from one absolute position adjustment to the next absolute position adjustment. Absolute position adjustments are implied in a text element and also occur in tspan elements with attributes such as x="13" or y="47". Relative position adjustments such as dy="5" or baseline adjustments do not start a new text chunk.
The blue line is correct; I was confused. Comment struck.
In your red line example, "H3" is a text chunk anchored at the default x=0, y=0. The "C" is another text chunk anchored at x=24, y=20.
In your yellow example, "H" is a text chunk end-anchored at x=24, y=20. The next text chunk is "3C" end-anchored at x=24, y=21. The tspan with "3" starts a new text chunk; the following #text node with "C" does not have any absolute positioning commands, so the "C" is added to the current text chunk.
The bug appears when there is a tspan element followed by a #text node.
I filed Phab:T200443.
Glrx (talk) 16:34, 26 July 2018 (UTC)
@Glrx: Thanks! Now I understand what a text chunk is. (or at least better)

“The ‘text-anchor’ property is applied to each individual text chunk within a given ‘text’ element. Each text chunk has an initial current text position, which represents the point in the user coordinate system resulting from (depending on context) application of the ‘x’ and ‘y’ attributes on the ‘text’ element, any ‘x’ or ‘y’ attribute values on a ‘tspan’, ‘tref’ or ‘altGlyph’ element assigned explicitly to the first rendered character in a text chunk, or determination of the initial current text position for a ‘textPath’ element.”

What if a text chunk has several alignments as in File:Test.svg (17:25, 26. Jul. 2018)? Does it take the first alignment of the first character?
 — Johannes Kalliauer - Talk | Contributions 17:33, 26 July 2018 (UTC)
LMAO. This is going to take some time.
 1 <?xml version="1.0" encoding="UTF-8"?>
 2 <svg font-size="25" viewBox="0 0 600 600" xmlns="">
 3  <metadata>
 4   <rdf:RDF xmlns:rdf="">
 5    <cc:Work xmlns:cc="" xmlns:dc="">
 6     <dc:format>image/svg+xml</dc:format>
 7     <dc:type rdf:resource=""/>
 8     <cc:license rdf:resource=""/>
 9     <cc:attributionName rdf:resource=""/>
10     <cc:attributionURL rdf:resource=""/>
11    </cc:Work>
12   </rdf:RDF>
13  </metadata>
14  <path d="m100 100h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600 50h600m-600-475v450m300-100v250" stroke="#000"/>
15  <text x="400" y="450" text-anchor="end">a<tspan x="400">b</tspan>c<tspan y="500">d</tspan>e</text>
16  <text x="400" y="550" text-anchor="end">a<tspan x="400">bc<tspan y="600">de</tspan></tspan></text>
17  <text x="100" y="100">a<tspan text-anchor="end">b</tspan>c<tspan text-anchor="middle">d</tspan>e</text>
18  <text x="100" y="150">a<tspan y="200" text-anchor="end">b</tspan>c<tspan x="100" text-anchor="middle">d</tspan>e</text>
19  <text x="100" y="250">a<tspan x="100" text-anchor="end">b</tspan>c<tspan y="300" text-anchor="middle">d</tspan>e</text>
20  <text x="100" y="350" text-anchor="middle">1<tspan text-anchor="end">2<tspan x="100" y="400">3</tspan>4</tspan>5<tspan x="100" y="450">6</tspan></text>
21 </svg>
Line 15 (400,450) Each x or y starts a new end-anchored text chunk. "a"| / "bc"| / "de"| (Google/Firefox |"de"; librsvg continues from last x position)
Line 16 (400,550) is simple. End anchored "a"| / "bc"| / "de"| (Google/Firefox |"de"; librsvg continues from last x position)
Line 17 (100,100) has problems because anchoring cannot occur within a text chunk. |"abcde" start anchored by original text element.
Line 18 (100,150) |"a" / "bc"| / "d|e" (librsvg continues from last x position)
Line 19 (100,200) |"a" / "bc"| / "d|e" (Google/Firefox use strange x to place "de"; librsvg from last x position)
Line 20 (100,350) "1|2" / |"345" / "|6|" (Google/Firefox "345"| which is capturing text-anchor from any left; reasonable)
I must read more about this because I'm disagreeing with Google and Firefox.
I think tspan should default its current position from the previous painting's end but then modify it with x and y attributes.
Google and Firefox appear to default to last virtual position; they might be doing "de"| but starting from end of "bc" so it looks like |"de".
I'll have to read the spec for current position.
Glrx (talk) 18:44, 26 July 2018 (UTC)
Thanks that's enough for me. In my opinion, a text-chunk should be identical to the tag containing the koordinates, otherwise it is stupid (difficult to read/understand)
I think in Line 18 "bc" is horizontally aligned at the end of the letter "a" in Chrome and Firefox, which seems to be wrong (IE, Edge and Inkscape are quite bad in rendering those examples, not worth mentiong there results), I think a new definition of x starts a new text-chunk in Chrome and Firefox and y does not start a new text-chunk.  — Johannes Kalliauer - Talk | Contributions 19:35, 26 July 2018 (UTC)
Yes, line 18 in Chrome and Firefox does what you say, but I think they render the line correctly. |"a" is written and updates the graphic's current position to end of a. The tspan uses the current position's x but drops 50 px due to the y attribute; the y causes a new text chunk. Then "bc"| is end-anchored at that position. The "d|e" text chunk is centered on the line.
The Chrome/Firefox behavior is a more complicated. Your explanation has trouble with "a" because "abc" would be a text chunk.
Yes, I tried Edge, but just gagged. I didn't try IE.
You've provided an impressive torture test.
Glrx (talk) 21:02, 26 July 2018 (UTC)
Johannes Kalliauer's torture test.

Bitte, sehen Sie das Bild. Glrx (talk) 19:52, 1 August 2018 (UTC)


hallo, ich hab mir deine Grafik angeschaut für die erneuerbaren energien in frankreich: file:Electricity in France de Gnuplot.svg

ich habe probeweise bei 1993 für die erneuerbaren (grün) einen peak von 600 eingefügt
ist das svg mit diesen daten verknüpft?
wie kann ich eine datenänderung zur anzeige bringen?

wenn ich von dem svg in commons auf den gnuplot-link klicke komme ich nur zum Artikel - ist iwo beschrieben, wie ich es selber so wie du anwenden kann?
würde mich sehr interessieren - danke

würd gern versuchen die anfrage in der de:WP:Grafikwerkstatt ganz unten (Anteile der Energieträger seit 1800) selber mit gnuplot zu bauen - wärst du so nett und unterstützt mich?
--Mrmw (talk) 12:06, 29 July 2018 (UTC)

@Mrmw: Ich kann dir gerne helfen, also die Daten sind nicht wikiintern verknüpft, sie sind nur Quelldateien, die du Benötigst um das SVG vollautomatisch auf deinen Privatpc erstellen zu können.
Wie du Gnuplot auf Windows 64bit installierst:
Wieauchimmer irgendwer muss sich um die Aktualisierung der Daten kümmern, das SVG erstellen kann ich recht schnell.
 — Johannes Kalliauer - Talk | Contributions 20:37, 29 July 2018 (UTC)


Hallo Johannes, wenn ich viel editiere kann ich leicht etwas übersehen; kommt leider gelegentlich vor. Obwohl ich weiss dass die Vorschläge des script immer überprüft werden müssen. Beim 2D gedrehtes Auflager.svg hat mich erst sehr gewundert, dass du das als "Fahne" kategorisiert hast. Dann habe ich gesehen: das Perhelion-script hat versucht, einen guten Vorschlag für das topic zu finden - und war heilfroh im Wort "Auflager" einen vermeintlichen Treffer zu landen... Beinahe wäre mir bei einem anderen Auflager dasselbe passiert! So lustig kann es manchmal zugehen mit unserer selbstgestrickten KI. Weiter guten Erfolg! -- sarang사랑 15:32, 14 August 2018 (UTC)

Gibt es eigentlich eine Liste von den Abkürzungen, obwohl ich schon lange editiere kenne ich grad einmal s=d auswendig, beim Rest vertraue ich aufgrund von Wissensmangel auf das Skript.  — Johannes Kalliauer - Talk | Contributions 21:45, 14 August 2018 (UTC)

Hallo Johannes, nun habe ich die von dir ersehnte Tabelle gebastelt. Sie ist vorsortiert nach den Codes. Ich hoffe du kannst jetzt besser mit dem Zeugs umgehen; vielleicht schaffen Perhelion und ich noch eine bessere Editieriungshilfe. -- sarang사랑 16:29, 28 August 2018 (UTC)

Mist jetzt habe ich keine Ausrede mehr, wenn ich falsch editiere. ;-) . Danke!  — Johannes Kalliauer - Talk | Contributions 07:51, 29 August 2018 (UTC)

A barnstar for you!Edit

  The Graphic Designer's Barnstar
For cleaning up many drawings. MaGa 16:26, 28 August 2018 (UTC)
Thank you! :-D
The Error is not really important, since they are rendered correctly by librsvg (the Rendering-Libary of Wikimedia), "just" browsers show a warning, and stops loading the file, also they should just ignore the unknown attribute. To avoid this Warning you could correct the sourcecode of the SVG with any text-editor by adding xmlns:inkscape="" anywhere in the <svg >-tag, or alternatively you could delete everything containing inkscape: (f.e. inkscape:transform-center-y="-23.229832" or inkscape:connector-curvature="0"). (I did both.)
Example of original file:
<?xml version="1.0" encoding="UTF-16"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">
<!-- Creator: CorelDRAW X8 -->
<svg xmlns="" xml:space="preserve" width="1931px" height="1141px" version="1.1" style="shape-rendering:geometricPrecision; text-rendering:geometricPrecision; image-rendering:optimizeQuality; fill-rule:evenodd; clip-rule:evenodd"
viewBox="0 0 7229557 4273050"
   <g id="g3138" inkscape:transform-center-y="-23.229832">
    <polygon id="path3475" class="fil5" points="2626654,4004654 3005125,4004654 3005125,4030993 2626654,4030993 " inkscape:connector-curvature="0"/>
    <polygon id="path3475_0" class="fil5" points="3383591,4004654 3005120,4004654 3005120,4030993 3383591,4030993 " inkscape:connector-curvature="0"/>
    <polygon id="path3475_1" class="fil1" points="3383587,4004654 4135251,4004654 4135251,4030993 3383587,4030993 " inkscape:connector-curvature="0"/>
Example of fixed file
<?xml version="1.0" encoding="UTF-16"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "">
<!-- Creator: CorelDRAW X8 -->
<svg xmlns="" xml:space="preserve" width="1931px" height="1141px" version="1.1" style="shape-rendering:geometricPrecision; text-rendering:geometricPrecision; image-rendering:optimizeQuality; fill-rule:evenodd; clip-rule:evenodd"
viewBox="0 0 7229557 4273050"
 xmlns:xlink="" xmlns:inkscape="">
   <g id="g3138">
    <polygon id="path3475" class="fil5" points="2626654,4004654 3005125,4004654 3005125,4030993 2626654,4030993 "/>
    <polygon id="path3475_0" class="fil5" points="3383591,4004654 3005120,4004654 3005120,4030993 3383591,4030993 "/>
    <polygon id="path3475_1" class="fil1" points="3383587,4004654 4135251,4004654 4135251,4030993 3383587,4030993 "/>
You could use to check if everything is ok.
I edited, cleaned up much more, which is unnecessary, and on its own not worth uploading a new version.
In my first corrections I deleted the CSS-code and implemented it into the SVG, but since this might be unwanted, for further editing, in my later corrections (since 21:16, 27. Aug.) I decided to keep the CSS-code.
 — Johannes Kalliauer - Talk | Contributions 07:47, 29 August 2018 (UTC)
Well, I doubt I will mess with code. I saw that you cleaned up some drawings of mine with text converted to curves, bringing back text. I don't know what is the problem with text: is it a application (Inkscape or Corel) or is it a rendering on Wikipedia. Very frustrating. So feel free to improve any of my drawings uploaded at Commons. Thanks again, and keep up good work.--MaGa 18:33, 1 September 2018 (UTC)

Another librsvg bugEdit

Firefox, Chrome and Internet Explorer align the fraction correctly, but the Wikimedia thumbnail renderer centres the "2", leaving the denominator off-centre.

Hi JoKalliauer,

Thanks for fixing my recent contributions.

Hope you don't mind my bothering you with another librsvg bug. On centre-aligned text with multiple tspans, only the first tspan is centre-aligned, as in this image. Can you please help me file a bug report?

cmɢʟee ⋅τaʟκ 10:45, 14 October 2018 (UTC)

@Cmglee:You specified <text><tspan x="0" dy="1em" text-anchor="middle">2</tspan><tspan font-style="italic">n</tspan></text>, and librsvg regognises <tspan x="0" dy="1em" text-anchor="middle">2</tspan> and aligns the 2 in the middle, which is the more intelligent definition. However Text-chunks in SVGs are defined differently see #Is_this_a_known_bug? for details.  — Johannes Kalliauer - Talk | Contributions 12:14, 14 October 2018 (UTC)
Thanks, Johannes. I didn't realise tspans can be nested – that's a good solution. In my example, I had the text-anchor in the outer g, not in the tspan. If the text-anchor were in the tspan, I agree that it's the more intelligent definition, though to go a different way from three independent established browsers likely makes the user think it's librsvg that's buggy. Anyway, I'll use nested tspans henceforth. Cheers, cmɢʟee ⋅τaʟκ 20:04, 14 October 2018 (UTC)

Thanks a lot for your help on File:Well_to_Wheels_(kWh)_-_Dual_Language_En+De_Original.svgEdit

Great job, this is wonderful! --Gregor Hagedorn (talk) 06:12, 24 October 2018 (UTC)

Thanks again, I did some cleanup and improvement work. However, working with Inkscape and the language switch did not work too well for me. Inkscape in most cases does not allow to change formatting or text inside a switch. I can ungroup and then edit the text elements, but then the switch is lost. A problem with having to work in the text editor for me was that tspan role=line are rendered differently in Inkscape and Commons; I had to split them into separate text. Which tool beyond text editor are you using? -- If you can improve the graph further I am grateful! --Gregor Hagedorn (talk) 02:35, 31 October 2018 (UTC)
@Gregor Hagedorn: Your comment and some comments that JoKalliauer made about how he edits switch-translated SVG troubles me. If Inkscape cannot edit such files easily, then there is little hope that other graphics editors can edit them. Using graphics editors after switch translation was a design issue, but I fear the issue has been dropped or overlooked.
On another front, the "Well to Wheels" image is misleading. The energies E are displayed as circles with radius proportional to E. Viewers judge the circles by their areas, which are proportional to E2, so they get a distorted perception. The radii should be scaled by the √E so the areas are proportional to E. Alternatively, the diagram could be done with flows whose widths are proportional to E. Johannes edited such a file at File:Breakdown of the incoming solar energy.svg. Glrx (talk) 17:20, 31 October 2018 (UTC)
Thanks @Glrx:! Your point about radius vs. area is valid and it would be nice to change. I like the circle style better than the Breakdown graphic, but both would do. I wish I had better tool with which I successfully create and edit SVG content! It is a pity that it is so difficult to export Wikimedia-compatible-svg from MS or LibreOffice! --Gregor Hagedorn (talk) 00:31, 1 November 2018 (UTC)
how to change the language
@Gregor Hagedorn, Glrx: Sorry! I found out[3] that is possible to change the <switch>-language: you have to change the GUI-Language and restart Inkscape.
@Glrx: I think outside von Commons switch-svgs seems to be very rare, since in most cases only SVG are only needed in one language.
 — Johannes Kalliauer - Talk | Contributions 09:43, 1 November 2018 (UTC)
Very helpful! In fact, more than you think. Just for the record: On my Inkscape installation the default setting "system language" actually caused that NO language/switch text was displayed at all (I live in Germany but use an English version of Windows). After I changed Inkscape Prefs to en + restart, I can now see en text. --Gregor Hagedorn (talk) 12:21, 1 November 2018 (UTC)
Danke, Johannes. That allows at least one method of editing the language, but it is sounds like it changes the user interface as well as which systemLanguage is displayed. I suspect that most commercial websites l10n their SVG files rather than i18n them. It keeps the file size smaller (no translation baggage), and l10n allows almost any graphics editor to work on the file (the files have no switches).
@Gregor Hagedorn:. I believe you should have seen text in your original configuration if File:Well to Wheels (kWh).svg had a default clause for its switches. I started to add the defaults yesterday, but the clauses had a lot of style and position information, so I went on to other tasks. Glrx (talk) 17:08, 1 November 2018 (UTC)

File:Элемент плана Красногвардейска 1939 года на экране монитора.JPG and othersEdit

Hi, please don't empty source field and don't remove license. If you think there is a copyright problem, nominate for deletion instead. Jcb (talk) 16:25, 1 December 2018 (UTC)

(talk page stalker) @Jcb: Where are policies about {{dw no source since}}? May it be used with {{own}}? Incnis Mrsi (talk) 17:00, 1 December 2018 (UTC)
(EC)That may be the case, but the edit of JoKalliauer moves the problem instead of solving it. If there is a copyright problem, a file should be nominated for deletion via tag or DR. By removing the license and emptying the source field, the file falls into the Category:Media without a license: needs history check and Category:Images without source maintenance categories. Jcb (talk) 17:01, 1 December 2018 (UTC)
@Jcb: Thanks for telling me, I tried to move the problem into a more correct problemcategory.
The work by Carlosjuradob who uploaded about 23 screenshots of AutoCAD was in my opinon below treshold, so in my opinon AutoCAD is the (main) autor, therefore the source should clarify the source of the software not of the screenshot, and the license is even more wrong, since AutoCAD ist not free content, therefore you cant publish under CC-BY-SA.
I recommended User:Carlosjuradob to starte a DR at their pictures: User_talk:Carlosjuradob#illegal publishing of AutoCAD-Screenshots.
I thougt I do not start a DR because:
Therfore the permission was missing, maybe Template:No_permission_since would be more correct?
 — Johannes Kalliauer - Talk | Contributions 17:43, 1 December 2018 (UTC)
Yes, {no permission since} would be fine. I have speedy deleted the screenshots as copyright violations, there is no way that Autodesk is going to give there permission for these files. (I know this company a bit, I work with AutoCAD and several other Autodesk products). Jcb (talk) 22:37, 1 December 2018 (UTC)

Problem mit File:Drini nonuniformconvergence SVG.svgEdit


Hallo Jo, du hattest da ne neue Version von erzeugt, die einen gewaltigen Fehler enthält: Die rote Grenzfunktion ist bis auf einen Punkt nicht mehr zu sehen! Die x-Achse sollte bis auf bei pi/2 rot sein. Ein weiterer kleiner Schönheitsfehler: Eine der grünen Funktionen geht rechts noch weiter. Und eigentlich fand ich die Beschriftungen der blauen Funktionen auch hilfreich... Könntest du das wieder fixen? AB, --χario 14:29, 11 December 2018 (UTC)

@Xario: Der source-code ist unsauber. Die Grafik wurde erstellt wobei die Achsen unterschiedliche Längen haben, dann wurde das in Inkscape anscheinend verzerrt und das was man bei Gnuplot vergessen hat in Inkscape hinzugefügt.
Ich hab die Elemente aus der Originaldatei 1:1 hineinkopiert und dann eine Verschiebung und Verzerrrung draufgehaut, dass es optisch etwa dort ist wo es hinsollte, wenn man genauer schaut sieht man Fehler.
 — Johannes Kalliauer - Talk | Contributions 18:00, 11 December 2018 (UTC)
Oh wow, das war ja blitzschnell, vielen Dank!!! Verstehe ich dich richtig, dass auch wenn die Grafik jetzt richtig aussieht, sie eigentlich Hacks/Workarounds enthält und im Grunde komplett neu gemacht werden müsste? Meinst du, es würde was nützen, das bei der Dateibeschreibungsseite (oder der Disk?!?) zu vermerken? So das vielleicht irgendwann mal jemand das machen könnte, wenn ihm/ihr langweilig ist? --χario 09:32, 12 December 2018 (UTC)
Zu der Unsauberkeit:
  • Die Elemente die in der von dir genannten Version gefehlt hatten, waren in Inkscape drüber gezeichnet, dies sollte man besser in Gnuplot selbst machen, aber es ist nicht falsch und ist in der aktuellen Datei noch immer so. Hierbei habe ich jedoch die betreffenden Elemente einfach hineikopiert und so verzerrt dass es in etwa passt, das gehört sauber gemacht.
  • Die Skalierung auf der x-Achse und auf der y-Achse waren nicht gleich lang (in Gnuplot falsch erzeugt und dann nochmals in Inkscpae "verunstaltet"), dies habe ich korrigiert.
Bezüglich der von dir geannten Kritik:
  • Meines Erachtens ist der vertikale rote Strich falsch: es gibt keinen x-Wert der auf den Bereich (0,1) abbildet (0 und 1 ausgenommen)
  • Die beiden horizontalen Striche sind ebenfalls falsch, weil
    • sie einen endlichen Bereich rund um pi/2 nicht da ist. (Man sollte vl. so ein symbol wie in File:Discontinuity-jump.svg einfügen)
    • Die Grünen und blauen Linien sind hinter der Achse, also sollten die roten Sriche auch hinter der Achse verschwinden.
  • Es ging nicht eine grüne Funktion rechts weiter sondern alle (die ungeraden Potenzen wie sin(x) verschwinden im negativen und Potenzen größer 3 verschwinden hinter der x-Achse), dies ist korrekt, sie auhören zu lassen wäre falsch (außer man schrenkt den Definitionsbereich ein, was nicht explizit gemacht wurde)
Die Beschriftung wegfallen zu lassen ist nicht gut, aber nicht falsch. Imzuge der anderen Korrekturen fand ich das nebensächlich. (Richtigkeit geht bei mir vor Verständlichkeit/Schönheit.)
Also die aktuelle Version ist wieder falsch weil die rote Grenzfunktion nicht zu sehen sein sollte.
Der source-code in Gnuplot gehört weiter überarbeitet (die grawierendseten Mängel habe ich behoben), sodass keine manuelle Nachbearbeitung notwendig ist. (bzw. sollte die Nachbearbeitung zumindest neu gemacht werden), dies anzumerken ist sicher nützlich.
@Incnis Mrsi: Was war deine Motivation die Grafik die seit fast einem Jahr unbekümmert vorlag "sofort" zurückzusetzen und oben geannte Fehler wieder einzuführen anstatt eine aktuelle Diskussion abzuwarten?
Hast du das Gefühl, dass ich keine gute Arbeit mache, bzw Dinge unbegründet mache, bzw. mir nur aus Unachtsamkeit unterlaufen ist?
 — Johannes Kalliauer - Talk | Contributions 19:02, 12 December 2018 (UTC)
Hallo, danke fürs ausführliche Antworten:
die Vertikale: Ohje, ich scheine völlig verdrängt zu haben, dass die existiert(e). Ja, die sollte def. weg. Die Idee mit dem Sprungpunkt hatte mit auch schon vorgeschwebt.
die Horizontale: Ob nur die vor der Achse ist finde ich nicht wild. Die falsche Lücke wäre, wie du schon sagst, am besten mit nem Sprungpunkt zu versehen. Mein Ansatz, warum ich dich angeschrieben hatte, war dass überall auf der Beschreibungsseite und in Artikeln immer von "der roten Grenzfunktion" die Rede ist - aber davon sah man eben nur noch einen einzelnen Punkt.
Schrift: Wenn ich das Bild in groß ansehe (auch alte Versionen), sieht das sin hoch 100 aus wie sin mal 100.
Definitionsbereich: Ich dachte einfach wieder annen symmetrischen Bildausschnitt.
Generell: die Datei ist nicht wirklich ideal: Warum sind gerade zwei aus der Funktionenschar in blau rausgehoben und dicker? Die grünen sehen so aus, als konvergierten sie gegen sin^10, diese große Lücke zwischen sin^20 und sin^100 und dann der Vertikalen machts auch nicht wirklich besser.
Hast du denn überhaupt noch Lust, die mit der Datei zu beschäftigen? Denn wenn nicht, würde ich diese ganzen Punkte bei der Disk der Dateibeschreibung erwähnen. Und ich stimme dir natürlich zu, das plötzliche Zurücksetzen war so hilfreich wie ein Kropf. --χario 11:15, 13 December 2018 (UTC)
Ich habe vor mich noch etwas damit zu beschäftigen. Wenn ich fertig bin, verständige ich dich.
Bezüglich User:Incnis Mrsi: Sie/Er beobachtet meine Disk und beantwortet für mich regelmässig Fragen und ich bin ihr/ihm dankbar dafür.
Und ehrlichgesagt sollte ich insgesammt sorgfältiger arbeiten. Ich will es nur explizit ansprechen/wissen, was der konkrete Hintergrund ist, bzw. ob das einen tieferen Sinn/Grund hat.
 — Johannes Kalliauer - Talk | Contributions 18:40, 13 December 2018 (UTC)

New bug?Edit

Hi. There's a recently uploaded SVG (SHSG coat of arms.svg), which disappears almost entirely below a certain size.


The image consists of linear gradients, groups and paths. I don't remember seeing this particular bug before. Do you recognize it? TilmannR (talk) 05:40, 5 January 2019 (UTC)


A related file has the same problem at a sightly different size. TilmannR (talk) 06:47, 5 January 2019 (UTC)

@TilmannR: I don't know this bug, and Commons:Commons_SVG_Checker renders much worse, therefore I would have to upload severals tests. Inkscape/Scour/SVGO/svgcleaner fixed the file, I don't know how. (@Glrx: knows more about SVG than me, @Perhelion: knows also many bugs and User:AKlapper_(WMF) reads all phab: tasks.)  — Johannes Kalliauer - Talk | Contributions 21:06, 5 January 2019 (UTC)
@JoKalliauer: I found out why the Checker stops rendering the file at some point: There's a gradient with gradientTransform="matrix(0 0 0 0 393.46 518.57)". Commons SVG Checker: SVG edge case - zero scale gradient.svg TilmannR (talk) 20:30, 8 January 2019 (UTC)
@JoKalliauer: Just having some fun: Identify renderer.svg :) Of course we could distinguish librsvg and browsers based on how they handle CSS and embedded raster graphics, but thanks to zero-scale-gradients we can show different images on two popular browsers and the Checker and Commons, using only a single weird SVG rendering edge case. TilmannR (talk) 22:16, 8 January 2019 (UTC)
@JoKalliauer: Remember how SHSG coat of arms.svg had a broken thumbnail? When gradients simply have a gradientTransform with a scale of zero, the SVG Checker version of librsvg dies and the Wikimedia version of librsvg survives. Therefore that specific bug couldn't have caused the broken thumbnail. I did some more experiments and found that Wikimedia's librsvg also dies, when a gradient is applied to an object of size zero. Apparently this also happens, when the image resolution, the object size and the gradient scale are small enough that the effective gradient size gets rounded down to zero. There's also a case where applying a gradient to the fill of a straight line breaks the rendering, but that requires more research. I also came across a case where rendering works at a small resolution and fails at a higher resolution. It continues to fail up to a certain size and then works again. My guess is that rounding errors cause the path to alternate between being a straight line and a very thin triangle.
Question: Is there a template for displaying old, overwritten versions of files? TilmannR (talk) 12:41, 9 January 2019 (UTC)
Identify renderer.svg Really interessting: In Firefox/Chrome if you mark it you copy everyting :-) :)
InternetExplorer/MicrosoftEdge renders just black.
Gimp/UbuntuFolderPreview renders as Wikipedia Commons (they are using librsrvg)
As far as I know there is no way of displaying old versions in Wikimedia (direcly) without uploading again.
 — Johannes Kalliauer - Talk | Contributions 17:28, 9 January 2019 (UTC)

PDF burningEdit

বাংলা | Deutsch | English | Español | Français | Italiano | Македонски | മലയാളം | मराठी | Português | Русский | Sicilianu | Svenska | +/−

Hello. This message is being sent to inform you that there is currently a discussion at Commons:Administrators' noticeboard/User problems#JoKalliauer and attribution chain. This is in relation to an issue with which you may have been involved. Thank you.

Incnis Mrsi (talk) 21:12, 13 January 2019 (UTC)

@Incnis Mrsi: Did you mean the attribution of the picture or of the description page?  — Johannes Kalliauer - Talk | Contributions 21:22, 13 January 2019 (UTC)

Eintragː Dieses SVG-Bild enthält eingebettete Rastergrafiken...Edit

Servus JoKalliauer,

Eintrag in 01-Parabelzirkel-van Schooten-Nachbau.svgː Dieses SVG-Bild enthält eingebettete Rastergrafiken....

Ich bräuchte wieder deine Hilfe. Die von mir hochgeladene Datei wurde in GeoGebra erstellt und als Skalierbare Vektografik (svg) (wie alle meine Konstruktionen) exportiert. Ich habe alle in Commons verfügbaren Auflösungen zu dieser Datei angesehen, sie zeigen alle ein scharfes Bild. Was ist noch erforderlich, damit die im Eintrag Dieses SVG-Bild enthält eingebettete Rastergrafiken... aufgeführten Hinweise erfüllt sind? Gruß--Petrus3743 (talk) 19:11, 24 February 2019 (UTC)

@Petrus3743: Die rote Parabel ist eingebettet:
kopiere Folgenden Text und füge es in die Adressleiste deines Browsers ein:
schau dir mal die Rote Parabel bei an, die Parabel ist nicht scharf
 — Johannes Kalliauer - Talk | Contributions 20:01, 25 February 2019 (UTC)
Ja, Johannes Kalliauer, danke für deine Bemühungen, jetzt sehe ich es auch. M. E. muss man unterscheiden, ob die Kurve z. B. von GeoGebra durch Berechnung erzeugt wurde, dann bleibt sie scharf File:01-Parabelzirkel-van Schooten-Basis.svg, oder unter „Algebra“ mit „Zahl, Animation ein“. Eine solche Kurve wird quasi Punkt für Punkt erstellt und wird bei sehr starker Vergrößerung unscharf File:01-Hyperbelzirkel-van Schooten.svg. Dies ist auch bei Animationen als GIF-Datei erkennbar File:01-Parabelzirkel-Animation.gif oder File:Parametric ellipse.gif. Es ist anzunehmen das dieser Effekt auch in einer PNG-Datei zu sehen ist. Die Frage ist auch, ob eine so starke Vergrößerung noch notwendig ist. Ich weiß keine Möglichkeit wie man dies verhindern kann.--Petrus3743 (talk) 22:25, 25 February 2019 (UTC)
@Petrus3743: Wenn {{Bad SVG}} eingeführt wird ist das nicht weiter wichtig, es ist nur eine Information, aber kein Grund etwas zu ändern.  — Johannes Kalliauer - Talk | Contributions 22:49, 27 February 2019 (UTC)
@JoKalliauer:, danke für diese Info. Gruß--Petrus3743 (talk) 23:01, 27 February 2019 (UTC)
@JoKalliauer:, ist mir erst jetzt aufgefallen, wie hast von diesem File:01-Parabelzirkel-van Schooten-Nachbau.svg die eingebetteten Rastergrafiken so gut entfernt? Ein Dankeschön dafürǃ Vielleicht kann es beim folgenden Bild auch probieren File:01-Parabelzirkel-van Schooten-Prinzipskizze.svg. Servus --Petrus3743 (talk) 00:06, 1 March 2019 (UTC)
@Petrus3743: Das kannst du in Inkscape [4] auch leicht selber machen: Bild markieren und dann auf Pfad > Bitmap nachzeichnen[5] gehen. Und für diesen Fall würde ich "Helligkeitschwellwert"(Standard) mit Standart-einstellungen nehmen.  — Johannes Kalliauer - Talk | Contributions 07:53, 1 March 2019 (UTC)

Problems with multi-language detectionEdit

Hi. Europe regions minimal cities.svg didn't show the language selection widget "Render this image in [English (en)] [Go]". My guess was that Commons is looking for <switch> elements containing <text> elements and the file contains <switch> elements containing <g> elements. But I found that SystemLanguageLayers.svg has a very similar structure and it doesn't have the same problem. Do you know anything about this? How does Commons determine whether a file is multilingual or not? TilmannR (talk) 20:03, 27 February 2019 (UTC)

I hope it works.
 — Johannes Kalliauer - Talk | Contributions 20:47, 27 February 2019 (UTC)
@JoKalliauer: Well, I tried to purge test.svg, but got a "Service Temporarily Unavailable" in return. And this doesn't look like a caching problem to me. At least test.svg reliably switches back and forth between having and not having a language selector. For now I'll continue to try to create a minimal file with <switch> and without language selector. Wish me luck. :) TilmannR (talk) 20:58, 27 February 2019 (UTC)
@TilmannR: Purging Test.svg will lead to a rendering of >2000 Files. Rendering of one single file (such as File:Dojikko2.3.svg lead to an overload to the server. Therfore purging test.svg is a bad idea. Currently it is not even possible to delete Test.svg, see File_talk:Test.svg.
@JoKalliauer: Oops. TilmannR (talk) 21:12, 27 February 2019 (UTC)
However, on my computer Europe regions minimal cities.svg shows the language selection widget "Dieses Bild in [Englisch (en)] rendern. [Los]".
 — Johannes Kalliauer - Talk | Contributions 21:09, 27 February 2019 (UTC)
Yes, that's after I've uploaded a fix, which has a <switch> at the beginning of the file. My current hypothesis is, that Commons only looks at the first 256kB of a file to determine whether it's multilingual or not. TilmannR (talk) 21:12, 27 February 2019 (UTC)
Yeah. I'm pretty sure now that that's the cause. What do we do about it? It's not really a bug. It's just a poorly documented attempt to limit the amount of work done during multi-language detection. Should we mention this on the various SVG help pages? It doesn't seem to be a common problem. TilmannR (talk) 21:22, 27 February 2019 (UTC)
Sorry I did read read didn't (past). My mistake, that's the reason why I thought about cache.
I would make a phab:-Report. Only if they are imporant and/or less work they will be implemented. If someone has a problem, you can refer to the report for more infos. (or can be found with a search engine)
Since it is not that common, I would not report it on any help-page. I would keep the helppages quite tight, only with the most important info, otherwise they won't be read.
I would say @Glrx: is the biggest expert for multilangual files on commons, he probabily knows more, or has a better opinion than me.
 — Johannes Kalliauer - Talk | Contributions 22:07, 27 February 2019 (UTC)
(e/c) MW parses the SVG file and looks for systemLanguage attributes; it does not look for switch. See source around line 266. Yes, metadata extraction only looks at the first 1/4 megabyte. See $wgSVGMetadataCutoff documentation. It is not a common problem; I've only run into it a couple times. Glrx (talk) 22:15, 27 February 2019 (UTC)

Begoon noticed that $wgSVGMetadataCutoff is mentioned on Help:Translation_tutorial#Language_matching_rules. Of course it's easy to miss such a small note among the vast amount of reading material that a newcomer has to work through. I therefore requested for the SVG Checker to emit a warning, when a file might have this problem. TilmannR (talk) 14:09, 28 February 2019 (UTC)

Fixing phab:T35245 in (R)-Citronellal Structural Formula V.1 1.svgEdit

Hi. is having trouble converting their files from ChemDraw to SVG. This specific problem can be solved by iteratively replacing (<tspan[^>]* x=")([^ "]+) ([^"]+)("[^>]*>)(.)([^<]+)(</tspan>) with \1\2\4\5\7\1\3\4\6\7, but I don't know how to wrap that into a user-friendly script that runs on Mac OS. Do you happen to be familiar with Mac or do you know anyone, who is? Thanks. TilmannR (talk) 14:12, 16 March 2019 (UTC)

You (and @:) can use or should it run in terminal and/or offline?
sed -ri 's/(<tspan[^>]* x=")([^ "]+) ([^"]+)("[^>]*>)(.)([^<]+)(<\/tspan>)/\1\2\4\5\7\1\3\4\6\7/g' filename.svg is a nice code, I use a similar code in my code, maybe I'll change it (and name you and this URL in a comment of the source code).
@TilmannR: I don't have Mac, therefore I can't test it and I don't know the problem. I took a short look at and . And I think the options are different and there is no --regexp-extended?
 — Johannes Kalliauer - Talk | Contributions 21:31, 17 March 2019 (UTC)
@JoKalliauer: When I upload (R)-Citronellal Structural Formula V.1 1.svg to SWAB (SvgWorkAroundBot), the "Convert to SVG" download yields a completely unmodified file. Can you replicate this? Is SWAB currently inactive? Would the GUI show any kind of error message, if something went wrong?
Okay, I now know that SWAB can't handle Inkscape SVGs. Why can't it? And please display an error message or at least mention such a strong limitation on its website.
If you want to use that regex in a general purpose tool, you need to be careful about the whitespace. E.g. <tspan[^>]* x=" won't match, if x is preceded by a tab or line break. It also doesn't handle comma-separated coordinates. (<tspan[^>]*\sx=")\s*([^\s,"]+)[\s,]+([^"]+)("[^>]*>)(.)([^<]+)(</tspan>) might work, but I didn't test it.
I don't know whether Jü uses the terminal and/or whether they are working offline, but anyone who uploads images to Commons has to be online at least sometimes. :) TilmannR (talk) 00:14, 18 March 2019 (UTC)
I will take a look at it. Yesterday it worked, but on my computer it shows the line breaks differnelty than in my browser.
The reasion why Inkscape-SVG don't work ist because of the line breaks. Sed only reads per default line-by-line. I will change the code.
 — Johannes Kalliauer - Talk | Contributions 07:40, 18 March 2019 (UTC)
@TilmannR: Firefox changes the carriage return(\r)/newline(\n) on Windows as well on Ubuntu, therefore when I download everything works. With wget the download seems to work, but then swab does not work. I assume the file contains carriage return as well as newline, therefore FF thinks it is Windows-formated and deletes all carriage returns without newlines, but since it was created on Mac most linebreaks are carriage returns.
However I decided to remove all carriage returns completely and replace all newlines (including following spaces) with a single space repaired, so swab (nice name ;-) ) should work now even for "Inkscape SVG (*.svg)"s.
Since my Operating System/Browser seems to modify the file while downloading, can you please check if it works now?
 — Johannes Kalliauer - Talk | Contributions 16:30, 18 March 2019 (UTC)
Great. It seems work now. TilmannR (talk) 18:49, 18 March 2019 (UTC)

Neue Dateiversion hochladen?Edit

Servus JoKalliauer, zunächst mal vielen Dank für die Anfertigung der Grafik Dynamische_Radlastverlagerung.svg. Bevor ich dich weiterhin mit meinen neuen Änderungswünschen erschrecke, habe ich es selber versucht. (Meine neue Version ist primitiver und nicht mehr unbedingt 100% korrekt. Alles was vom Thema ablenkt wurde weggelassen). Ich weiß allerdings nicht, wie man eine neue Datei-Version hoch lädt (in der Hilfe finde ich dazu nichts). Vermutlich muß ich hier den Hochlade-Assistent benutzen. Doch was trage ich in den einzelnen Abfrage-Feldern ein? --Q42xp (talk) 20:06, 19 March 2019 (UTC)

@Q42xp: Der Hochlade-Assistent ist praktisch für neue Dateien/neuen Dateinamen. Commons empfiehlt im Regelfall eine Neue Datei zu erstellen, siehe Commons:Overwriting_existing_files/de.
Jetzt zum kontkreten Fall: Gehe auf File:Dynamische_Radlastverlagerung.svg#filehistory, dort steht unter der Tabelle (und über Dateiverwendung) "Eine neue Version dieser Datei hochladen" (zumindest im Österreichischen Deutsch, in anderen Sprachen sollte etwas ähnliches stehen.)
 — Johannes Kalliauer - Talk | Contributions 20:13, 19 March 2019 (UTC)
Jetzt hat‘s geschnackelt. Aber wie kommst du auf die Seite „#filehistory“? Wenn ich die Seite direkt aufrufe, steht da: „Du kannst diese Datei nicht überschreiben.“ und nicht: „Eine neue Version dieser Datei hochladen“. Anscheinend ist Wikimedia nur was für Insider.
Dummerweise gibt es ein neues Problem: Ich habe mir gerade mein svg im Internet-Browser angesehen. Gegenüber der Ansicht in Inkscape ist die Beschriftung leicht nach rechts verschoben. Soll ich das svg trotzdem hochladen und kannst du das dann berichtigen (so dass es gefällig aussieht)? --Q42xp (talk) 20:52, 19 March 2019 (UTC)
Entweder du warst nicht angemeldet, weil nur angemeldete Nutzer können hochladen, oder nur erfahrene Nutzer dürfen Dateien überschreiben. Neulinge überschreiben oft Dateien und sollten sie aber unter einem neuen Namen hochladen. (Ich fand auf die schnelle nichts dazu.)
Lösungsvorschlag: Du ladest es unter einem neuen Namen mit dem Hochladeassitenten hoch oder du schickst es mir per Mail ( ) und erlaubst mir diese Arbeit unter CC-BY-SA 4.0 hochzuladen.
 — Johannes Kalliauer - Talk | Contributions 21:13, 19 March 2019 (UTC)
Ich hab’s jetzt einfach hochgeladen. So halbwegs passt es. Falls du Lust und Laune hast, kannst da ja nochmal drüber gehen. (Die Dateibeschreibung passe ich morgen an)--Q42xp (talk) 21:30, 19 March 2019 (UTC)
@Q42xp: Die Summe der Horizontalkräfte ist nicht Null. Das   entsteht genau durch den Versatz der beiden Horizontalkräfte, daher finde ich solltest du irgendwo auf Straßenniveau eine Horizontalkraft nach rechts zeichnen. (Kräfte darf man (bei starrkörpern) entlang der Wirkungslinie verschieben und daher ist es "egal" ob die kraft beim Hinterreifen oder beim Vorderreifen angreift.)  — Johannes Kalliauer - Talk | Contributions 21:55, 19 March 2019 (UTC)
Die Bremskräfte an der Kontaktstelle Reifen-Straße habe ich deshalb weggelassen, weil es im Dubbel hierzu eine vergleichbare Skizze gibt, in der diese Kräfte ebenfalls nicht eingezeichnet sind (Du findest diese Skizze, wenn du nach „dynamische Achslastverlagerung Dubbel“ googelst und dann auf den Reiter „Bücher“ umschaltest) Mein Ziel ist, die Grafik möglichst einfach zu halten. Aber ich stimme dir zu, vielleicht wäre es tatsächlich besser diese Kräfte wieder einzuzeichnen. Ich hab mal eine korrigierte Fassung hochgeladen.
Allerdings gibt es bei mir immer noch auffällige Unterschiede zwischen der Darstellung in Inkscape und in diversen Internet-Explorern. Sowohl im Firefox als auch beim Microsoft-IE erscheint in der Formel zu   ein Leerzeichen vor dem Malzeichen. Alle tief gestellten Zeichen werden wesentlich weniger tief dargestellt. Das schaut dann eher aus wie Kleinbuchstaben. Spaßeshalber habe ich das SVG auch mit „Libre Office“ geöffnet. Da wird praktisch die Hälfte gar nicht dargestellt. Die tiefgestellten Zeichen fehlen komplett und den Pfeilen sind die Pfeilspitzen abhanden gekommen. --Q42xp (talk) 20:27, 20 March 2019 (UTC)
Nachtrag: Jetzt nachdem ich das SVG in Wikimedia hochgeladen habe, schaut es dort genauso aus, wie es soll. Das falsche Leerzeichen vor dem Komma ist weg und die tiefgestellten Zeichen sind tiefgestellt. Mir sind diese SVG ein Rätsel.--Q42xp (talk) 20:52, 20 March 2019 (UTC)
@Q42xp: No software can render SVGs, that are according to the official Standart (2011) correclty.
RazFalcon did an awesome work, which software can render which file correclty. Since Internet Explorer (IE) is a very bad renderer it is not considered.
I corrected more than 1000 SVGs, which were not rendered correclty on Wikimedia, some of them can be found on User:JoKalliauer#Repairing_damaged_SVGs_(minor_edits).::::Wrong rendering does not necesarryly mean, that there is something wrong with your file.
On my Computer IE renders the file correclty. Which Version of IE do you have?
Since every render has its own errors:  , renders differnetly on
  1. "Firefox"
  2. "Chrome or Inkscape"
  3. "SVG Checker"
  4. "Wikimedia Commons"
  5. Internet Explorer
but it should render the same.
 — Johannes Kalliauer - Talk | Contributions 21:51, 20 March 2019 (UTC)
Ich ging fälschlicherweise davon aus, dass der Browser beim Aufruf einer Wiki-Website mit SVG-Grafik eine SVG–Datei erhält und daraus eine Pixelgrafik berechnet. Anscheinend wird dem Browser jedoch von der Wiki-Website eine PNG-Datei übermittelt. Wenn dem so ist, ist es egal wie ein Browser SVG-Dateien darstellt, da er ja keine erhält. Meine Aufregung darüber, dass unterschiedliche Browser dieselbe SVG-Datei unterschiedlich darstellen war also für die Katz. Nochmals Danke für deine sehr hilfreiche Unterstützung. (Die Grafik füge ich heute in den Artikel ein) Nichts für ungut. --Q42xp (talk) 21:01, 25 March 2019 (UTC)

Full bucket.svgEdit

Hallo Johannes, wenn ich irgendeinen SVG-Code vereinfache macht mich das noch lange nicht zum (Co-)Autor; ausserdem steht meine UserID ohnehin in der Upload-history, also käme es mir nicht in den Sinn mich da noch gross irgendwo als Urheber einzutragen! Es steht aber nicht dafür diese Eintragung wieder zu löschen.
Auch den Text in Empty bucket.svg (du hast gemeint diese Datei verbessern zu müssen) habe ich nicht signiert - es ist schliesslich kein Diskussionsbeitrag; und in der history bleibt ohnehin ersichtlich, dass er von mir stammt. mfg -- sarang사랑 08:44, 21 March 2019 (UTC)

@Sarang: Das sehe ich genau umgekehrt! Ich sehe dich als Hauptautor, der aktuellen Datei. Also "jeder" kann 3 Striche zeichnen und die mit einer Kontour füllen, insofern sehe ich keine Schöpferische Leistung von Rodrigo.Argenton.
Hingegen du hast den Code auf seine knappeste Essenz zusammengekürzt, das können in diesem Ausmaß nur wenige (da fallen sofort alle die keinen SVG-source-code lesen können, weg, das sind die meisten. Und von denen die SVGs lesen können, können auch ein großteil nicht so gut SVGen wie du). Des weiteren hast du dein kluges Köpfchen verwendet und festgestellt, dass es optisch ident ist, wenn die Striche die gleiche Farbe haben, sie ja eigentlich gar nicht "sieht" und sie zum Pfad dazurechnen könnte. Damit hast du auch die Doppelecken rechts oben und links oben behoben.
Ich glaube für dich ist das was du machst schon so klar, dass du gar nicht weißt, wie ausergewöhlich deine Fähigkeiten sind.
Wenn wir uns Empty bucket.svg anschauen:
  1. Ist von meiner Bearbeitung nichts mehr da, also sehe ich mich zu 0% Mitautor an der aktuellen Datei.
  2. Wäre die Version von 13:34, 28. Okt. 2017 die aktuelle, dann wäre eher die Autoren von scour, svgcleaner, svgo die Autoren als ich.
Wie auch immer beide Dateien sind eigentlich {{Pd-shape}} einzukategorisieren, somit gibt es gar keine Urheber. Weil einen Urheber kann es erst dann geben, wenn eine Schöpfungshöhe vorhanden. Wo nichts gemacht worden ist, kann jeder sagen er hat das "Nichts-Werk" gemacht und gleichzeitig kann jeder auch sagen er hat nicht am "Nichts-Werk" beteiligt.
Also eine Autorfrage bei etwas was keine Schöpfungshöhe hat, ist meiner Meinung nach sinnlos (oder mir zu philosophisch).
Selbst wenn ich hinschreibe "Die Queen von England" hat es erstellt ist es (Urheberrechtlich) nicht falsch, weil es Public Domain ist und somit jeder es als sein eigenes Werk reklamieren kann.
Konkret habe ich die Autoren in eine (für mich) wahrhaftere Formulierung gebracht, weil ich das Bild auf verwendet habe und dort die Autoren genannt habe.
Also ich wollte die Datei haben, weil sie eben so kurz ist, also eigentlich gibt es mir nicht um das Dargestellte sondern um den kurzen Code. (Ich weiß noch nicht inwiefern Rodrigo.Argenton Dateien geeignet sind als Minimal working Example, mit kürzestmöglichen Code, zu verwenden.)
 — Johannes Kalliauer - Talk | Contributions 18:14, 21 March 2019 (UTC)

Ok, das ist eine andere aber durchaus verstandliche Sichtweise, an der ich nichts bemangeln kann oder will. Ich neige zwar dazu meine Ideen und mir richtig erscheinenden Ansichten - nein, niemandem aufzuzwingen aber doch deutlich zur Diskussion zu stellen; aber eher nicht mich selbst allzu wichtig zu nehmen. Es gibt keine Dateien in deren Beschreibung 5mal die userID sarang zu finden ist (sowas gibt es ofter mit anderen UserIDs), oder Kategorien mit meinem Namen... Obwohl auch das durchaus Sinn und Berechtigung haben kann. Also bin und bleibe ich Co-Autor eines vollen Bechers. Das nehme ich doch gleich zum Anlass, mir hier auch einen Becher zu fullen (aber lieber nur halb) -- sarang사랑 18:37, 21 March 2019 (UTC)

Ubrigens, schau genau, beim Empty bucket.svg ist deine Version vom 28. Okt. 2017, 13:34 die aktuelle!
Und es gibt sehr of bombastische Lizenzen fur eindeutig ineligible Erzeugnisse....

BOT requestEdit

Hallo Johannes, du kannst doch auch bot? Ich hab in Commons Maint tincture code error >300 Dateien entdeckt, und soweit ich sehen konnte haben alle denselben Fehler: statt zB |Tincture=a/o/b steht dort |tincture={{tincture|a|o|b}}. Das liesse sich sogar mit VFC und regularem Ausdruck reparieren. Kannst du das? Oder weisst du jemanden der das kann? -- sarang사랑 17:05, 28 March 2019 (UTC)

Ich hätte als erstes an User:Sarangbot gedacht, aber wenn du mich fragst kann der bot das anscheinend nicht.
Ich kann
  1. mit Imker eine Kategorie auf meinen Laptop herunterladen
  2. wenn man die Dateinamen eingibt die Datei (auf Toolforge oder lokal) herunterladen
  3. die Datei (auf Toolforge oder am Laptop) bearbeiten
  4. die Datei unter den jeweiligen Dateinamen hochladen(überschreibt)
Jedoch weiß ich (noch) nicht wie man Dateibeschreibungen automatisiert bearbeitet. (vl. lese ich mich da jetzt anlassbezogen ein, wäre ohnehin nützlich; Schau mir das noch an, melde mich wenn das dann noch aktuell ist und nicht erledigt wurde.)
Für meinen Bot habe ich noch keinen Botflag angesucht, wollte es mal bei wenigen Dateien probelaufen lassen (die ich manuell nachkontrolliert habe) und dann darum ansuchen.
Alexis Jazz hat Fake SVGs to pngs konvertiert und die Dateibeschreibung "mitkopiert". Das hat er vermutlich atomatisiert gemacht, aber er hat meines Wissens keinen bot-account.
 — Johannes Kalliauer - Talk | Contributions 18:08, 28 March 2019 (UTC)
Danke, dann mach ich mal eine „quick & dirty“ Reparatur; ev. kann das spater mal richtig repariert werden. Btw, Sarangbot ist kein bot, nur eine Sockenpuppe. -- sarang사랑 19:32, 28 March 2019 (UTC)

Kategorisierung CC-BY-ND.svgEdit

Hallo Johannes, du hast diese Logos sehr gut simplifiziert. Die main_category SVG Simplified ist (von mir) vorgesehen fur einige wenige sehr pragnante Beispiele von Vereinfachungen, vor allem wenn die neue Version weniger als 5% der Vorversion hat. Deshalb passen deine Logo-Reduktionen gut hierher - aber nur einmal, nicht alle sechs! Alle sind in der Unterkategorie SVG simplified logos versammelt, und das eine mit der besten Relation von 0.54% zusatzlich in der Hauptkategorie - die ubersichtlich bleiben soll. ok? -- sarang사랑 10:19, 30 March 2019 (UTC)

Achso, mir nicht so wichtig. Ich habe vor heute; SVG Simplified noch nie gesehen, also wenn du Kategorieänderungen vornimmst, nur zu!! Ich finde jedoch ich mein Beispiel kein so gutes Beispiel, weil die Löschung von Adobe Illustrator pgf CDATA Blöcken ist für mich eine irrelevante Vereinfachung, diese wird selbst botmässig auf durchgeführt.
Also es war Unwissenheit meinerseits.
 — Johannes Kalliauer - Talk | Contributions 16:25, 30 March 2019 (UTC)
Wenn du meinst. Vielleicht sehe ich mal, was da vereinfachbar ist - nur so aus sportlichem Ehrgeiz... wie wenn es nicht genug anderes zu tun gibt.
Nur so zur Erinnerung fur dich: Es ist sehr sinnvoll, andere vom Hochladen neuer Dateien mit CDATA und anderem Mull abzuhalten, falls sie sich bekehren lassen. Hingegen bringt es wenig, einzelne Dateien zusatzlich neu zu erstellen - auch wenn das den Ladevorgang ein klein wenig reduzieren mag. Speziell bei diesen Logos, die nirgendwo verwendet werden, entfallt dieses Argument, wir haben also unbenutzte riesige plus unbenutzte angemessen grosse Dateien auf den Datenbanken. Doch die haben ja unendliche Kapazitat! -- sarang사랑 11:30, 31 March 2019 (UTC)
Ich hatte die Dateien selbst benötigt, deshalb habe ich sie optimiert. Diese Logos werden vl. öfter weiterverwendet nicht nur von mir, daher wollte ich sie in einer sinnvollen Dateigröße zur Verfügung stellen. Commons soll als eine nützliche Allmende bekannt sein und nicht für "unützbare" Dateien.
 — Johannes Kalliauer - Talk | Contributions 18:53, 31 March 2019 (UTC)

Notification about possible deletionEdit

Some contents have been listed at Commons:Deletion requests so that the community can discuss whether they should be kept or not. We would appreciate it if you could go to voice your opinion about this at their entry.

If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue.

Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!

Afrikaans | العربية | беларуская (тарашкевіца)‎ | български | বাংলা | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | Zazaki | Ελληνικά | English | Esperanto | español | eesti | فارسی | suomi | français | galego | עברית | hrvatski | magyar | Հայերեն | Bahasa Indonesia | íslenska | italiano | 日本語 | 한국어 | 한국어 (조선) | македонски | മലയാളം | Plattdüütsch | Nederlands | norsk nynorsk | norsk | occitan | polski | پښتو | português | português do Brasil | română | русский | sicilianu | slovenčina | slovenščina | shqip | српски / srpski | svenska | ไทย | Türkçe | українська | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−


Yours sincerely, please check the deletion request page for your image(s) uploaded per PD-VietnamGov minhhuy (talk) 03:28, 8 April 2019 (UTC)

Copyright status: File:Xfig splash logo.png, File:Xfig-logo.png, File:Xfig-title.svgEdit

Copyright status: File:Xfig-title.svg

беларуская (тарашкевіца)‎ | български | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | English | فارسی | suomi | français | magyar | italiano | македонски | മലയാളം | Bahasa Melayu | 日本語 | norsk | polski | português | português do Brasil | română | slovenščina | svenska | українська | ಕನ್ನಡ | ತುಳು | 中文(简体)‎ | 中文(繁體)‎ | +/−
This media may be deleted.
Thanks for uploading File:Xfig-title.svg. I notice that the file page either doesn't contain enough information about the license or it contains contradictory information about the license, so the copyright status is unclear.

If you created this file yourself, then you must provide a valid copyright tag. For example, you can tag it with {{self|GFDL|cc-by-sa-all}} to release it under the multi-license GFDL plus Creative Commons Attribution-ShareAlike All-version license or you can tag it with {{PD-self}} to release it into the public domain. (See Commons:Copyright tags for the full list of license tags that you can use.)

If you did not create the file yourself or if it is a derivative of another work that is possibly subject to copyright protection, then you must specify where you found it (e.g. usually a link to the web page where you got it), you must provide proof that it has a license that is acceptable for Commons (e.g. usually a link to the terms of use for content from that page), and you must add an appropriate license tag. If you did not create the file yourself and the specific source and license information is not available on the web, you must obtain permission through the OTRS system and follow the procedure described there.

Note that any unsourced or improperly licensed files will be deleted one week after they have been marked as lacking proper information, as described in criteria for deletion. If you have uploaded other files, please confirm that you have provided the proper information for those files, too. If you have any questions about licenses please ask at Commons:Village pump/Copyright or see our help pages. Thank you.

Jcb (talk) 23:29, 18 April 2019 (UTC)

@Jcb: There is a license, and it is according to Commons:Licensing#Acceptable_licenses.

The license tag is:

Any party obtaining a copy of these files is granted, free of charge, a full and unrestricted irrevocable, world-wide, paid up, royalty-free, nonexclusive right and license to deal in this software and documentation files (the "Software"), including without limitation the rights to use, copy, modify, merge, publish and/or distribute copies of the Software, and to permit persons who receive copies from any such party to do so, with the only requirement being that this copyright notice remain intact.

No representations are made about the suitability of this software for any purpose. It is provided "as is" without express or implied warranty. 

Accoding to w:Xfig it is w:Free and open-source and w:MIT License.

One of the authors of the software published File:Xfig-screenshot.png under {{GFDL|migration=relicense}}

 — Johannes Kalliauer - Talk | Contributions 06:08, 19 April 2019 (UTC)

You must use one of our established license templates. Jcb (talk) 11:29, 19 April 2019 (UTC)
@Jcb: is there a guideline? If I read Commons:Licensing/de#Zulässige_Lizenzen, it sounds like I can use any license that allows several things (reuse,making derivatives,...) .
I can create a new license template (at least for multilicensing). But is it allowed to just use a new license template?
Is there a list of all "established license templates"?
 — Johannes Kalliauer - Talk | Contributions 12:31, 19 April 2019 (UTC)
The currently accepted licenses are in Category:Primary license tags (flat list). If a file has no accepted license, it will be in Category:Files with no machine-readable license. Jcb (talk) 14:50, 19 April 2019 (UTC)
Return to the user page of "JoKalliauer".