User talk:JoKalliauer

From Wikimedia Commons, the free media repository
Jump to navigation Jump to search
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
Animated-Flag-Austria.gif
Ghost.svg



Welcome to Wikimedia Commons, JoKalliauer!
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment.  — Johannes Kalliauer - Talk | Contributions 11:33, 1 March 2017 (UTC)
Checkmark This section is resolved and can be archived. If you disagree, replace this template with your comment. JoKalliauer (talk) 20:21, 23 May 2018 (UTC)

File:Medellin Kartell.svg[edit]

Hallo JoKalliauer,

vielen Dank für die Vektorisierung. Ich war lange offline in der Wikipedia und habe es erst jetzt gesehen.

Grüße, Kopiersperre (talk) 09:55, 1 March 2017 (UTC)

Kein Problem  — Johannes Kalliauer - Talk | Contributions 11:33, 1 March 2017 (UTC)


Re:Group rename[edit]

Ok, but it is necessary to delete the redirects. You should use the template {{rename}} in each file to know what the new name you want. Example: in File:MDKQ anim3.svg add {{rename|1=|<new name>|2=2|3=<reason>|user=}} and fill in the parameters. I think an admin could do it faster, because there are many files and redirects must be deleted. Jarould [talk] 06:20, 29 July 2017 (UTC)

KPÖ[edit]

Die KPÖ würd' ich im Wahldiagramm auch für 2017 eintragen, KPÖplus ist schon ziemlich eindeutig eine Nachfolgepartei. Grüße, --BuschBohne (talk) 19:14, 15 October 2017 (UTC)

@BuschBohne: Ich hab leider noch keine Daten für die KPÖplus, kannst du sie mir bitte verlinken?  — Johannes Kalliauer - Talk | Contributions 19:25, 15 October 2017 (UTC)

Endergebnis ohne Briefwahl hat sie bei 0,7. --BuschBohne (talk) 19:28, 15 October 2017 (UTC)
Vermutlich wäre es auch sinnvoll, bei 2013 einen Punkt für's Team Stronach anzuzeigen. Und statt "Grune" soll's wohl "Grüne" heißen. Eventuell auch NEOS/LiF auf zwei Farben aufspalten. --BuschBohne (talk) 20:55, 17 October 2017 (UTC)
Grüne werde ich ausbessern. Daten werde ich aktualisieren sobald die Endergebnisse da sind. Weitere Parteien hinzufügen muss ich schauen wie das geht, es ist mein erstes Gnuplot-Diagramm. NEOS/LIF mag ich der Übersichtlichkeit nicht aufspalten. Ob ich Stronach bzw BZÖ hinzufüge werde ich noch schauen, ansonsten kannst du einfach ein neues Diagramm machen. Quellcode ist ohnehin vorhanden.  — Johannes Kalliauer - Talk | Contributions 21:18, 17 October 2017 (UTC)
Es reicht wenn du den Quellcode auf File:Wahlergebnisse_aut2017.svg änderst ich erstell dann die Grafik mit den geänderten Quellcode neu.  — Johannes Kalliauer - Talk | Contributions 21:19, 17 October 2017 (UTC)
@BuschBohne: https://upload.wikimedia.org/wikipedia/commons/6/66/Wahlergebnisse_aut2017Full.svg  — Johannes Kalliauer - Talk | Contributions 11:02, 21 October 2017 (UTC)
Achtung: Die 4%-Hürde wurde erstmals 1994 angewandt, zuvor war nur der Gewinn eines Grundmandates maßgeblich. --BuschBohne (talk) 14:10, 21 October 2017 (UTC)

Könntest du vielleicht noch zwei Diagramme erstellen, nur mit den Werten von jeweils SPÖ und FPÖ um diese zwei Diagramme zu ersetzen? --BuschBohne (talk) 16:22, 20 October 2017 (UTC)

Vielleicht wäre es für diese Diagramme besser, die Y-Achse bei 0 starten zu lassen. --BuschBohne (talk) 21:47, 21 October 2017 (UTC)

File:SVG 3 paths BugSolved.svg[edit]

Hey JoKalliauer, ich glaube hier irgendwas zusätzlich mit einem schwarzen Viereck zu erklären macht überhaupt keinen Sinn... weniger ist mehr (wenn es denn sein muss reicht hier ein simpler erklärender Satz, es wurde hier nur äußerst einfach der Bug mit gleichen Quadraten aufgezeigt). Des Weiteren ist dein Präfix Bezeichnung "BugSolved" sehr unglücklich (ansonsten hätte ich eine andere Datei von dir schon als Ersetzung genommen jedoch war mir der Name zu doof), denn jede Datei ist ohne Bugs zu erwarten und der Renderer wird auch ab und zu gefixt (was die Bez. zusätzlich irritierend macht). Nichtsdestotrotz danke für dein Effort in der Sache. Einen schönen Advent -- User: Perhelion 23:31, 9 December 2017 (UTC)

Danke für dein Feedback.
Hätte ich ein Viereck gemacht wäre es tatsächlich sinnlos, jedoch habe ich drei Vierecke, dies kann man vollautomatisch mit https://jakearchibald.github.io/svgomg/ machen, also ich habe keinen neuen Code geschrieben:
<path d="M0 0h300v300H0zM300 0h300v300H300zM600 0h300v300H600z"/>
Generell finde ich den Bug Librsvg_bugs#Hairline_cracks nicht wirklich relevant, mir wäre er zumindest noch nicht in realen Dateien untergekommen.
 — Johannes Kalliauer - Talk | Contributions 00:00, 10 December 2017 (UTC)
