User talk:Sarang/Archive/2009

Some resolved sections

Tutorial for ACC project

Hallo, Sarang. Thank you very much for your effort on ACC project. I think you would like to spend some time on reading Tutorial for ACC project that is likely helping you on the image preparation before uploading to Commons. Feel free to hold question on my talk page or Yug's. We hope you will enjoy in this project. Chanueting (talk) 13:35, 30 December 2009 (UTC)

Wow !

Hi,

I just see the new versions of File:Trigramme2633 ☳.svg, File:Trigramme2636 ☶.svg, File:Trigramme2637 ☷.svg. That’s *wonderful*, how do you do that ? Is it possible for every svg ? (even more complicated like : File:& (italic, 1735).svg)

Moreover, there lot more svg trigramme (File:Trigramme2630 ☰.svg, File:Trigramme2631 ☱.svg, File:Trigramme2632 ☲.svg, File:Trigramme2634 ☴.svg and so on in Category:Trigramme and hexagrams too).

Cdlt, VIGNERON * ^discut. 15:48, 19 December 2010 (UTC)

Hi Vigneron, I always thought that I am the only user interested in SVG disgarbaging. But now I am glad that you are on that subject.

I will work out a detailled answer for your questions. Just wait a bit! -- sarang♥사랑 15:54, 19 December 2010 (UTC)

It is two things: at one hand it is not at all useful, to generate "simple" graphics by editors like Inkscape, Adobe Illu and others. Rather easy structures can be drawn by hand with a minimum of effort. It is not so easy to tell at one first glance whether an image is simple and easy to draw, or not. At any case, straight lines, rectangles, circles and other simple geometric shapes are in most cases good to draw by hand, with a text editor.

At the other hand, it soon becomes difficult, and the effort incresaes rapidly for difficult shapes. Some types of curves are rather easy, others not. Your italic at-sign can be drawn by hand, but I would not do it without need. In such cases it may be better to draw it with an editor's help and then work it over to remove the garbage if any. If you like, I can look it over and reduce it a lot keeping same quality; but it had been better to do that before uploading to WP.

A third thing is that is not of much use to redraw all the ugly SVG graphics. It should be avoided from beginning to upload unnecessary large files, new uploads make Wikipedia not faster but the data amount increases, because all older versions are kept forever. My intention is to show that simple graphics can be drawn simple, hoping that somebody will recognize it (as you did) and think twice how to generate a SVG image; but it wo'nt help anybody if I redraw each of the 64 hexagrams. I just show as an example File:Iching-hexagram-03.svg and very few others. -- sarang♥사랑 16:26, 19 December 2010 (UTC) ‎

I totally agree with your points ! (Just one little point : reupload a new files increase the data amount but didn‘t it decrease the visualization on articles ?)

I agree a lot that SVG should be simple. The problem is : I don’t know how to draw good and simple SVG… When I open a SVG on a text editor, i’m totally puzzled with the code. For exemple, I open my version and your version of ☰. My version is full of strange code I didn’t understand and your version just contain little code but I did’nt understand it either… Apparently you convert 3 rectangle in 1 triple stroke (ok, I undestand that even if I don’t understand how you do it ; for File:BJT NPN symbol (case, unlabelled).svg I just don’t see what the “path” is). Plus I wonder : the begin of my version contains some metadata. Aren’t this metadata useful ?

I didn’t have to wait, thanks for your prompt response ! I hope you can teach me how to make my drawing (eg. my old italic ampersand and others olds symbols useful for fr:s:Wikisource:Glyphes & caractères/Collecte) simplier by myself ! (to avoid upload and re-uplaod again).

Cdlt, VIGNERON * ^discut. 18:15, 19 December 2010 (UTC)

White fields in File:Venn 1001 0111.svg etc

Hi,

if you want to simplify all (!?) files like File:Venn 1001 0111.svg, please keep the white fields in and keep the lines in the same thickness. However, I don't think, it's recommendable, to change 256 small files, just because the source is shorter. For sure, there are more useful things to do here. Greetings, Lipedia (talk) 16:25, 30 December 2010 (UTC)

Hi Tilman, it was my mistake not to check that the fields are white... Sorry, and thank you for recognizing my fault. I do not intend to replace all files, but I thought to show rather symbolically with some of them how easy it is to draw them more efficiently. Aber das kann ich gerne mit dir abstimmen, und wenn du es für arg bescheuert hältst kann ich es auch bleiben lassen. -- sarang♥사랑 16:39, 30 December 2010 (UTC)

Symbolisch war das durchaus sinnvoll. Mit einem Blick auf den Quelltext habe ich verstanden worum es geht, und werde über Inkscape wohl nochmal nachdenken müssen. Etwas gruseliges ist mir übrigens hier passiert. Die Dateigröße ist einfach nur peinlich. Im Moment wüßte ich aber nicht, wie ich es besser machen sollte.

Deine Hinweisaktionen finde ich an sich sinnvoll, allerdings denke ich, dass du sie mit einem Link auf ein Tutorial versehen solltest, wie man bessere SVGs macht. Falls es das nicht in allgemeinverständlicher Form gibt, könntest du es ja in der Wikiversity schreiben.

Ach so: Wenn du eins der Venn-Diagramme dauerhaft ändern willst (mit weißem Hintergrund innerhalb des äußeren Kreises, und gleicher Liniendicke), dann nimm doch File:Venn 0000 0001.svg. Das dürfte am häufigsten verwendet werden. Grüße, Lipedia (talk) 17:17, 30 December 2010 (UTC)

Hallo Tilman, bei der Symmetric group 4 erscheint es nicht sehr sinnvoll, das mit aller Gewalt als SVG zu erstellen. Wenn eine Grafik sehr stark strukturiert ist, wird es aufwendig - und bei Text ohnehin (wenn es als SVG-Text gestaltet ist; noch mehr natürlich, wenn der Text als Pfad dargestellt wird). Bei dieser Darstellung zahlreicher kleinteiliger Strukturen ufert SVG klarerweise sehr aus. So sinnvoll es ist, einfachere Kurven (und ganz besonders natürlich die mir so am Herzen liegenden ganz einfachen Geometrien) in SVG zu zeichnen, bei so aufwendigen Tabellen wird jede Vektorisierung zwangsläufig extrem aufwendig. Es ist sicher interessant, das auch mal zu machen, aber ich würde eher nicht noch viele solcher Tabellen basteln.

Das Venn 0000 0001 hat bei mir 424 byte, mit weißer Füllung. Ich habe mich ein wenig damit beschäftigt, wie es einfacher ginge, und gemerkt dass es mit vier circles am wenigsten Aufwand ist; es gibt ja immer hunderte Möglichkeiten, so was zu machen, und oft kommen nur zwei oder drei wirklich in Frage; von denen ziehe ich die mit der geringsten Dateigröße vor, obwohl andere manchmal interessanter wären.

