User talk:Sarang

From Wikimedia Commons, the free media repository
Jump to: navigation, search

Sarang (talk:sarang) is primarily a user of the German Wikipedia. At the Commons, I mainly try to improve the categorization and to simplify SVG drawings.  My editsMy galleryRéfo galerieCorbelle galerieSVG-check

Filing cabinet icon.svg

SpBot archives all sections tagged with {{Section resolved|1=~~~~}} after 1 day. For the archive overview, see Archive/. The latest archive is located at Archive/2014.


Over-categorization

Over-categorization[edit]

There seems some improovement possible with categorization.
As far as now done,the Category:Crux is subcategory to Category:Constellations, a subcategory to categories Category:Astronomical objects | Category:Asterisms (astronomy) | Category:Sky.

Category:Crux containes 3 subcategories:

About categorizing astronomical objects, I do not know enough about that complicated structur what is subcat or parent-cat.

But a lot of Southern hemisphere flags, showing the Southern Cross, show as well the cross of the Union Jack of the United Kingdom. Many of these flags are categorized at Category:Southern Cross flags, and also at the parent Category:Crux.

Seems that some work should be done. -- Sarang (talk) 10:54, 27 May 2009 (UTC)

SVG and clipping[edit]

Hey there. Tuvalkin suggested I asked you about this: how well does the librsvg code deals with clipping? The possibility of using it came up about the new   (ÜWBo+l) series of icon (and I can think of a few other uses too), but it's not clear whether it is at all possible. Circeus (talk) 03:50, 4 October 2011 (UTC)

Hey Circeus. Clipping is just one possibility among others. I used it several times without any librsvg-problems, and I never heard about (enough problems elsewhere but not with clipping). I am using your technique drawing parts outside the visible box as well, with no problems. But user AnonMoos told me recently that "keeping drawing elements within the rectangle is desirable if the SVG file is to be re-used as general clip-art (see File:Flag of South Africa.svg)..." — I understand that there might be problems only if you use such SVG drawings outside Wikipedia (outside the reach of our librsvg) when not converted to PNG. I cannot see the need to avoid the often much cheaper possibility to have parts outside the view. May be you ask AnonMoos more about the consequencies of these, he knows a lot.
BTW: I saw that some drawings in Icons for railway descriptions/experimental are much too complicated. Anything larger than a few hundred bytes is unnecessarily full of redundancies. Quickly I redraw some of the icons ( BSicon exSTR-C.svg, BSicon 8031.svg, BSicon 6001.svg, BSicon DAMMel.svg) reducing them to 2%, 5%, 7% and 8% respectively. IMHO it would be a good idea to look a bit more on simplicity of such simple graphics; if you want some support there just ask me! -- sarang사랑.svg사랑 08:42, 4 October 2011 (UTC)
Yeas, I've been simplifying stuff along the line too. It's a side part to my proposal for a new all-encompassing naming scheme for BSicons, which may get accompanied by drawing standards (there is some ridiculous variation in bridges!) Circeus (talk) 20:43, 4 October 2011 (UTC)

Template:F[edit]

Hallo Sarang, mir ist gerade bei File:Kühlsen Drostehof.jpg aufgefallen, dass seit Deinem Umbau von Template:Derivative versions die Information-Vorlage nicht mehr wie gewohnt angezeigt wird, nämlich wenn die Option „other fields“ genutzt wird. Der graue Rahmen um das komplette Information-Zeugs schließt dann „other fields“ (hier: Namensnennung) nicht mehr mit ein. Gut sehen kannst Du den Unterschied, wenn Du bei diesem Bild in der Vorschau die „Derivative versions“-Vorlage entfernst (dann erscheint das Namensnennungs-Feld wieder als normaler Bestandteil des Infokastens). Ich vermute, dass Template:F ursächlich ist, und dass dort etwas fehlt oder zuviel ist, entdecke aber auf Anhieb nichts und hoffe, dass Du dieses Problemchen lösen kannst. Grüße --:bdk: 18:34, 14 October 2011 (UTC)

Hallo bdk, danke für die Nachricht. Bisher konnte ich die Ursache noch nicht lokalisieren, aber ich finde es noch heraus, und mache es bald wieder heile. Gruß -- sarang사랑.svg사랑 22:49, 14 October 2011 (UTC)
Fein, dank Dir schon mal :-) --:bdk: 00:23, 15 October 2011 (UTC)
Hallo bdk, das Problem hätte ich nun ermittelt; eine allen zusagende, perfekte Lösung ist weniger einfach.
Also, der graue Rahmen wird nicht von {{F}} unterbrochen, es liegt an der von {{Derivative versions}} erzeugten Liste, und war bereits vor meinen Änderungen so; das Problem tritt identisch bei {{Derived from}} auf.
Jede Liste im Element "other_versions" von {{Information}} zerschlägt den Rahmen! Sieh dir einfach mal an, was bei der Eingabe von |other_versions=*Test geschieht. Noch viel schlimmer wird es, wenn |Permission=*self eingegeben wird.
Die Liste lässt sich mehr oder weniger gut substituieren. Weniger gut, weil das manuelle <br> ungleiche Umbrüche erzeugt, und weil ich diesen blauen Bollen nicht so schön dick hinbekomme, mit • oder komme ich nicht hin (blau wäre kein Problem, aber das bringt es ja wohl nicht). Es gibt eine ganze Menge anderer Zeichen die verwendet werden könnten, z.B. . In Kühlsen Drostehof.jpg habe ich es mal mit ⇒ versucht und weiss bereits jetzt, dass das vielen nicht gefallen würde...
Eine Möglichkeit wäre es mit Disc Plain blue.svg zu versuchen — ich habe da etwas für diesen Zweck besser geeignetes gezeichnet, wenn die Bullet-Darstellung mit einer Datei erfolgen soll, das "Bbullet12.svg", es kann noch beliebig angepasst werden.
Nun gibt es auch die Vorlage {{bullet}}, die so ein Ding   erzeugt. sarang사랑 20:08, 17 September 2013 (UTC)
Vorerst habe ich das nur in {{Derivative versions}} eingebaut. Wir können das hier weiterdiskutieren und nach besseren Lösungen suchen. Gruss -- sarang사랑.svg사랑 09:12, 15 October 2011 (UTC)
Hallo bdk, der Änderung in {{Derivative versions}} war nur sehr kurzes Leben beschieden, sie ist nach zwei Minuten zurückgesetzt worden. Die Situation ist ja eigentlich so, dass es nur ein work-around war für ein Problem, das tatsächlich in {{Information}} liegt, bei den Elementen Permission und other_versions; diese Vorlage ist heavy used, und um einiges komplizierter. Aber ich werde sie mir mal gelegentlich ansehen. Du könntest auch das lokalisierte Problem der Vorlagenwerkstatt melden, die haben Fachleute für so was. Gruss -- sarang사랑.svg사랑 09:28, 15 October 2011 (UTC)

Texteditor für SVG[edit]

Moin, ich bin von deinen Ideen (und Fähigkeiten) zur Bekämpfung aufgeblähter SVG wirklich begeistert und habe mir schon einige Inspiration für die Arbeit mit dem Texteditor geholt. Ich vermisse allerdings immer wieder hilfreiche Tools für diese Arbeit: Umwandlung von absoluten in relative Angaben; transformierte Pfade in normale Pfade mit neuen Koordinaten umzuwandeln... Eigentlich ist das ja nur Mathematik :) Hast du dafür etwas in Nutzung oder eine Idee? Und hast du zufällig Erfahrungen mit Programmen wie Scour, die einen Teil des Überhangs per WYSIWYG erstellter SVGs entfernen wollen? Vielen Dank für deine inspirierende Arbeit hier.. --Richtest (talk) 12:28, 8 December 2011 (UTC)