Ja der Bug ist in der Tat trivial und hatte jetzt auf der Bug-Seite überproportionale Aufmerksamkeit. Dass der Bug bei vereintem Pfad nicht auftritt ist gerade so erwähnenswert (ein kleines Charakteristikum das eigtl. erwartungsgemäß ist). -- User: Perhelion 00:17, 10 December 2017 (UTC)

File:comparison_land_area_units.svg[edit]

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.

Cheers,
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)
@Cmglee:
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)

SVG restoration[edit]

Hello.

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>
 </g>

 — 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)

File:Image-Tmi-2 schematic-fr Path.svg[edit]

Hello.
First, read carefully please the description of by= in {{derived from}}. Second, why did you create this new File: item at all? There is a problem with Adobe Inc. shit somewhere in revisions of File:Image-Tmi-2 schematic-fr.svg, but this site has a large crowd of sysops – it’s their job, these janitorial functions. Don’t please distract your valuable resources to it. Incnis Mrsi (talk) 21:23, 18 January 2018 (UTC)

There are many templates, I sometimes mess up between them, thanks for telling me. :-)
So File:Image-Tmi-2 schematic-fr Path.svg has to get deleted due to font-copyright-Problem of Adobe Inc. and File:Image-Tmi-2_schematic-fr.svg should be overwritten with File:Image-Tmi-2_schematic-fr_Text.svg?
 — Johannes Kalliauer - Talk | Contributions 21:38, 18 January 2018 (UTC)
Himmel OMG… didn’t you envisage that total deletion of Image-Tmi-2_schematic-fr.svg will destroy the last vestige of visible authorship claim for Kimdime? In case of revision deletion, SVGs with Adobe font will be inaccessible, but https://commons.wikimedia.org/w/index.php?title=File:Image-Tmi-2_schematic-fr.svg&action=history will persist… verunderstand? Incnis Mrsi (talk) 21:46, 18 January 2018 (UTC)


PS I am just a stupid user, who wrote a script, that starts 1)Inkscape 2)scour 4)svgcleaner 5)svgo. When you edit some files, you know what they change. It is just comparing input with output.
Because of your request on Commons:Deletion_requests/File:Test.svg. If you want to delete an old version you have to start a DeletionRequest (DR) or ask any admin to delete it. (see: User_talk:Jcb/archive/18#Delete_of_Fileversions)
Himmel...are you German speaking? If so we could talk German.
I ment I would upload a new version to File:Image-Tmi-2_schematic-fr.svg and then delete File:Image-Tmi-2_schematic-fr_Text.svg as a duplicate.
 — Johannes Kalliauer - Talk | Contributions 21:52, 18 January 2018 (UTC)
Unfortunately, don’t know much German, but can remember that in a Jaroslav Hašek’s story an Imperial Austrian officer exclaimed “Himmeldonnerwetter”. As for SVG pollution with copyrighted fonts, I expect that you’ll find many live examples with Arial and similar stuff. I didn’t hunt for it systematically any only excised copyrighted items when observed them in the code. Incnis Mrsi (talk) 10:41, 20 January 2018 (UTC)
In my opinion real text with font-family="ArialMT" is ok, because 'ArialMT will substituded in the Rendering by DejaVu Sans (also Liberation Sans might be a better choice).
But if ArialMT is converted to Path as in File:Image-Tmi-2_schematic-fr_Path.svg it is a copyright-problem and should be deleted.
 — Johannes Kalliauer - Talk | Contributions 10:58, 20 January 2018 (UTC)
Hi, I received a notification. Sorry didn't read the whole discussion. I think my contribution to this file is basically a translation. I won't take offence if my attribution disappears. RegardsKimdime (talk) 14:10, 21 January 2018 (UTC)

Graphics village pump[edit]

Hello.
Could you watch Commons: Graphics village pump #File:Envelope cast.svg, please? I currently can’t talk anymore, it’s past midnight in Russia. Incnis Mrsi (talk) 21:24, 27 January 2018 (UTC)

User:Perhelion fixed the file and I repaired the Gnuplot-Source-Code, now the Gnuplot makes one plot with 100 red Lines instead of 100 Plots over each other with one red line each. Now Gnuplot would create a valid file (without postprocessing).  — Johannes Kalliauer - Talk | Contributions 00:24, 28 January 2018 (UTC)

Neues Problem[edit]

fällt mir seit gestern auf: die diversen von Igen erzeugten Blöcke ragen nun über den Rand der "Information" hinaus, es gibt neue Zeilen wo bisher keine gewesen sind, zT geraten Texte übereinander. Ich konnte noch nicht herausfinden woran das liegt, ist aber ein unhaltbarer Zustand. Kannst du etwas finden? -- sarang사랑 10:09, 24 April 2018 (UTC)

@Sarang:<span style="float:left;height:1.2em;vertical-align:middle">{{{p|}}}<!-- soll geändert werden auf <span style="vertical-align:middle">{{{p|}}}<!-- JoKalliauer (talk) 16:49, 24 April 2018 (UTC)
Der Code sollte von
<span style="float:left;height:1.2em"><!-- 
-->{{Created with Inkscape|v}}<!--
--></span><!--

--><noinclude><br style="clear:both"/>
----
--some text--
----
</noinclude>

auf

<span><!-- 
-->{{Created with Inkscape|v}}<!--
--></span><!--

--><noinclude><br style="clear:both"/>
----
--some text--
----
</noinclude>

geändert werden.

JoKalliauer (talk) 16:53, 24 April 2018 (UTC)

Weiterdiskussion auf Template_talk:Image_generation#currently_not_working JoKalliauer (talk) 17:03, 24 April 2018 (UTC)
Danke Johannes; ich weiss immer noch nicht warum es plötzlich nicht mehr funktioniert hat. Wenn es mit dieser <span> Änderung besser geht - o.k.; aber das kann nichts damit zu tun haben dass die diversen boxes ausserhalb der Information-box erscheinen, und zT den Text der licence überschreiben. Wer oder was auch immer es gewesen ist, es ist inzwischen wieder repariert worden und alles sieht wieder gut aus (ev. nach purge).
Ich nehme deinen Änderungsvorschlag in die sandbox, für das baldige nächste update. Gruss -- sarang사랑 05:12, 25 April 2018 (UTC)

File:History of the Universe-zh-hant Workaround.svg[edit]

Commons-emblem-issue.svg
File:History of the Universe-zh-hant Workaround.svg 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) 21:30, 28 April 2018 (UTC)

