User talk:Sarang/Archive/2012

Category:Box drawing

For what purpose did you make this duplicate? There is already Category:Text mode box drawing, look better for existing categories next time. Incnis Mrsi (talk) 12:16, 11 January 2012 (UTC)

Hi Incnis, thank you for caring and looking for category usability.

Text mode box drawing is something complete different. IMHO this new category and Unicode 2500-257F Box Drawing are both useful for proper categorizing. -- sarang사랑 12:48, 11 January 2012 (UTC):This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)

Oppose to change license

I oppose to your changes in licenses of images to simple geometry. Unless there is a clear LEGAL definition defining the line, please revert license changes you have done to my images. --Nevit Dilmen (talk) 12:33, 30 January 2012 (UTC)

Hi Nevit, may I suggest that we ask license experts whether the images are too simple to get licensed? It is just my opinion that they all are ineligible; but if you like them licensed anyway otherway I will not at all oppose you. Of course you had done some work, and if you believe to have crossed the threshold it will be ok. -- sarang사랑 12:50, 30 January 2012 (UTC)

I suggest a new template. With summary such as:

The uploader User:xxx has uploaded this file with yyy license. User:zzz has suggested that the file might be in PD because it consists of simple shapes and geometry. You might use the file with the license of your choice.

No harm will be done this way.

As you might recall the first movement of Beethoven's 5th symphony is composed only of 4 notes: da da da da. Two rectangles compose a cross and that simple geometry has been used as an icon for thousands of years.

--Nevit Dilmen (talk) 13:32, 30 January 2012 (UTC)

Good idea! Either of us should discuss it at the village pump, or whatever else is the authority to decide that – otherwise a new license template will be heavy opposed.

But: IMHO/AFAIK when a file is PD any contradictionary stronger license will not give any protection. -- sarang사랑 13:39, 30 January 2012 (UTC):This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)

HQSG template / Category

User:AnonMoos pointed me User_talk:Achim1999#Templates to contact you regarding Template:HQSG. Achim1999 (talk) 15:42, 27 June 2012 (UTC)

O.K., I gave it a look. AnonMoos is right that at this state it does not fit into template style or rules. Never mind. Since there are only ~20 transclusions, it won't matter to change them.

If any template, it should include {{HandSVG}} as well as {{ValidSVG}} (ValidSVG with the source option).

After checking and thinking it over, I would suggest to use HandSVG expanding it with the character "H" for the 3^rd parameter, so creating it into Structured SVG while using all other possibilities:

{{HandSVG|Achim1999|f|H}} würde dann folgendes leisten: Kategorisierung nach Structured SVG, Manually coded Valid SVG und SVG simplified flags (wobei es besser wäre stattdessen in eine Unterkategorie wie SVG structured flags zu kategorisieren). Ausserdem wird die Beschreibung mit einem aussagekräftigen tag versehen, zu dem du gerne Vorschläge machen kannst - den Einbau in die Vorlage mache ich dann.

Alternativ wäre, doch eine eigene Vorlage zu lassen (obwohl es die Vorlageninflation weiter erhöht) und von dieser dann {{HandSVG}} aufrufen zu lassen, wie es {{SimplSVG}} bereits vormacht.

Zum Kategorienamen: Structured SVG ist ebensowenig optimal wie SVG Simplified, was eigentlich eine Abkürzung ist für "SVG simplified drawings" oder so; wenigstens ist der wichtigste Qualifier "SVG" führend, dem würde SVG Structured entsprechen, wenn es "SVG structured codings" meint. Noch ist das suboptimal, wäre aber noch besser als das historisch gewachsene Valid SVG bzw. Manually coded Valid SVG! Da alles mit der Vorlage gesetzt wird, ist die Änderung des Kategorienamens, auch später, ohne jedes Problem.

Wir können noch gemeinsam nach einer besseren Lösung suchen. sarang♥사랑 12:48, 30 June 2012 (UTC)

Danke für deine ersten Gedanken. Eine perfekte Lösung wird es nie geben, daher wäre eine weitere Verbesserung stets möglich. Und in dem Sinne kann man damit auch sofort anfangen. Die technische Umsetzung würde ich erstmal Dir aufbürden ;) -- wenn sie leicht ist um so besser -- da ich mich mit Templates GAR NICHT auskenne.

Wenn man sie mit HandSVG & SimpleSVG zusammen mischt, sollte man dafür sorgen, daß es dann aber auch nur noch dieses eine (HandSVG z.B. oder wie es auch immer genannt wird) benutzerseitig genutzt wird und nicht noch woanders weiter die früheren. ValidSVG ist davon vermutlich unberührt -- darf sinnvollerweise auch einzeln genutzt werden.

Stichwort Sinn / Zweck: Das ist das eigentlich Wichtigste. Dass man da eine zweckmäßige gute Grundphilosophie hat, damit man dies nicht alle Jahre neu ändern / überdenken muß! Bei meinem HQSG hatte ich High-Quality-Structured-Graphics (als Philosophie) im Hinterkopf! Erstens muß dies nicht notwendigerweise "händisch" überarbeiteter SVG-Code sein, wenn Programme die logische Struktur der Konstruktion/Geometrie erhalten und ordentlich ablegen, können sie natürlich auch diese Attribut/Markierung/Template erhalten (dies halte ich in der Zukunft auch für realistisch). Zweitens sollte man dies nicht nur auf SVG sondern allgemein auf Vektorgrafik (zukunftssicher) ausrichten (PS/EPS kenne ich da noch, bei PDF weiß ich nicht ob dies Sinn machen könnte?) Letzlich kann man über weitere Parameter natürlich vieles steuern (z.B. Gliederung nach Thematik der Graphik) oder (später) feiner fassen. Achim1999 (talk) 09:42, 1 July 2012 (UTC)

Gut, damit fällt {{HandSVG}} etc weg, wenn sowohl hand als auch SVG nur eine von mehreren Optionen sind - auch wenn zumindest vorerst bei allen in Frage kommenden Grafiken sehr wohl beides zutrifft. Das legt nahe, {{HQSG}} zu verwenden und sehr flexibel zu halten für künftige Erweiterungen. gl= mit default=SVG, und ed= mit default=hand würde dann zweckmässigerweise in {{HandSVG}} münden, bei anderer Parameterbesetzung muss dann eben was anderes erfolgen. Du musst dich nicht mit templates herumschlagen, das kannst du getrost anderen überlassen, wenn du nicht den Ehrgeiz verspürst auch noch in diese Materie einzudringen. Ich werde {{HQSG}} nach allen Richtungen offen und möglichst übersichtlich = leicht bearbeitbar gestalten. Verstehe ich dich richtig dass du benannte Parameter mit zweistelligen Namen (sc=, gl=) vorziehst? Kann ja alles leicht geändert werden, auch ed= für Editortool (oder "et"?). Üblicherweise kann im ersten unbenannten Parameter der Benutzer verewigt werden.

Wenn so eine strukturierte Grafik gleichzeitig eine manuelle Neuerstellung ist und eine vorige toolgezeichnete ersetzt, erscheint mir allerdings {{SimplSVG}} besser geeignet; dazu würde ich SimplSVG und HandSVG für diese neue Aufgabe erweitern. OK? -- sarang♥사랑 10:56, 1 July 2012 (UTC)

Was "benannte Parameter" oder andere interne Notationen angeht, dazu habe ich keinerlei Meinung. Und um dazu eine sinnvolle zu bilden, um dies letzlich gut beurteilen zu könenn, müsste ich erstmal viel mehr über Templates wissen. Daher halte ich mich da völlig raus. Auch zur Namenswahl habe ich keine Vorgaben -- mir geht es darum eine vernünftige sinnvolle Grundphilosophie umzusetzen. Ich hoffe dass es bald die Möglichkeit gibt diese SVG-Dateien ganz normal wie andere Artikelseiten hier auf Wikipedia SVG-Dateien zu editieren. Dies ist ja nur aus historischen Gründen ausgeschlossen worden -- die Tools der Versionsverwaltung dazu gibt es ja schon alle. Und da es ganz normaler (XML-)Text ist, kann man dann auch praktisch gute SVG-Grafik benutzerseitig erstellen/schreiben.

