Letzter Kommentar: vor 10 Jahren10 Kommentare3 Personen sind an der Diskussion beteiligt
Ich möchte auf ein paar Gedanken hinweisen, die mir bei dieser Vorlage gekommen sind.
Neben den beiden Grafiken, die du markiert hast, gibt es viele weitere Grafiken für das SVG-Buch. Angesichts der Arbeitsweise von Doktorchen nehme ich an, dass alle diese Grafiken valid sind (mit Ausnahme von solchen, die er zur Demonstration als ungültig belassen hat). Wer will diese Dateien prüfen und kennzeichnen?
Wenn die Vorlage nur für Dateien des SVG-Buches vorgesehen ist, ist sie nach unseren Regeln als Kategorie:Bucheigene Vorlage zu deklarieren. Dazu muss ein Name wie "SVG/ Vorlage:Valid" gewählt werden und die Kategorie:Bucheigene Vorlage eingetragen werden.
Wenn die Vorlage auch für andere lokal gespeicherte Dateien verwendet wird, gilt sie allgemein als WB-Vorlage und muss in eine passende Kategorie:Vorlage einsortiert werden.
Bitte beachte, dass bei de-WB alle Vorlagen kategorisiert werden, siehe die Hilfe. Außerdem empfehlen wir die Vorlage:Dokumentation zur Beschreibung einer Vorlage.
Danke für deine hilfreichen Hinweise. Ich muss gestehen dass ich mit den Gepflogenheiten bei WB nicht so vertraut bin; die Vorlage war eher ein Schnellschuss, sie sollte es (nicht nur mir) ermöglichen den SVG-Quellcode zu sehen (oder auch zu kopieren) ohne erst die Datei downloaden zu müssen.
Um den Code zu sehen ist es auch ausreichend die Vorlage temporär in eine Dateibeschreibung zu editieren, ohne die Änderung abzuspeichern. Als Hilfsmittel für diesen Zweck würde ich die Vorlage gerne behalten.
Natürlich sollten die Mängel geheilt werden.
Sie ist nicht nur für das SVG-Buch, was das Ändern des Namen wohl erübrigt.
Eine angemessene Dokumentation kann ich noch anfügen, und
Die Doku ist ja nicht nur nützlich, sondern wesentlich. Woher sollte man wissen, dass da ein "Validator" enthalten ist?! (Name und Kategorie sind wohl in Ordnung.)
Allerdings verwirrt mich, dass eine Datei als valid bezeichnet wird, während das erst geprüft werden soll/kann. Nach dem Anklicken wird der "Validator" aufgerufen, aber dann wird nach der URL gefragt. Als ich sie (am Beispiel von Datei:SVGpathM03.svg) eingetragen und Check drückte, wurden mehrere Fehler, aber kein SVG-Quelltext angezeigt. Offensichtlich wurde nicht die Datei selbst, sondern die Wiki-Seite geprüft.
Könnte es sein, dass die Beschreibung noch ergänzt werden sollte? Oder passt das besser in das SVG-Buch? (Achtung: Doktorchen nicht übergehen!) -- Jürgen11:18, 1. Feb. 2014 (CET)Beantworten
Ja, das mag etwas verwirrend sein. Es ist Sache des eintragenden Benutzers, entweder ValidSVG oder InvalidSVG einzutragen - nach dem Eintrag von ValidSVG kann man ja vor dem Abspeichern prüfen, ob es stimmt. In wikibooks gibt es InvalidSVG nicht, meinst du wir benötigen es? Wie gesagt, ich sehe den Hauptvorteil im temporären Eintrag, der den Artikel nicht ändert.
Deine beschriebene Irritation rührt davon, dass du wohl den linken Link (W3C) geklickt hast, statt den rechten (valid). Am besten ist es sicher, wenn ich den redundanten "W3C"-Link entferne, um Benutzer nicht in die Irre zu jagen. Und in der Doku kann ich das deutlicher formulieren. Wir werden das schon noch richtig hinbekommen! Gruss sarang♥사랑11:43, 1. Feb. 2014 (CET)Beantworten
Wissentlich habe ich zumindest keine fehlerhaften SVG-Dokumente im Buch verwurstet, wenn welche auftauchen, gucke ich mir das am besten selber an und behebe es - das übt ja auch - bei ein paar Dateien scheint allerdings irgendwas mit der Kodierung schiefgelaufen zu sein - hab jetzt aber nicht nachgesehen, ob das schon bei meinen originalen Dateien so ist ;o) Bei tiny 1.1 haben die beim Validator irgendwann mal eine dtd rausgenommen, weil sie es wohl nicht ertragen konnten, daß es zwei davon mit gleichem Inhalt gibt, das darf man beim W3C-Validator nicht so eng sehen ;o) Funktioniert das auch noch, wenn kein doctype drinsteht? Das gilt ja schon einmal für alle tiny 1.2 und dann in Zukunft auch für SVG 2. Als ich es gebraucht hätte, konnte der W3C-Validator jedenfalls tiny 1.2 nicht testen, weil immer ohne doctype.
Wozu braucht man den Knopf also wirklich? Wer sich da unsicher ist, kann es bei 1.1 doch vor dem Hochladen durchtesten. Allerdings findet der Validator ohnehin nicht alle Fehler, zeigt gelegentlich aber auch was als fehlerhaft an, was richtig ist - muß man also so oder so kritisch betrachten, was man sich zusammengebastelt hat... Sonst als Ergänzung zu validSVG, invalidSVG - warum nicht auch stupidSVG, braindeadSVG oder inefficientSVG, davon gibt es auf commons doch haufenweise - oder auch nondtdSVG, für alles was richtig ist, dem Validator aber anhand einer DTD nicht beizubringen ist? ;o)
Hallo Doktor Olaf, danke für deine Nachricht.
Schon vor einiger Zeit bin ich auf deine hilfreichen Ausführungen zu SVG und auf deine interessanten Grafiken aufmerksam geworden; obgleich ich selten in den WB stöbere.
Ich sehe es so dass wir beide versuchen Techniken zur SVG-Erstellung weiterzugeben, und den Standard in den Wp zu heben; jeder auf seine Weise, sehr unterschiedlich.
Während du dich eher von der wissenschaftlichen Seite näherst und mit Kenntnisreichtum und manchmal sogar Akribie grossartige Grafiken produzierst, und dir Mühe gibst auch anderen den Zugang dazu zu weisen, beschränke ich mich ganz gezielt auf einfache und einfachste Grafiken, für die eigentlich nur die manuelle Erstellung sinnvoll scheint.
ein Beispiel
Mittlerweile gibt es in den Commons viele hundert SVG-Grafiken, die von mir oder anderen simplifiziert worden sind, und um Interessierten das Auffinden zu erleichtern habe ich sie in eine Menge von Kategorien übersichtlich eingeordnet. Wenn du reinsiehst, wirst du alles finden können.
Gelegentlich erregt es leider Unwillen, wenn ich eine stolze Adobe-Grafik von hunderten Kilobyte auf wenige hundert Byte vereinfache. So was ganz einfaches ist zB dieses Bild.
Wie ich oben Jürgen oben erklärt habe, liegt es mir fern etwas über die Qualität deiner Grafiken auszusagen, oder gar was dran rumzumeckern. Ich wollte mir den Quellcode interessanter Bilder auf einfache Weise ansehen können, und da erschien mir diese verfügbare Vorlage geeignet.
Wie unser librsvg, hat auch der Validator einige Macken. In unserer (Wp etc.) Umgebung erscheinen DTD entbehrlich, der librsvg kommt sogar ohne ?xml aus - aber solche unvollständigen Codings würden anderswo Probleme bekommen. Ich teste meine Entwicklungen offline mit FF, der zeigt es gelegentlich anders als der librsvg mit seinen wohlbekannten bugs.
Deiner Anregung zu stupid & inefficient bin ich ja fast schon zuvorgekommen, wenn ich es auch etwas milder formulierte… wie gesagt, ich tobe mich da vor allem in den Commons aus.
Übrigens, Olaf, weil ich dich gerade dran habe: mit welchem Browser können denn die Animationen gesehen werden? Ich verwende FF, aber auch IE zeigt sie nicht. Gruss sarang♥사랑14:26, 2. Feb. 2014 (CET)Beantworten
Ja, bei ein oder zwei SVGs, die auf commons liegen und auch im SVG-Buch verwendet werden, habe ich mich selbst mal bemüht, die zu korrigieren und überflüssigen Kram rauszupuhlen, ist letztlich eine zwar ehrenvolle, aber doch nervige Aufgabe, hinter den eigentlichen Autoren hinterherzuräumen ;o)
Es gibt da allerdings nicht nur SVGs, die viel zu groß für ihren Inhalt sind, aufgrund fehlender title und desc sind die meisten auch hinsichtlich einer Textalternative einfach nur belanglos oder bedeutungslos - wobei es bei commons zugegebenermaßen ein Sprachproblem gibt, für welches SVG nicht wirklich eine Lösung hat - Diskussion in der W3C-SVG-mailing-Liste hat da leider auch keinen Fortschritt gebracht.
Bei Werken, die ich habe von Inkscape oder Potrace erstellen lassen, verwende ich meist ein eigenes Skript und Scour, um die SVGs von vektorisierten Pixelgraphiken etwa zu abstrahieren oder in der der Größe massiv zu verkleinern, teils um einen Faktor 10 oder gar 100. Zumindest meine Skripte runden Pfadangaben aber recht drastisch, so daß das Ergebnis nicht mehr exakt dasselbe ist, für den gewünschten Zweck aber eine äquivalente Präsentation ergibt - das basiert auf der Idee, daß man Koordinaten in Pfaden meist nicht auf 10 Stellen angeben muß, sondern bei geeigneter Skalierung mit maximal drei- oder vierziffrigen ganzen Zahlen hinkommt, was scour dann ohne Informationsverlust auch noch in relative Pfadkommandos umwandelt. Zum Beispiel erstelle ich damit gerade einige Bücher von Wilhelm Busch in Vektorgraphik als EPUB, etwa die fromme Helene nur 3.6 MB (mit 187 Bildern).
Ich habe es heute übrigens mal wieder mit dem W3C-Validator ohne DTD versucht, Test mit einer Datei in der Variante SVG tiny 1.2 - das Teil nimmt dann einen experimentellen Validator, welcher die vorhandenen Versions- und Profilangaben ignoriert und dann nur falsche Fehlermeldungen liefert ;o) Ich glaube, das ist das gleiche Teil wie für HTML5 ;o) Also: Augen auf beim Validieren ;o) Obwohl das Teil im Schnitt oft sehr nützlich ist, habe ich da schon einigen Blödsinn gesehen, den das Ding verzapft ;o)
Hinsichtlich der Animationen - am besten wird immer noch Opera funktionieren, gemäß der von mir erstellten, jedermann zugänglichen Test-Suite insbesondere die Version 10, 9-12 sollte auch in Ordnung sein. Nachdem sich Opera dann zumindest für windows vom eigenen Presto verabschiedet hat und auch WebKit/Blink verwendet, wird man von neueren Versionen nicht mehr so viel erwarten können, obwohl WebKit-basierte Programme auch Animation interpretieren, wie auch Geckos wie Firefox, nur eben nicht ganz so gut wie Opera. Batik/Squiggle ist auch noch eine Möglichkeit und auch noch das Adobe-Plugin, sofern man es noch auf einem Darstellungsprogramm zum Laufen bekommt. Die Auswahl ist also groß, zumindest wenn man bei den Animationen 'den Ball flach hält'. Das SVG-Buch hat eher Beispiele für alles, von daher gibt es da auch Beispiele, die aufgrund von Fehlern und Lücken in diesen Programmen gar nicht funktionieren oder nur in einem, etwa Opera 9-12 oder so. Aufgrund fundamentaler Fehler wird librsvg wohl bei vielen Beispielen aus dem SVG-Buch falsche Präsentationen liefern, auch ohne Animation, also ist die Bibliothek wohl noch nicht wirklich alltagstauglich, ich meine, beim W3C wurde zur Erstellung von Pixelgraphik-Vergleichsbildern eher Batik verwendet, aber auch da mußten einige Vergleichsbilder der Test-Suite per 'screen-shot' von der Ausgabe von Opera oder ähnlichen Programmen gewonnen werden. Doktorchen15:29, 2. Feb. 2014 (CET)Beantworten
Danke, ich habe mir nun Opera runtergeladen und werde mal sehen, was ich damit sehe. Und ob ich da weiter eindringen werde.
BTW: Wenn du deine Grafiken zum SVG-Buch in den Commons hinterlegt hättest wären sie einem weit grösseren Kreis zugänglich - IMHO sind sie auf der WB-Insel nicht so leicht zu finden. Auf Commons wären dann zahlreiche Kategorisierungen denkbar, zB (angedeutungsweise!) "Hoffmannbilder" oder "Doktorchenbilder", "Grafiken für Wikibooks-SVG", "SVG-Beispiele für …", "SVG-Animationen" oder was auch immer sonst hilfreich wäre zum Auffinden. Auf den WB fristen sie ein recht heimliches Dasein.
Ich habe aber den Eindruck, dass die Commons nicht so sehr dein Ding sind und du lieber exclusiv die WB pflegst.
Die Ansichten, was in den SVG-Code gehört, differerien beträchtlich, da lässt sich kein Konsens hestellen. Ich neige zur Minimalistik, d.h. was im Zielsystem –hier Wp mit dem librsvg– nicht benötigt wird lasse ich weg. Auch desc und title, alle Anmerkungen setze ich in die Dateibeschreibung oder auch, wenn es umfangreicher ist, in die Diskussionseite der Datei (eine ganze Menge steht in Commons:Category:Simplified SVG discussions). Nicht jeder SVG-Code ist fliessend lesbar, aber vollends unverständlich wird der Outputwust mancher tools mit endlosen sinnentleerten Definitionen (stroke:none;stroke-width:1.0000000000000000;stroke-dasharray:none;stroke-dashoffset: usw. usw.) und tief geschachtelten Transformationen. Da bemühe ich mich, es einfach und schon damit lesbarer zu halten. Aber ich akzeptiere alle anderen Ansichten, solange sie nicht mir aufgezwungen werden.
Wenn jemand so eine nackte Datei übertrüge, wäre die ohne inhärente Beschreibungen – das nehme ich in Kauf; auch, dass meine abgemagerte Version in anderen Zielsystemen nicht zurechtkäme. Wenn ich eine vorhandene Grafik vereinfache, belasse ich hingegen copyrights und descriptions. Zum Umwandeln in relative Pfadkoordinaten habe ich mir ein einfaches Werzeug gebastelt, damit kann ich auch beliebig runden (ich rechne zuerst exakt um, dann das Relative runde ich; Bézier-Zwischenpunkte kann ich ggf. ohne Gesamt-Einbussen etwas stärker runden). Aus reinem fachlichen Interesse hätte ich gerne gesehen, wo du in den Commons gepuhlt hast, doch konnte ich da nichts finden. Ach ja, noch ein schönes Neues Jahr! sarang♥사랑17:19, 2. Feb. 2014 (CET)Beantworten
Das habe ich primär gemacht, weil ich der Meinung war, daß wenn das schon ins SVG-Buch eingebunden wird, daß es dann zumindest richtig sein sollte: Druckversion Wenn die anderen Gnome-Bilder auch so sind, gibt es da sicher reichlich zu tun ;o)
Laut der Empfehlung zu SVG (alle Versionen) gehört wenigstens ein Element title (mit sinnvollem Inhalt) in die Datei, wenn diese nicht rein dekorativ ist - umgekehrt kann man aus dem Fehlen des Titels eigentlich schließen, daß die Datei praktisch keinen informativen Inhalt hat - wobei ich daran zweifle, daß alle Autoren dies denken, die keinen Titel verwenden ;o)
Wenn man Dateien so auf die freie Wildbahn entläßt, können natürlich auch andere Metainformationen sehr nützlich sein, etwa zur Lizenz und zum Autor etc. Wenn das direkt in der Datei steht, kann das auch nicht verloren gehen, wenn die Datei unverändert in anderem Zusammenhang verwendet wird. Daher habe ich entsprechende Metainformationen eingefügt, wenn die von mir erstellte Datei nicht als gemeinfrei gekennzeichnet ist - gibt dann natürlich auch wieder faszinierende Ergebnisse mit dem Validator, den es überfordert, wenn da plötzlich Elemente aus anderen Namensräumen auftauchen (oder man auch nur für XLink ein anderes Präfix definiert als gemeinhin üblich).
Ansonsten habe ich die zum SVG-Buch gehörigen Bilder hier abgelegt, weil sie primär für das SVG-Buch erstellt wurden. Da librsvg zudem viele davon falsch präsentiert, möchte ich jetzt nicht, daß da jemand dran herumbastelt, wenn er die Bilder auf commons für was anderes verwenden will, dann kann ich hier wieder anfangen, das Bild in der Originalvariante einzustellen.
TribarEin SVG aus dem Buch wurde mal von einem Roboter nach commons kopiert, wird dort aber auch kaum genutzt - ein Tribar nach Penrose mit Farbverlauf und Schattenwurf. Schon der Name der Datei läßt erkennen, daß die Datei zu einem bestimmten Zweck im Kontext des Buches hochgeladen wurde, um etwas zur Zeichenreihenfolge zu erläutern.
Ein anderes wird auch kaum genutzt: Animierte Karte
Vor ungewollten Zerstörungen sind deine Beispiele sicherlich hier besser geschützt, als irgendwo in den Commons. Obwohl es da durchaus Möglichkeiten gibt, Dateien vor gut- oder böswilligen Änderungen zu bewahren.
OttomanEmpire hatte ich bereits entdeckt, und war sehr angetan von den mir bisher (mein Zielgebiet ist das primtiv-einfache) unbekannten Möglichkeiten. Auch Postscript hatte ich schon kurz gesehen; diese „Nuvola SVG apps“ liegen bereits ausserhalb des Bereiches, auf den ich mich i.a. beschränke.
Die Gnomes haben es sehr in sich, gelegentlich hat sich da schon jemand erbarmt, zB bei und Ballast abgeworfen.
Das Tribar, und die anderen Zeichenreihenfolgen werde ich mir in Ruhe ansehen, und kann bestimmt viel davon lernen. Solche Grafiken scheinen auch ein Lieblingsgebiet von Anonmoos zu sein.
Ich werde mich mit all dem in nächster Zeit auseinandersetzen, und mir ggf. erlauben dich auf deiner Disku anzusprechen, um deine Kenntnisse anzuzapfen. Und ich sehe es ja sehr schnell wenn was in meine WB-Disku eingetragen wird. MFG sarang♥사랑19:28, 2. Feb. 2014 (CET)Beantworten
Neues Jahr! sarang♥사랑 17:19, 2. Feb. 2014 (CET)
und Ballast abgeworfen.