viewBox, width, and height[edit]

On 2 April, you said

Ich bevorzuge viewBox, weil im Browser dann das Bild genau hineingefittet wird (zu kleine Bilder sieht man groß genug um selbst Rundungsfehler durch CleanUp zu erkennen, zu große Bilder sieht man das ganze Bild ohne zu scrollen)
Bei dem Bild kam der Wunsch die Datei zu bereinigen, deshalb hab ich Scour im "aggressiven Modus" (inklusive --enable-viewboxing) durchlaufen lassen. Ob man viewBox bevorzugt oder nicht ist mMn Ansichtssache. Bei eigenen Bildern verwende ich viewBox (ohne height und ohne width) eigentlich immer.

but you just edited File:History of the Universe lang.svg and inserted a fixed width and height despite the file having a viewBox attribute. It doesn't make any difference to MW software today, but setting width and height to something other than 100% means the file will not do the right thing when inserted with the HTML object element. Glrx (talk) 15:03, 29 April 2018 (UTC)

@Glrx: Yes you can remove that, I forget to remove it. I used it because resolution with 5500 is a bit high, and https://commons.wikimedia.org/w/index.php?title=Commons:Commons_SVG_Checker&withJS=MediaWiki:CommonsSvgChecker.js as well as http://tools.wmflabs.org/svgcheck/ does show in this resolution of the viewbox, which is too large for my notebook (I know you can scoll out but 5500 is in my opinion very huge). I height and width for debugging reasons, so please remove it in the next edit. JoKalliauer (talk) 16:37, 29 April 2018 (UTC)

File:Image-Tmi-2 schematic-fr Path.svg[edit]

Commons-emblem-issue.svg
File:Image-Tmi-2 schematic-fr Path.svg 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) 16:18, 29 April 2018 (UTC)

@Glrx: File:Image-Tmi-2_schematic-fr.svg used font-family="'Myriad-Roman'", which is not available on commons therefore only File:Image-Tmi-2 schematic-fr Path.svg is identical to the original (the Original has already the converted the text to path). For the text-version I replaced the font with font-family="UnGraphic" which look's similar, but 'TOUR DE RÉFRIGÉRATION' was much too large therefore I used the smallest sans-font in File:MediaWiki_SVG_font_list_sans.svg (ordered in length of the characters), therefore it has a mixture of fonts which I would not recommend. I though I discus it first with you and then we both might come together to a conclusion and we summarise the conclusion in the official discussion for the administrators. JoKalliauer (talk) 16:48, 29 April 2018 (UTC)