Ich werde also das Venn 0000 0001 exemplarisch ersetzen, und damit ist's genug. Die Liniendicke ist 2.566, 2px sieht ganz gut aus, 3px zu dick, wenns unbedingt sein muss kann ich auch 2.5 oder 2.6 einsetzen. Bei andern Venns sah ich die stroke-width:2.56599999999999984 - wirklich, 17 Dezimalstellen, Inkscape-Sodipodi macht das so.

Übrigens, einen kleinen, sicher nicht störenden Fehler haben alle diese Grafiken, unmittelbar links der Kommissur der beiden oberen Kreise, bei stärkerer Vergrößerung ist da eine Unsauberkeit zu erkennen - kannst du es sehen?

Ob ich was schreiben sollte weiss ich noch nicht so recht. Es wird wohl nur sehr wenige interessieren, aber dieser Klientel würde ich gerne gute Tipps geben. Leider ist mein Englisch nicht so toll, das kannst du schon am Versuch hier sehen. Aber ich werde wohl was machen müssen, zumindest einen Anfang, den andere dann verbessern und ausbauen können. Ein wenig Resonanz auf meine Missionstätigkeit gibt es bereits, ein gewisses Interesse kann ich feststellen. In de:Scalable Vector Graphics#Editoren habe ich schon mal das Thema angeschnitten. Gruss, -- sarang♥사랑 19:01, 30 December 2010 (UTC)

Hallo Sarang. Den Fehler sehe ich in der 2000px-Vergrößerung. Nimm doch einfach 2.566, wenn das bei den anderen auch so ist. Wenn ich den Unterschied nicht sehe, soll mir die 2.6 auch recht sein.

Wenn du verständlich erklären kannst, wie du einfache SVGs machst, dann schreib doch was auf deutsch. Übersetzen kanns jemand anders - notfalls mach ich das. Kein Mensch braucht gutes Englisch. In das Template, mit dem du die korrigierten Bilder kennzeichnest, kann man ja auch später noch einen Link einfügen.

Was mich noch interessiert: Entlastet das Ganze auch die Wikimedia-Server, abgesehen vom gesparten Speicherplatz? Geht die Handarbeit genauso schnell, wenn man sich daran gewöhnt hat? Gibt es Boolesche Operationen? Wenn ein kompliziertes Objekt mehrmals auftauchen soll: Kann man es dann einmal speichern, und von verschiedenen Kopien nur die Positionen speichern? Grüße, Lipedia (talk) 20:46, 30 December 2010 (UTC)

Einen Unterschied zwischen 2.566 und 2.6 Pixel wirst du auch bei 2000fach nicht wirklich sehen können, vor allem ändert das nichts am Gesamteindruck, und auch im unmittelbaren Vergleich zwischen zwei Grafiken ist da nichts zu erkennen. Es ist halt eine von den Methoden der Editoren, die Dateien aufzublähen - wie ich finde, zu niemandes Nutzen.

Den Server entlastet es sicher nur sehr unwesentlich, da ist wohl kaum was zu merken, ob eine SVG-Datei von 200 oder 20 000 bytes gerendert wird. Speicherplatz spart es leider überhaupt nicht, denn ALLES wird aufbewahrt und steht auf sozusagen ewige Zeiten zur Verfügung und irgendwo herum. Deshalb mache ich nur Beispiele, und hüte mich an größeren Sets oder Kategorien zuviel zu überschreiben. Sinn hat das Ganze nur, wenn einige veranlasst werden gelegentlich die manuelle Erstellung zu erwägen, statt stets die einfachsten Formen von Inkscape & Co generieren zu lassen. Davon würde das Gesamtsystem sicher entlastet.

Da ich nicht weiss wie schnell es mit Editoren geht kann ich nicht vergleichen; ich finde jedenfalls dass es manuell recht schnell geht, es ist wohl auch von der Gewöhnung an das Textsystem bzw. das Editorprogramm abhängig. Komplexere einfache Grafiken dauern natürlich länger als einfachere einfache Grafiken. Da eigentlich die editor-erzeugte Grafikdatei immer nachbearbeitet werden sollte, mit Entmüllungssoftware oder manueller Bereinigung, verschiebt sich die Relation. Absehen will ich vom sportlichen Aspekt, wenn ich viel Zeit investiere um etwas zu optimieren.

Speziell bei vielen ähnlichen Grafiken (bei den 256 Vennen) geht es sicher blitzschnell, sobald die ersten paar Bilder erstellt sind, weil nur Kleinigkeiten angepasst werden müssen und das meiste kopierbar ist. Es ist immer die Entscheidung, schnell viel guten Output zu erzeugen, oder mit hohem Aufwand bei jedem einzelnen Bild die Details bis zum Äußersten zu optimieren; da gibt es für jeden einen individuellen Mittelweg.

Automatisierungsmöglichkeiten bieten die einfachen Office-Tools wie Excel und Word, damit lassen sich auch Koordinaten transformieren ohne dafür Programme zu entwickeln.

SVG hat eine primitive Boolesche Logik eingebaut, nach der Innen- und Außenseite einer Fläche unterschiedlich behandelt werden; sonst ist mir noch nichts aufgefallen, und das Textsystem bietet da auch nichts. Da gibt es bei Inkscape &Co sicher mehr Komfort.

Deine letzte Frage: da ist mir nichts bekannt, ich denke, echte externe Referenzierungen, die es ermöglichen Bausteine zusammenzusetzen, werden vom gegenwärtigen System noch nicht unterstützt. Klonen scheint nur intern möglich. Es gäbe einiges an Wünschenswerten, das vielleicht irgendwann mal kommen wird. -- sarang♥사랑 21:54, 30 December 2010 (UTC)

SVG condensing /optimization

I have some little tricks and techniques which work for the kinds of files that I do, and the particular methods I use to create them, but there are probably not a lot of techniques suitable for general-purpose use that wouldn't be fairly obvious if you read through selected sections of the SVG standards document. Someone who had a creative approach to good-quality SVGs was User:McSush... AnonMoos (talk) 22:43, 2 January 2011 (UTC)

File:Nopenis.svg is one file that I managed to condense down a fair amount, but not sure if it would help other people... AnonMoos (talk) 01:05, 3 January 2011 (UTC)

Thank you, I had dedected McSush and his good ideas some time ago. He is German user, as I am. As mentioned, my part is more simple to very simple graphics, easy to draw by hand. If you have some interesting techniques, it would be the best if you generate one or some few examples illustrating them useful and put them then into Simplified SVG discussions, where it can be found by interested users.