Hallo RichTest, es freut mich immer sehr zu sehen dass ich doch nicht als einziger an den redundanzüberfrachteten SVGs Anstoss nehme. Allerdings muss ich gestehen dass ich nicht nur null Erfahrung mit SVG-Programmen wie Inkscape&co habe, ich wende auch sonst sehr primitive Methoden an. Scour kenne ich nicht. Zum Editieren finde ich Notepad++ ausreichend, und die von dir angefragten Umrechnungen absolut→relativ bzw. Transformationsauflösungen lasse ich von Microsoft Excel errechnen, trotz mancher Mängel; die Relativierung kubischer Béziers ist damit etwas komplizierter, umso einfacher ist das Runden zur Reduzierung der Nachkommastellen. Für Zwischenkonversionen verwende ich noch andere MS-Programme wie das dafür sehr hilfreiche Word mit Macros. Falls dich solch primitive Hilfsmittel näher interessieren verrate ich dir gerne mehr, damit du nicht alles neu erfinden musst.
Es wäre natürlich grossartig dafür ein leistungsfähiges Programm zu haben, mit ausreichend Einstellmöglichkeiten und dennoch leicht zu bedienen… Bis so was gefunden (oder erfunden) wird mache ich mit meiner umständlichen Methode weiter. Und vieles dürfte einer automatisierten Bearbeitung kaum zugänglich sein, da bedarf es weiterhin menschlicher Interaktion. Wenn ich Grund zur Annahme hätte dass das noch mehr Benutzer interessiert könnte ich für sie eine Art Diskussionsportal einrichten, irgendwo im Umfeld von SVG Simplified. Es kommt noch dazu dass ich kaum neue Grafiken entwickle, stattdessen zeige ich beispielhaft bei den allerärgsten Hämmern wie es anders sein könnte.
Natürlich interessiert mich auch an welchen speziellen Grafiken du gerade bastelst. Gruss, -- sarang사랑.svg사랑 14:12, 8 December 2011 (UTC)
Hmm, also ich hab dieses Jahr mein erstes SVG gebastelt (Karte mit Openstreetmap-Daten), und dann ein paar simple Symbole: BSicon HANDCAR.svg BSicon DRAISINE.svg. Diese sind aber nicht aufs letzte Byte, sondern auf mein Verständnis hin optimiert. Habe mir (allerdings eher als Spielerei) auch schon mal kleine Programme geschrieben, die SVG-Dateien erstellen, zum Beispiel mit Zufallsgeneratoren.
Für Karten ist Inkscape o.ä. unerlässlich, aber die Ergebnisse ungeheuer aufgeblasen und ohne SVG-Eleganz. Aber bei 300kB SVG Ausgangsmaterial ist halt nix von Hand zu machen, wenn man nicht alles nachzeichnen will. Das mit Excel klingt sehr spannend, auch wenn ich mir gerade nicht vorstellen kann, wie du das gemacht hast.. Ich schick dir über de.wp mal ne Mail, vielleicht hast du Lust, mir das mal zu schicken, ist vielleicht einfacher als alles zu erklären. Vielen Dank -84.169.181.193 14:54, 8 December 2011 (UTC)
Ganz ausdrücklich beschänke ich mich auf einfache und einfachste Grafiken, also so was wie deine beiden BSicons. Natürlich lässt sich Aufwendigeres wie Karten nicht mehr von Hand zeichnen – aber immer noch anschliessend überarbeiten, mit tools und auch manuell, um zu einem akzeptablen Ergebnis zu gelangen.
Wie gesagt mache ich das meiste mit nur sehr geringer Unterstützung durch Automatismen. Wenn ich dir meine Vorgehensweise erkläre wirst du sicher Verbesserungsmöglichkeiten erkennen. Ich habe noch das "alte" Windows, XT glaube ich, die Officeprogramme sollten kompatibel sein, falls du moderner bist. Deine Mail ist angekommen, ich werde nun was zusammensuchen und -schreiben. -- sarang사랑.svg사랑 15:13, 8 December 2011 (UTC)
Hat zwar eigentlich mit deinem Ansatz nix zu tun, aber ich hab Scour mal ausprobiert, das reduziert fast auf die Hälfte bei meiner Karte, entsorgt viel Ballast, aber versteht natürlich nix, fürs automatische Gruppieren von Elementen aber ganz nett. Freu mich auf deine Mail, evtl. kann ja daraus eine Art Simple-SVG-Tutorial für Commons werden. -Richtest (talk) 16:17, 9 December 2011 (UTC)
Dass Scour ein leistungsfähiges tool sei und generell angewandt werden sollte habe ich früher schon gehört; wir könnten das deutlicher publik machen.
Leider habe ich noch nicht geschafft, ein übersichtliches Rezept für Simplifizierungen zu editieren. Auf die Schnelle habe ich in File talk:BSicon DRAISINE.svg ein paar Anmerkungen notiert, die dich vielleicht interessieren (Englisch ist nicht meine grosse Stärke, wenn du meine Texte verbesserst bin ich dir dankbar). Am Rezept bastele ich noch. Auch im Hinblick auf ein ev. Tutorial - wenngleich mir meine Methode etwas zu primitiv erscheint. -- sarang사랑.svg사랑 16:57, 9 December 2011 (UTC)
Ok, mit der DRAISINE hast du dir ja wirklich Arbeit gemacht, danke. Du scheinst wirklich ein Byte-Fuchser zu sein, das ist ja schon eine eigene Wissenschaft. Ich versuche allerdings meine SVGs lieber so zu erstellen, dass ich auch später noch verstehe, wozu was dient. Und das könnte ich nach deiner Radikalkur wohl nicht mehr ohne weiteres, auch wenn das vermutlich Übungssache ist. Plattenplatz im Byte-Bereich ist mir allerdings auch nicht so wichtig :) --Richtest (talk) 22:44, 9 December 2011 (UTC)

Das weiss ich schon dass ich da masslos übertreibe, alles Unnötige radikal wegzulassen; zur Leserlichkeit, da hast du recht, sollten wieder ein paar Zeichen mehr rein. Die Draisine ist ein Beispiel, beim Handcar liesse sich (in der Relation) mehr einsparen. Ich habe die Draisinengrafik nicht hochgeladen, wenn du sehen willst ob wirklich dasselbe gezeigt wird musst du es erst ausprobieren. -- sarang사랑.svg사랑 00:19, 10 December 2011 (UTC)

BSicon HANDCAR.svg Herausforderung angenommen: File Talk:BSicon HANDCAR.svg. Viel Spaß, ich glaube, ich hab es dir nicht zu leicht gemacht. Ich hab leider gerade wenig Zeit, um das Thema wirklich anzugehen, aber ich werd deine Mail nicht vergessen.. Danke --Richtest (talk) 01:32, 10 December 2011 (UTC)

Gratulation - das hast du ausgezeichnet hinbekommen. So sollten IMHO einfache SVGs erstellt werden! Wie Inkscape, Adobe &Co so was machen würden weisst du ja… Bei hinreichendem sportlichen Ehrgeiz lassen sich an bereits vereinfachten Grafiken immer wieder noch einzelne Bytes sparen, wobei der relative Aufwand dafür extrem ansteigt, und das Ganze immer mehr zu Lasten der Leserlichkeit geht. Ein recht krasses Beispiel ist die letzte, 6. Variante von Iching-hexagram-64.svg Iching-hexagram-64.svg diskutiert in File talk:Iching-hexagram-64.svg. Dessen 5. Version ist sehr elegant, die 6. jedoch schlichtweg nicht mehr verständlich. Speziell bei Serien erscheint es sinnvoll, ein brauchbares Muster zu haben, aus dem dann mit minimalen Anpassungen alle anderen Grafiken entwickelt werden können, wie in SVG simplification templates angedacht. Bei den BSicons gibt es vielfach auch Kleinserien von ±12 Grafiken, wie bei denBSicon ABZdf.svg-Variationen. So ein Muster sollte vor allem mit geringem, Aufwand varierbar sein und dafür nicht bis zum allerletzten Byte minimiert. -- sarang사랑.svg사랑 11:46, 10 December 2011 (UTC)

Mir ist gerade Wikiprojekt SVG #Manuell erstellte SVGs aufgefallen. Dort sollte man zumindest mal was dazu schreiben, wie die Vorteile aussehen und co.. -Richtest (talk) 20:53, 12 December 2011 (UTC)

Different SVG styles[edit]

The only SVG I've made from scratch which uses stroke-dash is File:Overhand-folded-ribbon-pentagon.svg (as far as I remember), while you seem to be constantly attempting to come up with new and innovative ways of making use of dashing... SFriendly.gif -- AnonMoos (talk) 13:58, 14 December 2011 (UTC)

Dashing seems really often a good way to minimize a drawing. Many files in Checkered could be drawn that way, and in many other cases it makes things easy, even when the first glance does not show dashed lines.
It had not been an option for Broken crossed circle.svg because its line ends, so I made it this time rather complicated with clipping twice instead. Sure a better solution can be found, at least the drawing is exact, even strict mathematically.
With Broken crossed circle 2.svg I had again troubles with the librsvg bug, it took ".16" for "0" and before I changed it to "0.16" (which will work) you remade in a good way. Thank you -- sarang사랑.svg사랑 17:33, 14 December 2011 (UTC)
I was motivated to change File:Broken crossed circle 2.svg as much as by the errors in the description and filename as anything. I changed the English description, but the German one is still inaccurate -- it's really not a cross, and it has only a somewhat remote relationship with a swastika... AnonMoos (talk) 19:21, 15 December 2011 (UTC)
I shall care for the German description -- sarang사랑.svg사랑 21:50, 15 December 2011 (UTC)

Feeling quite Sarang-ish today[edit]

File:Optical-illusion-diamonds.svg is the first SVG I made with a dashed line as wide as it is long... SFriendly.gif -- AnonMoos (talk) 14:14, 13 April 2012 (UTC)


Good and interesting work! I changed the template for two reasons:

  1. now it is tagged "valid SVG" and the validator displays the source code, and
  2. it is now an example in the dasharray-subcategory of SVG simplification technics where I am collecting some hints (if anybody will give them a look ...).

Do you have more ideas for the technics collection? -- sarang사랑.svg사랑 14:59, 13 April 2012 (UTC)