Zu deiner letzten Frage kann ich wenig sagen. Da müsste ich erstmal das genaue wieso/warum was Du da als Begründung/Zweck zu im Hinterkopf hast, hinterfragen -- würde ja bedeuten , daß man (abgesehen von ValidSVG) dann doch wieder viele SVG-Templates hat die eigentlich alle nur was über deren (des SVG-Files) Qualität aussagen.  :-/Achim1999 (talk) 17:28, 1 July 2012 (UTC)

Ich habe eben zufälligerweise festgestellt, daß Du ja gar nicht im Urlaub bist wie ich angenommen hatte. Daher meine Frage: Wann wolltest Du denn mit dieser Umsetzung anfangen? Achim1999 (talk) 19:02, 11 July 2012 (UTC)

Hallo, inzwischen habe ich die Vorlage fertig - bis auf den category-Namen, auf den wir uns einigen müssen. "Structured SVG" finde ich nicht so sehr gut, wie ich oben ausgeführt habe. Ich schlage vor, eine Oberkategorie "HQSG" oder explizit "High Qu.....Graphics" oder so ähnlich zu etablieren, und darunter (die einstweilen einzige Unterkategorie) "SVG structured" oder so ähnlich einzurichten; dorthin kommen dann deine Grafiken.
In den bisher 33 Dateien muss ohnehin "ValidSVG" + "HandSVG" + "HQSG" durch einen Vorlagenaufruf ersetzt werden, das geht schnell, jedenfalls ist hier ein anderer Kategoriename kein Mehraufwand. Sobald der Name feststeht lade ich die Vorlage hoch. sarang♥사랑 16:14, 14 July 2012 (UTC)

Hallo ihr, ich würde es sehr begrüßen wenn es nur eine Vorlage dbzg. (zwei?) Projekte gibt, damit wäre einigen Leuten geholfen (wie ich sehe bin ich da auch nicht der Einzige...) Eigentlich ist es auch eher eine interne Kategorie!? Ansonsten halte ich die Grundidee für sehr gut und bin auf euer fortwirken auch sehr gespannt. -- πϵρήλιο ℗ 19:25, 14 July 2012 (UTC)

In Prinzip bin ich auch gegen unnötig viele Vorlagen für die selbe Sache. Nur "validSVG" hat meines Erachtens nichts mehr mit einer inhaltlichen Bewertung des SVG-codes zu tun -- ausgenommen natürlich, daß es syntaxtisch korrekt ist. :-) Ich habe sogar versehentlich HQSG, die aber nicht valid-SVG sind, hier dreimal abgelegt. Warte noch auf Korrektur. :-/

Man sollte / könnte daher meiner Meinung nach beispielsweise handSVG + HQSG + simpledSVG (und ähnliches) in ein Template / Category packen.

Was den Namen der Kategorie oder Subkategorie angeht, würde ich deine Kompetenz und deinem Weitblick erstmal vertrauen und trete Dir mein Mitspracherecht hiermit ab um es Dir zu vereinfachen das zügig zu entscheiden und zu realisieren. Ich gebe allerdings zu bedenken: intendiert ist bei dem HQSG, dass die logische / geometrische Struktur der Zeichnung / Grafik im SVG-Kode gut ablesbar ist. Der Begriff "High Quality" alleine sagt darüber gar nichts aus.

Ansonsten natürlich Danke schon jetzt und ich hoffe Du kannst es bald zu Ende bringen. :) Achim1999 (talk) 18:28, 15 July 2012 (UTC)

Noch eine kurze Anmerkung/Bitte: Ich hoffe doch stark, daß nach der erfolgten Zusammenfassung der SVG-edit-Templates in ein einziges Template, das Feature von handSVG bzw. des dann neu geschaffenen Templates, den SVG-source-code per Link explizit anzubieten anzuzeigen, dann dort auch verhanden ist. :) Achim1999 (talk) 21:49, 15 July 2012 (UTC)

Ach so, hatte ich irgendwie nicht so klar ausgedrückt. Du, Sarang, darfst diese SVG-Templates auch mit doppeltem Stimmengewicht vereinigen wie Du magst (ich wollte Dir auch in diesem Punkt meine Stimme überlassen). Achim1999 (talk) 21:53, 15 July 2012 (UTC)

Hallo Perhelion, wie du richtig sahst ist {{HQSG}} eher eine vorläufige Sache, die zu ersetzen wir hier diskutieren. Es gibt die Vorlage {{HandSVG}} (eigentlich hat sie den umständlichen aber deutlicheren Langnamen {{Created with Text Editor}}), die ich im Laufe der Zeit um einiges erweitert habe, und noch weiter erweitern werde. Von {{SimplSVG}} wird u.a. sowohl {{Valid SVG}} als auch "HandSVG" aufgerufen.
Bei "gut strukturierten Grafiken" gibt es zwei Fälle: sie sind entweder manuell erstmals erstellt, oder sie wurden manuell neu codiert nachdem sie mit einem der Tools erzeugt worden waren (toolerzeugt und strukturiert wären ein Widerspruch per se).
Im ersteren Fall sollte "HandSVG", im anderen "SimplSVG" cat+tag leisten. Dabei muss beachtet werden, dass bei simplifizierten SVGs immer auch Valididät vorausgesetzt ist — bei allgemein texterstellten nicht unbedingt; diese Validität würde ich bei strukturierten nun implizieren.
SimplSVG kann immer auch für Grafiken ohne Toolvorgänger verwendet werden, wobei es dann statt "vereinfacht" eher "einfach" bedeutet. Eine Diskussion könnte entbrennen ob für neu erstellte strukturierte Grafiken ebenfalls generell "SimplSVG" geeignet wäre. Bei Betrachtung der beiden Grafiken 1.31.4 (Road sign).svg und 1.31.5 (Road sign).svg neige ich zur Ansicht dass es da einen Unterschied zu berücksichtigen gibt, und es sind nur bedingt vereinbare Zielsetzungen, Code zu verschlanken oder aber zu strukturieren. Zwar kann relativ einfach mit ganz gut strukturiert kombiniert sein, doch divergiert das bei extremer Verfolgung eines der beiden Ziele zusehends.

Ich habe mich viele Tage bemüht die Vorlage SimplSVG zu vereinfachen, wie es dringend angeraten wäre; das ist mir bis jetzt nicht gelungen — doch bleibe ich da dran, denn eine gut strukturierte (sic!) Vorlage ist leserlicher + wartbarer.

Die Erkenntnis sollten leider viel mehr Leute haben. :-/ Achim1999 (talk)

Hallo Achim, da eine Kategorie immer relativ leicht umzunennen und die Zuordnung durch eine Vorlage schnell zu ändern ist, lasse ich es mal beim bisherigen Namen. Bis uns was besseres einfällt. Die beiden Vorlagen werde ich demnächst upgraden, die Beschreibung erfolgt in deren Dokumentation und, ganz ausführlich, in deiner Kategorie. Übrigens, das past participle zu Write ist wirklich written. Leider ist mein Englisch auch nicht so toll, dass ich die Texte glätten könnte, doch der typo in superflous ist mir aufgefallen. Bis bald, -- sarang♥사랑 08:02, 16 July 2012 (UTC)

Na ja, ich gehöre nicht zu den Leuten die aus der relativen Häufigkeit von Typos/Grammar/Style/wording-Fehlern auf die inhaltliche Qualität der Aussage/Argumentation schließen. Daher bin ich zufrieden wenn ich meine den Sinn immer noch rauslesen zu können. Prinzipiell sollte mein English schon dazu ausreichen, ich habe nur keine Lust hier mir die Note 1 oder 2 zu verdienen und dafür stets 3mal querzulesen. Wozu der Aufwand? Ist eben eine Aufwand/Nutzen-abwägung. :-)

Ich finde es ziemlich witzlos zwischen tool-erstellt und manuall (weiter) editiert/erstellt irgendwie verzweifelt zu klassifisieren. Da dort ein völlig fliessender Übergang von 0 - 100 % existiert . Ich frage mich eh, was die Information, daß es vom XYZ_Tool (mit)erstellt wurde für einen tieferen Sinn hat, der so wichtig ist hier verewigt werden zu müssen. (Das einzige was mir dazu einfällt ist, daß es eine Werbung/Prestigesache für den Toolhersteller ist sich eventuell stärker zu verbreiten -- sprich Werbung in eigener Sache, wenn man propritäre Features so stärker durchdrücken möchte) Achim1999 (talk) 08:48, 16 July 2012 (UTC)