Depending your penis, first I had difficulties to look at it (offline, with Firefox) because it lacks the xmlns style informations. Then I played a bit with it: The scaling (.2 .2) can be replaced by transforming directly the coordinates, the accuracy for such a logo seems good enough with then rounding again to integers. Redundant separations can be removed: every sequence ",-" can be replaced by "-", and comma, space or linefeed (crlf) before letters (grouping the 'c', 'M' and 'l' sequences) as well. Necessary separators (commas, spaces) can be substituted by line feeds to avoid endless line lenghts. #f00 is a not so different red to #f00000. After all this treatment your penis looks so (420 bytes, with xmlns):

<svg xmlns="http://www.w3.org/2000/svg" version="1.0" width="405" height="405">
<g stroke="#f00" stroke-width="42">
<circle fill="#fff" cx="202" cy="202" r="178"/>
<path d="M82,82l240,240"/></g>
<path d="M305,137c0,0-2-2-2-3c-1-1-1-4-1-4c-7-3-14-5-22-5c-9
0-18,2-26,7c-7,4-13,9-20,13l-32,18l36,36l20-12
c7-4 15-7 22-11c15-8 24-24 26-41zM191,227l-36-36l-97,56c14,44
46,77 84,94c9-8 15-20 15-34c0-20-12-37-30-43z"/>
</svg>

and I cannot see the difference. An example of penis size reduction! The little reduction ratio proofs that your work is very close to the optimized version. It is quickly done if grouping the 'c'-sequences (and others) by linefeeds should be restored.

I tried to find out which of the preambles is really necessary or to recommend strongly. The Wikipedia renderer, IE-offline and Firefox-offline are working differently. I would like to fulfil the minmal requirements of any environment. -- sarang♥사랑 09:16, 3 January 2011 (UTC)

Nopenis.svg has already been integerized, but to a 2024x2024 grid. If I were to try to optimize the filesize further, I would just do width="2024" height="2024", rather than subjecting it to a double integerization process (which would create subtle inaccuracies for a very slight gain in file size). But I just noticed that with the current scaling factor, there's actually an internal 2025x2025 grid set up (not 2024x2024), so that it's very slightly off center...

FireFox requires xmlns="http://www.w3.org/2000/svg" or it won't display an SVG file, while early versions of Adobe SVG plug-in (widely distributed with Windows XP) will refuse to display an SVG file if xmlns="http://www.w3.org/2000/svg" is present. The RSVG software used by Wikimedia doesn't care. I consider the whole thing to be rather annoying... 10:07, 3 January 2011 (UTC)

Thanx fo the info; it is really annoying when one requires what the other forbids... so I cannot do to the pleasure of anybody. Actually it works with xmlns everywhere, without wiki-online and IE-offline, but not FF-offline.

Do you know also how about the <?xml ?> -line? With the entries version, encoding and standalone? It seems to be not necessary everywhere - why is it contained in almost each SVG file?? -- sarang♥사랑 10:29, 3 January 2011 (UTC)

<?xml ?> is a general XML header (nothing to do with SVG specifically at all). It can be used to inform an XML parser whether an XML file has an internal DTD, and which character set an XML file is in. I don't know which programs require such an "?xml" declaration, but the RSVG software used by Wikimedia doesn't. I usually include <?xml ?> and xmlns="http://www.w3.org/2000/svg" unless including them would significantly increase a file's size. By the way, one header which is quite functional is xmlns:xlink="http://www.w3.org/1999/xlink" -- a lot of programs will have problems with SVG files containing links unless it's present... AnonMoos (talk) 11:17, 3 January 2011 (UTC)

I know that <use xlink:href= requires this header definition.

---

P.S. If you really want to optimize something, here's an SVG file which I distribute with one of my fonts (I haven't uploaded it as a whole to Wikipeda, though I have uploaded certain sections as separate graphics); anything which would increase ZIP compressibility without re-integerizing would be nice...

I got it and will give it a look. First I try to make it a bit smaller just mechanically, without altering anything of the logik. I had removed it from the talk page. I shall inform you when I got results, better via e-mail. -- sarang♥사랑 11:52, 3 January 2011 (UTC)

It's a clip-art file of various characters from one of my fonts, enhanced by being displayed using techniques which cannot be done in the font itself (since standard font formats have rather strict limitations, allowing only the specification of basic fill operations which apply an unspecified foreground color against an unspecified background color, etc.). It's not meant to have an overall unified appearance, and I don't intend to upload it as a whole to Commons (as stated above), though certain sections have been uploaded in slightly different form as separate graphics. In most cases (except the triskelion), the SVG file carries over the limitation on font files that there must almost always be a curve endpoint anywhere a curve has a tangent angle of 0°, 90°, 180°, or 270°. There are no "<use" tags because it's impossible to include them in a way which will work both in early versions of Adobe SVG plug-in (widely distributed with Windows XP) and in other programs (see above), and I only recently decided to dump early Adobe SVG plug-in compatibility. The triskelion symbol is on Wikimedia Commons in ring form at File:Roissy triskelion iron ring signet.png. Anyway, I thought it would allow you to exercise your full talents at SVG optimization (though I'm actually most interested in compressing it to the minimum size in the font distribution ZIP file). AnonMoos (talk) 12:56, 4 January 2011 (UTC)

Thank you, I found the Roissy ring, but I thought there was another picture - I mixed it up in remembrance. If I try to make something: I shall extract single pics from your file, and treat them separately. Of course it will be possible to insert them again with the appropriate transform-translation. -- sarang♥사랑 12:35, 5 January 2011 (UTC)

also...

P.S. One special tool I do occasionally use which most other people might not is Fontforge, as mentioned on File talk:& (italic, 1735).svg. -- AnonMoos (talk) 19:17, 17 February 2011 (UTC)

Thanx for information. To the moment i do nothing with any tool and restrict to simple SVGs, where it is better to make them manually.

But it might be a good idea to create some more informations about good tools to let others know. -- sarang♥사랑 19:49, 17 February 2011 (UTC)

reupload of File:D-Serine.svg and others

Hello Sarang, I noticed that you overwrote the image with a different version. Many of my and other user's images are used in more than one project and are drawn the way they are on purpose (in this case according to german wikipedia's guidelines for chemical structures). I would prefer if you uploaded the changed image with another filename, rather than overwriting the existing image. It's no problem to have multiple images for the same chemical compound. Regards, --NEURO ^⇌ 19:22, 3 January 2011 (UTC)

Re: Your Spain traffic signals

Hi Benedicto, you made and uploaded a lot of SVG images.

Would you please look whether you could do that with a tool not producing such a lot of garbage?