I do not see a benefit in keeping the path text version. It may be an exact rendering, but an exact rendering is not needed. We don't need many copies of the essentially the same thing.
The fonts need not closely match. They are used as labels rather than calligraphic art.
Consider that images on Commons are intended to rendered everywhere (not just on Commons with RSVG). Yes, using a font such as "UnGraphic" may make the image work on Commons, but my machine doesn't have that font, so when I look at the Tmi-2 SVG in my browser, "TOUR DE RÉFRIGÉRATION" doesn't fit. The goal should be to make the SVG render reasonably with most user agents. That means one cannot rely on any one font being available. Images should render reasonably with the fallback fonts. I am guilty: I spent a long time using &thinsp; and Commons skinny fonts (font-family="Bitstream Charter") trying to keep the text in File:Proton proton cycle.svg within the boxes; then the font disappeared from Commons (look at hep now).
If the problem is to fit the line, then we could use a smaller font, we could avoid using all uppercase characters (e.g., the buildings could be in a bold font rather than uppercase), or we could use two lines. There's also textLength and lengthAdjust, but that's just asking for trouble.
File:Image-Tmi-2 schematic-fr Path.svg should be deleted. You should copy the SVG from File:Image-Tmi-2 schematic-fr Text.svg to File:Image-Tmi-2 schematic-fr.svg, and then File:Image-Tmi-2 schematic-fr Text.svg should be deleted as redundant. (Sometime File:Image-Tmi-2 schematic-fr.svg should be renamed to File:Tmi-2 schematic-fr.svg.)
Glrx (talk) 17:54, 29 April 2018 (UTC)
As written in my text above I changed "TOUR DE RÉFRIGÉRATION" to the smallest font font-family="Ubuntu Condensed" font-stretch="condensed", therefore I used two different fonts in the same file, which doesn't look nice. And if you do not have the font, font-stretch="condensed" should still work. If you do not have a Ubuntu Condensed installed you can download it from https://design.ubuntu.com/font/ . JoKalliauer (talk) 06:25, 30 April 2018 (UTC)
Do you know why https://commons.wikimedia.org/wiki/Commons:Commons_SVG_Checker?withJS=MediaWiki:CommonsSvgChecker.js&checkSVG=File:Proton_proton_cycle.svg says WARNING in <g>: Font type Bitstream Charter is not available in Wikimedia software. It will be rendered with minor differences by Wikimedia's SVG renderer. See https://meta.wikimedia.org/wiki/SVG_fonts for details. JoKalliauer (talk) 06:25, 30 April 2018 (UTC)
There is a hep label in the proton–proton illustration; that's the line that RSVG now renders outside the box.
Labels should have plenty of room so they can be translated.
Using special fonts is not a general fix. Most operating systems will not have "Ubuntu Condensed", and most users would not bother to download an uncommon font (even if free) just to make an illustration work. Commons should have SVG files that work out of the box most of the time. Tmi-2 Text did not work out of the box when I loaded into Chrome, Edge, or Firefox; the label touched the cooling tower walls. Making an illustration work out of the box means using ordinary fonts. I love Palatino, Berkeley, and Tekton, but when it comes to SVG illustrations, it can be better to use others.
Yes, I know why the Commons SVG Checker issues the warning message, I know the Checker tests some font names multiple times (e.g., "DejaVu Sans Mono"), and I know that the Checker uses a linear search instead of a faster JavaScript object.
No, I do not know why Commons dropped Bitstream Charter. It used to be on Commons,[2] and that is why I used it. You noticed Bitstream went away. Why Bitstream fonts are gone doesn't matter to me; they are just gone.
The French Wikipedia redirects fr:Tour de réfrigération to fr:Tour aéroréfrigérante which also uses tour de refroissement (which en.Wikt says is the translation). cooling tower (Q193886) gives all three translations.
Glrx (talk) 17:38, 30 April 2018 (UTC)
@Glrx: I'm not shure if Commons really "dropped Bitstream Charter" see c:File_talk:Meta_SVG_fonts.svg. (There might be some issues with Commons-Checker.) JoKalliauer (talk) 22:10, 2 May 2018 (UTC)
I'm guessing it was dropped by its absence on the list and the overflowing line in the illustration, but I don't know for sure. In many ways, it does not matter. Even if Commons has a font and librsvg knows to use it, that does not mean the typical Windows, Mac, or Unix user has the font installed on his system. Glrx (talk) 16:14, 3 May 2018 (UTC)
I am not believing the Commons-Checker according to available fonts, check File:MediaWiki_SVG_font_list_sans.svg the Fonts from "Kedage" to "Waree" are rendered with the default fallback-font (DejaVu Sans), but without any warning of Commons Checker. JoKalliauer (talk) 22:04, 3 May 2018 (UTC)
Commons SVG Checker's list of fonts is a snapshot of https://noc.wikimedia.org/conf/fc-list ; the JavaScript source gives the regex it used to process fc-list. The current version of fc-list does not have "Kedage", "Mallige", and "TAMu*" anymore, so those should fail. The curent file has "Kacst*" with styles Medium, Regular, KacstScreen, but only "KacstQurn" and "KacstTitleL" use style Regular (as second option). "Guseul", "Lohit Oriya", "Lohit Telugu", "mry_KacstQurn", "TAMu" has style Regular. "Waree" has styles Bold, BoldOblique, Book, Oblique. Fonts that have style Regular should work, but maybe the Latin characters of some fonts use the same Latin characters as RSVG fallback (or use SVG's character fallback). Maybe RSVG is running off a different list. In any event, the conclusion is Commons SVG Checker does not have an accurate font list. Glrx (talk) 01:41, 4 May 2018 (UTC)
Looks like fc-list is generated by Unix command fc-list (man 1). See example output here. Going to https://noc.wikimedia.org/conf/ says the fc-list file is "dynamically generated" and "perfectly up-to-date". Glrx (talk) 18:36, 4 May 2018 (UTC)
@Glrx: But https://gerrit.wikimedia.org/g/operations/mediawiki-config/+blame/master/fc-list?blame=1 looks like it was edited by some users? If more problems occour we might should update https://commons.wikimedia.org/wiki/MediaWiki:CommonsSvgChecker.js JoKalliauer (talk) 10:44, 5 May 2018 (UTC)
I think fc-list is just a status list rather than the database of installed fonts; editing fc-list doesn't seem to make sense; there's a library for font selection that should use the fonts that are actually installed. I'm slightly curious about an accurate font list for Commons. Updating Commons SVG Checker's list would not hurt, but we don't have an accurate list. Glrx (talk) 13:55, 5 May 2018 (UTC)

File:LibrsvgBug T193929.svg[edit]

Commons-emblem-issue.svg
File:LibrsvgBug T193929.svg 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) 00:14, 6 May 2018 (UTC)

Deleted because it was not a librsvgbug, see phab:T193929 for details.  — Johannes Kalliauer - Talk | Contributions 19:07, 6 June 2018 (UTC)
Attention: The “section resolved” template needs a valid date. The section will not be archived otherwise. Please use {{Section resolved|1=~~~~}} instead.

File:Antu application-pdf.svg[edit]

Hallo JoKalliauer, ich versuche zu verstehen, warum Du meine Änderungen an File:Antu application-pdf.svg rückgängig gemacht hast und die Datei wieder in Category:Uncheckable SVG created with Other tools:Antu icons einsortiert hast. Die Datei ist nicht mehr uncheckable, Kannst Du das bitte erklären? --Sebastian Wallroth (talk) 10:02, 6 May 2018 (UTC)

@Sebastian Wallroth: Sorry, mein Fehler, dachte das Skript hat die Kategorie unabsichtlich entfernt, hatte zu wenig aufgepasst. JoKalliauer (talk) 10:07, 6 May 2018 (UTC)
Ach, dass ist mir auch schon passiert. Grüße aus Berlin! --Sebastian Wallroth (talk) 11:41, 6 May 2018 (UTC)

Rsvg bug[edit]

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 https://commons.wikimedia.org/w/index.php?title=File:SVG_test_text_tspan_ws.svg&diff=prev&oldid=125897457 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. Face-smile.svg 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)

File:Delphi location.svg[edit]

Commons-emblem-issue.svg
File:Delphi location.svg 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 | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

Jcb (talk) 16:09, 5 June 2018 (UTC)