Da handelt es sich eher um mein Missionierungsbemühen — dass ich versuche darauf hinzuweisen dass Grafiken mit einfachen Strukturen IMHO besser manuell erstellt werden sollten; deshalb stelle ich auch den prozentuellen Unterschied so aufdringlich dar. Durchaus negative Werbung für Inkscape, Adobe & Co! Du hast ja auch die Erläuterungen der Simpl-Kategorie in die HQSG-Kategorie übernommen. Deshalb würde ich weiterhin bei den jeweiligen Dateien entweder den Verschlankungseffekt prozentuell ausdrücken, oder sie als manuell gut strukturiert einordnen; und beides wo es dir angebracht erscheint. -- sarang♥사랑 09:22, 16 July 2012 (UTC)

Okay. Dann halte ich mich da raus, weil dies eine bewusste psychologische Massnahme deinerseite ist. Achim1999 (talk) 14:18, 17 July 2012 (UTC)

Nun präsentiere ich {{HandSVG}} mit den Erweiterungen. In 1.31.4 (Road sign).svg habe ich es mal eingebaut - hier mit 1. und 2. Parameter (user und tool), wichtig ist in deinem Fall nur 3=H. Wenn du auch Simplifikation anmerken möchtest, ist in {{SimplSVG}} der Parameter 5=H erforderlich. Ich verfertige noch eine verständliche und genaue Beschreibung in deiner Kategorie. -- sarang♥사랑 12:44, 16 July 2012 (UTC)

Und ich warte auf deine Vorschläge, einmal zum Text der vorerst mal "It is a High Qualified Structured Graphic" lautet; und was du zum Umgang mit den beiden Vorlagen verbessert haben willst. Irgendwann können auch Subkategorien erforderlich werden, das kann bereits jetzt im Aufruf berücksichtigt werden. Die Vorlagen werden nun von ein paar weiteren Dateien verwendet. -- sarang♥사랑 06:30, 17 July 2012 (UTC)

Habe den Text im Template {{Created with Text Editor}} fuer 3=H geaendert. Da ich nicht genau weiss wozu der dient, weiss ich auch nicht ob er zu lang geraten ist. Darfst Du gerne wieder aendern. Ansonsten haette ich erstmal nur einen Source-code-Link des SVG noch sichtbar. Filesize anzeigen waere auch ganz nett, aber nicht ganz so wichtig (betrifft ja ebenso HandSVG). Den koennte man dann auch zusaetzlich erst ab <svg> messen, ohne Kommentare messen, etc. .... ist alles Geschmacksfrage, wenn man nichts besseres zu tun hat. :) Achim1999 (talk) 16:16, 17 July 2012 (UTC)

Jetzt sehe ich auch was ich angerichtet habe -- sprich wo und wie es sich bemerkbar macht. So ist das Source-code-Link-feature ja rausgeflogen. :-( Achim1999 (talk) 16:39, 17 July 2012 (UTC)

Ich fuehle mich etwas ueberfordert. Dies geschieht offenbar auf tieferen Ebenen.

"Some skill had been used to code the geometric structure of the drawing easily recognizable in the source." Das letze Woertchen "source" haette ich dann noch als anklickbaren Link genauso wie im Text "Its source code might contain additional information or higher level semantics of the topic" die Worte "source code" anklickbar sind und das gewuenscht leisten. Aber dieser Spruch ist ja nun weg (durch den von H=3 ersetz worden).

Und das das valid beim validSVG-Template da gruen unterlegt ist, ist ja auch nicht der Default.

Achim1999 (talk) 16:50, 17 July 2012 (UTC)

Passiert die Zusammenfassung von SVG-Templates (z.B. {{Created with Text Editor}} , {{HandSVG}} und {{SimplSVG}}) noch? (weiterer Kommentar folgt noch) Achim1999 (talk) 14:38, 17 July 2012 (UTC)

Nein, das ist nicht beabsichtigt. HandSVG ist ja nur eine Abkürzung, ein REDIRECT zu "Created..." und selbst keine Vorlage; und SimplSVG ist was anderes, wobei es seinerseits HandSVG (und ValidSVG) aufruft. -- sarang♥사랑 14:45, 17 July 2012 (UTC)

Ach so ... ich dachte. Schade(?), aber okay. Dann sollte ich wohl weiterhin HandSVG benutzen. SimplSVG ist ja eine Bewertungsfrage (wann ist etwas einfach?) und da ich meistens von Hand den SVG-Kode erstellt habe -- oder aus einem vorherigen veraendert (ob der vorherige nun rein manuelll oder aus einem Tool war, welches teilweise .. *ARGH* :-( ....) DAS sollte dein alleiniges Problem sein. :-). Praktisch heisst dies wohl nur, dass ich bei den betroffenen SVG-Files {{HQSG}} komplett loesche und bei deren {{HandSVG}} irgendwo 3=H einbaue. (Gucke ich nochmal nach) Achim1999 (talk) 14:55, 17 July 2012 (UTC)

Ich habe mir gerade die Flaggen von Nepal, New Zealand and Malawi angeguckt (also deren *.svg Files). Bei Nepal und Neuseeland haette ich es genau so gemacht. :) Bei Malawi ist leider das geschehen, wovor ich Dich vorher schon gewarnt hatte. Da Du hier handSVG rausgenommen hast. gibt es nun leider keinen SVG-Code mehr zu sehen (per anklickbaren Link). Das hatte ich als wuenschenswertes Feature erwartet (war vermutlich sogar mein Hauptgrund handSVG zu nutzen). Achim1999 (talk) 15:22, 17 July 2012 (UTC)

Malawi hat natürlich den Link zur Codebetrachtung. Das grünlich hervorgehobene Feld des W3C-Validators, wie es an mehreren Stellen beschrieben ist. sarang♥사랑

Nimm als Beispiel diese Änderung: Valid und HQSG raus, und Hand mit 3=H|sc=flag erweitern. Guten Erfolg! sarang♥사랑 16:28, 17 July 2012 (UTC)

Das weiss ich doch. :) Und das ist auch okay wie ich explizit dazu sagte. :) Aber Du hast doch SimpleSVG bei Malawi genutzt (wie auch bei Flag_of_Belarus.svg) so daB dann dieses Problem auftritt.

Das ist ja kein Feature von SimpleSVG sondern man muesste dann immer validSVG setzen nur um diesen Link zu bekommen oder? Sprich nur SimpleSVG mit H=5 ergibt keinen Link zum SVG-Source. Und ferner wird bei validSVG ja der Validator uebers das Web aufgerufen. Da habe ich auch oefters Timeouts bekommen (Serverueberlastung vermutlich). Alles das scheint bei handSVG nicht noetig zu sein. Achim1999 (talk) 16:33, 17 July 2012 (UTC)

Das bedarf wohl einer Klarstellung: Der Sourcezugriff ist ein feature von ValidSVG, wenn der entsprechende Parameter gesetzt wird (siehe die Doku zu ValidSVG). Simpl ruft Valid immer mit diesem Parameter auf. Nun macht das auch Hand dann, wenn 3=H sitzt (nochmal: Hand ist identisch mit "created with text editor", ein shortcut oder redirekt; wenn es dir besser gefällt kannst du den Langnamen mit 3=H verwenden). Der Text "This vector image was created with a text editor. Some skill had been used to code the geometric structure of the drawing easily recognizable in the source" ist viiiiiiiel zu lang, kein Mensch wird das lesen. Begnügen wir uns mit "...The geometric structure is easily recognizable in the source" oder so, aber bitte nicht in einer so stark frequentierten Vorlage öfter ändern! Wie wäre es mit "The source code shows the geometric structure"? Kurz und prägnant, das bringt es. sarang♥사랑 16:52, 17 July 2012 (UTC)

Ja, die Sache mit dem anklickbaren Source-code-Link in handSVG hatte ich auch gerade durchschaut und wollte dir dies mitteilen (mein schlechtes Gedaechtnis) -- und es kam zum Editkonflixt.

"The geometric structure is easily recognizable in the source code." Mit Source-code anklickbar. Oder ist der Text schon zu lang? Achim1999 (talk) 16:57, 17 July 2012 (UTC)