Your File:Spain traffic signal r301.svg containes more than 496000 bytes, while user Habbit made it with less than 9000 (but with a wrong font).

I tried to disgarbage your File:Spain traffic signal r1.svg and File:Spain traffic signal r100.svg reducing them to less than a half promille of their sizes, while showing almost the same picture.

May be it will not be difficult for you to find another strategy for creating SVGs, avoiding the hundreds of thousands of CDATA filler bytes of no use; at least it would be nice if you remove them before uploading (as I just did at File:Zonas Abono Transportes Madrid dg.svg). Thanx! -- sarang♥사랑 15:19, 22 July 2010 (UTC)

First, I'm sorry about answering you this late. I've been away for long.

Now, about garbage in SVG files, I had no idea about it. And, seriously, nowadays a 500 KB file is nothing in a hard drive, so maybe that's why I've never realized. But the thing is you're right, and an image like Spain traffic signal r100.svg, which is no more than a white circle and its red circumference, shouldn't take such amount of information.

However, though the problem is there, I don't think it's something necessary right now, as Wikipedia renders SVG in PNG. So, I'm starting right now to find out how I can make Adobe Illustrator SVGs more friendly —maybe unchecking “Keep Illustrator editing capabilities” option—. So when I'll be done, I'll reprocess former little by little, considering future Wikipedia's HTML 5 inline SVG capabilities.

On the other hand, I must ask you to be careful when editing traffic signs. They're not artist's conceptions but the official ones. They are drawn carefully according to Spanish laws and standards which describe thoroughly how to draw them. Corner radius, border width, colors, etc. Spain traffic signal r1.svg is an example of this. And, also, the <!DOCTYPE> heading is not garbage, so deleting it goes against the XML spec.

So, thank you for attract my attention on this subject.

Benedicto XVI Español | English 05:38, 5 January 2011 (UTC)

Hi Benedicto, I am sorry to have troubled you with my falsifying your traffic signals; but I am glad that you will care in future a bit more to file sizes. Uploading smaller versions does not help, because everything remains stored forever; my actions were just examples how drawings can be, or IMHO should be. By the way, Zonas Abono Transportes Madrid dg.svg shows exactly the same as the larger file. Good success! -- sarang♥사랑 12:35, 5 January 2011 (UTC)

Well, the problem just was on what I supposed: Illustrator keeps an Illustrator file type copy of the image embeded into the SVG. So simple deleting it and some unnecessary headers and voilà. Thank you once again for attracting my attention.

PS: About the older versions, maybe an user with privileges could delete them, I'm not sure.

Benedicto XVI Español | English 12:51, 5 January 2011 (UTC)

An admin on the commons told me files can only be hidden for normal users, but never really removed.

I told about this Illustrator disadvantage on a page about that topic. I just saw that I overlooked a large block in the Zonas, without any interfering the logic another 26KB are deleteable. But I won't do anything more on it - if you want, voilà!. -- sarang♥사랑 14:26, 5 January 2011 (UTC)

Adding nagging tagging to SVG files

In general it's nice if SVG files can be somewhat optimized, but there doesn't seem to be too much point to adding nagging tags to image description pages, unless the SVG file is spectacularly bloated. Many people only edit within InkScape etc., and would have no idea how to hand-edit an SVG file... AnonMoos (talk) 13:42, 14 January 2011 (UTC)

It is not at all my intention to annoy anybody, nor to declare somebodies work for bad. I just think it useful to collect some examples of typical Sodipodi-drawn files into a type of maintenance category. May be I should describe that better. Everybody can browse through these categories which are all linked together and see that it is possible to draw images with 5 to 10% of the Sodipodi/Inkscape size. Only few are interested in that fact, but these few should be enabled to find information about without the need to search a lot.

I can try to explain that at the categories header. -- sarang♥사랑 17:03, 14 January 2011 (UTC)

If you just want to classify files into a maintenance category, then you do not need to generate a large orange box. AnonMoos (talk) 17:50, 14 January 2011 (UTC)

I shall change the orange box to some plain text, without icons. Would you like to make some suggestions about that note? -- sarang♥사랑 19:17, 14 January 2011 (UTC)

File:Deutsche Turnerschaft.svg

If it's a flag image, shouldn't it have an opaque background? And the cropping is radically different from the PNG... AnonMoos (talk) 19:34, 27 January 2011 (UTC)

I took it for a logo, and ommitted the background. But you are right, it would be better to have it white. There is another problem: when I draw it offline, it looked well. Uploaded it looks wrong, the upper part is not parallel but bents together. I could not find what I made wrong. -- sarang♥사랑 19:52, 27 January 2011 (UTC)

It's hard for me to try to diagnose that file, since you use "q" curves, and I don't know anything about them in SVG (I always use cubics, like in PostScript...). AnonMoos (talk) 20:04, 27 January 2011 (UTC)

I used Q for my first time; I thought that A was not so good, because it is not circles or ellipses parts, and C was not necessary for the simple bows, so I tried Q as the medium possibility. And you are also right, it does not match so well the png shapes, nor other sources. I will keep in my mind either to repair it, or to have it deleted.-- sarang♥사랑 20:11, 27 January 2011 (UTC)

There's nothing wrong with quadratics as pure abstract geometric shapes, but they're often less flexible and less convenient for use in graphics (see my old remarks at en:Talk:TrueType...). -- AnonMoos (talk) 06:58, 28 January 2011 (UTC)

File:Nopoetry.svg

Hate to be too picky, but your edit broke the display of the Information template. AnonMoos (talk) 08:35, 28 January 2011 (UTC)

Sorry, typing error happened and I did not check carefully enough my catdiff-- sarang♥사랑 09:43, 28 January 2011 (UTC)

Help

Hi!

Thank you for uploading new versions of the files ... .

I have one question/request: would you have the time to help fixing this image? The lines are somewhat out of place (compare with this other image from the same set). Helder 23:07, 2 February 2011 (UTC)

Sorry, I overlooked your question. I'll answer at your home wiki.-- sarang♥사랑 09:46, 13 February 2011 (UTC)

Template:U

Hallo Kuru, du bist Admin auf den Commons? Du hast als letzter am {{U}} editiert. Als freqentierte Vorlage ist das Ding zu Recht protected, und ich wende mich an dich weil ich nicht ran kann.
Ich habe einen Zusatz zur bisherigen Auflösung gewissenhaft getestet, die Erweiterung ist unschädlich für alles bestehende.
Du kannst alles aus meiner Testvorlage {{÷}} kopieren. Anschließend wäre diese komplett zu löschen – das kannst du ja auch; zumindest die Kategorien sollten möglichst bald deaktiviert werden. Gruss -- sarang♥사랑 13:59, 26 January 2011 (UTC)