Probably should be spelled "techniques"... SFriendly.gif -- AnonMoos (talk) 15:03, 13 April 2012 (UTC)
Thank you. I am always fighting for good English, without success 사랑.svg. Changing a category name is a bit complicated, but if you improve some of may sentences: just go ahead! At SVG simplification by cloning I tried to explain what I called "cascaded cloning" (I am fearing my description is not very clear; this technique would reduce the number of "use"s in your drawing. -- sarang사랑.svg사랑 15:28, 13 April 2012 (UTC)
"Cascaded" is OK; "nested" could also be used... AnonMoos (talk) 16:31, 13 April 2012 (UTC)

Chess piece simplification[edit]

Thank-you for your edits to the yellow bishop. There are many other chess pieces, so if you are interested in doing one of each, I'll happily recreate the other colours and variations of them.  :) NikNaks talk - gallery - wikipedia 14:50, 26 December 2011 (UTC)

Of course I can give it a look, and do it time by time. If you look for the differencies you may see that it is not at all difficult but nevertheless it's some work needing time. -- sarang사랑.svg사랑 17:17, 26 December 2011 (UTC)

Knots[edit]

Actually, the serious mathematicians at http://katlas.org/ would consider me a mere tyro, since my interest is more on the quasi-decorative or ornamental uses of knots, not the basic mathematics. However, you can see my knot atlas home page (currently not fully updated) at http://katlas.math.utoronto.ca/wiki/User:AnonMoos ...

As for File:9crossings knot.svg, it's not mathematically a "knot" at all, unless the over-under interlacings are shown. If the interlacings are alternating, then it's a "7 4 knot", or Buddhist Endless Knot... AnonMoos (talk) 15:41, 27 December 2011 (UTC)

File:Chenhao2007SHIFF.jpg[edit]

Analyzed at http://katlas.math.utoronto.ca/wiki/8_18 . File:Celtic-knot-twoloops-bigends.svg has 14 crossings, and is mathematically technically a "link", not a "knot"... -- AnonMoos (talk) 17:18, 27 December 2011 (UTC)

SVG problem[edit]

Do you have any idea why the "14:50, 2 February 2012" version of File:No Logo logo.svg doesn't display correctly? It seems to be a bug, but if so, it's a rather strange one, and I don't know how to avoid it... AnonMoos (talk) 16:04, 2 February 2012 (UTC)

Oops, never mind, as soon as I posted this message, I finally saw the problem (had been assuming that a duplicate of the "N" outline was the "L" outline...). AnonMoos (talk) 16:10, 2 February 2012 (UTC)
Sometimes it's really difficult; and from time to time somebody else can help. That is the Wikipedia community. -- sarang사랑.svg사랑 16:15, 2 February 2012 (UTC)

File:AFEMRib.svg[edit]

LOL. I didn't think it was possible to minimize it any more. Nice work. Magasjukur2 (talk) 08:50, 13 February 2012 (UTC)

You did really good simplification work. But some reductions remain still almost always as a possibility. -- sarang사랑.svg사랑 08:55, 13 February 2012 (UTC)

Category talk:SVG simplified Coats of Arms[edit]

I was inspired by the discussion there, and the shield shape SVGs I included on that page to create a personal coat of arms for myself. Sorry that the SVG file is a hulking behemoth, weighing in at a huge 11kb, but the shield and its contents by themselves (omitting the triskelion and motto text converted to paths) would be a mere 2kb... AnonMoos (talk) 02:20, 16 March 2012 (UTC)

It looks really good! Lots of your work lead to a remarkable success. Good idea to document all its history and that of its components. sarang사랑.svg사랑 06:37, 16 March 2012 (UTC)
I took the freedom to reduce the size there on the talk page
It doesn't compare artistically to what User:Sodacan does, but it seems to work in its own little semi-paradoxical way... SFriendly.gif -- AnonMoos (talk) 23:53, 16 March 2012 (UTC)
Following your hint I looked at the pix of User:Sodacan; I admire this. But for my part, I restrict to my good old simple SVGs. sarang사랑.svg사랑 11:28, 17 March 2012 (UTC)

File:宿-5BBF.gif[edit]

Making a GIF transparent in cases such as this means thumbnails will have a relatively low quality (the transparent area eats away at the black area, so that small text will quickly become illegible)... AnonMoos (talk) 07:27, 19 March 2012 (UTC)

Thank you, I didn't know that. Now I can care in future; but I use GIF rather seldom and only for intermediate reasons, when SVG seems too much effort. Depending the case of this picture, I should rather remove the text from the picture, the explanation given in the description is more useful.
Sure you have seen that I redrew some extremly simple pics of Sodacan, when Sodipodi/Inkscape seems to me not such a good choice, as with this chakra Flag Thai Admiral.svg. sarang사랑.svg사랑 08:27, 19 March 2012 (UTC)

Possibly interesting SVG file[edit]

File:Op-art-4-sided-spiral-tunnel.svg has an unusual structure; it's highly repetitive, yet I'm not sure that the repetitive parts can be collapsed... AnonMoos (talk) 08:02, 30 March 2012 (UTC)

Good job on condensing; I had some difficulty in understanding how File:Op-art-4-sided-spiral-tunnel-6.svg etc. worked at first, but eventually managed to optimize the original file in the same way... AnonMoos (talk) 15:02, 31 March 2012 (UTC)

256x256 - Matrix[edit]

Hallo Sarang.
Vielleicht findest du etwas Zeit meinen Code für das Gitter in File:4-ary Boolean functions; matrix gbec; 1.svg zu verbessern. Ich habe viel mit Klonen gearbeitet um es einigermaßen schlank hinzukriegen, aber du findest bestimmt was Überflüssiges. Ich werde dieses Gitter oft benutzen, es lohnt sich also. Die Ebene entries brauchst du dir nicht anzusehen. Grüße, Lipedia (talk) 01:28, 20 May 2012 (UTC)

OK, ich schau mal. Bis bald sarang사랑.svg사랑 09:19, 20 May 2012 (UTC)
Jetzt habe ich es mir angesehen. Es ist viel einfacher als ich erst dachte, denn die breiteren Trennstriche verschieben die Quadrate nicht, sondern nehmen den benachbarten ein wenig Platz weg; das ist nicht ganz exakt, aber einerseits nicht zu sehen und somit ausreichend; andrerseits wäre die Berechnung für die farbigen Quadrate sehr umständlich, wenn die weiter rechts und unten stehenden immer um diese Pixelbruchteile verschoben wären. Das Gitter geht also sehr einfach zu zeichnen.
Immer wieder bin ich verblüfft wieviel unsinnigen Code Inkscape-Sodipodi zu erzeugen imstande ist. Z. B. das farbige Quadrat mit M 255 127 L 256 127 L 256 128 L 255 128 L 255 127 z. Die letzten paar Zeichen (L 255 127) und (z) sind äquivalent, eines davon würde genügen, und es sind sogar beide überflüssig. Der Code M255,255h1v1h-1 leistet genau dasselbe, wobei nur die beiden Koordinaten nach dem "M" variert werden müssen, das "h1v1h-1" bleibt für jedes der 256 × 256 möglichen Quadrate gleich (sog. relative Koordinaten: 1px horizontal nach rechts, 1 vertikal runter, 1 horizontal nach links - das ist es!). IMHO erhöhen die vielen redundanten Leerzeichen die Leserlichkeit keineswegs.
Ich werde schnell eine simplifizierte Version erstellen, die genau dasselbe zeichnet. Dauert noch ein wenig.
Wie erstellst du die Variationen? Wird das von einem Programm umgesetzt, oder machts du die Einträge manuell? sarang사랑.svg사랑 15:08, 20 May 2012 (UTC)

Ja, das Gitter ist einfach. Ich weiß nur nicht wie viel von dem Header Müll ist - oder vielleicht gebraucht wird, damit die Klone funktionieren. Ich halte es nicht für sinnvoll die farbigen Pfade in Ebene entries stark zu vereinfachen - abgesehen davon, dass ich die Startpunkt-Endpunkt-Redundanz und überflüssige Zeichen weglassen könnte. Ich habe in MATLAB ein Programm namens bin2svg.m geschrieben, das mir eine Binärmatrix in den Code für einen SVG-Pfad umwandelt. Das könnte ich in Details leicht ändern, aber ich habe wenig Lust auf Änderungen, die nur für Rechtecke Sinn ergeben (M255,255h1v1h-1), weil die meisten Pfade vermutlich keine Rechtecke sein werden. Wenn es dir Spaß macht, kannst du natürlich bin2svg.m überarbeiten. Lipedia (talk) 15:55, 20 May 2012 (UTC)

Können wir vielleicht die Details am Telefon besprechen? Du kannst mir ja eine Festnetznummer mailen. Sonst stelle ich es halt schriftlich zusammen, was es an Möglichkeiten gibt. sarang사랑.svg사랑 15:50, 20 May 2012 (UTC)

Ich glaube das Thema ist schriftlich am besten zu lösen. Willst du den Code für bin2svg.m? Lipedia (talk) 15:55, 20 May 2012 (UTC)

Gut, schriftlich. Ich würde auch die Transformationen weglassen, dazu müsste einen von mehrenen möglichen Anpassungen gewählt werden: das ganze kleiner, 256 × 256 + die Ränder; wenn du die Grösse 780 × 780 beibehalten willst, ginge das unwesentlich komplizierter mit viewBox. in beiden Fällen funktioniert die Färbung mit beiden oben gezeigten Methoden, der umständlichen und der kurzen.
Die größere Version geht auch ohne viewBox, dann müssten allerdings die Koordinaten den dreifachen Wert + 6 angeben, und h3v3h-3 zum Zeichnen (wenn es ohnehin per Programm errechnet wird wäre das wohl egal).
Oder eben doch mit Transformation.
Ich kann dir Muster machen von allen Möglichkeiten, oder du legst vorab fest was dir am ehesten liegt; dann mache ich das und du kannst es dir ansehen. sarang사랑.svg사랑 16:14, 20 May 2012 (UTC)

Mir ist gerade was seltsames passiert: Ich wollte dir als Muster File:Hadamard-Code.svg zeigen (mit bin2svg.m erstellt), aber beim Hochladen ging <?xml version="1.0" encoding="UTF-8" standalone="no"?> verloren. Verstehst du das?
Ich dachte mir schon, dass du die Transformation weglassen willst, aber ich will die Dinger auf jeden Fall in ordentlicher Größe auf der Beschreibungsseite, und andererseits würde ich den Output von bin2svg.m gern unverändert einbauen. Finde ich irgendwie eleganter.
Da die kleine Matrix nicht wollte habe ich jetzt mal File:Binary Walsh matrix 256.svg als Beispiel hochgeladen an dem man sieht wie mein Programm gegenwärtig die Pfade erstellt. Selbst bei diesem komplizierten Muster ist die Dateigröße moderat, ich sehe also keinen dringenden Verbesserungsbedarf bei den Pfaden. Nur der Header und das Gitter sind halt sehr unaufgeräumt. Lipedia (talk) 16:52, 20 May 2012 (UTC)

Gut, Tilman, ganz wie du willst. Im Header ist fast alles unnötig, und wenn nicht geklont wird ist auch "xmlns:xlink" überflüssig. Und das Gitter geht sehr einfach. Ich mache dir jetzt eine einfache Version von 4-ary Boolean functions; matrix gbec; 1.svg mit deinen Pfaden, auch wenn sie viel komplexer sind als nötig. Wie soll ich es machen - über deine Version laden, oder als Code in die Talkpage stellen? sarang사랑.svg사랑 17:07, 20 May 2012 (UTC)

Lad einfach drüber. Detailverbesserung an den Pfaden könnte ich noch mit einbauen. Wie würdest du
M 3 1 L 4 1 L 4 3 L 3 3 L 3 4 L 1 4 L 1 3 L 2 3 L 2 2 L 3 2 L 3 1 z
schreiben? (Das ist die zweite Pfadzeile in File:Binary Walsh matrix 256.svg.) Lipedia (talk) 17:27, 20 May 2012 (UTC)

Mal sehen: von Position 3,1 nach 4,1 geht mit h1; von 4,1 weiter nach 4,3 geht mit v2; von dort nach 3,3 geht mit h-1 (oder H3); runter nach 3,4 mit v1; nach links von 3,4 auf 1,4 mit -h2 (oder H1); rauf nach 1,3 mit v-1 (oder V3); mit h1 nach 2,3; mit v-1 nach 2,2; mit h1 nach 3,2; wenn es wie in der Walsh Matrix eine gefüllte Struktur ist reicht das, bei nur Umriß (fill="none") geht es mit "z" nach 3,1.
Also entweder verschieblich M3,1h1v2h-1v1h-2v-1h1v-1h1(z) oder absolut M3,1H4V3H3V4H1V3H2V4H3(z) (wenn ich mich nicht vertan habe...). Absolute Koordinaten können grössere Zahlenwerte benötigen, hier bei diesen Werten nahe dem Ursprung wird es durch das Vorzeichen länger. Natürlich kann absolute und relative Angabe gemischt werden, der Vorteil bei relativen ist die Verschieblichkeit - nur die Anfangskoordinaten müssen geändert werden.
Ich glaube das Klonen war nicht ganz korrekt, doch habe ich es nicht geprüft; jedenfalls sieht die 4-ary-Bool von mir etwas anders aus, regelmäßiger.
Jetzt habe ich die umständlichen Pfade drin, soll ich sie doch vereinfachen? sarang사랑.svg사랑 18:02, 20 May 2012 (UTC)
Beide Versionen sind jetzt hochgeladen, erst absolut, dann darüber relativ. Eventuell könnten die Strichstärken variiert werden?
Was beim Hadamard-Hochladen passiert ist kann ich mir auch nicht erklären, jedenfalls habe ich es heile gemacht. Ich hoffe ich konnte dir so helfen, wie du es wolltest. sarang사랑.svg사랑 18:49, 20 May 2012 (UTC)

WTF - echt beeindruckend, danke. Ich hätte nie gedacht, dass man das Gitter so klein kriegt. Jetzt verstehe ich auch deine Art die Pfade zu vereinfachen. Das müsste ich hinkriegen, mein Programm so zu verändern. Lipedia (talk) 20:10, 20 May 2012 (UTC)

Hallo Timan, da bin ich ganz sicher dass du das hinbekommst; die Programmierung sollte sogar um einiges einfacher werden als bisher. Natürlich könnte da noch viel weiter minimiert werden, aber es muss ja auch nicht übertrieben werden; wenn die ärgsten Inkscape-Redundanzen eliminiert werden ist schon viel gemacht. Wenn dir noch was nicht so klar ist mit SVG: frage mich, einiges weiss ich mittlerweile, und auch dokumentiert ist bereits manches in SVG simplification techniques. Ich werde da noch was reinstellen über Koordinaten, vielleicht gelingt es mir das verständlich darzustellen.
Ich habe null Ahnung von MATLAB, aber dein Programm interessiert mich, sicher kannn ich da von dir viel lernen. Ich mache bisher solche Berechnungen sehr primitiv mit EXCEL, mit externer Rumkopierei… ganz archaisch! Gruß sarang사랑.svg사랑 06:51, 21 May 2012 (UTC)

Hallo Tilman, ich konnte es doch nicht bleiben lassen dir noch die Variante mit relativen Parametern zu zeigen, da ändert sich "M" zu "m" und bei den höheren Zahlwerten wird einiges gespart. Ob du das in dein Programm einbauen willst wirst du entscheiden, die Berechnungslogik ist trivial (auch für eine eventuelle Wieder-Absolutierung; falls größere Änderungen anstehen, denn mit absoluten Werten ist alles viel flexibler. Ich habe mir Hilfsmittel zur Konvertierung in beide Richtungen erstellt.)
Bei Grafiken wie der Walsh matrix wäre der Spareffekt viel signifikanter.
Nur aus Gründen der besseren Lesbarkeit habe ich jedes Quadrätchen in einer Zeile belassen, eine Variante ohne linefeeds innerhalb der Pfaddaten wäre mit 868 bytes um 30 Stellen kleiner. Aber wir wollen ja nicht übertreiben, und den Code inspizierbar lassen. sarang사랑.svg사랑 14:14, 21 May 2012 (UTC)

So - hab mein Programm überarbeitet und veröffentlicht: v:User:Lipedia/bin2svg
Hast du was gegen große Ms? Siehe File:Hadamard-Code.svg und File:Binary Walsh matrix 256.svg.
Lipedia (talk) 20:53, 24 May 2012 (UTC)

Sieht gut aus! Dass es was gebracht hat und viel einfacher ist, siehst du ja selbst. Grosse "M" bedeuten: absolute neue (Move-to) Position, wenn kein neuer Kommandobuchstabe folgt werden die folgenden x/y-Parameter behandelt wie wenn ein "L" codiert wäre. Kleines "m" bedeutet die Werte sind die relative Verschiebung zur aktuellen Position (wenn es das erste Zeichen eines path data-strings ist ist es natürlich eine absolute Position), und es wird ein "l" impliziert wenn kein Kommandobuchstbe folgt.

Bei Hadamard folgt immer ein Kommando, somit entfällt die Bedeutung für die Folgeposition.

Da es meist lange Ketten von v/h-Kommandos enthält, wird die Einsparung durch das relative "m" nicht allzu berauschend werden; andrerseits wäre es bei den durch Programm erzeugten Parametern sicher leicht, stets die aktuelle Position zu wissen und statt "M" relativ zu codieren. Das Programm könnte sogar vergleichen was weniger Zeichen benötigt und dann je nachdem "M" oder "m" ausgebeben... Aber wie gesagt, das Programm müsste erweitert werden, und der Effekt wäre nicht mehr so dramatisch wie bei dem was du bereits erzielt hast. Wenn es dir Spass macht, der Sache wegen, nur zu; wennn nicht kannst du auch sehr zufrieden sein mit deinem Erfolg. Jedenfalls finde ich es gut codiert und ich habe nichts daran zu meckern. Glückwunsch zum Erfolg! sarang사랑.svg사랑 20:59, 24 May 2012 (UTC)

Bin2svg icon.svg
Eben ist mir aufgefallen: Codierungen wie M5,5h1v1h-1v-1 können noch etwas vereinfacht werden, ohne das "schließende" v-1 wird genau dasselbe gezeichnet. Äquivalent wäre M5,5h1v1h-1z, aber das v-1 (oder in diesem Fall V5) oder z wäre nur für die Umrisslinie (stroke="#???") erforderlich, während Flächen (fill="#???" bzw. implizit black) automatisch zum (letzten) M/m-Ausgangspunkt hin geschlossen werden (Svg example fill.svg Svg example fill.svg). Allerdings gilt das nicht für die aktuelle Position, die wird nur dann zum Ausgangspunkt zurückgeführt wenn es auch so codiert ist. Zu deiner Information, falls du es noch etwas schlanker haben möchtest. Nachtrag: In 4-ary Boolean hatte ich das Grün etwas geändert, weil IMHO #0F0 etwas zu hell ist, #0C0 passt weit besser zum Rot. sarang사랑.svg사랑 04:16, 25 May 2012 (UTC)

Die Kleinigkeit mit der letzten Koordinate habe ich noch geändert. Optimieren könnte man jetzt endlos. Dir wird nicht entgangen sein, dass man ein Schachbrett mit acht statt 32 Rechtecken zeichnen kann, und dann gibt es ja noch Klone. File:Binary Walsh matrix 256.svg schreit natürlich nach Klonen, auch File:4-ary Boolean functions; matrix ggbec; 55424.svg könnte man auf etwa ein Achtel eindampfen. Man könnte sicherlich einige Monate seines Lebens mit der Optimierung von bin2svg verbringen. Mich irritiert gerade eher, dass ich bei deinem Gitter in Inkscape die dünnsten Linien nicht sehen kann (oder nur vereinzelt). Stört mich ja nicht so lange sie hier zu sehen sind, ist aber seltsam. Lipedia (talk) 21:04, 25 May 2012 (UTC)

Natürlich könnte man noch endlos rumspielen und sich einen verkünsteln - da jedoch der nun erreichte Status sowohl gut strukturierten & leserlichen Code enthält als auch praktisch ballastfrei ist, hast du dein Ziel erreicht: über eine sinnvolle Ausgangsbasis für viele weitere Matrices zu verfügen.
Das mit den "dünnsten Linien…" konnte ich nicht verstehen, dass sie nur vereinzelt aber hier doch zu sehen seien. Klärst du mich bitte auf?
Die der Matrix innewohnende mathematische Logik habe ich noch nicht angesehen, wo sich Strukturen wiederholen und wie weit Kloning möglich ist. Wenn diese Logik allen Matrizen gemeinsam ist und bei dichter besetzten Gittern entsprechend viel einsparen lässt, wäre es natürlich schon etwas von ästhetischem Reiz, das wir überlegen könnten. sarang사랑.svg사랑 05:43, 26 May 2012 (UTC)

Es gibt die dünnsten Linien im Gitter, durch die man 256x256 u nd nicht nur 64x64 Quadrate sieht. Die sehe ich auf Commons, aber nicht wenn ich die Datei in Inkscape aufmache. Lipedia (talk) 07:04, 27 May 2012 (UTC)

Die dünnsten Linien der Einzelquadrate habe ich mit 0,03 px definiert, das px wiederum kann mit 0,01 mm angenommen werden. In der 2000er Vergrößerung ist die Linie gut zu sehen, bei kleinerer Darstellung natürlich weniger. Gerne kannst du es mit anderen Strichstärken versuchen, doch bleibt es grenzwertig, in einer Grafik 256 × 256 Quadrate darstellen zu wollen: in Gesamtsicht verschwinden da die Einzellinien zu Schatten, und in starken Vergrößerungen sind nur mehr Teilbereiche anzeigbar. Bei SVG kann es in verkleinerten Übersichten auch wesentlich anders aussehen wenn Strukturen genau auf Pixelgrenzen oder daneben definiert sind.
Was Inkscape zeigt habe ich noch nicht untersucht, für SVG offline verwende ich Firefox (und fallweise Windows IE), die vieles anders anzeigen als der Wikimedia renderer librsvg. Von den unterschiedlichen Macken dieser tools abgesehen, wird es bei derart feiner Strukturierung nie unproblematisch sein. Die Variante mit dasharray ist eine von vielen Möglichkeiten, und jede Variante kann in der Verkleinerung (als thumbnail) anders wirken. Übrigens, während der Entwicklung habe ich die Grafik mit viewBox extrem vergrößert, um die Details deutlich sehen zu können - so habe ich mich auch um größtmögliche Annäherung an deine Ursprungsgrafik bemüht. sarang사랑.svg사랑 06:25, 28 May 2012 (UTC)


Signature[edit]

Please change your signature. Per Commons:Signatures#Images_in_signature, images of any kind must not be used in signatures. Thank you --Gauravjuvekar (talk) 17:25, 23 June 2012 (UTC)

✓ Done. sarang사랑 17:34, 23 June 2012 (UTC)


Message tied up in Ribbon.jpg Hello, Sarang. You have new messages at MGA73's talk page.
You may remove this notice at any time by removing the {{Talkback}} or {{Tb}} template.

Asturianu | Беларуская (тарашкевіца)‎ | বাংলা | Català | Čeština | Deutsch | Deutsch (Sie-Form)‎ | English | Español | Suomi | Français | Galego | हिन्दी | Magyar | Italiano | 日本語 | ქართული | Македонски | മലയാളം | Plattdüütsch | Nederlands | Português | Română | Русский | Slovenščina | Svenska | Türkçe | +/−

Yes check.svg Resolved sarang사랑 17:24, 20 July 2012 (UTC)

U6A02 ()[edit]

OK, if it's a real tattoo, then it's certainly a rather large one, so I was mildly curious as to why it might have been chosen. Thanks... AnonMoos (talk) 15:51, 1 July 2012 (UTC)

The upper right was difficult to see on the 1st pic; the 2nd one was better. If the pic was licencable I would add it to the category, but for sure it is not. I am thinking of creating an own category Chinese glyph tattoos within the next days. -- sarang사랑 16:02, 1 July 2012 (UTC)
There's a semi-notorious site http://hanzismatter.blogspot.com/ which has exposed many blunders in the past... AnonMoos (talk) 16:28, 1 July 2012 (UTC)
P.S. You could always contact the "shadowcatcherimagery" site and ask them to relicense. AnonMoos (talk)`

File:Tattoo U+6A02.jpg[edit]

I don't know whether that image is copyrightable in that particular form or not, but we both know that the source isn't "vintage"[sic]. As explained in earlier -emails, it's from a photograph taken by one of the people responsible for the http://www.shadowcatcherimagery.com website (in 2001 or slightly before), though the photograph was not downloaded from the website. It would be cutting fewer corners to follow my suggestion above to ask the people at that site whether they would relicense the photograph(s) under a free license... AnonMoos (talk) 15:21, 23 September 2013 (UTC)

One year ago, shadowcatchers didn't answer my question. Depending this file, I believe that just the character without anything else from the photography, not showing all the photographical artwork, hopefully will not infringe the copyright, and the copyright for the character 樂 only is covered sufficiently by PD-Unicode. I do not feel completely well either, and I would much prefer to get the permission to show more of the picture. I am thinking of giving it another try and to contact shadowcatchers again.
Thank you for completing so neatly the file description. sarang사랑 09:51, 24 September 2013 (UTC)
I sent shadowcatchers again a mail - no reaction. sarang사랑 08:50, 14 October 2013 (UTC)

File:Mars symbol.svg[edit]

Guten Tag,

Es gibt ein problem mit den Bild Mars symbol.svg. Es gibt den richtigen symbol ♂ nicht mehr ; anstatt sehe ich eine schwarze geometrische Figur mit eine Kurve, zwei Strecke, und drei Ecke.

Deshalb stelle ich mich die Frage, um eine ältereres Version dieser Bild wieder zu machen.

Ich hoffe dass meine Deutsche Sprache genug gut ist. Verzweifeln Sie nicht, mich zu korrigieren.

Danke schön >^w^<

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

Good afternoon,

There is a problem with the picture Mars symbol.svg. The ordinary symbol ♂ doesn't appear anymore; instead of it, a plain black shape with two sides, one curve, and three vertexes.

This is why I ask myself a question: why not displaying an older version of this file.

I hope my German (and my English) are good enough; don't hesitate to correct me.

Thank you >^w^<

••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••

KiwiNeko14 (talk) 12:36, 16 October 2012 (UTC)

Merci beaucoup, KiwiNeko14, for telling me about this problem. It is caused by a well known librsvg bug and is now repaired by a workaround. Maintenant Mars symbol.svg Mars symbol.svg est comme tu veux. Je regret; désolé mon français n'est pas bon. sarang사랑 17:44, 16 October 2012 (UTC)
Kein problem Sarang, ich habe dich verstanden! Jetzt funktioniert es super, danke sehr! Guten Abend
KiwiNeko14 (talk) 18:50, 16 October 2012 (UTC)
Inzwischen ist der Bug auch generell gefixt Face-tongue.svg, siehe Bugzilla:31122 (live on 24.10.12) -- Perhelion (talk) 16:39, 29 October 2012 (UTC)
Being open is what the missing height happened (is this correct English?). De: Wobei offen ist was mit dem fehlenden height passiert (sieht schon etwas kurios aus, der Renderer macht daraus ein width="31" height="31"!?). -- Perhelion (talk) 08:13, 30 October 2012 (UTC)
Ganz generell scheint bei fehlenden width/height 512x512 genommen zu werden, zB wenn statt den beiden Angaben nur eine viewBox angegeben ist.
Offline wird bei nur width dieselbe height genommen,also ein Quadrat; mit dem librsvg gibt das dann Probleme, je nach der gerenderten Grösse. Bei solchen Variationen ist oft offline ok, nicht hingegen was dann in Wiki gezeigt wird. sarang사랑 10:01, 30 October 2012 (UTC)

My favorite SVG file ever![edit]

See File:Double optical illusion.svg... SFriendly.gif -- AnonMoos (talk) 20:19, 29 November 2012 (UTC)

Commons:WikiProject BSicon[edit]

You are invited to join Commons:WikiProject BSicon‎. Useddenim (talk) 19:44, 21 July 2013 (UTC)

Sq3_bluewhitegreen[edit]

Think it was just a caching problem; I purged and reloaded, and it looks fine for me now... AnonMoos (talk) 13:42, 26 July 2013 (UTC)

Template linking templates[edit]

Hi Sarang,

I noticed you're putting effort into cleaning up the existing template linking templates and extending their functionality. Kudos for this!

However did you read my comment here? I assume en:Template:tlg has already all the functionality you might want to implement in Template:Svtest plus much more (e.g. it already easily handles Interwiki-linking of templates, linking to arbitrary namspaces, etc).

I'd recommend to just import it here (as per my comment I mentioned) and built upon it's functionality instead of reinventing the wheel for Commons. This way future improvements can also quickly be applied on Commons and on enwiki. What do you think? --Patrick87 (talk) 09:51, 1 August 2013 (UTC)


Hi Patrick, deinen Beitrag habe ich sehr wohl entdeckt und gelesen. Gleichwohl halte ich die Importierung von {{tlg}} nicht für das Allheilmittel um diesen Vielfaltwirrwarr an template-templates aufzuräumen. "Tlg" ist ein sehr mächtiges Instrument, das aber einem etwas anderen Konzept folgt. Es ist sehr einfach, damit auf die Parameter einer Vorlage hinzuweisen, alles andere ist aber recht umständlich. Insbesondere hat Commons einen gewissen Standard für interwiki-templates bezüglich der Parameter 1=, 2= und 3=; es kann diskutiert werden ob dafür zusätzlich noch benannte Parameter (in diesem Fall wohl alttext und language eingeführt werden sollten, manche bevorzugen das. Einige tlg-Parameter (code, bold, italic) lassen sich weitaus einfacher codieren, zB mit ''{{tl|example}}'' oder als {{tl|example|''example''}} — wobei nichts dagegen spricht, es auch als Vorlagenparameter anzubieten. Ein eventueller bot-Lauf könnte so etwas auf beiderlei Arten umstellen. IMHO wäre es sicher am sinnvollsten, eine einzige Vorlage zu haben, am besten wohl als {{T}}, mit allen Parametern.
Praktikabel wird es am ehesten sein, zwei Vorlagen zu haben, eine wie {{T}} mit den unbenannten (aber auch benambaren!) Parametern für Displayname und Language, die andere zB {{Tp}} verwendet alle unbenannten Parameter 2 bis ∞ zur Aufzählung der Vorlagenparameter. Eine Fülle von benannten Parametern, bei den beiden Vorlagen identisch, erlaubt alle beliebigen Formatierungen. So sind Parameter in beiden Vorlagen mit parm= als ein komplexer Textstring, aber auch mit par1=, par2= etc. einzeln darstellbar. Beide Vorlagen würden sehr viel Code enthalten, deshalb wäre es vielleicht besser dass beide nur ihre Parameter an eine Supervorlage übergeben, die dann alles macht.
Es liefe darauf hinaus, dass mehrere sehr einfache Vorlagen durch eine überaus komplexe Vorlage ersetzt werden, und die sehr einfachen Vorlagenaufrufe in sehr vielen Fällen dann die leistungsfähige zentrale Vorlage aufrufen, ohne irgendwelche Werte für die zahlreichen Parameter zu übergeben.
Was hältst du davon? Wollen wir uns dafür aus dem Fenster lehnen? Und das ganze mal an der entsprechenden Stelle formulieren? Gruss, sarang사랑 07:38, 2 August 2013 (UTC)

Ganz ehrlich muss ich sagen, dass ich davon nicht viel halte. Die von dir vorgeschlagene Vorlage mit drei unbenannten Parametern für Vorlage/Alternativtext/Sprache würde das "Vielfaltwirrwarr" wie du es selbst nennst nämlich noch deutlich verschlimmern. Bist du dir sicher, dass es diese Variante auch noch braucht und ein einfacher "lang" Parameter nicht ausreicht (falls überhaupt nötig, schließlich kann man bei "tlg" einfach per Sprach-Prefix verlinken - auch zu anderen Projekten was bei deinem Vorschlag nochmal einen Parameter erfordern würde)? Aus meiner Sicht sprechen sogar einige Dinge dagegen:
  • Zunächst mal wird ohnehin eher selten zu anderssprachigen Wikipedias oder gar zu anderen Projekten verlinkt. Wenn man das wirklich will, warum nicht einfach mit Prefix (oder von mir aus auch lang-Parameter)?
  • Bis heute ist die Interwikifunktionalität in den meisten Vorlagen gar nicht vorhanden. Es scheint also kein großer Bedarf zu bestehen. Die Funktion per Parameter nachzurüsten sollte also mehr als genügen.
  • In der englischen Vorlage habe ich den "lang" Parameter sogar ganz entfernt – weil er überhaupt nicht benutzt wurde. (Ich vermute aber mal, dass der Bedarf auf Commons nach Interwikilinks etwas höher sein würde).
  • Die von dir vorgeschlagene Version ist von vornherein limitiert was Parameter angeht. Man kommt also, trotz der noch größer werdenden Vorlagenvielfalt, nicht darum sich mehrere Vorlagen zu merken.
  • Auch der Alternativtext wird so gut wie nicht benutzt. Schlussendlich ist er fast nur in Kombination mit Interwikilinks nützlich oder für Vorlagen im Benutzernamensraum (um den Namensraum zu "verstecken").
Ganz grundlegend würden mir persönlich zwei Vorlagen genügen (den ganzen Formatierungsmist halte ich ohnehin für unnötig), so wie in der deutschen Wikipedia: {{tl}} zur verlinkten Verwendung und {{tnl}} zur Erklärung der Vorlagenverwendung ohne Verlinkung oder bei mehrfacher Verwendung im Fließtext. Aber das werden wir hier kaum durchsetzen können, deshalb war mein persönliches Ziel die Vorlagenverwendung so gut wie möglich zu vereinheitlichen (mit gleichen Parametern, identischer Funktionalität und sinnvollen Namen)... und dem läuft dein Vorschlag leider ziemlich entgegen.
Ich würde mich freuen, wenn wir da eine sinnvolle Lösung finden könnten um das Wirrwarr etwas zu entwirren. Wenn wir zwei uns schon nicht einig sind brauchen wir glaube ich auch noch gar nicht daran denken irgendwas irgendwo zu formulieren. Face-wink.svg --Patrick87 (talk) 18:56, 2 August 2013 (UTC)
Die unbenannten drei Parameter sind ein in den Commons verbreiteter Standard, und in Vorlagen wie {{C}}, {{F}}, {{U}}, {{W}} und nun auch in {{U}} realisiert. Ich will keine weiteren Vorlagen, im Gegennteil, doch habe ich die drei Vorlagen {{T}}, {{T1}} und {{Tl}} einheitlich von einem auf drei unbenannte P. erweitert. Natürlich wird der 2. kaum, und der 3. Parameter noch weniger benützt; die Erweiterung ist mehr eine Anpassung an diesen erwähnten Standard.
Es wäre bereits jetzt möglich, {{T1}} und die sehr frequentierte Vorlage {{Tl}} per bot auf {{T}} umzustellen, oder aber zwei davon so zu reduzieren, dass sie nur mehr mit ihren Parametern die 3. aufrufen; so eine Verschachtelung brächte keinen direkten Vorteil, ausser dass als Endziel nur mehr eine Vorlage zu pflegen wäre.

Template:HandSVG als Autorinformation[edit]

Hi Sarang,

du bestückst gerade ein paar SVGs mit {{HandSVG}}, danke dafür! Allerdings ist mir aufgefallen, dass du im {{Information}} Template das "author" Feld mit dieser Vorlage ersetzt.

{{HandSVG}} enthält zwar ebenfalls einen Link zum Autor wenn man es richtig einsetzt, allerdings glaube ich, dass das trotzdem keine gute Idee ist:

  • Die Vorlage sagt zunächst mal etwas über den Inhalt der SVG aus, enthält die W3C Info-Vorlage, etc. Das hat alles nichts mit dem Autor zu tun und gehört somit auch nicht ins "author" Feld.
  • Bei den CC-Lizenzen wird oftmals empfohlen den Autor "so wie im "author" Feld angegeben" zu zitieren, wenn nicht anders angegeben. Zum einen lässt sich diese Empfehlung so dann natürlich nicht mehr anwenden, zum anderen veränderst du diese Information (worüber der ursprüngliche Autor eventuell nicht glücklich ist).
  • Ein Laie, der über diese Vorlage stolpert, kann damit wahrscheinlich nichts anfangen. Er kapiert vielleicht gar nicht, dass hier tatsächlich auch der Autor der Datei angegeben wird (was bei einem einfachen Wikilink hingegen offesichtlich sein sollte).
  • Oftmals wird ein SVG von einem anderen Benutzer erstmals optimiert oder noch weiter optimiert, nachdem es der ursprüngliche Autor hochgeladen hat. Das SVG ist dann natürlich trotzdem ein {{HandSVG}}, allerdings hatte der ursprüngliche Autor damit ja nichts zu tun.
  • Maschinenlesbarkeit: Wenn ich im "author" Feld nach einem Wikilink suche, habe ich wenn eine Vorlage verwendet wird schlechte Karten. Zugegeben ein schwaches Argument, da öfters Vorlagen im "author" Feld verwendet werden, aber sollte man trotzdem nicht ganz aus den Augen verlieren.

Meiner Meinung nach sollten Autor und die {{HandSVG}} Infos strikt getrennt bleiben. Das eine hat mit dem anderen schlicht nichts zu tun. Die Möglichkeit überhaupt einen Autor anzugeben ist in meinen Augen bereits zweifelhaft, denn grafischer Inhalt und Dateiinhalt in der SVG sind wie du selbst weißt zwei völlig unterschiedliche Dinge. Der Autor im {{Information}} Template bezieht sich auf den grafischen Inhalt, der Autor in {{HandSVG}} auf den Dateiinhalt. --Patrick87 (talk) 12:04, 3 August 2013 (UTC) P.S. Habe dir auf meiner Disussionsseite geantwortet.


Welcome, Dear Filemover![edit]

Commons File mover.svg

Hi Sarang, you're now a filemover. When moving files please respect the following advice:

  • Use the CommonsDelinker link in the {{rename}} template to order a bot to replace all ocurrences of the old title with the new one. Or, if there was no rename-request, please use the Move & Replace-tab.
  • Please do not tag redirects as {{speedy}}. Other projects, including those using InstantCommons, might be using the file even though they don't show up in the global usage. Deleting the redirects would break their file references.
  • Please know and follow the file rename guidelines.

Deutsch | English | 한국어 | മലയാളം | Русский | +/− --Steinsplitter (talk) 07:37, 5 August 2013 (UTC)

Es ist empfehlenswert sich eine Benutzerseite anzulegen, oder wenigstens eine Weiterleitung auf die Disk. Danke.--Steinsplitter (talk) 07:38, 5 August 2013 (UTC)

Statistics[edit]

Statistics
  • Files:
20,814,190
  • Page total:
29,063,878
  • User total:
3,670,145
  • Active users:
30,155

Commons:Requests for comment/How Commons should deal with TemplateData[edit]

Hallo Sarang, I würde gern wissen, ob Du in Zukunft TemplateData lieber per JSON eingeben willst oder dazu gern Vorlagensyntax benutzen möchtest. Danke für Deine Zeit. Beste Grüße Rillke(q?) 18:53, 28 August 2013 (UTC)

Hallo Rainer, bisher wusste ich nichts von der JSON-Möglichkeit. Ich möchte gerne auf effiziente Weise gute und brauchbare (also ebenfalls effizente) Dateien erstellen; das betrifft auch templates. Somit werde ich mich damit auseinandersetzen, und demnächst nach Infos suchen. Danke für deinen Hinweis. sarang사랑 05:56, 29 August 2013 (UTC)
TemplateData ist lediglich für die Beschreibung von Vorlagen. -- Rillke(q?) 08:10, 29 August 2013 (UTC)
Ich blicke noch nicht recht durch. Die Beschreibung (documentation) von Vorlagen soll nicht über die {{TemplateBox}} erfolgen? sarang사랑 11:32, 29 August 2013 (UTC)
Es steht die Frage im Raum, ob wir weiterhin {{TemplateBox}} benutzen oder <templatedata>JSON code</templatedata> direkt auf die Vorlagenseiten schreiben. {{TemplateBox}} kann auch TemplateData exportieren (- das passiert im Hintergrund -); alles was man dazu machen muss, ist {{TemplateBox}} den Parameter |useTemplateData=1 zu übergeben, dann exportiert es TemplateData, welches von Tools wie UploadWizard benutzt werden kann. -- Rillke(q?) 11:51, 29 August 2013 (UTC)
Du hast sicher ein Beispiel, wie so was aussieht, und was da zu editieren ist? sarang사랑 17:32, 29 August 2013 (UTC)
Konstruierte Beispiele sind auf Commons:Requests for comment/How Commons should deal with TemplateData#Make the test - What are you more comfortable with?.
Real-world-Beispiel ist Template:Information (Template:Information/doc [diese Unterseite wird in die Vorlage als Vorlagendokumentation eingebunden; TemplateData momentan unter der Parametertabelle; das Output können wir aber beliebig ändern] vs. Template:Information/sandbox/TemplateData [TemplateData direkt auf der Vorlagenseite]) -- Rillke(q?) 17:49, 29 August 2013 (UTC)
Danke — einstweilen, ich sehe es mir an sarang사랑 06:33, 30 August 2013 (UTC)

Category:Chinese_glyph_tattoos[edit]

Commons-emblem-issue.svg Category:Chinese_glyph_tattoos has been listed at Commons:Categories for discussion so that the community can discuss ways in which it should be changed. We would appreciate it if you could go to voice your opinion about this at its entry.

If you created this category, please note that the fact that it has been proposed for discussion 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. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category.

In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!


беларуская (тарашкевіца)‎ | Deutsch | English | español | français | עברית | magyar | italiano | 日本語 | македонски | português | русский | +/−

Brainy J (talk) 18:07, 30 August 2013 (UTC)

Katalanische Esteladas[edit]

Hi Sarang. Vielleicht könntest du mal diese beiden Esteladas - Estelada blava.svg, Estelada roja.svg - entrümpeln, bevor es jemand macht, der dabei den Stern wieder nach oben dreht. Grüße, mate2code 17:34, 16 September 2013 (UTC)

✓ Done und auch gleich Estelada blava vertical.svg Estelada blava vertical.svg 07:21, 17 September 2013 (UTC) Gruß sarang사랑

File:2-d dense packing r4.svg[edit]

I've reverted your change sorry. If you view both versions at full scale in your browser, you will see that they are slightly different, such that your circles slightly overlap. Unfortunately this is not good enough for a packing diagram. --99of9 (talk) 06:46, 10 October 2013 (UTC)

Thank you. I've changed the size of the small circles. This can be done even more, if desired, any fractions of 0.001 px or whatever, without increasing the size to 52 KB; ½ KB is enough to do that. If you compare it to the 52 K version, you may see that the small circles are now a bit better centered in the gaps between the large circles.
It would be possible to remove also all the superfluous Inkscape coding from all the other circle packing pictures, but IMHO this example is enough for the moment. If you want some more corrections, please just let me know. sarang사랑 07:34, 10 October 2013 (UTC)

File:Symbol LED.svg[edit]

Hello. I’ve corrected the syntax errors you introduced here. I just wanted to ask, if this was kind of a automatic replacement process, so did you do this change to many other files? If so, could you correct them? If not: How could that happen? ;-) Erik Streb (talk) 18:42, 13 October 2013 (UTC)

Hallo Erik, nix automatic, war nur ein dummer Fehler, rein manuell. Dank für deine Korrektur sarang사랑 07:39, 14 October 2013 (UTC)

SimplSVG[edit]

Okay, ty for the post. I will take a look at it, later on. Regards, Citypeek (talk) 07:50, 15 October 2013 (UTC)

  • I have taken a look at it, and was surprised that you didn't change just one file (the Spanish traffic signals) but a lot. Did you change all the templates of the files I edited? Anyway, thank you. Regards, Citypeek (talk) 10:46, 23 October 2013 (UTC)

My file replacements[edit]

Hi Sarang, I'm sorry for my wrong file replacements, the fact is that I'm a beginner and didn't know about the validity/invalidity of svg files. I promise I'll never make that error again. Please tell me where I can learn about cleaning up svg files, I'll be happy to learn and help. --Teoamez (talk) 10:28, 16 October 2013 (UTC)

About Liguria preistorica[edit]

Thanks! I used commonist and so.... one mistake did multiply into hundreds. A good opportunity to move my bot so far useless....let's try and learn :-) --Alex_brollo Talk|Contrib 21:54, 7 November 2013 (UTC)

File:Predicate logic; tensor 013 MP and 113 SM.svg[edit]

Hallo Sarang, Ich hab mal wieder eine Serie unsinnig großer Dateien. Das müsste mit Klonen eigentlich viel kleiner gehen. Ebenso hier und da. Falls du Lust hast, viel Spaß... mate2code 22:17, 5 January 2014 (UTC)

Hallo Mat2code, ich habe mir kurz mal Predicate logic; matrix 103 SP.svg angesehen. Es wird offensichtlich von links oben nach rechts unten 'angereichert', und erinnert mich diesbezüglich an 7-segment.svg; das konnte ich 2012 mit einer Art verschachteltem Cloning auf 2 K reduzieren. Genau diese Logik kann auf das Predicate angewandt werden, und ähnlich eine drastische Verkleinerung bewirken wie als Beispiel DrSuper super super super.svg, oder andere Anwendungen von cascaded cloning in SVG simplification by cloning.
Im Moment habe ich nicht soviel Zeit um mich damit intensiv auseinandersetzen zu können. Meinst du, du kannst den Code von 7segment verstehen und auf das Predicate umsetzen? Gruss sarang사랑 16:24, 6 January 2014 (UTC)
Ich werd's später mal versuchen. Wird schon gehen. mate2code 00:59, 7 January 2014 (UTC)
Dabei werde ich dir gerne helfen. BTW, so extrem einfache Grafiken wie in Predicate logic; 2 variables; different predicates; 2x2 list lassen sich IMHO angemessener manuell zeichnen; ist vielleicht weniger dein Ding, dennoch schlage ich es dir vor - als Beispiel habe ich das schon mal bei 2 Grafiken aus zwei bzw. drei SMP-Elementen getan, mit einfacher Variation der Opazität sind alle anderen daraus herstellbar.
Um den SVG-Code der umfänglichen Grafiken wie in Syllogism minterm lists ohne Herunterladen ansehen zu können habe ich das {{template}} um {{ValidSVG}} (mit option) erweitert - und dabei gesehen dass Inkscape wieder mal invaliden Codeballast erzeugt hat. BTW, ich hätte in das template Parameter aufgenommen, zB date, und an {{Information}} weitergereicht, um dort den Defaultwert zu überschreiben. Auch hätte ich deine templates anders kategorisiert; ich nehme an die gegenwärtige Kategorisierung ist weniger gezielt als wegen der Einfachheit entstanden. Wenn du willst mache ich dir dazu Vorschläge. Weiter frohes Schaffen in 2014, sarang사랑 07:54, 7 January 2014 (UTC)

File:Braille 101101sq.svg[edit]

Commons-emblem-issue.svg File:Braille 101101sq.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 | עברית | Magyar | Bahasa Indonesia | Íslenska | Italiano | 日本語 | 한국어 | Македонски | മലയാളം | Plattdüütsch | Nederlands | Norsk nynorsk | Norsk bokmål | Occitan | Polski | Português | Português do Brasil | Română | Русский | Slovenčina | Slovenščina | Српски / srpski | Svenska | Türkçe | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

JuTa 03:47, 12 January 2014 (UTC)

Thanks (Chinese New Year)[edit]

Thanks for e-mail. Just noticed File:DoC Enblem Logo.svg -- it seems to have extra bottom margin, and a typo in the filename ("Enblem" for "Emblem"). If it's a real coat of arms, it should probably have white in the shield, not transparent (though if it's not really a coat of arms, just a shield-shaped logo, then transparent could be appropriate...) AnonMoos (talk) 02:13, 1 February 2014 (UTC)

Thank you for telling me. Now the name is corrected, the margin is removed and the background is white. sarang사랑 08:49, 1 February 2014 (UTC)

Categorisation on seal script radicals[edit]

I just wanted to say that Chinese seal characters and Han characters are two historically related but very different writing systems and there is no straightforward and unfailing way to equate them to each other, as is the case with Latin, Greek and Cyrillic letters. Seal characters will be encoded on Unicode’s Tertiary Ideographic Plane (TIP). LiliCharlie (talk) 13:16, 22 February 2014 (UTC)

Thank you. AFAIK the TIP is designed to contain 30000-317FF Oracle Bone Script, 32000-32FFF Bronze Script and 34000-368FF Small Seal Script. When this is established, the codepoint can be notified.
We categorize seal, big seal, bronze and oracle together to the corresponding traditional radicals, or compositions. It is thought not so much an equation but showing the development, somehow. Your Shuowen characters are very welcome to give an additional impression. And the additional categorization to the corresponding character may be helpful, anyway, to find the graphics designed by you.
It will be a lot of work to categorize the pictures, but I think it's worth the effort. sarang사랑 15:54, 22 February 2014 (UTC)

File:Protest against S21 30Okt-04.jpg[edit]

Commons-emblem-issue.svg File:Protest against S21 30Okt-04.jpg 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 | עברית | Magyar | Bahasa Indonesia | Íslenska | Italiano | 日本語 | 한국어 | Македонски | മലയാളം | Plattdüütsch | Nederlands | Norsk nynorsk | Norsk bokmål | Occitan | Polski | Português | Português do Brasil | Română | Русский | Slovenčina | Slovenščina | Српски / srpski | Svenska | Türkçe | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

77.184.169.50 20:45, 8 March 2014 (UTC)

Creation of new help-page[edit]

Because I know you are interested in cleaning up SVG-files, I point out to you the new page I have made of cleaning up Chemdraw-files: Help:SVG/basic There is a problem though: someone created the subcategory Created with ChemDraw. Result is that ALL the pages with the Chemdraw-template on it, are automatically mentioned on this page, although they are completely W3C-valid. Can you have a look at it? Regards, Wereldburger758 (talk) 09:34, 22 March 2014 (UTC)

Thank you for your info. I tagged the category to drew the attention on that ChemDraw fault. Now I changed my notes and removed the Invalid tag - if you want, adjust the text even more.
I did not check it carefully, but your help page seems very useful. I am sure all the generated id's are not necessary at all. As long an id is not referenced you can remove it without any change for the picture. sarang사랑 10:10, 22 March 2014 (UTC)
Sorry, if I could give my opinion. I find the page pretty bad, this misses the point completely. Anyway the instructions are too complicated and very cumbersome (especially in relation basics). -- Perhelion (talk) 12:41, 22 March 2014 (UTC)
New page: From invalid to valid SVG: Adobe Illustrator-files. I will comment on your remarks tomorrow. Today is over and out. Wereldburger758 (talk) 13:06, 22 March 2014 (UTC)
(ihr könnt ja beide deutsch) Diese help-page gehört noch sehr angepasst, um wirklich hilfreich zu sein. Ich bin da nicht so geeignete Ansprechstelle, ich habe kaum Erfahrund mit Inkscape und gar keine mit Adobe, weil ich mich nur um einfache und einfachste Grafiken kümmere, und die sind am besten ohne jedes Tool zu erzeugen. Ich weiss nur dass das meiste ohne Schaden weggelassen werden kann, auch noch viel mehr vom header.
Wichtig wäre auch noch ein Hinweis, dass alle SVGs vor dem Hochladen auf Valididät (und Funktionieren mit dem librsvg) geprüft werden könnten (sollten), Commons hat dieses tool dafür. Der Gebrauch erspart so manche uploads von kaputten Grafiken. sarang사랑 14:12, 22 March 2014 (UTC)
I agree that it would be better that ALL SVG-files are checked on validity before uploading but that is a different matter (but a good idea). What needs to be changed on the page: https://commons.wikimedia.org/wiki/Help:SVG/basic1? You put a template on the page. If you want to change something, then go ahead. Or let me know, so that we can discuss about it.
To Perhelion: the page is made for two reasons: 1. Sometimes images don't render properly on Wikipedia although elsewhere they do. Cleaning up the image according the W3C-instructions will make them renderable on Wikipedia for sure. 2. Sometimes the size of images is way too big. Cleaning up the code will sometimes reduce the size to 95%.
That some of the content is difficult for you to understand, is not something I can remedy. Coding is a difficult subject for a lot of people. What I do agree upon is that the pagename must be renamed. Something like SVG/Validation. Wereldburger758 (talk) 12:28, 23 March 2014 (UTC)
Hello Wereldburger, I understand fully what you had written (but I'm far from being a beginner). Sorry if I expressed me unclear (it gives me the impression you do not seem to check for answers your other posts).[1][2] Additional if someone understand and find your page than someone don't need your hints. Also, I could write your page in one sentence. "Open the Chemdraw-SVG-file with Inkscape, save the file as Optimized Inkscape." File fixed. Or for example with Textpad, this simple editor can use Regexp, also with an Regexp-counter for replacing remaining IDs (which can also complete be removed as mentioned Sarang). In other words, write a general page for everything that I would support. Greetings -- Perhelion (talk) 13:17, 23 March 2014 (UTC)
I am clearly in the wrong here. I didn't know about the option to save a file as Optimized Inkscape. In the past I had been given the advice to save a file as Plain SVG. That meant that I had to edit the file after that with a text-editor to make it W3C-valid. The page can be deleted. I will have to check if the same goes for Adobe Illustrator-files. If so, then the other page can also be deleted. But I am calling it a day now. Wereldburger758 (talk) 17:14, 23 March 2014 (UTC)
I am thinking that Perhelion knows a lot about SVG tools; on the contrary to me, I am on the simple side. Everybody of us can learn from the other, that's a good thing of Wikipedia and the exchanging of skills.
At the moment I am expanding the templates, look to {{Adobe}} for the parameter "v". You inserted a screenprint of the Triforin Stereoisomers Structural Formulae.svg in your help page, I repaired something in the declaration of this file. sarang사랑 17:50, 23 March 2014 (UTC)
The advice to save as "Plain SVG" is a (in my opinion) common misconception. It is correct in the sense that an SVG file should be saved in conformance to standards without any third-party extensions (which is what the option "Plain SVG") in Inkscape should do. However I found this option to often not work as expected (e.g. resulting file still not in conformance to SVG standard, loss of information, introduction of rendering errors etc.). By using Scour (the Python script behind the scenes of the "Optimized Inkscape SVG" export option) most of the issues can be solved while even optimizing the SVG for file size.
Two other two misconceptions I want to point out are converting objects to paths and un-grouping:
  • "Objects to path" should basically never be done. Geometric shapes should always stay objects when possible (better have an easy circle which still can be resized easily than a complex path representing this shape which can not be modified easily). Also for fonts theres mostly no good reason for it as it will make modifying of the text impossible. The only exception is when you need some fancy font or textpath which is not supported by LibRSVG).
  • Un-grouping will destroy any SVG structure that might have existed in the original SVG and will actually increase the resulting SVGs size in most cases. Therefore normally groups should be left untouched (Scour will take care of unnecessary groups) or tuned by hand (can be very tedious and there is no universal easy scheme that you can apply to every file).
--Patrick87 (talk) 18:00, 23 March 2014 (UTC)
In my opinion, there is a need for a page about validation. Can you have a go, Patrick? What is needed is a procedure. So that a newbie can follow instructions one by one to get the desidered result. I will of course assist. Wereldburger758 (talk) 10:22, 24 March 2014 (UTC)

SVG optimalization[edit]

Hi,

I have reverted an image, because I couldn't edit it and I couldn't separate groups an other. What is the problem with it? What do you use to the optimalization? Bye: Madboy74 (talk) 17:48, 23 March 2014 (UTC)

What was wrong? I would like to create files that can be used by others, so please tell more about the problem Coa Slovakia Town Besztercebánya.svg made. sarang사랑 17:53, 23 March 2014 (UTC)
I don't know. Please try open it with the Inkscape and you can see it. I don't know why, but the Inkscape can't edit it. I downloaded your latest work Coa_Slovakia_Town_Galgóc.svg and it's correct.
I ha ve an other problem. Please don't change the colors, because my almost all images are in a uniform palette and in the future I will convert the other ones too, because I want standardised pictures. My images are used some non-Wiki projects.
Thank you for your optimalizations, because the Inkscape can't do it perfectly. Can you do it on my largest images?
Bye,
Madboy74 (talk) 18:50, 24 March 2014 (UTC)
At Coa Slovakia Town Galgóc.svg I didn't change anything, I just removed some not needed declarations. But for Besztercebánya I draw with complete new code, rather complicated with fill pattern and dash-arrays; may be Inkscape missed the <defs> statement, which is not needed by librsvg or W3C. Almost never I change colors, I respect the colors that a CoA has been given by previous authors.
It's only extremly simple SVG drawings I try to simplify keeping their shape and appearance, and I do it manually. Sorry, I do not work any more with Inkscape, and I apologize that Inkscape was not able to handle my coding. I used only the W3C validator but didn't check whether Inkscape is happy with my code. I am thinking of doing this check in future.
BTW, you manage to free your pictures from the usual Inkscape-specific redundant ballast. You do it with Inkscape? Or Scour? sarang사랑 06:39, 25 March 2014 (UTC)
I use the Inkscape. Unfortunately, some images are too large but I cleaned up the images before saving. Nowtime I save my images in Optimised SVG format. In the most of case, the images are smaller. Some time I save the SVG images to PDF and I import it back to the Inkscape. Few times it can reduce the file sizes dramatically but some times the importing make issues. The Scour and the SVGCleaner made a lot of problem for me so I avoid to use them.
Bye: Madboy74 (talk) 18:00, 25 March 2014 (UTC)
Thnak you, bye sarang사랑 18:03, 25 March 2014 (UTC)

Category:Created with Inkscape-hand-addition-BOTrequ1[edit]

"After" is OK. Some people might consider it a little pseudo-French (d'après), but it's perfectly standard in art history terminology, where they speak of an engraving by X after a painting by Y. I don't see any great problem, but you could substitute "following" or "according to" if you want to purge any taint of elevated style (though the subject matter of heraldry often involves semi-archaic words and expressions)... AnonMoos (talk) 15:38, 28 March 2014 (UTC)

Thank you. It looked to me like a verbatim translation of a foreign sentence. But now I know better, and won't change the expression of somebody else. sarang사랑 17:55, 28 March 2014 (UTC)

{{Created with}}[edit]

90% is fine for me too! -- SERGIO (aka the Blackcat) 09:15, 1 April 2014 (UTC)

Have a look at it and tell me if it's what you wanted. -- SERGIO (aka the Blackcat) 13:16, 3 April 2014 (UTC)
I rather suggested to write style="width:{{{width|90%}}}; to allow other widths than only pencented ones. but on the other hand it might be neither necessary (?) to offer that option, and it is less effort (!) not to be forced to write the "%" when changing the width from outside. You may decide whether or not to make another edit. I just need to know to maintain the docu correctly. Thank you sarang사랑 13:46, 3 April 2014 (UTC)

Ok. Meanwhile could you please translate in German this?

This photograph is a 2014 work by Sergio D’Afflitto. It is released under the terms of CC-BY-SA licence. Anyone who reuses this work must give appropriate credit to its author.

Thanks :-) -- SERGIO (aka the Blackcat) 10:03, 4 April 2014 (UTC)

There are numerous possibilities to translate it into good German. How about that
Dieses Lichtbild wurde 2014 von Sergio D’Afflitto erstellt. Die Lizensierung erfolgt mit CC-BY-SA. Bei jeder Weiterverwendung dieser Arbeit ist der Urheber auf geeignete Weise zu nennen.
You want some other suggestions? {{cc-by-sa-3.0}} contains translations in all languages.
2nd sentence: Es wird unter der xx Lizenz publiziert.
(pastv tense) Es wurde ...
Bei jeder Verwendung ist auf die Urheberschaft zu verweisen.
Der Autor muss bei jeder Verwendung dieser Arbeit genannt werden.
sarang사랑 10:32, 4 April 2014 (UTC)
Ok, thanks, I updated {{Created with}}, but can't find the code for modifying the other two mentionned. -- SERGIO (aka the Blackcat) 11:01, 4 April 2014 (UTC)
Just follow the links on your talk page to the template's talk, you can find everything there. sarang사랑 12:12, 4 April 2014 (UTC)
Tell me when you finished editing my talk page, so I can update the templates with no need of always correcting it :-) :) :) :) -- SERGIO (aka the Blackcat) 21:50, 6 April 2014 (UTC)
Oh, sorry - I did not realize that you are also wake... I am ready, you may go on now. Thank you sarang사랑 22:26, 6 April 2014 (UTC)
Ok, I upgraded all the six templates. Please check them and tell me soon whether it's all ok or you found problems. -- SERGIO (aka the Blackcat) 21:23, 9 April 2014 (UTC)
Ok. Have you also talked with someone who usually follows those templates? -- SERGIO (aka the Blackcat) 12:20, 10 April 2014 (UTC)
Until now I had not yet talked to a lot of people. The expansions I inserted are not harmful for the existing transclusions, but offer many additional possibilities, e.g. for the urgently needed diffusion of the overcrowded categories. The policy I understand is that every SVG image should not only specify by the use of which tool is was made but also whether its valid or invalid in means of W3C.
I made the updates of the documentations, and I will also care that users will know how to use the templates.
The updates in your talk page are made. Thank you sarang사랑 12:44, 10 April 2014 (UTC)
Help me, I'm lost. What edits do you need now? -- SERGIO (aka the Blackcat) 08:40, 14 April 2014 (UTC)

File:Ecu-proportions.svg[edit]

Don't see any problem with "due to" on that page, but "has been invalid" should be "was invalid". By the way, a heraldic shield constructed according to that mathematical formula would be rather ugly... "Pgf data blocks" is what I usually call "Adobe cruft", but that's just my personal thing. AnonMoos (talk) 14:32, 13 April 2014 (UTC)

Thank you. I will take "was", if it's better. I don't like the proportions either, it is just to show how such a simple SVG can be drawn. PercevalBxl produced hundreds of bad SVG CoAs nobody needs, in 2008, and then vanished...
Adobe produces IMHO also a lot of other cruft, not only but in special when compared to rather simple code possibilities; this is also personal. sarang사랑 14:55, 13 April 2014 (UTC)