"The geometric structure of this vector image is eye-catching coded". Mit "eye-catching coded" als link zum source code. "eye-catching" is reisserischer als "easily recognizable" Je nachdem was man will :-) Achim1999 (talk) 17:04, 17 July 2012 (UTC)

Jetzt wird der Link schon von Valid zur Verfügung gestellt. Das zieht sich einheitlich durch alle SVG Dateien, und ist auch schon in den meisten Sprachen angepasst. Denk daran, dass Änderungen im Text von HandSVG in allen Sprachen nachvollzogen werden müssen! Ich kann das nicht, und will es auch gar nicht. Schon das spricht für einen einfachen kurzen englischen Text, der kommt wenn das entsprechende Sprachfeature nicht existiert. Wenn es zu kompliziert wird (das ist der Fall bei diesem Source-Link), findet sich keiner der das machen will.

Ich denke ganz gut passen würde "Its geometric structure can be seen in the coding." oder noch besser einfach "The coding follows the geometric structures." Ich denke noch weiter nach. sarang♥사랑 17:35, 17 July 2012 (UTC)

Hmm ... ich habe das Gefühl das ich was wesentliches hier nicht verstehe.

"Jetzt wird der Link schon von Valid zur Verfügung gestellt." Okay und? Ich meine was hat das jetzt mit meinem auszusuchenden Text zu tun?

Verstehe ich das richtig, daß du keinen Link auf den Source-code in diesem Text den ich mir ausdenken sollte setzen kannst oder willst?

Keine Angst, ich werde nicht auch noch an dem {{HandSVG}} rumspielen, nach dem ich es mir ja schon durch eigenmächtiges ersetzen meines langen Text für H=3 bei "{{SimplSVG}} verscherzt habe. :) Achim1999 (talk) 21:44, 17 July 2012 (UTC)

Wo wird denn der Text "Its source code might contain additional information or higher level semantics of the topic" den {{HandSVG}} ausgibt definiert? Damit ich mal sehe was oder wie dieser Link bei source dort reingesetzt wird (das code dort nun grün unterlegt ist, hast Du vermutlich gemacht). Achim1999 (talk) 22:04, 17 July 2012 (UTC)

Noch was: Der Spruch:"This vector image was created with a text editor." muß der auch bei meinem Text (also bei 3=H) auch immer davor sein? Also vor dem Text den ich mir ausdenken dürfte. Achim1999 (talk) 22:13, 17 July 2012 (UTC)

Ja. Der erste Satz ist 'hart' codiert, in allen neun Sprachen, und nur der zweite kann variiert werden. Da werde ich auch keine Umgehung suchen, wegen der anzustrebenden Einheitlichkeit. Wenn beim Aufruf kein zweiter Satz mitgegeben wird bleibt das Wortungetüm. Die deutsche Variante lautet "Die Datei enthält u.U. weitere Informationen, oder ihr Aufbau entspricht in besonderem Maße dem dargestellten Gegenstand". In manchen der anderen Sprachen klingt es weniger mühsam.

Ich tendiere zu einem einfachen "The coding shows the geometric structures", eventuell noch adjectiviert (simply, clearly, exactly, im/expressingly, …). Allzuviel Text lenkt vom wesentlichen ab - der (mehr oder weniger getreuen) Repräsentation der geometrischen Gegebenheiten. Wir können in Ruhe den passenden Text überlegen, ev. auch andere Meinungen einholen; wenn der Text wirklich stimmig ist wird er auch eher erhalten bleiben.

Demnächst werde ich mal sehen, wie das Einpflegen der Mehrsprachigkeit funktioniert. sarang♥사랑 06:18, 18 July 2012 (UTC)

Hmm ... irgendwie mißfällt mir die ganze Herangehendsweise. Du hattest von mir erwartet mir einen Text aus zudenken. Ich hatte angenommen, der sollte diesen 2ten Satz den handSVG produziert ersetzen (daß der erste immer bleiben soll/musste wusste ich da nicht. Dadurch wird der ganze Spruch ja auch länger und in meinem Fall finde ich die Information daß das vector-Bild manuell kodiert wurde ziemlich egal. Es darf gerne auch durch ein Tool kodiert sein, wenn es immernoch gut lesbar und die geometrische Struktur im Source evident ist.) Daher könnte bei H=3 der feste Satz von mir aus auch fehlen, IMHO. Wogegen ich aber (mehr als auf eine möglichst gute/treffende Formulierung) Wert auf einen Link zum Source lege, weil da kann man den dran direkt einsehen und von dieser behaupteten erkennbaren geometrischen Struktur des Bildes dort sich selbst ein Bild machen! Über Nacht habe ich nochmals nachgedacht: Das der SVG-code per Web zu einem anderen Server geschickt wird, nur damit der ein Sourcelisting zurück schickt ist ja wie mit Kanonen auf Spatzen geschosssen. Wenn der eigentlich Grund wäre eine Validierung zu bekommmen und das Sourcelisting gibt es wunschweise ohne wesentlichen Zusatzaufwand dazu, dann ist das ja zu verstehen. Aber von Validierung muß/will ich ja erstmal hier gar nix wissen (dazu würde wenn gewünscht explizit validSVG ganz unabhängig gesetzt um dies zu Überprüfen. Ganz davon abgesehen, müsste ja eigentlich das Template validSVG nicht immer ein validSVG-Symbol produzieren, sondern bei Fehlern die der Validator findet, dann ein anderes invalidSVG-Symbol produzieren. Von daher ist das ja schon logisch falsch konzipiert.) Um zurück zum Sourcelistingwunsch zu kommen: Dazu muß man ja lediglich den hier vorhanden Source wieder HIER (auf dem lokalen Server) textual ausgeben, mehr nicht! Nicht ihn erst durch die Welt schicken. Ich bekomme das Gefühl, auch weil Du dich da inhaltlich nicht tiefer rantraust :) , daß diese ganzen Templates nicht konsistent und orthogonal designt worden sind. Das man für 9 Sprachen Texte abgreifbar haben muß, ist da ja wohl das alles geringste Problem. :)

Viele Worte von mir, aber ich denke jetzt habe ich die Problematik endlich auf den Punkt gebracht. Korrigiere mich bitte wenn das anders ist oder Du es auch nur anders siehst. Achim1999 (talk) 09:45, 18 July 2012 (UTC)

Vieles das wünschenswert wäre wird von Wikimedia nicht angeboten, zB die Grösse einer Datei auslesen zu können, oder auf den Quellcode direkt zugreifen zu können. Glücklicherweise wird das vom Validator angeboten, wie ich vor einger Zeit herausfinden konnte. Meines Wissens hat auch noch niemand ein Programm dafür erstellt. Es bleibt also AFAIK nur der Umweg über den Validator, tut mir leid. Ohne diese Option würde der Code erst sichtbar wenn die zuvor herunterzuladende Datei geöffnet wird!

Ich kann mir nicht vorstellen dass etwas toolcodiertes deinen Anforderungen entspräche. Abgesehen von der Unleserlichkeit, den oft tief geschachtelten Transformationskaskaden und all dem sonstigen Müll habe ich noch nie gesehen dass ein circle wirklich verwendet wird - gelegentlich mal ein rect, aber meist verworrene Pfade. Mit klarer Struktur ist da nichts, deshalb die Beschränkung auf HandSVG. Und da will ich mal ganz stark annehmen dass der Erzeuger der Grafik etwas Valides reinstellt, sonst bekommt er eins auf die Finger.

Der Validator kann zwar aufgerufen werden, doch erfolgt keinerlei Rückmeldung über die Valididät. Es ist keine Art von Statuscode vorgesehen, nur die Displayausgabe. Anhand dieser kann dann ValidSVG - oder aber {{InvalidSVG}} - gesetzt werden. Solche Sachen gehen eben nur umständlich, auch wenn es anders besser wäre.

Du kannst gerne Experten befragen die sich besser auskennen, doch fürchte ich dass dir deine Wünsche, so legitim sie auch sind, niemand erfüllen kann. Ich kann dir im engen Rahmen meiner Möglichkeiten helfen, aber nicht dir liefern was du dir vorstellst. -- sarang♥사랑 10:33, 18 July 2012 (UTC)