Please see: User_talk:Marsyas#File:Delphi_location.svg  — Johannes Kalliauer - Talk | Contributions 19:05, 6 June 2018 (UTC)

File:Delos location.svg[edit]

Commons-emblem-issue.svg
File:Delos location.svg 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 | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

Jcb (talk) 16:09, 5 June 2018 (UTC)

Please see: User_talk:Marsyas#File:Delos_location.svg  — Johannes Kalliauer - Talk | Contributions 19:05, 6 June 2018 (UTC)

CDATA[edit]

Hallo Johannes, in den letzten Tagen hast du aus einer Menge Dateien das PGF CDATA entfernt. Meine Meinung dazu: wenn es sich um eine Datei handelt die oft (oder sonstwie wichtig) eingebunden ist, wird das downloading durch die drastische Verkleinerung gringfügig beschleunigt; wenn das nicht der Fall ist, die Datei also nur gelegentlich mal angesehen wird, bringt eine solche Qualitätsverbesserung keinen Nutzen. Ich empfehle also, jedesmal abzuwägen ob die Erzeugung so einer weiteren Datei, eines besseren Duplikats, gerechtfertigt ist. Aber auf jeden Fall sollte das PGF-tag aus der Beschreibung entfernt werden! Fallls du meinst, mache ich eventuell noch ein tag "...enthielt PGF" – was meinst du?. -- sarang사랑 12:51, 9 June 2018 (UTC)

I doubt removing PGF CDATA has much of an impact on download speed. The SVG files are converted to PNG files at the server farm, and then the PNG files are cached for subsequent requests. A smaller SVG file will take less time for the server to read, but once converted, the SVG files need not be read again.
That said, I have no objection to removing the PGF CDATA; to most users it is dead weight.
I do object to other "optimizations" that affect the organization of the SVG file. The goal should not be an optimized SVG file but rather a clean SVG file.
Glrx (talk) 13:52, 9 June 2018 (UTC)
@Sarang: Yes I know "~" should be deleted, but in this case, I choose to parallel process files, therefore I first add Igen to several files, then I download the file, then I check again if all errors are removed, and remove the "~" again. I think it is not a problem to keep ~ for a few days. (I will clean the file-description-pages up upon myself.) "contained PGF" does not make sense to me, as long as those data are really useless, as I assume?  — Johannes Kalliauer - Talk | Contributions 14:26, 9 June 2018 (UTC)
@Glrx: Everytime the SVG is requested in a new size it has to be read again, or if someone "?action=purge" it, both does not occur that often, but files are often copied several times within Wikipedia (f.e translation to different language).
@Sarang, Glrx: However: In my opinion Category:SVG files with errors should be (with view exeptions) empty, because files might be invalid, but they should not contain errors (I mean real errors, which won't render correct, might not correlate with W3C-errors. Errors like links to not embedded pictures, or syntax-mistakes, or foreignObject only few Software knows, wrong MIME-type, missing xmlns...). As long as Adobe files with CDATA blocks is a subcategory of SVG files with errors, I think the files should be reuploaded to reduce the files in SVG files with errors, if we change categories, I would think differently.
 — Johannes Kalliauer - Talk | Contributions 14:26, 9 June 2018 (UTC)
@Sarang: Should Adobe files with CDATA blocks be a subcategory of SVG media for cleanup?  — Johannes Kalliauer - Talk | Contributions 12:20, 10 June 2018 (UTC)
I would suggest: no. Neither I think it the best idea to subcategorize them to SVG files with errors. It is of some interest how many huge files are around with these useless blocks, but it is not a real error, it's just ... filling the data bases. IMHO it is enough when the CDATA category is a subcat of the Adobe files. -- sarang사랑 12:45, 10 June 2018 (UTC)
Totally agree: Now Adobe files with CDATA blocks is a subcategory of SVG files with errors and therefore a subsubcategory of SVG media for cleanup, which does not make much sence as you said. Removing SVG files with errors on Adobe files with CDATA blocks makes sense to me.  — Johannes Kalliauer - Talk | Contributions 12:54, 10 June 2018 (UTC)
Yes, PGF CDATA blocks are not errors just like RDF, sodipodi, and chem elements are not errors; PGF data just has little value.
Please do not switch to English on my account. Glrx (talk) 18:11, 10 June 2018 (UTC)
Ich habe jetzt die Kategorie SVG files with errors(und somit auch SVG media for cleanup) entfernt: siehe history  — Johannes Kalliauer - Talk | Contributions 18:22, 10 June 2018 (UTC)

RSVG[edit]

ich habe ein neues Igen hochgeladen, und konnte den workaround in RSVG Bug wieder entfernen. Falls dir auffällt dass was nicht stimmt, bitte um Info. Danke -- sarang사랑 13:09, 9 June 2018 (UTC)

Archived page[edit]

I see you recently started a new section on an archived page. Figured you might want to know. - Jmabel ! talk 21:40, 11 June 2018 (UTC)

@Jmabel: I think User_talk:Rillke is the recent page. (It redirects to User_talk:Rillke/Discuss/2016). — Johannes Kalliauer - Talk | Contributions 21:49, 11 June 2018 (UTC)
I think what may be more germane is that Rillke hasn't edited Commons in over 2 years. - Jmabel ! talk 22:29, 11 June 2018 (UTC)

[File:Human 100 100000.svg][edit]

Why did you add SVG compatibility issues to File:Human 100 100000.svg]? Is it a former bug?  — Johannes Kalliauer - Talk | Contributions 20:09, 20 June 2018 (UTC)

  • Yes it wat tagged at 2012. I removed tag since it is no longer valid. --Nevit Dilmen (talk) 14:09, 21 June 2018 (UTC)