Alles erledigt. Die Sachen von {{÷}} sind in {{U}} eingeflossen und {{÷}} ist gelöscht.

Ich bin mir noch nicht schlüssig welche Kategorien du genau meinst ("zumindest die Kategorien sollten möglichst bald deaktiviert werden")

mfg --D-Kuru (talk) 18:09, 3 February 2011 (UTC)

File:Anti-Islamism.svg

Not sure why you increased the size of the margins so much... AnonMoos (talk) 08:46, 12 February 2011 (UTC)

Did I make something wrong? I cannot see at the moment.-- sarang♥사랑 08:59, 12 February 2011 (UTC)

Don't know if it's "wrong" as such, but your version has a noticeably larger relative margin size than the original upload. AnonMoos (talk) 10:55, 12 February 2011 (UTC)

That was not intended. I will work both Anti-images over again, and look for more similarity with the original uploads; what is your opinion: crescent black as original, or green as more correct? If you see it as a kind of traffic sign, black-white-red is better choice. I dont' know. As well I can revert my upload. -- sarang♥사랑 19:02, 12 February 2011 (UTC)

I don't care enough to revert (or I would have done so already), but it seems to me of somewhat dubious value to refine fully "correct" Islamic symbolism in an anti-Islam image. Anyway, if you look at the flags of majority-Muslim countries, the color green is certainly associated with Islam (or some would say, with Muhammad), but crescents on a green field are actually more common than green crescents. Also, the crescent only became associated with Islamic realms beginning with the rise of Turkish empires in the middle east, and some would say that technically it's a cultural symbol of Muslims more than an Islamic symbol as such... AnonMoos (talk) 00:08, 13 February 2011 (UTC)

I will work it over, to get the same appearance with adequate size.-- sarang♥사랑 09:46, 13 February 2011 (UTC)

Eigenes Werk

Hallo Sarang, wieso hast du bei File:Str8ts9x9 Medium SOL animated.gif als Quelle/source "Own work" angegeben? Die Datei war doch aus der de.wikipedia kopiert, oder? Viele Grüße --Saibo (Δ) 21:34, 12 February 2011 (UTC)

Weil ich mit der umständlichen regulären Transferprozedur noch nicht vertraut bin, habe ich die Datei runter- und in die Commons hochgeladen. Dabei habe ich den Autor eingetragen, und die Datei als dessen "own" erschien mir korrekt zugeordnet. Es wäre It is from another Wikimedia project wohl die bessere Wahl gewesen...

Das habe ich bereits in vielen Transfers so gemacht. Auch bei den anderen Str8ts-Transfers, vom Author=Ulcman.

Jedenfalls, danke für deine Überarbeitungen, Ergänzungen und Richtigstellungen in der Dateibeschreibung!-- sarang♥사랑 09:46, 13 February 2011 (UTC)

Gern geschehen. Nunja, manche Leute schreiben auch "own" bei source rein, wenn sie etwas aus der dewp transferieren - aber irgendwo auf der Dateiseite sollte dann trotzdem die echte Quelle (also wo du die Datei herhast) stehen, sonst kann man das ja nicht nachvollziehen, wieso diese Datei vom Autor xyz unter der von dir angegebenen Lizenz steht. Schau dir mal an, wie es mit dem Commonshelper geht - so schwer ist das nicht bzw. nimmt einem Arbeit ab. Ich helfe dir gern weiter, wenn du Fragen hast. Viele Grüße --Saibo (Δ) 13:28, 15 February 2011 (UTC)

File:Steady.svg

[1]

I will not guess what geometry has the world you are living in, but please, learn better, what is an equilateral triangle (de ko) in the Euclidean plane of SVG images. Incnis Mrsi (talk) 11:34, 15 February 2011 (UTC)

File:Flag of Libya (1951).svg

I'm not going to revert your upload, but you changed elliptical arcs to circular arcs, and if you flip back and forth between the two versions, there is a definitely discernible difference in appearance (even if relatively small)... AnonMoos (talk) 03:09, 25 February 2011 (UTC)

I think that when you fully integerized the star and crescent, you kind of simplified too much; I re-uploaded with one digit after the decimal point... AnonMoos (talk) 07:34, 25 February 2011 (UTC)

Hello! I downloaded the flag some days ago when it had 3.767 bytes, and intended some simplfications. I checked carefully to minimize any difference; the star seemed to me not so perfect as it should be, so I found it better to have the more geometrical version i made. I also do not agree to the shade of the green color, but nevertheless I used it.

I would not call the arcs elliptical; between the two radius (A 80.005592 80.005608) is a difference of 0.000016, which is nothing. And the other one is (A 182.30783 182.30783) perfect circular. Of course I accepted some rounding inaccurancies, but I thought that the flag gives rather a raw impression and has never followed any official predictions about its exact shape.

Imediatly after I made my quick upload I recognized that you did it too, some hours earlier. Several times before when I saw that you made new reduced versions I let my hands off from these files, it is not at all my intention to come into a simplification war against you; my knowledge of SVG is too poor, compared to yours. So my overloading your version was more an error than planned.

Anyway, thank you for restoring the appearance it had before; it looks perfectly the same and is very simple in coding, which makes it now to the perfect version.-- sarang사랑 11:15, 25 February 2011 (UTC)

I don't object to overwriting my uploads in itself, but in this case it changed the shape -- If you look at the original file version, you see that "A 80.005592 80.005608" is embedded in a transformation matrix "0.692627,0,0,0.680816", while "A 182.30783 182.30783" is embedded in a transformation matrix "0.348773,0,0,0.342827", so the curves do become somewhat elliptical after the transformations are applied. My "15:09, 24 February 2011" upload is an accurate reflection of the vector data in the original file (to three digits after the decimal point), but recast in a form which does not use any transformations. If you'll give me your e-mail address, I'll e-mail you three 6kb GIFs which show why I wasn't completely satisfied with your version... AnonMoos (talk) 17:57, 25 February 2011 (UTC)

You are right in every point. I always wonder why Sodipodi creates the transformations (sometimes several cascades of) instead of using data directly. Transformations can be useful when one shape is used twice or more often, or to rotate something, but Sodipodi seems to use them just to hide the true values and to make things a bit more complicated. Have you seen the "zero path" after the second (black) rectangle? By the way, you have tools to convert a (rather low quality and some errors containing) PNG to SVG, as Wappen Bad Friedrichshall.png? I'll send you my address.-- sarang사랑 06:59, 26 February 2011 (UTC)