Danke fuer deine ehrliche und offene Einschaetzung. In Summa heisst das wohl: Man muss/sollte sich damit abfinden, alternativ muss man sich da einarbeiten und alles selbst programmieren, da die die das Wissen haben und koennten (die Wiki-developper die diese Verwaltung des SVGs ja so und nicht anders realisiert haben) dies nicht wuenschen oder meinen das Aufwand/Nutzenverhaeltnis sei zu schlecht. :-(

Zu den Tools und deren Kodierungsqualitaet. Ich vermute Du schildern den Ist-Zustand den du kennst. Ich gebe die Hoffnung aber nicht auf, dass der sich auch aendern kann und nicht zwanghaft so (schlecht) bleiben muss.

Ich frage mich ernsthaft ob es Sinn macht, wenn ich mich da soweit einarbeite einige neue Features fuers SVG-Files zu realiseren -- um ehrlich zu sein: ob es das Wert ist -- ich meine damit, daB die dann geleistet Arbeit nicht umsonst ist, weil andere meinen das blockieren / ignorieren oder gar wieder rueckgaengig machen zu muessen. Rein fachlich traue ich es mir zu -- das waere nicht das Problem, die Template Logik scheint ja nur schlecht lesbar kodiert zu sein, aber schenbar von geringer Komplexitaet (womit auch leider wenig Moeglichkeiten in Hand geben werden).

Zu deiner urspruenglichen Frage, dieses spezielen Textes: Das waere fuer mich dann Kinderkram, sprich nicht interessant und ich haette kein Interesse dran den konkret mitzubestimmen. Sprich alles ist / waere dann dann Bier -- zumindest ich weare in der Beziehung nur noch ein normaler User der ein von Dir angebotenes neues Feature (H=3 oder H=5) nutzt oder eben nicht.

Wer ist denn hier auf WMF noch mindestens so kompetent wie Du (oder sogar kompetenter) in der Beziehung zu/zur SVG-Verwaltung/Moeglichkeiten, damit ich noch eine weitere Einschaetzung der Sachlage einholen koennte? Achim1999 (talk) 10:59, 18 July 2012 (UTC)

Ich sehe mich da nicht als kompetent an, ich mache halt einfach und versuche Dinge zu verbessern. Es gibt das Commons:Help desk, wo gelegentlich was geantwortet wird.

Erwarte nie dass dir für irgendeine Arbeit Anerkennung gezollt oder Dank bezeugt wird.

Das Vorlagenkonzept hat vor allem die Schwäche dass es keinerlei interne Variablen hat, das macht es in etwas komplexeren Vorlagen sehr aufwendig, weil öfter Codingsequenzen wiederholt werden müssen. Ich habe dafür Alternativen entwickelt, die aber in anderer Hinsicht aufwendig sind. sarang♥사랑 12:46, 18 July 2012 (UTC):This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)

User:Achim1999s SEINE Antwortsektion -- (Ein Versuch)

Diese Sektion war eigentlich dafür gedacht Editkonflikte zu vermeiden, daher (Ein Versuch) -- und meine anmaßende Überschrift, daß dies MEINE User:Achim1999s Antwortsektion sei, auf Deiner, User:Sarangs, Talk-Seite ist.  :)

HQSG-Integration in vorhandene Templates

Zitat von Dir: "Und da will ich mal ganz stark annehmen dass der Erzeuger der Grafik etwas Valides reinstellt, sonst bekommt er eins auf die Finger." Tja, dann bekomme ich schon dreimal was auf die Finger! :-) Ich hatte Kode fuer Flaggen in SVG eingestellet (Nationalflaggen fuer NeuZealand, Malawi und noch ein dritter Staat) wo ich in der <DOC-Style Dokumentationszeile ganz oben behaupte, SVG version 1.1 werde genutzt, um dann im nachfolgenden <svg>-statment version="1.0" zu setzen. Hat mir der Validator natuerlich korrekt als Fehler angezeigt. (Sollte wohl besser version="1.1" im <svg> Statement dann sein (oder 1.0 im <DOC>). Eine Mini-Kleinigkeit, aber dies ergibt ein invalid-SVG! Ein anderer Fall (den ich dann selbst spaeter korrigiert habe) war, ich habe von jemand anderem den SVG-Kode verbessert/reduziert/lesbarer gemacht , aber alle seine dann noch noetigen Labels uebernommen. Und er hatte Labelnamen die mit Ziffern anfangen, was auch verboten ist (in version 1.1. und 1.0" also auch invalid SVG ergibt. Der Renderer hier und mein lokaler uebersehen das gnaedigerweise (und vermutlich auch der den der urspreungliche Autor verwendet hatte). So kommen hier sicher auf wikimedia auch noch mehr invalid-SVGs rein und bleiben eventuell dann spaeter sogar mit validSVG versehen (weil eine vorherige Version 'mal valid war) stehen!

Ganz generell: Version kann im ?xml-statement definiert werden, im svg-statement sollte es nicht angeführt sein, das gibt nur Probleme. Dem Renderer (librsvg) ist vieles sehr egal, der verlangt nicht mal das ?xml, sicher überliest er das einfach. Dafür hat eine eine ganze Reihe von bekannten Fehlern. Auch mit <DOC> fängt er nichts an. Deshalb finde ich das es wenig Sinn macht diese SVG-Regeln einzuhalten wenn die Grafiken für Wikimedia bestimmt sind. Sollten sie portiert werden kann man sie erforderlichenfalls immer noch mit diesem Zeugs aufblähen, jedenfalls weiss auch zB FireFox nichts damit anzufangen.

Das Problem der zwischenzeitlich invaliden Versionen werden wir immer wieder haben; auch wenn es dem librsvg egal ist sollten Dateien immer validiert, und ggf korrigiert werden.

Zu letzter Aussage stimme ich Dir völlig zu. Allerdings die Versionsangabe im ?xml-statment ist doch die Version der XML-Syntax und die im <svg>-stament, die version vom svg. Also 2 verschiedene. Ja, das <DOC>-statement hatte ich sogar (an Anlehnung an HTML) selbst reingepackt, da ich dachte dann sei das konform(er) und schadet aber sich nicht. PS: Diese ganze Schilderung sollte Dir nur zeigen, daß deine Annahme abgelegter SVG-Kode ist hier immer valid und deshlab muß das valdSVG-Tokens rechtens sein, falsch ist. :) Achim1999 (talk) 18:36, 18 July 2012 (UTC)

Zu deiner Verbesserung der File:Flag of Malawi.svg

Die relativen Koordinaten in dem einzigen Pfad dort sind sicher eine gute Idee, aber da alle Spaces und Kommatas zu elimineren die syntakisch ueberfluessig sind, nur um unter 1000 Byte Kode zukommen (rate ich mal als Grund), dem kann ich als H=3 Qualitaet nicht zustimmen. :-( Uebrigens werden genaue Dateigroessen noch bis MINDESTENS 1012 Byte bei SVG-Files angezeigt (ich vermute bis 1023 oder bis 1049 Bytes).

Ein Pfad ist nun mal ein eher unanschauliches Element. Bei kurvigen Strukturen wirst du aber nicht darum herumkommen. Und wenn der "d"-string von vielen Kommata gelängt wird wird die Codierung IMHO auch nicht anschaulicher.

Sorry, da behaupte ich genau das Gegenteil. Habe ich in der Category:Structured SVG sogar an diesem/deinem Beispiel erklärt. Achim1999 (talk)

Ich akzeptiere deine hierzu andere Meinung, doch finde ich SVG-Grafiken sollten in erster Linie serverfreundlich sein, und erst dann auch noch möglichst lesbar. 12:46, 18 July 2012 (UTC)

Ups, Du machst hier gerade eine 180°-Wendung. Weiter oben, wo ich Dir auf beipflictete, schriebst Du, lesbarer Kode ist wesentlich wartungsfreudnlicher und nun opfert Du dies der "Serverfreundlichkeit" .

Im konkreten Fall des Pfades frage ich mich allerdings noch, was ist deine Serverfreundlichkeit hier denn genau? Daß Du 5-10% Bytes bei der Darstellung sparst? Achim1999 (talk) 18:42, 18 July 2012 (UTC)

File:SVG example R.svg

Habe mir bei deinem Test.SVG (die 6-streifen-flagge) 'mal erlaubt width & height rauszuloeschen und viewBox zu verwenden. Mal gucken was das (didaktisch) bei Dir bewirkt. ;-) Achim1999 (talk) 11:31, 18 July 2012 (UTC)

Das finde ich gar nicht gut. Damit wird aus der definierten Weite von 30px plötzlich 512px, was ich in diesem Fall nicht wollte. sarang♥사랑 12:46, 18 July 2012 (UTC)

Was soll denn der Sinn von absoluten Weiten- und Höhenangaben des Gesamtbildes (also im äusseren <svg>-statement) sein? Verrate mir das bitte 'mal. Die absolute Größe wird doch IMMER erst im Nachhinein beim Rendern festgelegt. Ich finde es dagegen eine schlechte Angewohnheit eine viewBox (also BoundingBox) wegzulassen -- das wird dann häufig zu Unwissenheit und man weiß dann als Weiternutzer miteinmal nix -- sprich darf dann selbst bei komplzierteren Grafik nachrechnen um den weissen Rahmen drumrum wegzubekommen, wenn man die irgendwo genau einbinden will -- habe ich schon öfters hier gesehen. Es ist ja gut daß wir uns an diesem eigentlich irrelvanten Test-SVG darüber streiten / diskutieren können. :) Achim1999 (talk) 18:53, 18 July 2012 (UTC)

The validation proofed its validity.

Das ist falsches English. "proved" müsste die Vergangenheitsform des Verbes lauten. Aber ich glaube nicht daß Du dies meintest. ;) "its" bezieht sich in dem Satz auf "validation" und das willst Du wohl nicht aussagen und es ist auch falsch. "The validation proved the validity of the code." eventuell. Oder "Its validity was proved by validation." Wobei dann das richtige vorausgehen muß um den korrekten Bezug zu "Its" zu haben. Aber ich denke diese Formulierung ist auch im Englischen schlechter Stil "validity .... by validation". "syntactical correctness" ist Dir wohl zu lang. "proved" ist ein sehr starkes Wort, Ich hätte einfach "was shown" geschrieben. Achim1999 (talk) 18:26, 19 July 2012 (UTC)

"The validator statet its syntactical correctness" besser?

Ja besser. Mir ist nur nicht klar, ob ein Engländer dieses "its" auf den vorausgehenden Satz bezieht oder auf den "validator" selbst. Sprich, ich weiß nicht welches Geschlecht der "validator"im englischen grammatikalisch hat, ob masukulin (dann wäre alles okay) oder neutral (dann wäre die Formulierung falsch). [1] gibt darüber keine Auskunft -- ich fürchte aber fast, das Software/Computerprogramme im englischen immer "es" ist/sind. Achim1999 (talk) 22:33, 19 July 2012 (UTC)

Sammelsurium von Antworten und eingestreuten Erwiderungen von der anderen Seite :-/

Englische Formulierung

Danke für deine Überlegungen. Den Text brauchen wir noch in Deutsch - die anderen Sprachen soll wer andres einpflegen. Ich tendierte zu "The validator checked successfully the syntactical correctness", das mag korrekt sein aber IMO zu umständlich, "The syntax check was successful" genügt auch als Hinweis; weil mir das "was" zu unmittelbar erschien habe ich dann "had been" gewählt.

.

Wenn Du nun auch noch auf den Tempus achten willst, darf ich fragen wieso nicht "has been"? Achim1999 (talk) 14:34, 20 July 2012 (UTC)

Hmm .. in deutsch vielleicht: "Die syntaktische Korrektheit wurde bestaetigt"? oder "ist bestaetigt worden"? ;) "Achim1999 (talk) 15:17, 20 July 2012 (UTC)