Troubling edits[edit]

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.[3] 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: https://github.com/KDE/oxygen-icons5/blob/master/256x256/mimetypes/application-rtf.png).
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)

Hi! It's me![edit]

When using the cleanup.js tool, which one should I click? cleanup JS, fast cleanup TS (new), or cleanup TS?--Jeromi Mikhael (talk) 06:29, 23 June 2018 (UTC)

@Jeromi Mikhael: I think there is no "right" one, I am using User:Perhelion/simpleSVGcheck.js (see User:JoKalliauer/common.js), (as far as I know) this is developed by User:Perhelion (with some input from User:Sarang). Since you are using a tool of User:Magog the Ogre: I would ask User talk:Magog the Ogre.  — Johannes Kalliauer - Talk | Contributions 08:37, 23 June 2018 (UTC)
@Jeromi Mikhael: TS is better. I kept JS around only by popular demand. It's more aggressive in the changes it makes, but it's buggy and fixes fewer problems. Magog the Ogre (talk) (contribs) 17:14, 23 June 2018 (UTC)
@Magog the Ogre: Umm, the fast one or the normal one?--Jeromi Mikhael (talk) 06:31, 24 June 2018 (UTC)
@Jeromi Mikhael: The normal one of course. I personally using a fork of Magogs version for improvements and testing, so only the JS version. The TS version is not necessary better. The more features should be ported to the JS version too (I personally don't see a real advantage of a TS version, maybe it is the better knowledge of PHP by Magog). -- User: Perhelion 23:00, 27 June 2018 (UTC)

File:20T superconducting magnet.png[edit]

Commons-emblem-issue.svg
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)

wordmark[edit]

Hi JoKalliauer,

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

Fake SVG[edit]

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 Template:FakeSVG ware vorerst ein stub wie das Template: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' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="http://www.w3.org/2000/svg">
 <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 16.2.08.3-.08.3h-11.12v-.6z"/>
</svg>
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' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="http://www.w3.org/2000/svg">
 <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 16.2.08.3-.08.3h-11.12v-.6z"/>
</svg>
 — 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' 'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>
<svg font-family="Liberation Sans" font-size="10" viewBox="5.46 8.78 52.73 18.82" xmlns="http://www.w3.org/2000/svg">
 <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 16.2.08.3-.08.3h-11.12v-.6z"/>
</svg>
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="http://www.w3.org/2000/svg">
 3  <metadata>
 4   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
 5    <cc:Work xmlns:cc="http://web.resource.org/cc/" xmlns:dc="http://purl.org/dc/elements/1.1/">
 6     <dc:format>image/svg+xml</dc:format>
 7     <dc:type rdf:resource="http://purl.org/dc/dcmitype/StillImage"/>
 8     <cc:license rdf:resource="http://creativecommons.org/licenses/by-sa/3.0/"/>
 9     <cc:attributionName rdf:resource="https://commons.wikimedia.org/wiki/User:Glrx"/>
10     <cc:attributionURL rdf:resource="https://commons.wikimedia.org/w/index.php?title=File:SVG_Test_TextAlign.svg"/>
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)
https://upload.wikimedia.org/wikipedia/commons/archive/b/bd/20180726195300%21Test.svg
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)

gnuplot[edit]

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)

Script[edit]

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]

Graphic Designer Barnstar Hires.png 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="http://www.inkscape.org/namespaces/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" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Creator: CorelDRAW X8 -->
<svg xmlns="http://www.w3.org/2000/svg" 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="http://www.w3.org/1999/xlink">
   <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"/>
   </g>
</svg>
Example of fixed file
<?xml version="1.0" encoding="UTF-16"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<!-- Creator: CorelDRAW X8 -->
<svg xmlns="http://www.w3.org/2000/svg" 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="http://www.w3.org/1999/xlink" xmlns:inkscape="http://www.inkscape.org/namespaces/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 "/>
   </g>
</svg>
You could use https://validator.w3.org/check 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)

File:Bronze-service-star-3d-vector.svg[edit]

Hey, thanks! That looks so much better at reduced sizes now! — fourthords | =Λ= | 15:42, 2 September 2018 (UTC)