Not sure why Inkscape does that -- I don't actually use Inkscape to edit SVG files (only to test and convert SVG files). I have a clunky procedure I sometimes use to resolve all transformations -- I convert the SVG to PostScript using the Inkscape "print direct" command, slightly edit the headers of the resulting file, convert to PDF using GhostScript, then convert back to raw unstructured PostScript using the PDFToPS utility in the "xpdf" package. The end result is that all transformations are resolved (except occasionally strokes affected by unequal stretchings), and you get "real" numbers which reflect the actual placement of objects in the SVG rectangle. This involves a lot of steps, but all the numbers are calculated automatically, without any need for guessing or hand-approximation.

I somewhat regularized the star in File:Flag_of_Libya_(1951).svg, and can fully regularize it if you really think it necessary...

The only vectorization program I regularly use is "autotrace", which is most useful for vectorizing large two-color (full black and full white only) images. For File:Wappen_Bad_Friedrichshall.png you could check out vectormagic.com's free trial period... AnonMoos (talk) 19:48, 27 February 2011 (UTC)

• I do not think that it is necessary to regularize something of that flag any more. Or, wait with that until the new Lybian government asks you explicitly for that service.
• My conversions are more old-fashioned, without procedures and programs. For calculations (as de-tranformations) I use excel tables, a quick (and not too dirty) possibility. This enables me also to compare immediately different roundings.
• To extract the coding from (and to insert into) the SVG source code text I use two steps of MS-word macros, a very cheap solution but sufficient for converting to/from xls table strucure. It does all the eliminating of redundant spaces and commas.
• I shall give it a try to vectorize with vectormagic, as you told me.

Thanx for your advices.-- sarang사랑 11:04, 28 February 2011 (UTC)

I've been using PostScript since around 1992, so it comes easier to me than SVG (see Category:Generated by PostScript) and it's natural for me to use PostScript tools to cast SVG files into "canonical" form (though such PostScript canonical form is not thoroughly optimized for SVG -- circles become four 90-degree cubic bezier arcs...). AnonMoos (talk) 20:23, 1 March 2011 (UTC)

Beautiful graphics Generated by PostScript! -- sarang사랑 18:54, 2 March 2011 (UTC)

Thanks... AnonMoos (talk) 14:26, 3 March 2011 (UTC)

SVG path question

By the way, is it possible to specify a circle with an "M" or "m" followed by a single "A" or "a" path command (instead of two)? None of my experiments really worked... AnonMoos (talk) 20:23, 1 March 2011 (UTC)

To be exact: No, you cannot; but you can draw almost a circle, so close to a real circle that in many cases it can be used for it. See the examples at SVG Anti logos, e.g. Anti.svg. By drawing a circle with a minimized gap, as <path stroke="#000" fill="none" d="M250,20a200,200 0 1,1-.1,0"/> (for width=height=500), or similar (you can make a smaller gap with -.001 if necessary) you will get the impression of a complete full circle; but of course it isn't.

The Anti.svg, and all the others where I used this trick, have a very small irregularity where the diagonal stroke continues from the circle gap. The greater the stroke-width is, the worse is this failure; at No gesture.svg with 2000px you see that clearly. You can also see it at Anti-Catholicism.svg unzoomed with its 250px - but I thought it to be sufficient in these cases. Otherwise I had to change from integers to real values, and/or to connect the stroke not directly to the circle. I hope this will help you.-- sarang사랑 18:54, 2 March 2011 (UTC)

OK, I was curious to know; I guess I'll generally continue to use two 180° "A" paths... AnonMoos (talk) 14:26, 3 March 2011 (UTC)

---

I was more concerned to know whether it was geometrically possible, than whether you could save a few bytes by approximating. Someone who is heavily into the geometric mathematics of SVG files is User:Georg-Johann... AnonMoos (talk) 18:06, 9 December 2011 (UTC)

---

Thanks, but as already indicated, I mainly wanted to know if it was possible to specify a geometrically-possible perfect circle by using an "A" command. I'm really not so interested in shaving a few bytes off of SVG files that I would substitute something else for a real circle (my goal is more a clean SVG file, not necessarily one with an absolute minimum bytes count and slightly off geometry). AnonMoos (talk) 15:00, 25 May 2012 (UTC)

Labores flag

Sorry I didn't get back to you before, but I don't always check my e-mail regularly. That approach involved specifying 4 different red shapes, none congruent, and so seemed somewhat inelegant. However, I've uploaded a new version condensed with a somewhat different approach. AnonMoos (talk) 16:43, 7 March 2011 (UTC)

There are always incountable possibilities to draw an image, even a simple one. Of course your version, with 2 rects and 1 path used a 2^nd time, is somehow clearer and much better to understand than mine with only 1 rect and 1 (long) path, and its overlaid areas. Nevertheless I think my attempt interesting, and it belongs more to my style.-- sarang사랑 22:03, 7 March 2011 (UTC)

Just think, "What Would McSush Do?" The truly elegant approach would be to use a stroke within a clipping path, as in the flag of South Africa, but I don't feel like doing the trigonometric calculations that would be necessary to change the fill to a stroke... AnonMoos (talk) 07:45, 8 March 2011 (UTC)

File:Mappusweg.gif

File:Mappusweg.gif 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 see Commons:But it's my own work! for a guide on how to address these issues. 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!

Túrelio (talk) 07:54, 23 March 2011 (UTC) Mappus is weg, & Mappusweg is weg...

BSicon_ehRP2e.svg

Thanks for this, man. I try to avoid the clutter, and my more recent SVGs show this (I hope!), but it is great to see that most of what I was afraid to cull is really needless. Tuvalkin (talk) 23:54, 16 April 2011 (UTC)

File:Ali-kufi.svg

Unfortunately, it's simply an undisputable fact that the great majority of SVG-makers would have no idea how to generate an SVG from scratch by hand in a text editor, so the advice you added to this image's description page was unhelpful. AnonMoos (talk) 13:05, 1 May 2011 (UTC)

Thank you for caring. But I think that any user who wants to know about can find several explanations how to do, indeed some users had asked me directly and some of them are now trying, with or without my further advicing. So I think it might be helpful to mention it, and will do no harm. -- sarang사랑 13:10, 1 May 2011 (UTC)

Then why not say "in such cases better-quality results can be obtained by [doing X]" instead of "it should not be generated with Inkscape"? -- because the latter wording can be easily interpreted as having a somewhat chiding tone, or seeming to claim that this is a commandment that was handed down on stone tablets from Mt. Sinai... AnonMoos (talk) 13:17, 1 May 2011 (UTC)

That's a good idea, I will follow it immediately. Thanx -- sarang사랑 13:20, 1 May 2011 (UTC)

You have removed my "commandment", so it's o.k. And I shall care in future… -- sarang사랑 13:24, 1 May 2011 (UTC)