.

Damit ist zumindest das böse "proof" ersetzt, und die Suche nach Synonymen (statet, showed, postulatet, declared, finished ...) vermieden. Nach was Perfektem können wir immer noch suchen.

Editkonflikt

Zu anderem: Edit conflict gibt es immer wenn zwei gleichzeitig an einer Seite editieren, da nützt eine neue Sektion nichts. Da müssten wir schon jeder auf des jeweils anderen talk page schreiben.

.

Editkonflikte gibt es nicht, wenn unterschiedliche Subsections betroffen sind! Das war auch der Sinn hier eigene Subsubsektionen fuer Antworten aufzumachen. Okay, es ist deine Talk-Seite und wenn Du das nicht willst, dann eben nicht. Achim1999 (talk) 14:34, 20 July 2012 (UTC)

Sinn der width/height-Angabe

Die width/height-Angabe macht dann etwas aus wenn die Grafik für sich betrachtet wird;

Was soll das denn inhaltlich ueberhaupt bedeuten: "die Grafik für sich betrachtet wird" -- also ohne rendering oder wie?

wenn sie ohne Größenmodifikation eingebunden wird wie ;

Konkret im Fall wird NICHTS eingebunden! :-( Achim1999 (talk)

.

Nun rate ich 'mal. Du wolltest das diese Grafik entsprechend der hier benutzten Fontgroesse passend ist. Dazu hast Du hart die benoetigte Endgroesse der Grafik als width und height angegeben. Also ganz speziell im Prinzip nur hierfuer gerechtfertigte Werte. Okay. Dann ist eine width/height-Angabe sicher noetig und wuenschenswert. Und dass Du die BoundingBox dann so hinkodiert hast, dass sie bei 0,0 links oben liegt und in der Kodierung genau der gewuenschten Pixelgroesse in diesem Fall entspricht ist wohl kaum dem SVG-File anzusehen. Dessen Wiederverwendung wird somit auch massiv eingeschraenkt. :) Ein gut strukturiertes SVG wuerde sicher diese width & height Angabe haben und zusaetzlich noch eine viewBox-Angabe.

Ich glaube kaum dass dann dein schwammiger Begriff von "Serverfreundlichkeit" wesentlich tangiert wuerde. :-) Achim1999 (talk) 15:40, 20 July 2012 (UTC)

.

Nur so hier zum Spass: Alter/deine Byte-minimaler Codierung:

   <?xml version="1.0" encoding="UTF-8"?>
   <svg xmlns="http://www.w3.org/2000/svg" width="21" height="9">
   <path d="m6.5,4 4-4 4,4zm0,1 4,4 4-4z"/>
   </svg>

Meine teure geometrisch offensichtlichere Kodierung :->>

   <?xml version="1.0" encoding="UTF-8"?>
   <svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        width="21" height="9" viewBox="-21 -9 42 18">
   <g id="up">
      <path id="half" d="m 0,-9 v 8 h -8 z"/>
      <use xlink:href="half" transform="scale(-1,1)"/>
   </g>
   <use xlink:href="up" transform="scale(1,-1)"/>
   </svg>

Ich hoffe dass das letztere wirklich das gleiche Symbol/Grafik darstellt. ;) Ich waere schon zufrieden wenn das der Code eines Tools waere. Und ich frage mich ernsthaft, was Du glaubst um welchen Faktor denn die Serverlast hoeher waere (vom Einlesen des SVG-Codes bis zur dargestellten zugehoerigen Grafik auf dem Schirm)! Achim1999 (talk) 16:07, 20 July 2012 (UTC)

.

und vor allem wenn offline damit gearbeitet wird: allzu kleine werden auch durch Zoom-out nicht ausreichend erkennbar, allzugrosse sind trotz Zoom-in nur teilweise sichtbar. So gesehen, sind ungefähr Weiten ≤ 600 bis 800 und Höhen ≤ 400 bis 600 benutzerfreundlich.

.

Wenn sie gerendert wird, IST immer eine width/height Angabe vorhanden -- ist keine angegeben/uebergeben, wird ein Default des aktuellen Renderers genommen -- wie hier bei Wikipedia gesehen. Wenn Du nichts explizites beim Einbinden/Erstellen angibst, bedeutet es eigentlich, dass eine konkrete width/height-Angabe egal ist -- wie es ja auch eigentlich Sinn macht (Du kennst ja nicht die Pixelgroesse die beim Rendern im Medium letztlich vorliegt) . Und ansonsten kannst Du sie ja angeben. Das "Weiten ≤ 600 bis 800 und Höhen ≤ 400 bis 600 benutzerfreundlich" sind, dies ist einfach eine dreiste Behauptung die je nach Anwendung falsch sein kann (haengt wie ich sagte, von der metrischen Pixelaufloesung der entgueltigen Bitmaps ab und davon welche absolute Groesse vom Anwender gewuenscht ist). Also so gesehen voellig witzlose Angabe von width und height im SVG-code. Entweder es ist egal, dann braucht man auch nix, oder der Benutzer (oder Codeersteller) darf/soll es selbst sagen was er bei seiner Anwendung am liebsten hat -- das macht/kann er dann aber eh spaeter (machen). Fuer den allgemeinen Benutzer mitdenken geht nicht! Das haengt ja alles von seiner konkreten Soft- und Hardware ab WAS WIE geht oder nicht. Darueber sollte man sich daher kein Urteil anmassen, da man ihn bzw. seine Umgebung nicht kennst. :) Achim1999 (talk) 14:34, 20 July 2012 (UTC)