@Fourthords: I did a "shitty" repair, I deleted some blurs and I think I reduced one blur, but the whole picture should be redrawn in my opionin, since it ist badly traced (try zoom in or look at 1.038 × 1.024 Pixel-PNG, and take a closer look at the edges of the star. Reducing file size is just done, by using three fully-automatic optimizers scour, svgcleaner, svgoptimizer. Just reducing file-size is generally [not really a valid reason for]/[not worth] reuploading.  — Johannes Kalliauer - Talk | Contributions 16:25, 4 September 2018 (UTC)

lang=fa in infobox image[edit]

Change |image=xyz.svg to |image=[[File:xyz.svg|lang=fa|200px]] Glrx (talk) 15:50, 19 September 2018 (UTC)

Text rendering[edit]

Hallo Johannes, du bist doch ein Experte fur bugs. Der Benutzer Istkart hat Abertausende suboptimaler Karten hochgeladen, alle mit kyrillischen Texten. Von 09-2012 bis 02-2015 hat er Esri-ArcMap verwendet, und alle Texte in diesen unzahligen Karten werden nicht gerendert. Kannst du ermitteln, woran das liegt (wenn es kein zu grosser Aufwand ist!), eventuell bedarf es einer Subkategorie fur diesen Fehler. Gruss -- sarang사랑 07:05, 20 September 2018 (UTC)

Fonttest-Kerning.svg
(@Sarang:)
Die Texte werden gerendert, nur sehr in­ak­ku­rat (phab:T36947, hab noch nie ein so "schönes" Bug-Beispiel gesehen.). Er verwendet font-size="1" für alle Texte für alle seine SVG-Karten, die Genauigkeit ist bei Schriften unter 25px schlecht, siehe File:Fonttest-Kerning.svg. Der Bug wurde schon von librsvg (angeblich/vermutlich) behoben phab:T36947#4078851, @AKlapper (WMF): nur gehört librsvg auf Wikimedia upgedated phab:T193352.
Also ist der Text kein Fehler von Istkart (sonderm vom Renderer), aber die Bilder sind nicht richtig ArcMap eingebunden xlink:href="data:;base64, iVBORw0KGgoAAAANSUhEUgAA..., korrekt ist aber xlink:href="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAA... phab:T5537, wobei derzeit kann man solche Bilder auf Wikimedia gar nicht mehr hochladen (glaub Sicherheitsgründe).
 — Johannes Kalliauer - Talk | Contributions 15:39, 20 September 2018 (UTC)
@JoKalliauer: Wie bereits von Dir zitiert: https://phabricator.wikimedia.org/T193352#4166886 . Gibt es eine Frage, oder was war die Intention des Pings? --AKlapper (WMF) (talk) 15:48, 20 September 2018 (UTC)
@AKlapper (WMF): Sorry, hab zu wenig Ahnung von Abhänigkeiten/Debian-Paketen, dass ich das Problem nicht verstehe, und es mir folgedessen nicht gemerkt hatte(und auch nicht nochmal gelesen hatte). Danke für die Antwort  — Johannes Kalliauer - Talk | Contributions 15:54, 20 September 2018 (UTC)
@JoKalliauer: Ah. Heh. :) Okay. Und ich bin oft sehr schlecht im Fragen rauslesen wenn sie nicht total explizit sind, daher hatte ich nachgefragt... der letzte Kommentar in dem Ticket macht etwas Hoffnung dass das Problem in den naechsten Monat vielleicht in Debian geloest wird. --AKlapper (WMF) (talk) 16:00, 20 September 2018 (UTC)
Yes, the font size is an issue on almost all the labels, but there are also logical errors in the maps. Consider File:Historical map of Greece 1200 BC.svg. The svg element has width="841.49291pt" height="595.50236pt" viewBox="0 0 841.49291 595.50236", but text is intended to the left (negative x) and above (negative y) of the viewBox. In addition, clip paths exclude the text. For example,
<clipPath id="SVG_CP_7">
	<path d="M0,595.50236L0,0L841.49291,0L841.49291,595.50236L0,595.50236z"/>
</clipPath>
<g font-family="'Arial'" font-size="1" kerning="0" font-weight="400" fill="#0000C8" clip-path="url(#SVG_CP_7)" >
	<text text-anchor="start" transform="matrix(6.83814 0 0 6.84064 678.41548 -6.4901)" >
		<tspan direction="ltr" unicode-bidi="embed" x="0 ">2</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="0.52651 ">9</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="1.10567 ">°</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="1.52687 ">0</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="2.10603 ">&apos;</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="2.26398 ">0</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="2.84314 ">&quot;</tspan>
		<tspan direction="ltr" unicode-bidi="embed" x="3.2117 ">E</tspan>
	</text>
</g>
The 29°0'0" is intended to be 6.83814 pixels tall with text anchor at (678.41548, -6.4901), so all the text is outside the viewBox. In addition, SVG_CP_7 clips everything whose y is less than 0. The clip paths are overkill.
As a side note, font-size should be used instead of scaling with a transform. The direction is not needed, and the unicode-bidi="embed" is pointless when the characters are individually placed in their own text chunks. It is also pointless because all the characters are either left-to-right or neutral; there will not be any direction changes. It appears to be an effort to defeat any Unicode reordering. Also, text-anchor="middle" is a more appropriate way to deal with differing font metrics than explicit placement of each character.
<text x="680" y="-6.5" font-size="7" fill="#0000C8" text-anchor="middle">29°0'0"</text>
Glrx (talk) 16:53, 20 September 2018 (UTC)
@Glrx: Thanks. I didn't look that close into the file (I just do some halfautomatic scriptprozessing). Now I see there are several more things to improve.  — Johannes Kalliauer - Talk | Contributions 21:01, 20 September 2018 (UTC)
@Sarang: In der SVG maps showing history in Russian gibt es über 200 *.jpg, kann man die mit einem Batchprozess nach Maps showing history in Russian verschieben?  — Johannes Kalliauer - Talk | Contributions 16:33, 21 September 2018 (UTC) 0 ✓ Done (320 maps) -- sarang사랑

Da bist du viel fleissiger gewesen als ich dir zumuten wollte! Danke.
Unser Kyrillo-Fan war ja auch immens fleissig. Von 07-2012 bis 08-2012 hat er Karten mit ArcMap 10.0.0.2414 erstellt, die den Text rendern; ab 09-2012 bis 02-2015 mit buggy ArcMap 10.1.0.3035 (der librsvg zeigt Text nicht an, der Browser (mit "edit SVG") kann das!); das scheint er irgendwann gemerkt zu haben, jedenfalls erzeugt er von 03-2015 bis 10-2016 JPG-Karten. Erst ab 11-2016 verwendet er ein SVG-tool "Qt" (? - mir unbekannt) das auch den Text anzeigt. (Ob text oder nicht ist mir ziemlich egal, mein Kyrillisch ist nicht so gut dass ich das fliessend lesen könnte.) IMHO sind seine alle Karten nicht so gut oder brauchbar, dass eine Verbesserung lohnt; ganz abgesehen von der Kyrillität! Wenigstens sind die Dateinamen in Englisch... -- sarang사랑 04:16, 22 September 2018 (UTC)

File:Na+H2O.svg[edit]