Ahmadi

I don't "follow" either of you, in the sense of closely monitoring your edits, nor am I going to do so (though I do look at your uploaded files gallery on average about once a month or so). My only interaction with Ahmadi has been with respect to the feminism symbol image files, where he has a tendency to overlook certain necessary details, but I wouldn't describe his contributions as "nonsense"... AnonMoos (talk) 09:14, 3 May 2011 (UTC)

The "n"-word is not a nice classification but he made others a lot of reset work by his rather insensitive changing of pictures; besides of his more useful work.

I am glad that you check sometimes the quality of my doings, correcting it where necessary. -- sarang사랑 17:49, 14 May 2011 (UTC)

First try

Hi,

I've done a trial on File:Cantonales 2001.svg. I reduce the size from 411 to 144 Ko. It's nice for a try but did you see somethings else to optimize it further ?

Cdlt, VIGNERON * ^discut. 19:56, 9 May 2011 (UTC)

Bonjour Nicolas, sorry I didn't answer earlier, but there was no yellow bar of new talk entries so I didn't look.

You did a lot of work, as far as I see in a first glance, by grouping (same style attributes), by calculating absolute values to relative coordinates, and more re-arranging. You may be proud about your success, saving two thirds of idle coding for just the same image. How did you calculate the relative values - can you use your procedure as well for other pictures (with not too much adapting needed)? I guess that you did a lot "by hand" and other work by some automated help.

Of course it will be possible to remove some more of Sodipodi generated coding but with much less success. Most of the style attributes may either be removed completely, or written more simple. Many spaces are just for better readability and not necessary (e.g. d="m 464.74613,382.24778 -2.75,0.21875 -2.125,3.3125…" is the same as d="m464.74613,382.24778-2.75,0.21875-2.125,3.3125…" [a minus sign or a command letter is seperator enough and needs neither espace nor virgule]), but such alternations will not change so much; you have already done the essential part of it. Your way is a good one! Cdlt -- sarang사랑 17:49, 14 May 2011 (UTC)

File:OEISicon.svg

Hi Sarang,
maybe this is a candidate for one of your simplifications. There is a strange rendering mistage I cant solve: The little white squares in the corners. In Inkscape the file looks ok. Lipedia (talk) 13:08, 18 July 2011 (UTC)

Hi Tilman, sure it is a challing candidate. Both versions, 6 KB as well as 14 KB, show the same error in the corners. I think it will be possible to draw it extremely near to your pics but errorfree with very simple SVG commands that it will need about 1 KB. I shall give it a look. -- sarang사랑 16:54, 19 July 2011 (UTC)

Hi again, I gave it a 1st try using text. As always, it depends on the font when it is rendered. What looked exactly fine when I looked at it offline, appears different when rendered by librsvg: the letters are not close together but separeted by large distances.

I am more successful drawing it with simple SVG path commands but that is more complicated to do, I am not yet ready and need some more time.

Now I know which Sodipodi error causes the squares, it is possible to go around and avoid it. But it seems preferable to take another way. -- sarang사랑 17:15, 20 July 2011 (UTC)

File:Symbol píča.svg

By the way, I still have no idea what the "reduction ratio" number is supposed to mean ("reduction ratio=0883" etc.)... AnonMoos (talk) 12:34, 29 August 2011 (UTC)

Nothing of great significance. It is used as sorting criteria within categories, it is explained in SVG Simplified,and is calculated from current :: previous file size. 0883 means reduction to 08.83%. -- sarang사랑 12:49, 29 August 2011 (UTC)

Might be nice to have a more user-friendly display ("compressed to 8.83% of former size" or whatever) on the individual image description pages... AnonMoos (talk) 01:21, 30 August 2011 (UTC)

Will be no problem to give this info. I did not believe that anybody would be interested in such details, so I took this abbreviated form. But I will check an extension of {{SimplSVG}} to give a display as you suggested. -- sarang사랑 07:50, 30 August 2011 (UTC)

If it's displayed at all, it should not be displayed in a very cryptic form. I don't know much about the technical details of template script programming and so can't give advice at Svtest... AnonMoos (talk) 13:36, 31 August 2011 (UTC)

If you want the least amount of words, how about "now 8.83% of previous size"? AnonMoos (talk) 13:05, 5 September 2011 (UTC)

Ok, thanx, I will tell it this way. -- sarang사랑 14:00, 5 September 2011 (UTC)

typo

"extremly"... AnonMoos (talk) 17:13, 10 September 2011 (UTC)

Oops... It is always helpful if somebody knowing really English gives a look to my writings. Thanx! -- sarang사랑 17:44, 10 September 2011 (UTC)

BSicons: Replacing white masks with dashing

Perfect at 500×500px.

Gapped at 500×500px.

You may want to check this. --Tuvalkin (talk) 06:51, 3 September 2011 (UTC)

Great, thanks, I need help! The dashing thing doesn’t look the same in the browser (as an SVG) and on the PNGs created by Mediawiki, I'm freaking out. You'll shed some light on the matter and give some advice here, please? --Tuvalkin (talk) 09:43, 3 September 2011 (UTC)

Bom dias, the Wikimedia SVG tool (librsvg) has some bugs; it needs some work-arounds to avoid them. I will look for your problems; in the meantime you may check BSicon vÜWBr.svg:  whether it shows what you want. -- sarang사랑 09:52, 3 September 2011 (UTC)

Well, that's great! I like your compact SVGing, and also for some reason your dash-array 210,180 in  (vÜWBr) was rasterized by that librsvg thing properly, while mine (same values) was not in in  (vÜWBl) (extra gap at lower left). Probably it is not unwise and go ahead with this, trusting that sonner or later librsvg will catch up? --Tuvalkin (talk) 10:47, 3 September 2011 (UTC)

I checked a while but couldn't find out why your pic is misinterpreted. Since you messaged me I made a simplified version of vÜWBl, from which I created quickly the vÜWBr, and it seems to work correctly. I can replace the the gapped pic, and when I shall find out the reason I will tell you. May be stripping some redundant codes had helped? -- sarang사랑 10:57, 3 September 2011 (UTC)

This is what I saw on my screen; now I see it properly — thank you! I then thought it was because you are using stroke-dasharray="160 220" while I had favoured style="stroke-dasharray:160 220", but this says it is not so. Maybe spaces vs. commas? I’ll be trying it now. :-\ --Tuvalkin (talk) 11:38, 3 September 2011 (UTC)

Yay!! You rock, Sarang! --Tuvalkin (talk) 11:42, 3 September 2011 (UTC)