"schlechter Code"

Dass du das Beispiel in Structured SVG so als "schlechten Code" abqualifizierst finde ich gar nicht NPOV. So wie ich deine Ansicht gelten lasse, ohne ihr vollumfänglich beizupflichten, solltest du andere Standpunkte akzeptieren können; solange sie nicht definitiv falsch sind.

.

"schlecht" setzt eine Bewertung vorhaus. Und hier bei Strukturiert geht es u.a. um die Lesbarkeit. Diese ist schon gut objektivierbar und in derem Sinne ist dies sicher schlecht -- man koennte sogar drueber diskutieren dies bereits als falsch anzusehen (im Sinne der Philosophie dieser Category!). Ferner sehe ich beim besten Willen nicht was das einsparen der Whitespaces hier fuer einen Vorteil bringt (10% weniger Kodelaenge) der dies auch nur annaehernd aufwiegt (geforderte Lesbarkeit). (NPOV sagt mir als Abkuerzung nichts). Wie Du hoffetnlcih siechst, habve ich versucht dieses "schlecht" in einem objektiven Sinne der intendierten HQSG-Philosophie zu benuzten -- nicht in einem subjektiven. Habe in der Category:Structured SG auch nochmals die Grundphilosophie praezisiert: Eine SVG-Kodierung die die geometrische Struktur des Bildes leicht (mit menschlichem Auge) semantisch erkennbar macht. Achim1999 (talk) 14:34, 20 July 2012 (UTC)

gestrafft

Gestrafft ist nicht gleich schlecht! Ich habe übrigens versucht, das mal in Manually coded SVG einleitend darzustellen. Es sind ganz einfach zwei unterschiedliche (und tw. widersprüchliche) Qualitätskriterien, deren jeweiliges Extrem nicht anzustreben ist. Es ist aber sicher sinnvoll, in lehrreichen Beispielen den Sachverhalt deutlich darzustellen.

Übrigens habe ich für die Bearbeitung spezielle Hilfsmittel, um kompakte d-strings in ihre x/y-tupel zu zerlegen bzw. aus dieser Form maximal zu komprimieren, und auch um absolute in relative Koordinaten zu ändern.

.

Schoen fuer Dich. Bei HQSG geht es aber um die Lesbarkeit des unbearbeiteten SVG-Kodes. Ich erwarte nicht das der der den Code lesen will, bestimmte Tools zur Verfuegugn hat. Sonst haette man XML auch als Binaerformat realisieren koennen -- spart vielmehr Bytes. Achim1999 (talk) 14:34, 20 July 2012 (UTC)

viewBox

Eine ViewBox kann sehr hilfreich sein, eine generelle Erfordernis ist nicht gegeben. Vor allem bei einfachen und einfachsten Grafiken. Da steht wieder Meinung gegen Meinung, und wir können nur die jeweils andere tolerieren. Wo du Schwierigkeiten siehst habe ich deinem Text nicht entnehmen können.

.

ARGH Wir konnen darueber reflektieren und nicht, das Nachdenken einfach einstellen wie in deiner Aussage "wir können nur die jeweils andere tolerieren". :-(

Hmm ich entnehme deiner Aussage leider nicht, wo Du welches Problem siehst. Deshalb habe ich ja auch noch diese zwei real-world Beispiele genannt und nicht kuenstliche, witzlose Beispiele zum Streiten um Prinzipien. Sorry! Eine generelle Notwendigkeit fuer width/height is nicht gegeben! Aber eine viewBox hat eine wesentlich greossere Bedeutung als diese width/height-angabe. Das schient Dir (und vielen anderen) nicht klar zu sein. Eben weil die konkrete absolute Groesse erst noch spaeter beim Rendern festgelegt werden kann. Dagegen muB eine Grafik nicht notwendigerweise immer links bei x=0 und oben bei y=0 anfangen! Argh! Achim1999 (talk) 14:34, 20 July 2012 (UTC)

Blick vorwaerts

Etwas besseres als {{HandSVG}} wirst du so schnell nicht bekommen. Es ist aber natürlich eine einfache Sache, von HandSVG ggf. ganz andere Vorlagen aufrufen zu lassen, wenn das mal interessant wird - zB bei Kategorienuntergliederungen etc. Es spricht nichts dagegen HQSG nun endlich zu ersetzen. -- sarang♥사랑 10:43, 20 July 2012 (UTC)::

.

Tja da sagst Du was. Ich weiss auch/leider mittlerweile wie das HandSVG und validSVG aufgebaut ist und wo diese hart kodierten Texte stehen. Haettest Du dich nicht angeboten dies alles zu vereinfachen (besser gesagt in SimplSVG und HandSVG zu integrieren), haette ich JETZT einfach die HandSVG-vorlage genommen zum neuen HQSG Template kopiert und dort einfach meinen Wunschtext reingesetzt und den den ich nicht sehen will gestrichen. Fertig - Ende, aus! Leider hast Du mir im Nachhinein gesagt, dass Du diesen Aufwand in dem allgemein SimpleSVG- und HandSVG-Template Zusammenfassung nicht treiben willst. Pech fuer mich, dass ich da Kompetenz bei Dir anfaenglich unterstellt hatte wo leider keine ausreichende vorhanden war. Achim1999 (talk) 14:34, 20 July 2012 (UTC)

naming of Category: Structured SVG

"....which present their image with an easily human-readable coding reflecting the obvious geometry of the image". Mit dieser Definition kommen wir meinem intendierten Zweck, IMHO, schon sehr nahe. Zu deutsch "Solche Grafiken sollten so kodiert sein, dass ihr Aussehen / (genauer ihre Geometrie) leicht (mit dem menschlichen Auge) im Quelltext (SVG-code) erkennbar ist". "Strukturierte Kodierung" ist somit hier als Synonym fuer diese Art von Kodierung zu verstehen. Achim1999 (talk) 15:05, 20 July 2012 (UTC)

This section was archived on a request by: sarang♥사랑 15:40, 20 July 2012 (UTC)

Deletion warnings

File:U+2689.svg

File:U+2689.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!

Manslay (talk) 09:02, 17 August 2012 (UTC)

File:U+2688.svg

File:U+2688.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!

Manslay (talk) 09:03, 17 August 2012 (UTC)

File:U+2687.svg

File:U+2687.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!

Manslay (talk) 09:03, 17 August 2012 (UTC)

File:Coat of arms of Joseon Korea.svg

File:Coat of arms of Joseon Korea.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!

FASTILY ^(TALK) 22:06, 9 September 2012 (UTC)

File:Ihwamun.svg

File:Ihwamun.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!

FASTILY ^(TALK) 22:10, 9 September 2012 (UTC)

File:Fluglärm Protest.jpg

File:Fluglärm Protest.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 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) 13:38, 31 October 2012 (UTC)

File:IsraelStamps2009-אג10.jpg

File:IsraelStamps2009-אג10.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 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) 14:06, 31 October 2012 (UTC)

File:Protest against S21 30Okt-11.jpg

File:Protest against S21 30Okt-11.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 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) 14:11, 31 October 2012 (UTC)

File:Protest against S21 30Okt-13.jpg

File:Protest against S21 30Okt-13.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 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) 14:19, 31 October 2012 (UTC)

File:Protestplakat S21 am Bauzaun - 99.jpg

File:Protestplakat S21 am Bauzaun - 99.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 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) 14:21, 31 October 2012 (UTC)

File:AmaranthSeed.jpg

File:AmaranthSeed.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 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) 14:27, 31 October 2012 (UTC)

File source is not properly indicated: File:Holy Condom.jpg

This media was probably deleted.