Hallo JoKalliauer. Deine Version mag technisch besser sein, aber optisch überzeugt sie nicht (insbesondere bezüglich des Pluszeichens). Magst du nacharbeiten oder soll ich die Version zurücksetzen? --Leyo 12:31, 1 October 2018 (UTC)

@Leyo:
Danke für's anschreiben, wollte dich vorher auch schon fast anschreiben, dachte dann aber es war nur weil ich das Plus nicht hochgestellt hatte.
Mich überzeugt der (für mich motivationslos) gedrehte Text in der Pfad-Text-version nicht, daher habe ich das Bild in meinem zweiten Edit (30. Sep. 2018) überarbeitet. (Mein erster Edit (27. Sep. 2018) war fälschlicherweise weil ich phab:T36947 (Text-kerning) nicht gesehen habe, das habe ich jetzt in meinem dritten Edit (1. Okt. 2018) auch behoben.)
Ich hab jetzt in meinem dritten Edit (1. Okt. 2018) ein normals Plus "+" hochgestellt vorher hatte ich ein hochgestelltes Plus "⁺".
Ich hab in meinem dritten Edit (1. Okt. 2018) das Pluszeichen bei File:Na+H2O.svg sehr an deine Version angepasst siehe File:Test.svg (18:54, 1. Okt. 2018) (Dein Pfad-text ist zum Vergleich grün hinterlegt.)
Gibt es noch etwas zum nacharbeiten?
 — Johannes Kalliauer - Talk | Contributions 19:41, 1 October 2018 (UTC)
Johannes, herunter ist nicht richtig.
  <text x=" 990" y="2570">δ+</text>
SVG 1.1 <number> hat kein " ". Mit Google Chrome, " 990" → "0".
Glrx (talk) 20:15, 1 October 2018 (UTC)
Danke euch beiden! Jetzt sieht's gut aus. --Leyo 23:27, 1 October 2018 (UTC)
Thanks User:Glrx. I fixed it now. (But I find it strange since x="1,2,3" is allowed.) Do you know why the radialGradient of the upper and lower H2O one looks different to the side H2O? (seems to be a librsvgbug)  — Johannes Kalliauer - Talk | Contributions 06:41, 2 October 2018 (UTC)
I think the simple rule is no leading spaces. The list "1,2,3" may separate the elements (but not begin the elements) with whitespace or a comma surrounded by optional whitespace. See <list-of-Ts>. That's where MW ran into trouble with viewBox="0,0 , 640 320".
The difference in the radialGradient bothered me yesterday, but I haven't investigated. The effect appears in Chrome, Edge, and Firefox. My guess is a bounding box issue; the bounding box computation uses an inexact shortcut. The user agent may see the use instance, calculate the bounding box of the use prototype (say 100×100px for a 100px diameter circle), and then modify that bounding box by the transform to compute the bounding box of the instance (getting say 123×123px -- that is, it computes the bounding box of a rotated square rather than a rotated circle). The larger bounding box means the focus is closer to the perimeter and the gradient is spread out more. The bounding boxes for the two vertical instances are not expanded at all because the rotation is 0 or 180°, but the four side images are expanded. If my theory is correct, the expansion can be countered with gradientUnits=userSpaceOnUse instead of the default objectBoundingBox.
Glrx (talk) 15:19, 2 October 2018 (UTC)
It may also be the rotation of the hydrogen expanding the box. A simpler test would temporarily delete the hydrogen and see if all the oxygen then look the same. Glrx (talk) 15:36, 2 October 2018 (UTC)
I noticed that the transform is not 180° it is transform="rotate(178)", therefore I was wondering. (Or do you think rotation(0.98888...*π (rad)) is rounded to rotation(1*π (rad))?)  — Johannes Kalliauer - Talk | Contributions 15:42, 2 October 2018 (UTC)
A rotation off by 2° would make little visual difference on the bounding box. I would have made the rotations multiples of 60°, but I kept the angle distribution of the original. I was going to keep the radial distribution, but the molecules on the left were all closer than the right, so I just made them the same.
I should look at this some time; I think the hydrogens will not make a difference because I only do gradient fills on circles/atoms rather than molecules. I don't know if the SVG standard specifies how bounding boxes are computed. At the same time, I want a better understanding of symbol and marker. Glrx (talk) 16:35, 2 October 2018 (UTC)

Your edit on File:Indonesia (orthographic projection).svg[edit]

Hi. After you added colour-shading on the map, you did not include Riau Island Province (Natuna Islands). Do you mind to fix that? Thank you Badpuccini (talk) 14:09, 7 October 2018 (UTC)

@Badpuccini: Thanks ✓ Done  — Johannes Kalliauer - Talk | Contributions 14:29, 7 October 2018 (UTC)

LibrSVG workaround[edit]

I have just fulfilled your old request. Please check if everything is fine. --jdx Re: 11:40, 10 October 2018 (UTC)

Thanks! :-D  — Johannes Kalliauer - Talk | Contributions 20:01, 10 October 2018 (UTC)

Another librsvg bug[edit]

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?

Thanks,
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)

File:Emblema Buenos Aires 2018 youth olympic games.svg[edit]

Hi. You added PD-font to Emblema Buenos Aires 2018 youth olympic games.svg, but I don't believe that's correct:

  • It's weird for the image to be simultaneously CC-BY and PD licensed.
  • PD-font only applies to raster renderings (e.g. PNGs). Maybe you meant PD-textlogo?

TilmannR (talk) 18:55, 18 October 2018 (UTC)

Thanks a lot for your help on File:Well_to_Wheels_(kWh)_-_Dual_Language_En+De_Original.svg[edit]

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[4] 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)

Creator:Johannes Kalliauer[edit]

Commons-emblem-issue.svg
Creator:Johannes Kalliauer 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 creator, 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.

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 | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

~Moheen (keep talking) 05:30, 5 November 2018 (UTC)