The specs tell: no difference between space and comma. But there are other bugs against the specs. I believe rather the bug is initiated by the numeric values, when rendering different size cause different rounding errors. I intend to test with stroke-dasharray="215,148". Due to my experiencies, this could help.

Another file where this bug becomes visible is File:U+06DE.svg: -- sarang사랑 11:53, 3 September 2011 (UTC)

or Roundel-sable.svg (should not touch the right and bottom line)  

---

You should file a bug report, since it's annoying that a completely "plain Jane" file such as Image:U+06DE.svg (with no complex or esoteric code) has such problems... AnonMoos (talk) 12:12, 8 September 2011 (UTC)

Template:Derivative versions

Hallo Sarang, wichtiger Hinweis: mit deinem Browser scheint etwas nicht zu stimmen. Du hast wohl unabsichtlich bei deinem Edit in Template:Derivative versions viele Sprachen zerstört. Da ist was mit dem UTF-8-Support falsch. Bitte prüfe bis du weißt, dass das nicht mehr passiert mit "änderungen zeigen" vorm Abspeichern, dass es nicht auftritt, wenn du solche Edits machst. Viele Grüße --Saibo (Δ) 02:48, 5 September 2011 (UTC)

Danke. Das ist mir recht peinlich, dass mir das passiert ist und ich es überdies nicht gemerkt habe. Zwar habe ich die Änderung extern getestet, aber nach dem Umspeichern nicht mehr genau genug auf alles geachtet. Ich gelobe Besserung -- sarang사랑 05:21, 5 September 2011 (UTC)

Ah, okay. Dann ging vielleicht beim "Umspeichern" von Texteditor (ohne UTF-8) zu Browser etwas verloren? Viele Grüße --Saibo (Δ) 16:02, 5 September 2011 (UTC)

Hallo Saibo, ich habe vor die Erweiterung in {{Derivative versions}} wieder einzubauen (diesmal ohne Kollateralschäden), da ich sie für sinnvoll halte. Und da bin ich mir einer Sache unsicher; ich weiss dass auf commons vieles ganz anders gesehen wird als in der de:WP, aber du bist ja in beiden Welten zuhause und meine Frage ist eher allgemein. In der Vorlage wird öfters, einstweilen bis zu 20mal,
*[[:File:{{{7|}}}|{{{7|}}}]] }}{{#ifexist:Media:{{{8|}}}| codiert.

Das könnte ich entweder 20mal so erweitern

*[[:File:{{{7|}}}|{{{7|}}}]]{{#if:{{{display|}}}| [[File:{{{7}}}{{!}}{{{display}}}px]]}} }}{{#ifexist:Media:{{{8|}}}|

oder indem ich eine andere Vorlage sekundär aufrufe, dann sieht die Zeile so aus
*{{F|{{{7}}}|3={{{display|}}}}}}}{{#ifexist:Media:{{{8|}}}|, also viel übersichtlicher.

Ich neige zur kurzen Variante. Spricht irgendetwas dagegen, in diesem Fall von der Vorlage eine weitere Vorlage aufrufen zu lassen? Solche Schachtelungen gibt es ja oft.

PS.: Ich finde die commons-Vorlage {{F}} recht brauchbar. Leider sind in der de:WP solche shorthands unerwünscht. -- sarang♥사랑 17:07, 5. Sep. 2011 (CEST)

Hi Sarang, bitte belasse Commons in Commons und dewp in dewp, wenn es geht. :) Dann geht auch das Verlinken einfacher.

Gut, leuchtet mir ein, mache ich. -- sarang사랑 16:43, 5 September 2011 (UTC)

Nun zur Sache: was ist denn an der bisherigen Variante schlecht? Sie ist recht kurz und übersichtlich und benutzt keine weitere Vorlage (deren Syntax und Funktion ohne weiteres Ansehen mir erstmal unbekannt ist). Ansonsten habe ich und AFAIK auch die Commons-Community nichts gegen Vorlagenschachtelung. Die Server solln arbeiten (wenns für uns dadurch leichter/besser geht) - dazu sind sie da. ;) Viele Grüße --Saibo (Δ) 16:02, 5 September 2011 (UTC)

Danke, da bin ich beruhigt, und lasse die Server feste arbeiten. Gruß -- sarang사랑 16:43, 5 September 2011 (UTC)

So, aber eine Sache musst du mir bitte dennoch erklären: wie auch schon oben gefragt: was ist daran leichter lesbar? Ich finde es deutlich komplizierter. Viele Grüße --Saibo (Δ) 23:56, 7 September 2011 (UTC)

Hallo Saibo, ich finde gut dass du sowas überwachst um eventuellem Wildwuchs in den Commons vorzubeugen. Gerne versuche ich dir das zu erläutern.

Es geht nicht darum eine funktionierende Vorlage zu ändern, sondern um eine kleine Erweiterung. Wie im obigen Beispiel zur Anfrage gezeigt, ist es innerhalb der Vorlage natürlich komplizierter als ohne die Erweiterung, aber durch die Verwendung von {{F}} dennoch lesbarer als die mittlere (eingerückte) Codezeile im Beispiel. Je einfacher etwas in einem Vorlagenaufruf ist, desto komplizierter wird es zwangsläufig innerhalb der Vorlage. Eine Anwendung kanst du in der Beschreibung von BSicon exvBHF.svg sehen, dort sollte auch zu erkennen sein warum mir die Erweiterung sinnvoll schien.

BTW: In {{Derivative versions}} wird immer jeder der 20 möglichen Parameter auf Existenz geprüft, statt nach dem ersten leeren Parameter abzubrechen. Ich weiss zuwenig über Vorlagenauflösung um beurteilen zu können wieweit es das Servern erleichtern würde — oder auch komplizieren, durch die notwendige tiefe Schachtelung der Klammerungen; deshalb habe ich es damit belassen. Mit freundlichem Gruß, -- sarang사랑 09:11, 8 September 2011 (UTC)

Boah, sag doch gleich, dass du die Funktionalität der Vorlage erweitert hast (das wusste ich nicht!). Mir war sowieso unklar, wieso du "expansion" als editcomment nimmst. Hättest du "new functionality: display parameter" genommen, hätte ich es sofort verstanden.  :)

Der 20malige Aufruf ist mir reichlich wurscht, wie oben gesagt. Ich habe keine Lust da irgendwas zu basteln, was abbrechen würde. Viele Grüße --Saibo (Δ) 02:28, 9 September 2011 (UTC)

File:FlagofGod.svg

File:FlagofGod.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 see Commons:But it's my own work! for a guide on how to address these issues. 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!

P199 (talk) 17:07, 8 September 2011 (UTC)

TUSC token 3431030a226da4f24391e82cf0a5d5f9

I am now proud owner of a TUSC account!