A file that you have uploaded to Wikimedia Commons, File:Holy Condom.jpg, was missing information about where it comes from or who created it, which is needed to verify its copyright status. The file probably has been deleted. If you've got all required information, request undeletion providing this information and the link to the concerned file ([[:File:Holy Condom.jpg]]). If you created the content yourself, enter {{Own}} as the source. If you did not add a licensing template, you must add one. You may use, for example, {{self|GFDL|cc-by-sa-all}} or {{Cc-zero}} to release certain rights to your work. If someone else created the content, or if it is based on someone else's work, the source should be the address to the web page where you found it, the name and ISBN of the book you scanned it from, or similar. You should also name the author, provide verifiable information to show that the content is in the public domain or has been published under a free license by its author, and add an appropriate template identifying the public domain or licensing status, if you have not already done so. Warning: Wikimedia Commons takes copyright violations very seriously and persistent violators will be blocked from editing. Please add the required information for this and other files you have uploaded before adding more files. If you need assistance, please ask at the help desk. Thank you!

Túrelio (talk) 14:42, 31 October 2012 (UTC)

Source for b/w pope image is missing. --Túrelio (talk) 14:45, 31 October 2012 (UTC)

File:GR221 Guide.jpg

File:GR221 Guide.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 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) 14:45, 31 October 2012 (UTC)

File:Flag of Finland Icon.svg

File:Flag of Finland Icon.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!

Fry1989 ^eh? 23:12, 4 June 2012 (UTC):This section was archived on a request by: sarang♥사랑 05:49, 22 July 2013 (UTC)

File:肀-order.gif

File:肀-order.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!

Michelet-密是力 (talk) 22:05, 10 December 2012 (UTC):This section was archived on a request by: sarang♥사랑 05:49, 22 July 2013 (UTC)

Watchlist register suddenly moves the registers "View"/"Edit"/"View history"

Notiz: habe geantwortet COM:HD#Watchlist register suddenly moves the registers "View"/"Edit"/"View history" Viele Grüße --Saibo (Δ) 17:40, 9 February 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

User talk:Hyacinth#Template:Wikipedia category

What does "Commons has since years the potent template..." mean? Are you an English speaker? Do you mean "Commons has had for years the effective template..." Hyacinth (talk) 01:00, 27 February 2012 (UTC)

Hi Hyacinth - yes, thank you, I was not able to express that so well in English, hopefully it can be understood with some effort and good will. I cordially invite you to correct my expressions everywhere you like when you dedect something like that. -- sarang사랑 06:16, 27 February 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

Arms

Rename requests

Hi. I have completed your rename requests starting with File:204 - zhi3 - embroidery.svg. In the future, please make one request per file, which may reference a common page or permalink with detailed reasons. Thanks.   — Jeff G. ツ 15:17, 20 April 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

File:Flag of Libya (1951).svg

Not sure why you added a French-language template to that page, given that the official language is Arabic, it was formerly an Italian colony (not French), and the main foreign language there now is English... AnonMoos (talk) 15:51, 25 May 2012 (UTC)

You are right, once more. I returned to Anglais. sarang사랑 20:44, 25 May 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

File:Inversion set 16.svg

Hi. Diese Dateien sind schon einigermaßen müllfrei. Wenn es dir Spaß macht kannst du ja noch ein Bisschen aufräumen. Ich werde sicher noch einige dieser Dreiecke benutzen. Wichtiger wäre aber später eine möglicht kleine Datei File:Inversion set 8.svg zu machen. Grüße, Lipedia (talk) 22:16, 5 June 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

Gut, ich schaue es mir mal an. Auf den allerersten Blick: da lässt sich viel machen. Was wird denn da variert, um Inversion set 8 zu bekommen? Noch blicke ich nicht durch, und du brauchst ja eine allgemein verwendbare Lösung. sarang사랑 08:30, 6 June 2012 (UTC)

File:Inversion set 8.svg hat dann diese Form: File:8 choose 2 array.svg
In all diese Dateien wird immer nur ein mit bin2svg erzeugter Pfad eingefügt. Lipedia (talk) 11:50, 6 June 2012 (UTC)

Die Achterversion hat einerseits wesentlich einfachere Strukturen, und dein bin2svg wirst du sicher gut hinbekommen dass es runde Bollen erzeugt.

Andrerseits ist es mit Texten, in diesem Fall Ziffern, so eine Sache in SVG: als Text über fonts ist es unzuverlässig, richtig gut wird es nur bei bildlicher Darstellung. Und die treibt die Dateigröße jeder Grafik in schwindelnde Höhen. Natürlich lässt sich auch da einiges vereinfachen, die Inkscape-Realisierung muss nicht so hingenommen werden (zB mit 13 Nachkommastellen in den Koordinaten…). Jedenfalls kannst du mit meiner Assistenz rechnen. sarang사랑 07:08, 7 June 2012 (UTC)

Ich verstehe es nun so, dass die "Achterversion" die Strukturen wie Inversion set 16 haben soll, jedoch um eine 2er-Potenz geringer; also 28 Quadrate statt 120. Das lässt sich gut aus dem 16er-Set reduzieren.-- sarang사랑 09:30, 7 June 2012 (UTC)

File:Ralik-Inseln.svg

If all you're doing is removing the metadata, then that's not much of a "simplification", and I wonder whether it's really worth it to upload a new file version to just do that alone... AnonMoos (talk) 17:31, 10 August 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

File:Lojban-Logo.svg

Just noticed that your 06:49, 24 February 2012 version seems to have somewhat different geometry from the 21:36, 13 December 2005 version... AnonMoos (talk) 18:00, 13 August 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

File:Ellipses-Symbola.svg

Thank you for optimizing the file File:Ellipses-Symbola.svg which I had uploaded to Wikimedia Commons. However, the file now is different: the second and fourth ellipse now have a white filling, instead of being hollow. Please correct this. Thank you. -- Karl432 (talk) 14:08, 24 September 2012 (UTC)

Sorry! Thanx for telling me. Filling is now transparent. sarang♥사랑 14:28, 24 September 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)

SVG display strangeness

Would you know why File:Fentes_Young.svg doesn't display? Thanks. AnonMoos (talk) 09:04, 29 October 2012 (UTC)

Librsvg behaves really strange. The validator check tells about several errors, but after I have fixed most of them there remains an error with the radius of the radial gradient. Till now I coudn't find out. It doesn't even work properly offline, i.e. with FF instead of the librsvg. I've tried a lot — unsuccessful, sorry sarang♥사랑 13:25, 29 October 2012 (UTC)

OK, but the file works in Adobe SVG plugin, and in the version of Inkscape I have on my system, and displays with a few semi-minor glitches on Firefox on my system, so I thought the problem would be mainly with Librsvg... AnonMoos (talk) 18:14, 30 October 2012 (UTC)

With IE or FF it shows only a small upper part of each of the three "radiation" triangles, while each should be almost half of the image height. Funny is a long time delay, the three triangles are not shown immediately. sarang♥사랑 06:06, 31 October 2012 (UTC)

---

Think I fixed it, but as much through guesswork as anything. By the way, the 380px-wide thumbnail is 388kb in size! AnonMoos (talk) 19:20, 1 November 2012 (UTC)

Good work! I've checked it, the SVG errors are still present. It would be easy to fix them also. I've tagged the image description (with the access to the validator output of its source, that any SVG drawing should bear), I leave it to you to change it after your fixing however you like. sarang♥사랑 06:36, 2 November 2012 (UTC)

Not entirely sure what the point of the tagging is, since as far as I can tell, zillions of Inkscape-generated files would have the same "errors". It seems to be complaining as much that Sodipodi and Inkscape haven't defined SGML DTDs, as about errors in this particular file. I didn't look at the validator output on the file before now, but if I had, I never would have assumed that fixing the validator "errors" would fix the file... AnonMoos (talk) 08:33, 2 November 2012 (UTC)

Ok, you may remove the tag. sarang♥사랑 08:36, 2 November 2012 (UTC)

I took the opportunity to remove some Inkscape cruft which had no impact whatsoever on Commons rendering to PNG -- but I didn't feel as though I was fixing "errors" as I did so. AnonMoos (talk) 02:03, 3 November 2012 (UTC):This section was archived on a request by: sarang♥사랑 11:12, 18 September 2013 (UTC)