Diskussion:Scalable Vector Graphics/Archiv/1

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Scalable Vector Graphics/Archiv/1#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Scalable_Vector_Graphics/Archiv/1#Thema_1

- 2004 -

ECMAScript versus JavaScript

Wegen EcmaScript vs JavaScript: EcmaScript ist insofern der offizielle Name, als dass die Sprache unter diesem Namen standardisiert wurde (und auch im SVG-Standard explizit erwähnt wird). Ich würde trotzdem lieber JavaScript da stehen sehen, weil das die Lesbarkeit deutlich erhöht - ein Leser ohne Vorkenntnisse kennt eventuell Javascript, aber kaum Ecmascript oder gar Tcl. Noch lieber wäre mir, keins von beiden zu erwähnen :). Meinungen dazu? dbh 13:05, 18. Mär 2004 (CET)

Derjenige der weder ECMAScript noch TCL kennt kann doch einfach die Links anklicken und die entsprechenden Artikel lesen. Sollen die Leute nicht was dazu lernen dürfen? ;-) 195.243.149.235 13:19, 18. Mär 2004 (CET)

Ich glaube auch, dass ECMA korrekter und daher enzyklopädisch angemessener ist :) TRauMa 22:33, 24. Mär 2004 (CET)

Ich bin mit der momentanen Version schon zufrieden, wollte aber anmerken, dass die Gleichung »JavaScript == ECMAScript« so nicht stimmt. ECMAScript ist ein klar definierter Standard einer Skriptsprache (in bisher 3, bald 4 Versionen), JavaScript ist ein Warenzeichen (von Sun), das nicht nur zur Bezeichnung verschiedener, teils inkompatibler Implementierungen einer Skriptsprache, sondern auch des damit assoziierten HTML-DOM verwendet wird.

JavaScript 1.1 und 1.2 waren Grundlagen von ECMAScript 3, das aber eine Mischung daraus mit JScript und eigenen Ideen ist. JavaScript 1.3 und später hat wiederum ECMAScript implementiert, aber um eigene Sprachelemente erweitert (etwa ist der seit Langem gültige JavaScript-Code const obj= #1= { p: #1#, v: 7, get value () { return this.p.v }, set value ( v ) { return this.p.v= v } }; ++obj.value; in SVG im Allgemeinen nicht verfügbar). Neuerdings wird die JavaScript-Syntax wieder grob erweitert, wobei sicher nicht alles davon in das nächste ECMAScript fließt.

ECMAScript bezieht sich nur im Vorwort auf JavaScript: »This ECMA Standard is based on several originating technologies, the most well known being JavaScript (Netscape) and JScript (Microsoft)«, SVG erwähnt JavaScript gar nicht, und benutzt sogar den (unregistrierten) Mediatype text/ecmascript. --84.150.149.104 22:15, 26. Okt. 2006 (CEST)

OK, allerdings fand ich das schlichte Ersetzen jedes JavaScripts durch ECMAScript erschreckend, denn sehr vielen Leuten sagt letzter Begriff nichts, erster jedoch schon. (Lediglich als nachträgliche Begründung dieses Edits).

Ehrlich gesagt sind deine zwei Absätze recht informativ, vielleicht könnte man die beim Teil "Scripting" irgendwie einbauen? ;-)

Grüße, --Benji 00:15, 28. Okt. 2006 (CEST)

Hier im Artikel wär das deplatziert, das gehört nach JavaScript (wo das meiste im Prinzip schon drinsteht). Ich hab aber den Klammerzusatz noch etwas präzisiert. --84.150.135.131 18:01, 28. Okt. 2006 (CEST)

schrifttypen

ich vermisse ein bischen den hinweis, dass man bei svg auch mit css arbeiten und so z.b. schriftypen (.cef) einbinden kann. der vorteil ist, das man, anders als bei html, beliebige schriftarten (vorzugsweise freie fonts ;-)) verwenden kann und dabei den text (beliebig positioniert) nicht in vektoren oder pixel umwandeln muss, sondern - suchmaschienfreundlich und barrierefei - als text belassen kann.... --Lucky strike 12:58, 13. Nov 2004 (CET)

Erledigt. Reicht das, oder noch ausführlicher? luettmatten 15:26, 2. Jul. 2008 (CEST)

- 2005 -

SVG in Wikipedia

zur möglichen Nutzung läuft unter commons:Commons:Village_pump#Formats_on_commons eine Diskussion. Kolossos 21:26, 24. Jun 2005 (CEST)

Laut commons:SVG image support werden seit Anfang September SVG-Grafiken serverseitig gerendert. Clientseitiges Rendern in einem modernem Browser geht AFAIK nocht nicht, siehe http://bugzilla.wikipedia.org/show_bug.cgi?id=3593 --Gruß, Helge 02:45, 4. Okt 2005 (CEST)

Die Commons Seite scheint es nicht mehr zu geben, und Commons:Dateitypen ist veraltet. --Gruß, Helge 22:18, 17. Okt 2005 (CEST)

Mitlerweile beherrschen drei moderne Browser (Firefox 3, Safari 3 und Opera 9.5) die einwandfreie Darstellung der in Wikipedia verwendeten SVG-Grafiken. Ich glaube, dass dieser Punkt nach drei Jahren von der Diksussions entfernt werden kann. luettmatten 15:30, 2. Jul. 2008 (CEST)

Varianten

Ich weiß nicht ob diese Sharp-handy Variante wirklich platzsparender als ein mit GZIP behandelte SVG-Datei ist. Gzip ist ein OpenSource-Komprimierungsprogramm. Gzip erreicht ca. 95% Kompression und die Datei (meistens mit der Endung .svgz) ist ohne Entpackprogram problemlos in jedem mir bekannten Browser lauffähig. Ich finde das sollte erwähnt werden da die Dateigröße ansonsten ein großer Nachhteil gegenüber Flash darstellt.

Kann diese Sharp-Variante also vielleicht geöscht werden oder hat was hat das noch mit dem Standard zu tuen? Kolossos 00:42, 23. Mär 2005 (CET)

Übersicht SVG-Unterstützung in Browsern

Mir scheint, als wären die Angaben in der Tabelle etwas seltsam. Unter Linux hat der Adobe Viewer eigentlich genau die selben Eigenschaften wie unter Linux (über Instabilitäten kann ich nicht urteilen, da bei meinen Tests weder die Windows noch die Linux Variante abgestürzt sind). Auch im Konqueror kann man mit KSVG (also native) Scripting benutzen. Dies scheint sogar besser zu funktionieren, als mit dem Firefox unter Windows. Nur das Scripting von außerhalb und Einbinden über namespaces hat bei mir nicht funktioniert. Dies soll aber mit KSVG2 funktionieren (habe da aber keine Erfahrung gemacht).

Dafür scheint Opera keine Scripts zu interpretieren type="application/x-javascript"

Sind halt meine Erfahrungen in den verschiedenen Browsern. --136.199.8.128 17:32, 10. Jul 2005 (CEST)

Bei mir klappt SVG in MozillaFF ganz wunderbar, ich habs unter Gentoo mit USE="mozsvg" kompiliert.

Mandriva Linux enthält Firefox und Mozilla mit angeschalteter SVG-Unterstützung auch schon seit vielen Versionen. --Gruß, Helge 02:45, 4. Okt 2005 (CEST)

Mac OS X und deren Browser ist mitlerweile vollständig in der Tabelle enthalten - habe den entsprechenden Absatz hier auf der Diskussionsseite entfernt. Was allerdings überall fehlt ist die neuste Variante des Firefox (FF3). Der RC1 steht noch drin aber ich denke seit dem wird sich auch einiges gebessert haben. Wenn jemand darüber genauere Informationen hat, dann bitte diese in der Tabelle vervollständigen. luettmatten 15:37, 2. Jul. 2008 (CEST)

Seltsam -- (sicherlich nicht nur) ich habe bisher noch nie bemerkt, daß z.B. das Mozilla-Team mit dem Firefox Windows bevorzugt, danach Linux und irgendwann viel später irgend welche andere Systeme bedient.

"Programme, die SVG unterstützen"

In der Liste tauchen einige Sachen auf, die als Editor schon oben stehen - wo ist da der Sinn? Ich habe es mal etwas abgeändert. Und gibt es einen Unterschied zwischen Adobe Illustrator CS und 9/11? Oder ist das auch nur doppelt gelistet? --Liquidat ^Diskussion 13:39, 20. Jul 2005 (CEST)

Du hast vollkommen Recht, die Verdoppelung ist unnütz, ich hab sie daher gleich weggeräumt, wie einige andere auch. Viele Grüße, --Volker E. 15:17, 20. Jul 2005 (CEST)

Es fehlt eine Liste von wichtigen Programmen wie den Office-Paketen bzgl. der SVG-Unterstützung. Bei dieser noch zu erstellenden Liste sowie auch bei den Browsern sollte Angegeben sein welcher SVG-Standard (1.0, 1.2 etc.) unterstütz wird.

ich habe hier Freehand 11 und kann svg weder importieren noch exportieren. mach ich was falsch oder ist die info im artikel falsch? Benedikt.Seidl 19:07, 10. Nov. 2007 (CET)

Tabelle

Ich hab Opera/Windows mal auf teilweise geändert, weil z.B. tspan bei mir im aktuellen Opera (8.50) garnicht funktionierte. Bitte auf Überprüfung mit anderen Browsern/OS. tspan ist z.B. nötig, um Text vertikal mittig zu positionieren, warum auch immer man dazu unbedingt tspan braucht... Aber das is ein anderes Thema. -- MasterG 23:31, 4. Okt 2005 (CEST)

Gibt es einen Test, etwas Verbindliches für alle auf dem die Tabelle aufbaut? Wenn man die Browser vergleicht braucht man ja gleiche voraussetzungen...

Auch wird nirgends erklärt was eine Wallclock ist. Ich hab keine Ahnung... - Metoc ☺ 17:15, 28. Mär 2006 (CEST)

Beispiele von Maik B.

Hallo Maik B.!

Deine SVG-Beispiele sind prima. Noch schöner wären sie, wenn Du die SVG-Dateien selbst auf Commons laden würdest anstelle der PNG-Abzüge. Würdest Du das tun, oder willst Du die SVGs selbst nicht unter die GFD-Lizenz stellen? Danke -- Dr. Schorsch*Schwätzle? 16:23, 6. Dez 2005 (CET)

Super wär auch, wenn der Kernpunkt des Beispiels etwas primärer wäre. Bei den aktuellen Grafiken ist über 50% der Fläche lediglich Rahmen bzw. Layout. Dadurch ist z. B. bei der Grafik zu dem Turbulence-Filter der visuelle Effekt nahezu gar nicht zu erkennen. Beispiele zu Animationen machen zur Zeit (noch) keinen Sinn, da Sie – wie ich vermute – mittels Batik als statische PNG-Grafiken vorgerendert werden. Gruß, norro 17:15, 6. Dez 2005 (CET)

Hallo, ja mit Batik ist das so ne Sache. Er rendert mit zwar eine recht passable Rastergrafik, aber eben nur passabel. Beim rendern der Datei Turbulence, sind nicht alle Filter übernommen worden. Das Ergebnis war also nur halbrichtig. Dasselbe ist bei der Pfadanimation der Fall. Da einige Sachen transformiert sind und mit CSS gearbeitet wurde, werden diese ebenfalls nicht korrekt gerendert. Die Originaldateien, also SVG, könnte ich schon im Layout abspecken, jedoch würde das noch etwas Zeit in Anspruch nehmen. Ich hoffe ihr könnt euch noch gedulden. Bis dahin existiert ja ein Link auf meine Homepage, wo die Datein im Original angeschaut werden können. grüße Benutzer:Maik B.

Hallo,

laut commons:SVG wird momentan rsvg zum Rendern der SVGs zu PNGs verwendet, nicht Batik. Aber ich denke, auch der könnte die Sachen nicht richtig darstellen.

Die SVG-Beispiele finde ich an sich auch ganz klasse, nur grenzen sie schon fast an ein Tutorial und sind stilistisch auch so geschrieben. Ich denke, sie sollten sehr auf das wesentliche begrenzt werden, stattdessen lieber passende Links auf deine Tutorial-Webseiten oder ähnliches. Mit den momentanten PNG-Bildern kann denke ich kein Leser was anfangen. Z.B. das Bild zum SVG-Scripting: Da passiert nix. Wie sollte auch (PNG).

Grüße, --Benji 17:50, 25. Jul 2006 (CEST)

Lesenswert-Diskussion Dezember 2005

Bitte nicht mehr abstimmen

•  Pro Der Artikel ist gut aufgebaut, und schildert leicht verstaendliche Beispiele. Meiner Meinung nach ist er lesenswert. --coolpix 18:01, 22. Dez 2005 (CET)

•  Kontra Was der Artikel tatsächlich strukturiert und leicht verständlich vorträgt ist bloß die rein technische Seite, die Datenstruktur eines SVG-Dokuments. Alles darüber hinausgehende und in meinen Augen Elementare wie z. B. Entstehung, Beziehung zu XML, Konkurrenz zu Flash/anderen Vektorgrafikformaten, Bedeutung/Zukunftsaussichten, Verbreitung, Anwendungsgebiete usw. fehlt völlig oder wird lediglich in einzelnen (Neben-)Sätzen behandelt. norro 20:23, 22. Dez 2005 (CET)

•  Kontra ack Norro --Chrislb 06:03, 23. Dez 2005 (CET)

• mmh ja, stimmt auch wieder. soll ja kein tutorial (oder so aehnlich) sein. --coolpix 15:54, 23. Dez 2005 (CET)

- 2006 -

xmlns / RIA

hallo! Laut [1] ist das xmlns-Element im svg-Tag pflicht. Tatsächlich interpretiert der Opera nur solche svg-Tags: <svg xmlns="http:// www.w3.org/2000/svg"> Ist das korrekt so oder ist das ein Fehler von Opera? Weil auch in den Beispielen im Artikel ist nicht überall der Tag korrekt, auch auf den SVG Beispiel-Seiten nicht.

Außerdem wäre es mal interessant etwas von SVG im Zusammenhang mit einer Rich Internet Application im Artikel zu lesen. Tyset 21:36, 22. Feb 2006 (CET)

Weniger ist mehr! ?

Muss dieser riesige Abschnitt Elemente wirklich sein? Mit so vielen Beispiel-Quelltexten? Das grenzt ja schon fast an ein Tutorial. IMHO hat das in einer Enzyklopädie nichts zu suchen. Es gibt ja genügend Weblinks.

Auch der Abschnitt Beispiel scheint in dieser Form etwas deplaziert, da es mittlerweile direkt darüber vor Beispielen nur so wimmelt. --Pumbaa80 13:32, 27. Mär 2006 (CEST)

Ich habe von Programmieren keine Ahnung, daher weiß ich nicht von welcher Bedeutung diese Beispiele (so würde ich das verstehn) sind. Vielleicht interessant. Mir reicht da eine Beschreibung, was möglich ist mit diesem Format. Ein paar Worte, Zeilen zur programmierung sind sicher nicht verkehrt. - Metoc ☺ 17:44, 27. Mär 2006 (CEST)

Die Abschnitte Struktur, Elemente und Koordinaten sollten im Artikel verbleiben, da sie wichtige und gut aufbereitete Informationen erhalten. Allerdings sollten sie ans Ende des Artikels, noch hinter Konferenzen, verschoben werden, da sie den kleinsten Interessentenkreis ansprechen. --Squizzz 17:49, 27. Mär 2006 (CEST)

Ich stimme zu, dass die Abschnitte nicht gelöscht werden sollten. Sie müssen aber deutlich verkürzt werden. Die bloße Tatsache, dass ein Artikel/Abschnitt zahlreiche interessante, gut dargestellte Informationen enthält, gibt ihm noch keine Existenzberechtigung in einer Enzyklopädie. Siehe hierzu Punkt 8 auf der Seite Was Wikipedia nicht ist --Pumbaa80 21:47, 27. Mär 2006 (CEST)

Ich widerspreche dir: es handelt sich weder um eine Anleitung, noch einen Ratgeber. Vielmehr werden die grafischen Primitiven mit ihrer SVG-Syntax aufgelistet. Das ist genau das, was ich bei einem Wikipedia-Artikel in einem Experten-Abschnitt erwarte. --Squizzz 22:19, 27. Mär 2006 (CEST)

"Experten-Abschnitte" sind genau das, was man vermeiden sollte: Die Wikipedia ist eine allgemeine Enzyklopädie und kein Fachbuch. (Wikipedia:Wie_schreibe_ich_einen_guten_Artikel). Das heißt also: Der Artikel sollte Laien erklären, was SVG ist und wie es funktioniert. Man sollte sich in einen Leser hineinversetzen, der noch nie von SVG gehört hat, und überlegen, welche Abschnitte er verstehen wird. Aber dazu gehört noch nicht mal die Auflistung aller Primitive, und schon gar nicht Sourcecodes. Für sowas gibt es ja Tutorials.

Ich könnte mir eine ähniche Struktur wie im Artikel HTML vorstellen. Da ist auch nicht haarklein erklärt, wie man alle Tags verwendet. Ein, zwei Beispiele sind völlig ausreichend Unter Umständen könnte man auch den Abschnitt Elemente ein einen separaten Artikel auslagern. --Pumbaa80 23:46, 27. Mär 2006 (CEST)

Bevor wir hier in eine Grundsatzsiskussion verfallen, habe ich jetzt erst einmal die Reihenfolge der Abschnitte wie oben vorgeschlagen geändert. --Squizzz 23:53, 27. Mär 2006 (CEST)

Man sollte schauen was hier sinnvoll ist oder nicht...

Animationen, Grafische Effekte/Filter, Grafische Effekte/Filter, Grafische Effekte/Filter beinhalten etwas viel Code, mir aber egal, stört mich nicht. Sicherlich noch Inhaltlich zu erweitern aber der Text ist auch für den Laien verständlich. Graphische Primitiven sind einerseits sehr leicht zu verstehen, doch stellt man sich nach Linie die Frage, ist das hier eine Funktionsreferenz? Einerseits wunderbar, aber hier sollte besser ein generelles Verständnis vermittelt werden. In WikiBooks kann man gern Tutorials, etc dazu schreiben ;) - Metoc ☺ 17:12, 28. Mär 2006 (CEST)

Ich sehe schon, man könnte hier ewig weiterdiskutieren. Aber das führt ja zu nichts. Meine Argumente stehen da; ich lasse mich auch gern überstimmen. Vielleicht schaut Ihr mal zum Vergleich auch noch die anderssprachigen SVG-Artikel an. I'm outta here ;-) Ich wünsche gutes Gelingen -- Pumbaa80 18:22, 28. Mär 2006 (CEST)

Mir ist der Abschnitt auch deutlich zu lang. Am Wikibook scheint es noch arg an Elementen zu mangeln, ich würde vorschlagen sie dorthin zu verschieben. --Kockmeyer 20:17, 19. Apr. 2007 (CEST)

Ganz wichtig

Für jeden Laien sollte ganz am anfang des Artikels klar und deutlich stehen das die Beispielgraphiken keine wirkichen SVG-Daten sind sondern SVG-graphiken als Rastergraphik (vom Server) vorgerendert - sprich: Nicht vom Browser gerendert (wie es eigentlichs ein sollte). Desweiteren fehlt in der Linkliste ein klar ersichtlicher eintrag mit dem Tierl: "Hier können sie Testen ob/bzw wie ihr Browser SVG-graphiken rendert. 62.47.135.253 16:54, 23. Jun 2006 (CEST)

Der vorgeschlagene Hinweis für Laien hat unter Umständen seine Berechtigung. Jedoch, wenn man auf die Beispielgrafiken klickt, bis zur "Rein-Darstellung" dann werden die in einem SVG-fähigen Brwoser auch als SVG angezeigt. luettmatten 16:12, 2. Jul. 2008 (CEST)

Neutralität

Irgendwie wäre etwas neutraleres als die Deutsche Flagge als erstes Beispiel besser geeignet. Wie wäre es z.B. einfach mit einer horizontaler Linie? --PhilippW 12:02, 18. Aug 2006 (CEST)

FULL ACK - ich finde die deutsche Flagge in *JEDER* Hinsicht unpassend. Ein Bild oben rechts lenkt Aufmerksamkeit auf sich. Ohne den Text zu lesen, denke ich, ich bin hier auf irgendeinem Artikel über Deutschland. Passender wäre vielleicht sowas wie Bild:Svg.svg, nur ist das ziemlich wirr, zeigt nur einige "Funktionen" von SVG und in jedem Fall nicht repräsentativ.

Was man machen könnte: Native Zeichenformen vorstellen. Oder einfach SVG zeichnen. Oder vielleicht eine Infobox Software (doch was soll da rein?)?

Ich würde gern solch ein SVG erstellen, wenn ein vernünftiger Vorschlag getroffen wurde :-)

Grüße, --Benji 15:09, 18. Aug 2006 (CEST)

ich denke das Rote Kreuz Logo [2] wäre da besser geeignet. Es ähnlich primitiv wie die Flagge, aber neutraler. --Steffen2 17:46, 25. Aug 2006 (CEST)

Neutraler ja, passender nicht - es besteht auch hier kein Zusammenhang und man könnte meinen, es handelt sich - um all das, was man aus einem roten Kreuz heraus interpretieren kann ;-) --Benji 20:41, 25. Aug 2006 (CEST)

Ich bin der Meinung, die Deutschland-Flagge macht die eigentlichen Vorteile des svg-Formates nicht klar. Wie wäre es mit einem einfachen Kreis oder einem Buchstaben (z.B. das vorgeschlagene "SVG")

Ich finde den Teil des SVG-Bildes gut, wo die drei Kreis zu sehen sind. Wäre das was? --Thire 19:53, 16. Sep 2006 (CEST)

Es gibt nach wievor nicht die perfekte repräsentative SVG-Grafik. Vielleicht ist die englische Lösung einfach die Beste. --Benji 22:45, 17. Sep 2006 (CEST)

Ja, Image:Bitmap VS SVG.png gefällt mir auch gut. Aber: Quelltext hat diese Grafik ja keine (ist ja eine Rastergrafik) und es ist eben keine SVG-Grafik, was als oberestes Beispiel ja ganz nett wäre. --Thire 08:58, 18. Sep 2006 (CEST)

SVG-Logo (bezüglich #Neutralität)

Hallo,

seit dieser Änderung steht im SVG-Artikel, wenn auch etwas deplatziert, dass es einen "Logo Contest" o.ä. geben soll. Gesetz dem Fall, in naher Zukunft sollte sich sowas durchsetzen, wäre das die ideale Lösung für die Diskussion zur Neutralität der Deutschlandflagge.

Grüße, --Benji 23:10, 25. Sep 2006 (CEST)

Im Prinzip ja, v.a., weil geplant ist, das Logo unter einer CC NoDerivs-Lizenz zu veröffentlichen, was das Einbinden in die Wikipedia erleichtert. Praktisch hängt es natürlich davon ab, welches Logo gewinnt. Es bleibt spannend bis zum 17.10., da ist Preisverleihung. --Manuel - (Diskussion) 06:50, 26. Sep 2006 (CEST)

Öhm, hallo? ND ist ein Verstoß gegen WP:BR. TZM –– Unterstützt die Toleranzkriterien 15:11, 28. Okt. 2006 (CEST)

Ist es nun ein Verstoß oder nicht? Das Logo wurde heute schließlich eingefügt. So wie ich das sehe ist es ein Verstoß. -- Sepp

Nachdem ich mir die Erläuterungen dazu durchgelesen hatte, denk ich, dass das Logo doch verwendet werden kann. Ich hab es mal aus Primitiven redesigned Im Gegensatz zum Original ist hier der Quelltext auch recht verständlich, es könnte also als Ersatz für die Deutschlandflagge dienen.

Neu-erstelltes Logo: Datei:Svglogo2.svg

Quelltext (ohne Lizenzzeug und etwas gekürzt):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg 
xmlns="http://www.w3.org/2000/svg"
xmlns:xlink="http://www.w3.org/1999/xlink"
width="100%"
height="100%"
viewBox="-150 -150 300 300">
<title>SVG Logo</title>
<defs>
 <circle id="sc" cx="0" cy="-100" r="32" fill="#FFB13B" stroke="#000000" stroke-width="18" />
 <line id="l" x1="0" y1="-100" x2="0" y2="100" stroke="#FFB13B" stroke-width="32" />
</defs>
<circle cx="0" cy="0" r="100" fill="#000000" />
<use xlink:href="#sc" />
<use xlink:href="#sc" transform="rotate(45,0,0)" />
<use xlink:href="#sc" transform="rotate(90,0,0)" />
<use xlink:href="#sc" transform="rotate(135,0,0)" />
<use xlink:href="#sc" transform="rotate(180,0,0)" />
<use xlink:href="#sc" transform="rotate(225,0,0)" />
<use xlink:href="#sc" transform="rotate(270,0,0)" />
<use xlink:href="#sc" transform="rotate(315,0,0)" />
<use xlink:href="#l" />
<use xlink:href="#l" transform="rotate(45,0,0)" />
<use xlink:href="#l" transform="rotate(90,0,0)" />
<use xlink:href="#l" transform="rotate(135,0,0)" />
</svg>

-- Ff-Sepp 13:55, 12. Jan. 2007 (CET)

Ich habe das Logo gestern hochgeladen (Bild:SVG-Logo.svg). Und weil es als Gebrauchsgrafik keine ausreichende Schöpfungshöhe aufweist, ist es vollkommen schnurz, welche Lizenz sich da irgendjemand ausdenkt - es ist in Deutschland gar nicht urheberrechtlich schützbar. --AFranK99 [Disk.] 18:48, 12. Jan. 2007 (CET)

Kann mir jemand erklären warum meine Version des Logos gelöscht wurde? Als Ersatz fürdie Deutschlandflagge war das doch ideal. --Ff-Sepp 12:00, 13. Jan. 2007 (CET)

1. Da wir kein redundantes Zeug brauchen, das nicht mal das original darstellt. 2. Die Deutschlandfahne verständlicher ist. Ein XML-Laie würde prompt verstehen wie das funktioniert (blackstripe etc.) aber bei dem SVG Logo ist es schon zu kompliziert. Damals als ich mich zum ersten mal mit SVG beschäftigte, hat mir die SVG-Deutschlandfahne sehr viel mehr beigebracht als den ganzen Text durchzulesen, und das kann ich von dem SVG Logo nicht behaupten. Vielleicht wäre ein anderes Bild besser angebracht? Irgendwas abstraktes? --Ar-ras (D BT) 00:43, 14. Jan. 2007 (CET)

hmm... naja wie wärs mit drei streifen in den svg-farben? ;) --Ff-Sepp 00:50, 14. Jan. 2007 (CET)

Hallo,

um die Diskussion mal etwas sinnvoll vorzuführen: Das neue Logo von www.svglogo.com scheint nach [3] und der Benutzung in [4] offiziell zu sein. Ungeachtet seiner Komplexität fände ich es daher schade, es im Artikel *nicht* zu benutzen, wenn es doch so einfach und unkompliziert (auch in Lizenz-Hinsicht) ist. Von daher ein Kompromiss-Vorschlag meinerseits:

• Das offizielle Logo nach ganz oben ohne seinen Quelltext
• Das einfache und offensichtlich lehrreichere Deutschlandflaggen-Beispiel etwas oder direkt drunter, ggf. sogar neben das Inhaltsverzeichnis. Damit erübrigt sich auch jeder Missverstand (Neutralitätsgründe, etc.), denn jedem ist ersichtlich, dass die Deutschlandflagge eine sehr einfache und anschlauliche Anwendung von SVG ist.

Ich könnte das jetzt direkt im Artikel umsetzen, aber ich will keinen Edit-War o.ä. erzeugen; eine sinnvolle Diskussion an dieser Stelle hier mit Konsens wäre mir lieber.

Grüße, --(Vorstehender nicht signierter Beitrag stammt von Benji (Diskussion • Beiträge) 16:29, 14. Jan 2007 (CEST)) -- Ar-ras (D BT) 00:09, 15. Jan. 2007 (CET)16:29, 14. Jan. 2007 (CET)

PS: Eine der Logo-Variationen gefällt mir eh besser als dieses nackte achteckige Etwas.

Da ist mir aber

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE svg>
<svg
  xmlns="http://www.w3.org/2000/svg"
  width="300"
  height="300">
    <rect
      width="300"
      height="300"
      x="0"
      y="0"
      fill="#685d53"
      id="Hintergrund" />
   <rect
      width="200"
      height="200"
      x="10"
      y="10"
      fill="#be3f12"
      id="Rotes_Quadrat" />
   <rect
      width="70"
      height="70"
      x="220"
      y="220"
      fill="#3e4779"
      id="Blaues_Quadrat" />
   <rect
      width="70"
      height="200"
      x="220"
      y="10"
      fill="#000000"
      id="Schwarzes_Quadrat" />
   <rect
      width="200"
      height="70"
      x="10"
      y="220"
      fill="#dbbc21"
      id="Gelbes_Quadrat" />
</svg>

lieber--Ar-ras (D BT) 01:35, 14. Jan. 2007 (CET)

Ich war mal so frei und habe die restlichen Varianten auch noch hochgeladen:

• 
• Datei:SVG-Logo2.svg
• 
• 
• 
• 

Bedient Euch. --AFranK99 [Disk.] 18:13, 14. Jan. 2007 (CET)

Vorschlag von Benjji ist akzeptabel (wenn nicht sogar hervorragend) --Ar-ras (D BT) 00:09, 15. Jan. 2007 (CET)

Find ich auch. --AFranK99 [Disk.] 07:44, 15. Jan. 2007 (CET)

Jupp, dass ist wohl die beste Variante :) --Ff-Sepp 17:19, 15. Jan. 2007 (CET),

Find ich schön, dass der Vorschlag soviel Zustimmung erhalten hat. Daher hab ich es einfach mal umgesetzt, wobei ich mit der Deutschland-Tabelle verschiedenste Konfigurationen (Flagge links, sourcecode rechts oder auch Sourcecode ohne Umbrüche in rect-Tags und dafür breiter) ausprobiert habe. Naja, die momentane (alte) Lösung ist ziemlich wuchtig, aber ansonsten find ichs ganz hübsch. --Benji 21:33, 15. Jan. 2007 (CET)

Programm, das Bilder in .svg umwandelt?

Gibt es ein Programm, dass einfach mittels "Speichern unter.." bzw. "exportieren als" ein normales png oder jpg Bild in svg Format umwandeln kann. Besonders für Logos wäre so ein Programm sicherlich sehr nützlich. --Red Grasshopper 19:41, 6. Nov. 2006 (CET)

• PNG oder JPG Bilder sind Pixelgrafiken. SVG ist ein Vektorgrafikformat. Um eine Pixelgrafik in eine Vektorgrafik zu wandeln, gibt es in einigen Vektorprogrammen sog. "Tracer", die Pixelgrafiken in Vektorgrafiken wandeln. Die Qualität der einzelnen Tracer hängt vom Vektorgrafikprogramm (und natürlich von der Qualität der Vorlage) ab. Einigermaßen vernünftige Wandlungs-Ergebnisse findet man in den Vektorgrafikprogrammen Xara Xtreme, Adobe Illustrator, Corel Draw und Inkscape. Allerdings haben alle Bitmap-Tracer die negative Eigenschaft, dass meistens mehr Arbeit beim späteren Nachbearbeiten der automatisiert gewandelten Ergebnisse entsteht, als wenn man das Bild gleich mit Hilfe der Zeichenfunktionen der jeweiligen Vektorgrafikprogramme nachgezeichnet hätte. Der Grund dafür ist, dass die Algorithmen der Tracer nicht erkennen können, wie sie ein Bild optimal aufbauen könnten, um am Ende des Prozesses möglichst wenige Objekte zu haben. Stattdessen erzeugen die Tracer - je nach Komplexität der Ausgangsgrafik - viele tausende Vektorobjekte, die das manuelle Nachbearbeiten zur Qual machen. Daher empfehle ich für wirklich professionelle Ergebnisse das Nachzeichnen des Logos in einem Vektorgrafikprogramm (wende ich in der Praxis beispielsweise so an). Gruß --Remi 19:53, 6. Nov. 2006 (CET)

• Hallo Red Grashopper,

die Umwandlung eines Vektorgrafikformates zu einer Bitmapgrafik (also sowas wie PNG oder JPG) ist mit einer entsprechenden Renderingengine sehr einfach (bekannte Beispiele: die von Inkscape, rsvg (wird von Wikimedia genutzt), Apache Batik (Software)).

Andersrum ist es allerdings deutlich komplizierter: Das "Vektorisieren" kann nach vielen unterschiedlichen Gesichtspunkten geschehen und kann nur bei sehr einfachen Grafiken automatisiert werden, ansonsten entstehen je nach Algorithmus sehr schlechte Ergebnisse (sowohl in Qualität als auch Dateigröße). Eine recht bekannte Vektorisationssoftware ist Potrace, http://potrace.sourceforge.net, sie wird in Inkscape verwendet.

Siehe dazu auch: Vektorisierung

Grüße, --Benji 20:01, 6. Nov. 2006 (CET)

Vielen Dank für die schnelle kompetende Antwort. Ich habe mir Inkscape heruntergeladen - leide finde ich die automatische Tracer Funktion nicht. Vielleicht bin ich auch einfach zu blind ... Red Grasshopper 20:18, 6. Nov. 2006 (CET)

Datei->Bitmap importieren, Bildobjekt ausgewählt haben, Pfad->Bitmap vektorisieren.

Siehe auch hier: [5]

--Benji 21:22, 6. Nov. 2006 (CET)

Animationen & Wikipedia

Gibt es freie Programme, die es erlauben animierte SVGs zu erstellen und kann Wikipedia mit solchen files umgehen? --Thire 11:10, 21. Jul 2006 (CEST)

Wikipedia kann nicht mit animierten SVGs umgehen (weder "native" Animation, noch Animation mit JavaScript & Co.), und ich hab auch noch nie mit einem Programm, welches sowas erzeugen könnte, gearbeitet. (Ich könnte mir aber vorstellen, dass Adobe sowas z.B. in seinem Adobe Illustrator hat)

Grüße, --Benji 15:21, 18. Aug 2006 (CEST)

Das Animationsbeispiel (mit Playbutton) wird bei allen mir zur Verfügung stehenden Programmen (Firefox, KSvg, Inkscape) statisch angezeigt. Mit welchem Programm kann ich native Animationen sichtbar machen?

Ich habe hier ein weiteres Beispiel gefunden. Als ich einen Bericht las, wonach Opera die beste Unterstützung bietet, habe ich Opera unter Debian installiert - und voila, die Beispiele werden angezeigt (gelber Ball rollt auf Kreisbogen). Im Beispiel muss die Schrift schräg einfliegen. Der Opera stellt das richtig dar.

Tabelle: Browsersupport

1. Wallclock wird nie unterstützt - sollte die Spalte nicht entfernt werden?

2. Es wird suggeriert, dass der Internetexplorer SVG unterstützt. Natürlich tut dies nur das Adobeplugin; das lässt sich aber auch in anderen Browsern (z.B. Mozilla) nutzen, so dass auch hier die entsprechende Zeile: Mit Plugin volle Unterstützung stehen müsste. Das ist auf der englischsprachigen Seite besser gelöst.

Darüber hinaus tauchen unter Windows Browser auf, die auch auf den anderen Systemen verfügbar sind (z.B. Firefox 3), sollte für solche „Multiplattformbrowser“ nicht besser ein eigener Block gemacht werden um sie nicht überall aufführen zu müssen. --Gorp 00:05, 13. Sep. 2008 (CEST)

- 2007 -

Freier SVG-Druckertreiber

Wann gibt es denn endlich einen freien SVG-Druckertreiber? Bestimmte (ältere, aber gute) Grafikprogramme unter Windows haben keine SVG-Unterstützung, Copy/Paste in neuere Grafikprogramme mit SVG-Unterstützung klappt bei Farbverläufen nicht immer etc. Vielleicht gibt es sowas irgendwann mal im Ghostscript-Projekt, weiss da jemand wes? Oder irgendwann mal ein pdf2svg? (nicht signierter Beitrag von 194.138.39.140 (Diskussion) )

Liebe IP,

was für Forderungen stellst du denn an eine Enzyklopädie? Wir stellen hier eigentlich keine Software her. Mal abgesehen von deinen schwammigen Beschreibungen ist das eigentlich auch kein Platz, um solche speziellen Anwendungsmöglichkeiten von SVG zu diskutieren. --Benji 20:59, 3. Jul. 2007 (CEST)

was sind grundformen?

in der kopatibilitäts-tabelle wir dvon "grundformen" gesprochen, aber nirgend wird erklärt was das ist. kann ich also keinen kreis anzeigen wenns da rot ist? kann doch nicht sein, oder?

Selbstverständlich nicht. Grafische Primitivien/"Grundformen" sind allgemein z.B. sowas wie Kreise, Quadrate, Vierecke Dreiecke (X-ecke) - sehr primitive Formen halt. Den Kontrast stellen "Pfade" mit ihrem ganzen Funktionsapperat dar, womit jede beliebige Form gezeichnet werden kann. Wie die dann farblich aussehen, oder gar - im Beispiel SVG - von irgendwelchen Filtern verfremdet werden, ist dann ein ganz anderes Kapitel. Solche Funktionen zu programmieren ist durchaus Aufwand - daher ja auch die Übersicht über den Fortschritt der Implementierungen ("Kompatibilitäts-Tabelle"). --Benji 20:28, 18. Jan. 2007 (CET)

Batik proprietär?

in "SVG-Unterstützung in Software" schreibt ihr das Batik proprietär sei... steht aber unter Apache-Lizenz. Laut Free Software Foundation definition ist das Freie Software. (nicht signierter Beitrag von 88.64.155.241 (Diskussion) )

In der Tat, Batik gehört zum Apache XML Project und dort ist, wie bei allen Apache-Projekten, alles unter der Apache-Lizenz freigegeben. Abgesehen davon baut Batik auf reinem Java auf und ist damit nicht nur auf die drei dort genannten Plattformen beschränkt. Danke für den Hinweis. --Benji 19:27, 18. Jan. 2007 (CET)

Überarbeiten: Aufklappbare Boxen

Aufklappbare Boxen, wie sie in Navigationsleisten eingesetzt werden, dürfen nicht in Artikeln verwendet werden - da sie nicht mit gedruckt werden. Werden sie nicht eingearbeitet, werde ich sie in den kommenden Tagen ersatzlos streichen. --Atamari 18:20, 28. Jan. 2007 (CET)

Das hat sich wohl irgendjemand einfallen lassen. Die Boxen haben zudem den Nachteil, dass sie umfangreichen Inhalt relativ unauffällig verschweigen. Um den Artikel nicht übermäßig lang werden zu lassen, gibt es stattdessen eigentlich nur noch die Möglichkeit, z.B. diese Teile auszulagern. Dies kann auf verschiedene Wege passieren, klassisches Beispiel ist sowas wie Frankfurt am Main#Religionen: Hauptartikel: Religionen in Frankfurt am Main. Deutlich weniger elegant (ich finds sehr hässlich), aber evv. weniger strukturell aufdringlich ist sowas wie z.B. in Elvis Presley#Filmografie: Ausgelagert nach Elvis Presley/Filmografie. Letzteres wäre, mit einer Notation wie ''Hauptartikel: [[SVG/Technik|Technik von SVG]]'' o.ä. kombinierbar, was eleganter aussieht als im Presley-Artikel und gleichzeit weniger offensichtlichen Artikel-Overhead erzeugt.

Grüße, --Benji 19:46, 29. Jan. 2007 (CET)

Ich glaube nicht, dass der Artikel im Moment zu lang ist. Da liegt meines Erachtens nicht das Problem. --Atamari 20:20, 29. Jan. 2007 (CET)

Wo dann? Denn sonst: Sei mutig! und entferne die Boxen einfach --Benji 20:39, 29. Jan. 2007 (CET)

Ich finde das mit den Aufklapp-Boxen gut. Es macht den Text übersichtlich und der Leser findet die Beispiele dort, wo sie hingehören. Für überflüssig oder verzichtbar halte ich die Beispiele dagegen nicht. Das Problem ist doch blos die Druckausgabe - man sollte sich besser dafür etwas einfallen lassen, anstatt den Artikel zu kastrieren! --BeeDotGee 10:37, 30. Jan. 2007 (CET)

• Entsorgt --Atamari 18:48, 30. Jan. 2007 (CET)

• BeeDotGee, das Problem ist einfach, dass dynamisch aufklappbare Inhalte in der Wikipedia keineswegs normal sind, zumindest bei Texten. Nicht mal die Portale sind mit sowas ausgestattet. Das verwirrt den Leser nun mal. Auch wenn es technisch möglich wäre (ziemlich einfach sogar) --Benji 21:09, 30. Jan. 2007 (CET)

Bildwarnung

Die unten genannten Bilder, die in diesem Artikel verwendet werden, sind auf Commons gelöscht oder zur Löschung vorgeschlagen worden. Bitte entferne die Bilder gegebenenfalls aus dem Artikel oder beteilige dich an der betreffenden Diskussion auf Commons. Diese Nachricht wurde automatisch von CommonsTicker erzeugt.

• Image:Svg_example4.svg:
  • Datrio  entfernt Lizenzmarker CC-BY-2.5 von Template:Svg_example2

I'll be bold and update this, Nethac DIU is notified about this change (diff); Bilder:

• Image:Svg_example5.svg:
  • Datrio  entfernt Lizenzmarker CC-BY-2.5 von Template:Svg_example2

I'll be bold and update this, Nethac DIU is notified about this change (diff); Bilder:

-- DuesenBot 15:32, 6. Feb. 2007 (CET)

Was bedeutet dies für diese Artikel (SVG) hier? Eine Löschung/Löschwarnung ist es ja offenbar nicht. Daher denke ich, dass wir die Bilder zunächst nicht entfernen brauchen?!?! --Nyks ► Fragen? 15:52, 6. Feb. 2007 (CET)

Ich hab mal bei den Commons vorbeigeschaut und keine Hinweise auf eine bevorstehende Löschung gefunden. Ich würds ignorieren. --Manuel - (Diskussion) 16:37, 6. Feb. 2007 (CET)

Könnt ihr kein Englisch? xyz entfernt Lizenzmarker von abc - sprich es hat sich nur die Lizenz geändert - gelöscht wird hier garnix. :-)

Grüße, --Benji 23:32, 5. Mär. 2007 (CET)

Anarchodingsdabumsflagge

Das ist doch nicht Euer Ernst?? Also, statt drei Rechtecken zwei Dreiecke, das ist ja wohl kaum anschaulicher. Und bei der Deutschlandflagge ist der Wiedererkennungswert sehr viel höher, also der Effekt: "Oh, so leicht kann man mit SVG die Deutschlandflagge beschreiben?". Mit der neuen Flagge denkt jeder ja erst mal nur, "wasndas?" Außerdem finde ich die Verwendung einer solchen ideologisch behafteten Flagge als Beispiel wirklich unglücklich. Ich wäre dankbar für Pro-Argumente, sonst setze ich das wieder auf die D-Flagge zurück. Gruß, --Flo12 12:01, 22. Mär. 2007 (CET)

Die Deutschlandflagge ist ja wohl ideologisch MINDESTENS genauso belastet wie die Anarchistenflagge. Am liebsten wäre mir GAR keine Flagge, aber besser als die Deutschlandflagge ist die Anarchistenflagge auf alle Fälle.--88.66.17.116 13:09, 24. Mär. 2007 (CET)

Wahrscheinlich war die Intention von Nobletrip auch eher satirischer Natur. Er wollte dem offensichtlich durchgeknallten Patrioten, der die deutsche Flagge hier eingebaut hat, einfach zeigen, wie übel es ist, wenn ein Artikel über ein Dateiformat ein politisches Statement entält. Vielleicht sollten wir daraus lernen und einfach alle Flaggen weglassen?--88.66.17.116 13:32, 24. Mär. 2007 (CET)

Hallo,

na, höre ich da einen anonymisierten Nobletrip? ;-) Irgendwie kommt mir die Interpretation seiner handlung nämlich ziemlich weit hergeholt vor. Ich für meine Fälle habe in der Flagge echt keine Ironie gesehen, und ich will den Leuten ja auch nichts unterstellen.

Fakt ist jedenfalls: Mit der Deutschlandflagge kann man ideologisch eine Menge verbinden, es aber auch lassen und sie z.B. als Repräsentant einer Sprache sehen. Wesentlich belasteter finde ich da schon die Anarchistenflagge. Aber es spielt ja auch überhaupt keine Rolle, beides ist nicht so klasse, siehe weiter oben #Neutralität. Nun müsste man halt einen würdigen Ersatz finden, ob das das Haus vom Nikolaus sein kann, mag ich auch bezweifeln.

Grüße, --Benji 21:45, 24. Mär. 2007 (CET)

Ich finde die Interpretation liegt extrem nahe. Man kommt auf die Seite, sieht die Deutschland-Flagge, fühlt sich spontan belästigt. Man will etwas dagegen tun, weiß aber dass Argumente auf Wikipedia nicht immer funktionieren (besonders wenn man sieht, dass das Thema bereits diskutiert wurde und der Konsens "Deutsche Flagge drin lassen" war).--88.66.17.116 00:17, 25. Mär. 2007 (CET)

Man fühlt sich belästigt von der Deutschlandflagge? Also, tut mir leid, aber das ist echt wieder typisch deutsch. Ich glaube, es gibt nicht viele Leute weltweit, die sich vom Anblick der eigenen Staatsflagge belästigt fühlen. Die Deutschlandflagge ist doch nun echt relativ wenig belastet; man sollte sie nicht mit der Reichsflagge verwechseln (was bei akuter Farbblindheit jedoch leicht passieren kann). Achso: Was machen wir mit den ganzen Artikeln mit der Vorlage:Deutschlandlastig?

Der Unterschied ist (Überraschung:) da *geht* es auch um Deutschland und nicht um ein *Dateiformat*.--88.64.177.248 00:35, 26. Mär. 2007 (CEST)

OK, ich geb's auf; hier sind offensichtlich nur *** am Werk, die, selbst wenn sie nur ein Dateiformat beschreiben wollen, ihre lodernde Vaterlandsliebe nicht unter Kontrolle halten können. Kein Wunder, dass die Wikipedia immer noch als unseriöse Informationsquelle gilt.--88.66.1.152 10:43, 29. Mär. 2007 (CEST)

Um mal wieder sachlich zu werden: Am ehesten geeignet wäre vielleicht (neben dem Haus des Nikolaus) irgendein bekanntes, einfaches Logo. Ich denke, der Wiedererkennungswert ist schon wichtig für den Leser. Gruß, --Flo12 00:26, 26. Mär. 2007 (CEST)

Oh man, hier gehts ja mal wieder zu. Um mal 88.66.1.152s Beschimpfungen außer acht zu lassen, ich stimme Flo12 schon wieder zu. Allerdings sind die meisten Logos auch wieder wertend, sollte man also lieber gleich zu einem Piktogramm greifen. Was wiederum ziemlich kompliziert wird. Ach ja, so eine Flagge mit 3 Rechtecken ist halt doch irgendwie praktisch.

Als Gesamtalternative könnte man halt alles an "Initialbeispielen" weglassen und jeweils bei den grafischen Primitiven (Verwendungs-)beispiele machen. Grüße, --Benji 21:55, 29. Mär. 2007 (CEST)

Darüber habe ich auch schon nachgedacht. Dazu muss ich dann aber sagen, damals (damals...), als ich das erste Mal diesen Artikel las und gleich am Anfang das Beispiel der Deutschlandflagge sah, hat mich das gleich so fasziniert (nicht wegen des Motivs, sondern wie einfach eben so etwas bekanntes abgebildet werden kann), dass ich mich weiter mit dem Datenformat beschäftigt hab und inzwischen eigene SVGs (vor allem Wappen) für die WP erstelle. Durch ein eingängiges Beispiel am Anfang kann man beim Leser also einen "Early Win" erzielen, denke ich. Piktogramm ist schon ne gute Idee, oder vielleicht ein Straßenverkehrsschild? --Flo12 01:07, 30. Mär. 2007 (CEST)

Na gut, aber ob man nun Piktogramm oder Verkehrsschild nimmt, fast alle Grafiken sind hoffnungslos zu kompliziert. Ich fände ein Beispiel schön, was sich ausschließlich der grafischen Primitivien Kreis/Rechteck/Text bedient (weil selbst kurze Pfade sehr kompliziert und nicht selbsterklärend aussehen). Selbst sowas oder das hier, eigentlich sehr primitive Verkehrszeichen, wurden mit solchen Pfaden zusammengesteckt. Es geht halt nichts über eine Flagge ;-)

Wir könnten ja auch eine Fantasieflagge erfinden, die einen einfachen Quelltext hat und trotzdem ansprechend aussieht ;-) --Benji 19:11, 30. Mär. 2007 (CEST)

Wie wärs mit dem hier? Ich weiß, der Quellcode ist auch hoffnungslos kompliziert, aber das heißt nicht, dass das nicht einfacher geht. Ich könnte das als Beispiel neu erstellen, mit zwei Kreisen und einem Rechteck. Sollte anschaulich sein... eventuell ist das Motiv allerdings wieder abschreckend... :-/ Ich persönlich bin ja auch ein Fan von "alles so lassen", nur um das noch mal zu erwähnen ;-) --Flo12 00:22, 31. Mär. 2007 (CEST)

Wie wär's mit dem Haus vom Nikolaus? Na sowas, das ist ja noch eine PNG-Grafik im Artikel, da kann man ein doppelt gutes Werk tun. --Pjacobi 12:19, 22. Mär. 2007 (CET)

Sehr gute Idee.--88.66.17.116 13:09, 24. Mär. 2007 (CET)

Dass die Deutschlandflagge seit jeher problematisch ist, hatte ich schon mehrmals auf dieser Diskussionsseite erwähnt, mittlerweile wurde sie ja endlich durch das offizielle SVG-Logo verdrängt. Und in Hinsicht dieser dubiosen Flagge stimme ich mit Flo12 in *JEDER* Hinsicht überein. Abgesehen davon war der D-Flaggen-Quelltext deutlich anschaulicher. Zunächst nehme ich mir also bedingungslos das Recht heraus, wenigstens die Deutschland-Flagge zurückzuholen. Neutraler als diese von Benutzer:Nobletrip ausgehende Anarchistenflagge ist sie allemal.

Grüße, --Benji 17:34, 22. Mär. 2007 (CET)

Danke! :-) --Flo12 20:22, 22. Mär. 2007 (CET)

Ich halte die D-Flage für nicht besonders gelungen. Ich schlage vor einfach eine 4- oder 5- "zeilige" oder "Spaltige" Flagge zu verwenden, auf der einfach nur verscheide Graustufen zu sehen sind. --Kockmeyer 20:26, 19. Apr. 2007 (CEST)

Also dieses graue Teil ist ja wohl ein schlechter Witz... ...bei der Deutschlandflagge habe ich auf den ersten Blick verstanden, warum svg toll ist, den Quelltext für die graue guckt sich doch kein Mensch groß an. Aber wir können ja monatlich Deutschland-, Schweiz-, Österreich- (ohne Wappen oder Adler) und die Friedens- / CSD-Flagge (sorry, ich weiß das politisch korrekte BegriffIn nicht) rotieren lassen... ...wird wohl eh so oder so ähnlich kommen, so aufgeladen wie dieser Punkt ist...

Mir gefällt das graue Teil auch nicht :( --Benji 20:28, 4. Mai 2007 (CEST)

Wenn wir schon am Abstimmen sind: mir auch nicht! (Vielleicht mal wirklich ne Zählung unter eigenem Abschnitt?) --Flo12 23:58, 4. Mai 2007 (CEST)

Hallo-Welt-Beispiel

Hallo, allerseits,

angesichts der Tatsache, daß bei den Hallo-Welt-Programmen beileibe nicht nur Programme stehen, sondern u. a. auch ein POV-Ray-Beispiel: Könnte einer der hier versammelten Experten dort ein (minimalistisches) SVG-Beispiel plazieren? Danke ;-) --Tobias 15:53, 14. Apr. 2007 (CEST)

Unterstützung in professionellen Vektorgrafikprogrammen

(Hierhin kopiert von der Benutzer-Diskussion Ralf Roletschek

Hi Ralf,

kannst Du hierfür eine Quelle angeben? Ich weiß, CorelDRAW (z. B.) mag kein professionelles Programm sein, aber in dem Kontext ist doch "professionell" selbst schon etwas POV-belastet. Oder gibt es eine offizielle Liste von "professionellen" und "nicht-professionellen" Vektorprogrammen? Danke und Gruß, --Flo12 12:16, 22. Apr. 2007 (CEST)

Als halbwegs professionell mögen Programme des Computer Aided Design sein, eine Liste findest du auf Liste_mechanischer_CAD-Lösungen. CorelDRAW ist in der Tat nichts weiter als ein Malprogramm. Sollte man statt professionell vielleicht kommerziell schreiben? Das wäre zusätzlich noch falsch. --RalfR 12:25, 22. Apr. 2007 (CEST)

Zwischen dem eingefügten Satz „Das Dateiformat SVG wird von keinem professionellen Vektorgrafik-Programm unterstützt.“ und Deiner belegten Aussage, Programme aus der Liste_mechanischer_CAD-Lösungen unterstützten SVG nicht als Ausgabeformat besteht ein deutlicher Unterschied. Dazu müsste dargelegt werden, dass mechanische oder architektonische CAD-Programme die einzigen Vektorgrafikprogramme sind, was nicht der Fall ist. Als Beispiel für ein professionelles Vektorgrafikprogramm mit SVG-Unterstützung möchte ich z. B. den Adobe Illustrator nennen (aus dem Artikel: „Adobe Illustrator ist ein vektorbasiertes Grafik- und Zeichenprogramm“). Fazit: Die Aussage müsste meiner Meinung nach auf CAD-Programme reduziert werden. Da das nur ein Teil der Grafikprogramme ist und SVG sich bei 3D-CAD-Programmen als Ausgabeformat ohnehin nicht primär eignet, verliert dieser Satz für mich damit zumindest in der Einleitung seine Daseinsberechtigung. Unabhängig davon stimme ich Benutzer:Flo12 insofern zu, dass professionell solange POV ist, wie es nicht klar definiert werden kann. --norro 13:27, 22. Apr. 2007 (CEST)

Ok, "professionell" ist unglücklich und vielleicht auch POV - kannst du es besser definieren? Ich möchte den Fakt darstellen, daß so gut wie kein ernstzunehmendes Programm SVG unterstützt. Ob Illustrator dazuzähklt, ist Ansichtssache. Kritik scheint an dem Format unerwünscht, das habe ich in der Wikipedia oft genug erlebt. Mangelnde Kompatibilität ist allerdings ein ernstzunehmender Kritikpunkt, auch wenn das die Befürworter des Formates ungern sehen. Inventor und 3DStudio sind keineswegs reine CAD-Programme sondern bedienen sogar reichlichst den Film- und Spielemarkt - und als Austauschformat ist DXF seit Jahrzehnten bewährt und etabliert (und zudem ein offenes und freies Format). --RalfR 13:57, 22. Apr. 2007 (CEST)

Illustrator und Freehand (das SVG in seinen letzten Versionen unterstützen soll) sind sicherlich „professionelle“ Programme. Nicht für die Konstruktion, aber im grafischen Gewerbe. Über CorelDraw schweigt des Sängers Höflichkeit, aber in gewisser Weise wird auch das von „Profis“ verwendet, den Jungs von der Folienschneiderfraktion z. B. Rainer Z ... 15:52, 22. Apr. 2007 (CEST)

Du magst das zwar anders sehen aber CorelDRAW ist ein professionelles Vektorgrafikprogramm (zumindest seit der X3). Da das auch nichts mit CAD-Programmen zu tun hat, belegen die Listen auch nichts. Für CAD-Programme ist SVG vielleicht nicht da ideale Format, nur gibt es eben auch noch viele andere Anwendungsbereiche, in denen SVG auf dem Weg ist, sich als Standard zu etablieren. Ich hab die Änderung deshalb auch rückgängig gemacht, da sie einfach nicht den Tatsachen entspricht und auch nichts mit Kritik am Format zu tun hat. -- net 15:56, 22. Apr. 2007 (CEST)

Ralf, ich schlage vor, im Abschnitt zur SVG-Unterstützung in Software ein, zwei Sätze zur Verbreitung in CAD-Software zu schreiben. Damit trüge man dieser Kritik Rechnung (obwohl es tatsächlich keine Kritik am Format selbst ist), würde dieser Tatsache allerdings auch nur die Relevanz beimessen, die sie meiner Meinung nach auch besitzt. Das Wort „professionell“ würed ich dabei erst einmal vermeiden, da es scheinbar nicht konsensfähig ist (wie auch diese Diskussion hier zeigt). Gruß, norro 16:41, 22. Apr. 2007 (CEST)

@RalfR, Rainer Z: Ich schätze Eure Bildkunst sehr, aber diese Aussagen bzgl. CorelDraw sind der größte Blödsinn, den ich je gelesen habe. Ihr solltet mal damit arbeiten, dann könnt Ihr diesbzgl. mitreden. CorelDraw besitzt wie der Illustrator eine sehr gute Im- und Export-Unterstützung von SVG. Freehand unterstützt SVG weder beim Import noch beim Export, auch nicht in der letzten Version MX. Der Vergleich von CAD und Vektorzeichenprogrammen ist ebenfalls Unsinn, da beide in der Regel für völlig verschiedene Anwendungsbereiche verwendet werden. Kein Mensch zeichnet Karten oder Illustrationen mit nem CAD-Programm. Ach was reg ich mich auf, CAD-Leute schwören auf CAD-Software. GIS-Leute machen alles mit ArcGIS und Grafikwerkstatt- und Kartenwerkstatt-Leute benutzen Illustrator, Inkscape, Freehand oder eben CorelDraw. --Lencer 19:14, 2. Apr. 2008 (CEST)

Fehler im Scripting Beispiel?

Hallo, kann es sein, dass in dem Sourcecode zum Scripting von SVG ein Fehler ist? So wie es ist funktioniert das Beispiel in meinem Firefox 2.0.0.3 WinXP nicht.

Es funktioniert allerdings wenn man den Code wie folgt ändert:

Die Änderungen sind in Zeile 9:

function wachsen(evt) {

an Stelle von <![CDATA [[function wachsen(evt) {

und in Zeile 20

}

an Stelle von

}]] >

Ich habe mich bisher nicht viel mit SVG beschäftigt. Es kann also auch gut sein, dass das angegebene Beispiel vollkommen ok ist und der Fehler durch einen Bug im Browser zustandekommt. (nicht signierter Beitrag von 212.17.244.52 (Diskussion) )

Hallo,

Nach CDATA müsste es <![CDATA[ anstelle von <![CDATA[[ heißen. Vielleicht bringt das den Feuerfuchs ja durcheinander. --Benji 23:22, 25. Apr. 2007 (CEST)

Struktur: Dokumenttypdeklaration fehlt

Im abschnitt Struktur wird beschrieben, dass zum SVG-Standard die Dokumenttypdeklaration mit einem Verweis auf eine DTD-Datei nach der XML-Deklaration folgt. Die Fehlt aber in dem folgenden Codebeispiel, oder? Das ist doch das mit dem <!DOCTYPE ... > oder? --Supaari mail 12:34, 29. Jun. 2007 (CEST)

Jup, habs grad repariert! Danke für den Hinweis. --Manuel - (Diskussion) 14:31, 29. Jun. 2007 (CEST)

Beispielcode nicht valide

Der unter "Struktur" abgebildete Beispielcode wird von dem W3C Validator nicht als Standardkonform betrachtet. Grund dafür ist wohl der xmlns:ev Eintrag. --Makkonen 19:50, 21. Jul. 2007 (CEST)

Wo gibt es beim W3C denn einen SVG-Validator? -- net 22:00, 21. Jul. 2007 (CEST)

hier - hat mich auch überrascht, aber der hat das als SVG erkannt. Aber rein XML-syntaktisch ist die xmlns-Angabe definitiv korrekt - jeder normale XML-Parser dürfte da nicht meckern. Der SVG Validator scheint da recht streng zu sein... --Flo12 22:51, 21. Jul. 2007 (CEST)

Nur weil er den Doctype erkennt und entsprechend nach der DTD validiert, versteht der Validator aber trotzdem noch kein XML und damit SVG. XHTML 1.1 mit XForms oder MathML kann man bspw. auch nicht validieren. -- net 00:48, 22. Jul. 2007 (CEST)

Ich denke er versteht sehr wohl SVG. Er muss ja nur die XML Syntax prüfen und danach die einzelnen Abschnitte prüfen, ob sie laut der SVG Spezifikation existieren. Gegen die xmlns Angabe meckert der Validator auch garnicht, nur eben wegen der xmlns:ev Angabe. Das :ev scheint Probleme zu bereiten. Auch wenn das Syntaktisch für XML korrekt sein mag, vielleicht existiert so eine Angabe in SVG einfach nicht... Ich bin da leider kein Experte, deshalb habe ich das auch nur hier angemerkt ;) --Makkonen 09:30, 22. Jul. 2007 (CEST)

Der W3C-Validator versteht XML wie ich schon sagte nicht richtig. Er kann nur nach der DTD validieren und nicht nach dem XML-Schema. Außerdem kommt er mit XML-Namespaces wie xmlns:ev nicht klar und bringt da fälschlicherweise einen Fehler. Soweit ich das sehe, ist das Script valide. -- net 10:27, 22. Jul. 2007 (CEST)

Aber wieso meckert er nicht über den xlink-Namespace (xmlns:xlink="...")? --Flo12 12:41, 22. Jul. 2007 (CEST)

Ich weiß es leider auch nicht. Den Event-Namespace bemängelt der Validator überall, bspw. auch bei diesen XForms-Beispielen, die direkt vom W3C sind: [6] Entweder hat er generell ein Problem damit oder dieser Namespace ist es ab SVG 1.2 erlaubt. -- net 13:29, 22. Jul. 2007 (CEST)

Ich kenne leider den doctype für 1.2 und 2.0 nicht, könntest du das vielleicht mal testen, damit wir gewissheit haben? --Makkonen 17:51, 22. Jul. 2007 (CEST)

SVG 1.2 bietet der W3C-Validator noch nicht zum Validieren an, sonst hätte ich es schon gemacht. -- net 17:54, 22. Jul. 2007 (CEST)

SVG-Grafik – ein weißer Schimmel

Der Begriff SVG-Grafik ist eigentlich so falsch wie HIV-Virus und LCD-Display. Im Artikel und auf vielen weiteren Seiten wird die Begriff leider gebraucht. Spricht irgendetwas gegen ein generelles Ersetzen durch SV-Grafik (wie es im Fall von HI_Virus und LC-Display gemacht wird) oder SVG-Datei? --Kuebi 15:12, 23. Okt. 2007 (CEST)

Also SV-Grafik versteht keiner, dann schon eher SVG-Datei. Je nach Kontext kann man evtl. auch nur von „Grafik“ sprechen. -- net 16:20, 23. Okt. 2007 (CEST)

Tja, diese Dopplungen haben sich leider umgangssprachlich etabliert und ohne versteht man den Sinn meistens nicht mehr. Wenn mir auch HI-Virus als Wort bekannt vorkommt, SV-Grafik versteht man echt nicht. --Benji 10:46, 26. Okt. 2007 (CEST)

Nähere Erklärung im Artikel angebracht

"welches so gedreht wurde, dass die X-Achse nach rechts und die Y-Achse nach unten weist". Durch ein Drehung alleine kann das doch nicht zustandekommen. Oder ? sollte es nicht beser heißen: so verändert wurde, dass die X-Achse nach rechts und die Y-Achse nach unten weist ? --84.137.19.230 12:29, 27. Okt. 2007 (CEST)

Sind Scalable Vector Graphics eigentlich skalierbar? ;)

Natürlich weiß ich dass es sich um Vektorgrafiken handelt, und weiß wie ich diese mit Software wie z.B. Adobe Illustrator skalieren kann. Ich kenne jedoch mit keinem gängigen Broweser eine Technik, um die Grafik direkt im Browser größer anzuzeigen, womit der Hauptvorteil von SVG gegenüber Rastergrafiken verschwindet. Haben die Browserhersteller dort wirklich "am Namen vorbei" entwickelt?

Die Frage scheint noch nicht endgültig geklärt zu sein, aber sie haben sich auch schon andere gestellt. Siehe http://praegnanz.de/weblog/scalable-vector-graphics-skalierbar-einbetten --89.53.250.114 01:52, 27. Nov. 2007 (CET) (der selbe anonyme Nutzer, der einige Tage vorher die Frage gestellt hatte :) )

Wenn unter KDE Ksvg installiert ist, wird im Konqueror-Browser die SVG-Datei skalierbar angezeigt. Es gibt dann einen Button +/- in einer Lupe.

Koordinatensystem und -angabe

Hallo! Da es sich sowieso um eine zweidimensionale Anwendung handelt, kann man meiner Meinung im Satz "Es handelt sich dabei um ein zweidimensionales rechtshändiges Koordinatensystem, [...]" die Angabe "rechtshändig" weglassen. Da keine dritte Dimension gegeben ist, ist es unnötig, anzuzeigen, dass diese bei vorliegender Orientierung (x-Achse nach rechts, y-Achse nach unten) quasi in den Bildschirm hinein gehen würde (siehe auch:Rechte Hand Regel). Bei normaler z-Achsen-Ausrichtung (aus dem Monitor heraus) wäre das System sonst auch ein Linkshandsystem. Wichtiger wäre vielleicht, zu erwähnen, dass es sich um ein kartesisches Koordinatensystem handelt. -- Gruss, Ω² 17:45, 28. Nov. 2007 (CET)

Stimmt. Dann mach mal :-) --Benji 22:06, 29. Nov. 2007 (CET)

ok.. (fisselkram, hier) ;) -- Ω² 10:34, 30. Nov. 2007 (CET)

Sehe ich anders: Mit rechtshändig ist hier gemeint, dass die 2. Achse nach mit der 1. Achse einen 90-Gradwinkel im negativen Drehsinn (im Uhrzeiger) hat.

Ja, kla. Ob dieser Drehsinn nun aber negativ oder positiv ist, hängt davon ab, wohin die z-Achse zeigt, ob in die Monitorebene hinein oder aus ihr heraus. (Deine Beiträge kannst du mit vier Tilden unterschreiben..) --Gruss, Ω² 10:28, 11. Dez. 2007 (CET)

3D Dateiformat?

Ich suche nach einen Quelloffenen 3D Dateiformat. Ich habe gehoft über diese seite ein solches Link zu finden. Gibt es überhaupt ein gutes Quelloffenes 3D Dateiformat. Am besten währe es, wenn es eine Alternatife zu igs, DWG, step, etc. Darstellen würde.

Wie wäre es mit DXF? --RalfR → BIENE braucht Hilfe 16:05, 10. Dez. 2007 (CET)

VRML bzw. X3D ist in bunt und in Farbe. Oder vielleicht das Dateiformat von Blender. --Kolossos 16:41, 10. Dez. 2007 (CET)

Link zu VectorMagic

Hi, du hast den Link zu VectorMagic im Artikel Scalable Vector Graphics wieder rausgenommen. Dabei verweist du auf WP:WEB. Könntest du deine Entscheidung bitte begründen, da ich nicht erkennen kann, auf welchen Punkt du dich beziehst. --jed 06:28, 17. Dez. 2007 (CET)

Zitat aus WP:WEB: „Ein Weblink muss sich direkt auf das im Artikel besprochene Thema beziehen, also weder auf einen Oberbegriff noch auf einzelne Teilaspekte“. Ein Tool zum Konvertieren von Grafiken bezieht sich eben nicht auf das Artikelthema und bietet keine weiterführenden Informationen. -- net 09:04, 17. Dez. 2007 (CET)

Dort steht jedoch auch: Weitere Links sind nur erwünscht, wenn diese einen deutlichen Mehrwert zu dem Artikel und der offiziellen Seite bieten. Das Tool bietet sicherlich keine weiteren Informationen, aber einen deutlichen Mehrwert: man kann damit einfach SVG Dateien erstellen. Im Artikel werden z.B. die verschiedenen Programme, mit denen man SVG erstellen kann, aufgeführt. Inhaltlich würde der Link am ehesten dorthin passen. Wenn du willst, kann man dort einen Unterpunkt Online-Programme (oder ähnlich) einrichten oder man nimmt den Link einfach mit in die Liste. Oder man versteckt ihn in einer Fußnote wie etwa: Auch Online ist die Erstellung von SVG-Dateien möglich<ref>Link</ref>. Im englischen Artikel ist die Seite jedenfalls unter Weblinks aufgeführt. --jed 10:58, 17. Dez. 2007 (CET)

Dieses Tool bietet IMO keinen deutlichen Mehrwert für den Artikel. Es gibt ’zig Tools, Programme und Bibliotheken, die SVGs erstellen, konvertieren oder was auch immer können. Es ist nicht der Sinn von WP, auf alle diese Tools zu verlinken. Dafür ist bspw. das Open Directory Project da. -- net 11:45, 17. Dez. 2007 (CET)

Mir sind keine weiteren Tools bekannt, mit denen man online SVG-Dateien erzeugen kann. Insoweit hält sich der Andrang an Links noch in Grenzen. Und wie ich schon schrieb: es werden ja im Artikel eine ganze Reihe von Tools genannt, warum also VectorMagic mit dem Alleinstellungsmerkmal "online" nicht? --jed 14:40, 17. Dez. 2007 (CET)

Hast du VerctorMagic schonmal verwendet, und den Output mit anderen Vektorisierern verglichen? Meines Erachtens ist das ein gewaltiger Mehrwert. --e-Malte 15:02, 17. Dez. 2007 (CET)

Hi Jedi. Das Tool kann im Artikel ggf. erwähnt werden; es geht aktuell um die Platzierung unter Weblinks (gemäß WP:WEB nicht angebracht). Gruß, --norro 14:45, 17. Dez. 2007 (CET)

Hallo, das hatte ich anders verstanden, eher als grundsätzliche Ablehnung, die ich nicht nachvollziehen konnte. Ich habe VectorMagic nun ohne Weblink in die Liste der Programme aufgenommen. Ich hoffe, dass ist soweit in Ordnung? Oder sollte man noch extra hinzuschreiben: Flash-Anwendung = Browser = Internet? --jed 18:45, 17. Dez. 2007 (CET)

- 2008 -

CAT - CAD

Da SVG ein XML-basiertes Dateiformat ist, können SVG-Dateien mit Hilfe eines Texteditors bearbeitet werden. Dies bedeutet, dass die Texte, die in SVG-Dateien verwendet werden, auch für gegebenenfalls erforderliche Übersetzungen mit CAT-Programmen leichter zugänglich sind.
Ist hier wirkich CAT gemeint oder nicht eher CAD?--Anka ☺ ☻ 17:33, 18. Mär. 2008 (CET)

SVG-Unterstützung in Software

Dieser Abschnitt sollte erweitert werden. Es sollte grundsätzlich angezeigt sein, ob die Programme Im- und Export, sowie Bearbeitung von SVG beherrschen. Gimp, kann bspw. nur importieren und "rendert" aus dem SVG ein Pixelbild. Das sollte schon deutlich gemacht werden. LilyPond kann bspw. nur exportieren. Grüße Lencer 19:24, 2. Apr. 2008 (CEST)

Überarbeiten

Die betreffenden Stellen sind im Artikel selbst durch Kommentare angegeben. Stammen aber nicht von mit. --Thornard, ^Diskussion, 20:29, 2. Apr. 2008 (CEST)

Ohne die Comments gelesen zu haben: Aktuell ist es nicht mehr. FF3 zum Beipsiel ist bereits final! --KEBA 18:13, 25. Jun. 2008 (CEST)

Resistor.svg

„Das rechts dargestellte Bild Variable Resistor.svg (Schaltbild eines Potenziometers) hat den folgenden kommentierten Quelltext“ Die SVG-Datei hat weder den kommentierten Quelltext, noch entspricht das dargestellte Bild dem kommentierten Quelltext. (nicht signierter Beitrag von irgendeine IP (Diskussion | Beiträge) )

Hallo,

Verschiedene Leute haben den Quelltext der SVG-Datei abgeändert, aber der Quelltext von Version 21:39, 30. Sep. 2005 von commons:User:Xorx entspricht dem dargestellten Quelltext.

Viele Grüße, --Benji 01:12, 17. Jul. 2008 (CEST)

Das ist richtig, und als E-Techniker finde ich die neue Version sogar schicker. Aber so kann es doch nicht bleiben, zumindest muss doch der Quelltext zum dargestellten Bild passen. Am schönsten währe natürlich, wenn jemand das (von Inkscape erzeugte) SVG mit dem im Artikel verwendeten Methoden (rect, line, polyline, polygon) von Hand neu schreibt, so dass das Ergebnis gleich bleibt und auch den Quelltext im Artikel entsprechend anpasst. Gibt es eigentlich eine Möglichkeit den Quelltext im Artikel direkt durch die SVG-Datei zu ersetzen (single Source)? --Gruß, Thomas

Ja, die Version ohne der unnötigen Ecke beim Pfeil ist m.E. auch geläufiger. Du könntest dich ja Anmelden, d.h. eigentlich müsstest du dich bei den Commons registrieren, weil dort das Bild gespeichert wird. Anschließend darfst du nach Belieben eine neue Version des Bildes hochladen. Ansonsten könnte ich das auch mal bei Zeiten übernehmen (vielleicht noch im Laufe der Woche).

Mit der momentanen Version der verwendeten Wikisoftware MediaWiki ist es meines Wissens außerdem nicht möglich, den Quelltext der SVG-Datei direkt in einer Seite einzubinden. Grüße, --Benji 12:15, 18. Jul. 2008 (CEST)

Beispiel-SVG

Moin, ich finde das graue Teil nicht sonderlich hübsch, die Deutschlandflagge war da wesentlich besser, aber die ist einigen hier ja zu politisch aufgeladen. Was haltet ihr von folgendem Kompromiss:

<?xml version="1.0" encoding="utf-8" ?>
<svg width="400" height="400">
 <title>SVG</title>
 <style type="text/css"><![CDATA[
  text {font-size:60px; text-anchor:middle;}
 ]]></style>
 <rect x="0" y="0" height="400" width="400" fill="white" stroke="blue" stroke-width="100" />
 <rect x="160" y="80" width="80" height="240" fill="red" />
 <rect x="80" y="160" width="240" height="80" fill="red" />
 <switch>
  <text x="200" y="220" systemLanguage="de">Arzt</text>
  <text x="200" y="220" systemLanguage="fr">Médicin</text>
  <text x="200" y="220">Doctor</text>
 </switch>
</svg>

Fertig wird ein einfaches Schild mit breitem blauen Rahmen und rotem Kreuz. Auf dem ist in schwarzer Schrift "Arzt", "Doctor" oder "Médicin" geschrieben, je nach Spracheinstellung des Browsers.

Das Beispiel ist nicht zu komplex, zeigt aber die vielfältigen Möglichkeiten von SVG. Zur Not könnte man den Text auch weglassen, dann fällt aber das Feature weg, was SVG am stärksten von anderen Web-Grafikformaen abhebt.

--Ff-Sepp 18:20, 8. Sep. 2008 (CEST)

Für alle, die keinen SVG-fähigen Browser zur Hand haben: So ähnlich sieht das Bild gerendert aus, nur noch mit Schrift im Kreuz

Hallo Ff-Sepp,

mir gefällt das triste graue Beispiel momentan auch nicht. Das mit dem Arzt/Médicin/Doctor wird man nur leider nicht nachvollziehen können, da hier in der Wikipedia die Bilder serverseitig mit librsvg zu PNG-Bildern gerendert werden – nix da also mit Spracheinstellung des Benutzers. Ansonsten sieht es auf jeden Fall schon mal farbenfroher aus. --Benji 20:15, 8. Sep. 2008 (CEST)

Jupp, dieses Rendering ist extrem ärgerlich, zumal seit FF3 nun endlich native SVG-Unterstützung mitbringt, diese Sonderbehandlung eigentlich sein lassen könnte, gerade für Commons wäre echtes einbinden von SVG wegen der Mehrsprachigkeit absolut genial. --Ff-Sepp 23:00, 8. Sep. 2008 (CEST)

Ich finde nicht dass das Beispiel jetzt an diesem Sprachswitch scheitern sollte, also dennoch trotzdem ganz klar  Pro. --Vanger ^!–!? 06:10, 9. Sep. 2008 (CEST)

Können wir das jetzt als Konsens dafür sehen, zum neuen Bild zu wechseln? Welcher Text soll dann letztlich da drin stehen?

Das Sprachswitching-Feature von SVG kannte ich noch nicht. Es würde sich natürlich hervorragend als ultimative Lösung des Mehrsprachenproblems anbieten, wird aber von keiner Software (außer Firefox...), die mir bekannt wäre, unterstützt. Selbst wenn librsvg und die Mediawiki-Software es unterstützen würden, bräuchte man also immer noch Endanwendersoftware wie Inkscape, die es *auch* unterstützt. --Benji 00:36, 10. Sep. 2008 (CEST)

Vorerst dann eben einsprachig. Da wir in der deutschsprachigen WP sind, mit der Aufschrift "Arzt" ;) --Vanger ^!–!? 06:06, 10. Sep. 2008 (CEST)

Das Mehrsprachenfeature wird auch von der Webkit- (Safari, Epiphany, Konqueror, uvm.) und Opera-Engine unterstützt, also von allen bis auf den IE. Bezüglich der Erstellung würde ich eh nen Texteditor emfehlen. Wäre schön, wenn Wikipedia endlich nativ SVG anzeigen würde, oder man das in den Optionen aktivieren könnte. --Ff-Sepp 11:14, 10. Sep. 2008 (CEST)

So sieht es jetzt aus: Bild:Beispiel-SVG.svg

Ich hab ein bisschen recherchiert und zum einen einen librsvg-Fork gefunden, der dieses systemLanguage/switch-Feature unterstützt [7]. Auch die MediaWiki-Integration wurde bereits diskutiert, vgl. commons:Commons:Village_pump/Archive/21#SVG_i18n. Kurzfristig wird das also erst mal nichts mit der Mehrsprachigkeit ;-)

Ich nahm mir mal die Freiheit, deinen Code leicht verändert als Public-Domain auf die Commons hochzuaden, Ff-Sepp. Jetzt steht der Einbindung in den Artikel eigentlich nichts mehr im Wege. --Benji 13:19, 10. Sep. 2008 (CEST)

...also hab ich sie gleich mal vollzogen :-) --Benji 13:26, 10. Sep. 2008 (CEST)

Das Beispieldokument sollte sich an den SVG-Standard halten. Bei diesem Bild [8] zeigt der Firefox statt dem Bild nur ein XML-Baum an, weil DOCTYPE, xmlns usw. fehlen. --Fomafix 13:38, 10. Sep. 2008 (CEST)

Oh, das hab ich vergessen. Danke für den Hinweis. --Benji 13:41, 10. Sep. 2008 (CEST)

SVG ist kein reines Vektorformat

...jedenfalls nicht ausschließlich. Verläufe, Animationen und Strukturen haben nichts mit Vektoren zu tun. SVG ist ein Mischformat und nicht nur deshalb wird es von CAD-Programmen nicht unterstützt. Der ganze Artikel ist eine Lobpreisung des Formats, was sich außerhalb der Wikipedia einfach nicht durchsetzt und von den Browsern auch nicht anständig umgesetzt wird. Das sollte auch deutlich im Artikel stehen und nicht nur "zwischen den Zeilen" - wie die Erwähnung der allseits bekannten Probleme und die Tatsache, daß SVG außerhalb des Dunstkreises der freien Software keine Bedeutung hat. --RalfR → DOG 2008 06:23, 10. Sep. 2008 (CEST)

Es gibt nur noch einen Browser, der SVG nicht unterstützt, den IE. Und wieso disqualifizieren Verläufe und Strukturen es als Vektorformat? --Ff-Sepp 10:58, 10. Sep. 2008 (CEST)

Sag mal, fängst du schon wieder mit deinem SVG-Bashing an? Es bringt nichts, wenn du immer neue Sachen gegen SVG an den Haaren herbei ziehst. -- net 11:48, 10. Sep. 2008 (CEST)

Ich habe konkrete Fakten angesprochen, warum steht das nicht im Artikel? Der IE unterstützt kein SVG. Wenn dazu extra Software installiert werden muß, sind das bevormundende Techniken, welche beispielsweise bei Weblinks in Artikeln zur Löschung führen. Das Format ist (im Gegensatz zu JPG, GIF usw.) mit Hausmitteln der Betriebssysteme nicht handhabbar. --RalfR → DOG 2008 13:25, 10. Sep. 2008 (CEST)

Du hast drei Fakten angesprochen: 1. „Verläufe, Animationen und Strukturen“ – beantworte dazu bitte Ff-Sepps Frage; 2. „Browserunterstützung“ – steht gleich im allerersten Absatz des Artikels. 3. „CAD-Programme“ – ist für SVG irrelevant und wurde schon besprochen. -- net 13:32, 10. Sep. 2008 (CEST)

1. siehe Vektorgrafik: Eine Vektorgrafik ist eine Computergrafik, die aus grafischen Primitiven wie Linien, Kreisen, Polygonen oder allgemeinen Kurven (Splines) zusammengesetzt ist. Verläufe usw. sind keine grafische Primitive, Bemaßungen eigentlich auch nicht und Beschriftungen nur, wenn die Schrift eine Vektorschrift ist.
2. Die Tabelle unten spricht was anderes als der einleitende Satz, die gelben und roten Bereiche sieht doch jeder. Lediglich Amaya und Opera 9 unterstützen vollständig, welchen Marktanteil die haben, brauchen wir nicht diskutieren. Und selbst wenn dort ein grünes Feld ist, treten immer wieder Probleme auf.
3. warum CAD-Programme bei Vektorgrafiken irrelevant sind, will mir nicht in den Sinn, sie sind doch die einzigen neben CNC, die reine Vektordaten verarbeiten --RalfR → DOG 2008 13:47, 10. Sep. 2008 (CEST)

1. siehe Vektorgrafik: Im Artikel steht schon in der Einleitung „Neben der Form und Position der Primitiven werden eventuell auch die Farbe, Strichstärke, diverse Füllmuster und weitere, das Aussehen bestimmende Daten, angegeben.“ Farbverläufe würde ich jetzt als Füllmuster betrachten, welches durch ein paar numerischen Werte beschrieben wird.
2. Ich verstehe nicht ganz was daran jetzt ein Problem ist. Es steht doch in Form eine Tabelle im Artikel. Was willst du denn jetzt eigentlich?
3. CAD-Programme benötigen halt andere Formate. Das Gebiet der Vektorgratik ist halt sehr vielfälltig. So dass es eben auch für jedes Anwendungsgebiet eigene optimierte Formate gibt.

--Thornard, ^Diskussion, 13:59, 10. Sep. 2008 (CEST)

Zu 1. sag ich nichts mehr, das ist wieder mal an den Haaren herbeigezogen. Zu 2. an der vollständige Unterstützung fehlen bei den meisten Browsern nur die Animationen. Alles andere geht und wenn doch etwas noch nicht umgesetzt ist, spricht das trotzdem nicht gegen SVG oder sein Potential. HTML und CSS werden heute auch noch von kaum einen Browser wirklich vollständig unterstützt und trotzdem haben sich diese Standards durchgesetzt. Zu 3. wurde schon alles gesagt. SVG wurde nicht für den Einsatz in CAD-Programmen entwickelt und entsprechend gibt es für Autodesk und Co. vermutlich auch keinen Grund, das mit zu unterstützen. Das spricht auch nicht gegen. -- net 14:33, 10. Sep. 2008 (CEST)

Zu 1.: Eine Vektorgrafik besteht aus mathematisch exakten Repräsentationen der grafischen Primitven bzw. der Inhalte. Den Verlauf, die Struktur etc. kann man auch alles z.B. als Vektor, Matrix o.ä. beschreiben, also einer mathematischen Repräsentation. Wenn dann innerhalb dieser Repräsentation ebenfalls nur mathematisch korrekte Inhalte, sprich: Vektoren, grafische Primitiven, Farben und ähnliches vorkommen, ist es eine Vektorgrafik. Ein Verlauf ist ja eine Interpolation zwischen zwei Punkten von zwei (oder mehr) Farbwerten. Man kann auch anstelle eines Verlaufes ganz ganz viele kleine, ausgerichtete Rechtecke/Pfade mit der passenden Farbe für den Verlauf machen. Dann ist es immernoch ein Farbverlauf, heißt aber nicht mehr so. --e-Malte 14:51, 10. Sep. 2008 (CEST)

Tabelle der Browserunterstützungen überarbeitet

Tag zusammen, ich habe die Tabelle der Browserunterstützungen überarbeitet. Folgende Gründe/Änderungen:

• Wie weiter oben gewünscht habe ich die Unterstützung nur durch ein Plugin ausgegliedert.
• Die Tabelle baut nun primär auf die Rendering-Engine auf, der Webbrowser ist grundsätzlich erst ein mal irrelevant - eine Ausnahme bildet Google Chrome, dieser setzt WebKit mit einer eigenen JS-Engine ein. Es wird nun immer ausschließlich der wichtigste Browser einer Rendering-Engine genannt (vgl. Acid (Browsertests)), dementsprechend sind SeaMonkey (vgl. Firefox 2.0) und Konqueror (vgl. Safari) rausgeflogen.
• "größtenteils" vs. "teilweise" entfernt, der Firefox wird nicht mit "größtenteils" besser hingestellt als bspw. Amaya.
• Alle nicht mehr offiziell unterstützten Browserversionen rausgeschmissen.
• Die Reihenfolge der Rendering-Engines ergibt sich aus der Unterstützung von SVG.
• Da durch das Aufräumen keine Unterschiede mehr zwischen den Betriebssystemen existierten, wurde diese ebenfalls rausgenommen.

--Vanger ^!–!? 15:34, 23. Sep. 2008 (CEST)

Grundsätzlich begrüße ich die Änderung. Allerdings sollte Konqueror wieder in die Liste rein, da der auf KHTML und nicht auf Webkit aufsetzt. Auch wenn Webkit von KHTML abgeleitet ist, fließen Änderungen nicht immer und nicht sofort in KHTML zurück. Dagegen würde ich Google Chrome rausnehmen. Erstens setzt der eben wirklich auf Webkit auf und zweitens ist die teilweise Unterstützung von SVG nicht mit Quellen belegt. Chrome sollte eigentlich genau wie Safari SVG vollständig unterstützen und wenn nicht, sollte man dazu schon mal einen Quelle angeben. -- net 16:33, 23. Sep. 2008 (CEST)

Gut, ich habe den Konqueror nun wieder rein genommen auch wenn ich weiterhin finde, dass sie doch irgendwie zusammen gehören... Aber gut, an so einer Kleinigkeit soll es doch nun wirklich nicht hängen ;) Google Chrome würde ich aufgrund der komplett eigenen JavaScript-Engine lieber drinnen lassen, mal ganz davon abgesehen was Google noch so (zukünftig) alles an WebKit für ihren Chrome modifiziert... Anzumerken sei jetzt mal noch dass die Quellen der jeweiligen Unterstützung für alle Browser fehlen, ich wüsste ehrlich gesagt auch nicht wie man die testen kann - gibt es da Tests? Wenn ja könnte ich alle Browser mal testen... --Vanger ^!–!? 20:39, 23. Sep. 2008 (CEST)

Hallo ich hätte da ein paar Fragen/Anmerkungen:

• Was bedeuted die Spalte 'scripting', das gehört auf jeden Fall irgendwo erwähnt, Das Adobe Plug-In (in IE 7) scheint die Scripte, die ich zum ausprobieren geschrieben habe eher zu akzeptieren als mein Opera und mein Firefox (siehe dazu auch s-v-g.net), wie ist das zu erklären?
• Die Beispiele sind zwar alle ganz schön und gut, viel praktischer wäre ein Beispiel zum einbinden von SVG-Grafiken in HTML-Dokumente, ähnlich denen bei selfsvg

Firefox und SVGZ

Hallo, wenn ich im Firefox (egal ob Version 2 oder 3) eine SVGZ-Datei anzeigen möchte, erscheint bei mir nur „Fehler: XML-Datei nicht wohlgeformt“ oder die Datei wird zum Download angeboten. Opera zeigt jedoch auch SVGZ-Dateien an. Ist das bei euch auch so? Wenn das bei jedem so ist, könnte man das auch in den Artikel einbauen. -- Tofra ^Diskussion _Beiträge 16:39, 13. Okt. 2008 (CEST)

Mein Firefox 3.0.3 öffnet die Datei erst gar nicht, sie wird schlicht nur zum Download angeboten. Das liegt vermutlich daran, weil der Firefox keine gzip-Unterstützung besitzt, das ist für den Artikel aber irrelevant, meines Wissens gehört die gzip-Komprimierung nicht zu den offiziellen SVG-Spezifikationen. --Vanger ^!–!? 16:54, 13. Okt. 2008 (CEST)

Das hier ist zwar eigentlich kein Support-Forum aber trotzdem hier mal ein Link zur Lösung des Problems (kein Fehler von Firefox). -- net 21:39, 13. Okt. 2008 (CEST)

svg und Zoomen

Wenn FF ein SVG in einem Artikel darstellt, wird das anscheinend von wiki skaliert und dann als png ausgeliefert. Das merkt man daran, dass wenn ich mir Seiten Artikel von FF zoomen lasse, die Schrift zwar scharf bleibt, die svgs aber ziemlich schnell unscharf werden. Wenn man die SVG-Datei dagegen direkt anzeigen laesst, kann ich dagegen zoomen soviel ich will. Wird daran schon gearbeitet?

--Gmeyer 20:36, 4. Dez. 2008 (CET)

Die SVG-Bilder werden von MediaWiki automatisch mit librsvg automatisch in ein PNG umgewandelt und in den Artikel als PNG angezeigt. Erst beim Aufruf der Datei über die Bildbeschreibungsseite gelangt man direkt zum SVG und nicht zum automatisch erstellten PNG-Pendanten, da du im Artikel nur den PNG-Pendanten angezeigt bekommst, wird das Bild beim Zoomen natürlich pixelig. Das Ganze ist notwendig weil einige Browser überhaupt kein SVG (besonders der Internet Explorer) oder noch nicht in XHTML integriert verstehen. --Vanger ^!–!? 20:42, 4. Dez. 2008 (CET)

Außer IE ist es mittlerweile nur noch Lynx, der kein SVG beherrscht ;-) Wenn IE also nicht dämliche 60-80% Marktanteile hätte, könnte man SVG längst inline einbetten und alle wären glücklich. --Manuel - (Diskussion) 09:51, 5. Dez. 2008 (CET)

Aber die viele Browser identifizieren sich doch, da koennte man dem FF doch das svg ausliefern. --Gmeyer 03:28, 14. Dez. 2008 (CET)

Das ist zwar prinzipiell wahr, aber die Seitendarstellung vom User Agent abhängig zu machen gehört eigentlich nicht zum guten Ton, vom Implementierungsaufwand in der Mediawiki einmal abgesehen. --Benji 14:57, 14. Dez. 2008 (CET)

Mag ja sein, aber warum muessen sich die "fortschrittlichen" Nutzer von den Nachzueglern ausbremsen lassen? --Gmeyer 12:26, 20. Dez. 2008 (CET)

War das nicht schon immer so? Die Verbreitung von (eingebettetem) SVG im Web ist nunmal gering, und ich persönlich fände es recht dumm, wenn die Wikipedia auf diese Technik setzt und damit einen Großteil der Leser frustriert. Die sind doch selbst dran schuld ist dann zwar sicherlich ein berechtigtes Argument, doch wenn einer ahnungslosen Mehrheit von Benutzern kannst du weder Vorwürfe machen, noch kannst du sie ignorieren. --Benji 23:11, 20. Dez. 2008 (CET)

Das mit der PNG-Vorschau ist IMO nachvollziebar. Aber daß man, um dann doch noch die SVG-Version zu Gesicht zu bekommen, einen weiteren PNG-Zwischenschritt bewältigen muß, halte ich (gerade hier) für einen Fehler: gerade die technisch eher unbedarften (und, damit meist einhergehend, nur Windows/IE kennenden) Anwender (gerne mal als „DAU“ bezeichnet) dürften überfordert sein. Die sich damit ergebenden Folgen, scheint mir, widersprechen den Intentionen, welche hinter einer Enzyklopädie stehen (sollten). --87.163.56.188 01:00, 2. Jul. 2009 (CEST)

Mit dem Konzept einer Enzyklpädie oder auch nur der Philosophie, die hinter ihr steckt, hat das m.E. gar nichts zu tun. Es handelt sich lediglich um eine technische Krücke. Das ist in der Tat für andere Dateiformate eleganter gelöst, beispielsweise OGG-Mediafiles, für die es diese Abspielextension gibt, die per JavaScript automatisch das beste Ausgabeformat für den Browser wählt. Aber die Diskussion um die beste technische Realisierung in der MediaWiki-Software (!) gehört auch nicht in die Diskussion in einer Enzyklopädie, die diese Software nutzt, über den Artikel, der das Dateiformat beschreibt. Ich bin dafür, weiteren Klärungsbedarf mindestens mal auf meta:SVG (siehe dort z.B. Links: meta:SVG whiteboard) oder am Besten gleich auf der Homepage der MediaWiki-Software, unter mw:SVG, zu decken. Viele Grüße, --Benji 01:42, 2. Jul. 2009 (CEST)

- 2009 -

Arzt Schild ?

Was soll dieses "riesen" Beispiel ? Es macht den ganzen Format kaputt. Und wieso ist es oben bei "Geschichte" eingebunden? Irgendwas stimmt da doch nicht... --WissensDürster 15:10, 14. Feb. 2009 (CET)

Das Beispiel rückt in den Absatz „Geschichte“, weil über dem Bild noch die Infobox hockt. Das Beispiel ist so breit, weil der darunter platzierte, zugehörige SVG-Quelltext in der breite ansehnlich darstellbar ist. Bei mir wird übrigend das Layout nicht zerschossen (bei einer Auflösung von 1280x1024). Welche Auflösung hast Du denn, dass das bei Dir Probleme verursacht? Wenn Du Ideen hast, wie ein besseres Beispiel aussehen kann oder wie dieses Beispiel besser platziert werden kann, schreib sie mal hier auf. Ich finde das Beispiel auch durchaus noch ausbaufähig. Gruß, norro ^wdw 15:16, 14. Feb. 2009 (CET)

Ich nutze 1024, und das tun sicher die meisten. Aber darum geht es glaub ich nicht. Auch auf einem Widescreen-Bildschirm würde ich das Beispiel unter der Infobox und halb in der Geschichte drin sehen. Und ich verstehe immer noch nicht warum. Das Beispiel vom Inhalt mag ok sein. Es ist doch nur so, dass es nach unten müsste, und da gibt es ja auch schon eins. Eben unter "Elemente" 4.6. Beispiel - zack. Da ist es viel passender. Also wenn niemand was dagegen hat, sollte das Beispiel einfach da unten eingereiht werden. Das wäre alles. --WissensDürster 19:37, 15. Feb. 2009 (CET)

unten einreihen – ja, aber nicht unter 4.6 Polylinie, sondern – um Mehrsprachigkeit ergänzt – unter 4.8 Text. (Die Mehrsprachigkeit ist das für die Verwendung in Wikimedia wesentliche SVG-Merkmal.) Den Code linksbündig, das Ergebnis rechts. Der dort vorhandene Code-Schnipsel kann dann weg. Ich muss jetzt arbeiten. – Rainald62 08:44, 16. Feb. 2009 (CET)

Wunderbar, wenn es jemand fachlich korrekt einordnen kann. Ich kenn mich da nicht genug aus. Aber das klingt schonmal gut. Entweder es macht einer, oder ich versuch's heute Abend. Grüße --WissensDürster 09:06, 16. Feb. 2009 (CET)

So - Abend. Hatte deine Idee mit der Mehrsprachigkeit überlesen. Dazu kann ich leider nicht sagen. Und offenbar kann ich es auch nicht weglassen. Und weil darüber hinaus, das Beispiel nicht lebensnotwenig ist nehme ich es erstmal raus und packs hier rein. Aus Protest wird man oft schneller aktiv - nicht bös gemeint =)

Ein Erste-Hilfe-Schild als SVG. Der komplette Quelltext: <?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd"> <svg width="400" height="400" xmlns="http://www.w3.org/2000/svg"> <title>SVG</title> <style type="text/css"><![CDATA[ text {font-size:60px; text-anchor:middle;} ]]></style> <rect x="0" y="0" height="400" width="400" fill="white" stroke="blue" stroke-width="100" /> <rect x="160" y="80" width="80" height="240" fill="red" /> <rect x="80" y="160" width="240" height="80" fill="red" /> <text x="200" y="220">Arzt</text> </svg>

Also, wenn sich jemand auskennt, das bitte unter 4.7.Mehrsprachigkeit (was auch immer das ist), nach 4.8 als Beispiel zu packen. --WissensDürster 23:04, 16. Feb. 2009 (CET)

4.6? 4.7? 4.8? – sorry, ich hatte dein "Elemente" 4.6   als   Primitive 4.1.6 Polylinie interpretiert und dann aus 4.6   4.8 gemacht, statt 4.1.8. Jedenfalls gehört das Arzt-Schild (wenn überhaupt – ich hatte es dringelassen, weil der Autor vllt noch dran hängt) nach 4.1.8 Text, denn Mehrsprachigkeit macht nur für Text Sinn. Die Mehrsprachigkeit ist dort auch schon erklärt, auch mit Code-Fragment (viel Spaß beim Basteln). – Rainald62 17:03, 24. Feb. 2009 (CET)

svg.org nicht erreichbar

Steht unter Weblinks, ist aber nicht erreichbar. DNS Auflösung klapp, ping dagegen nicht. Als ich vor ein paar Tagen dort hinwollte war's auch schon so. Ich finde der Verweiß sollte aus den Weblinks herausgenommen werden, zumindest bis er wieder erreichbar ist. Gruß --Gorp 00:40, 1. Mär. 2009 (CET)

Sei mutig und entfern es halt. Es ist zwar meines Erachtens ein sehr wichtiger Weblink, aber wenn er nunmal nicht geht... Wär schön, wenn du ihn wieder einstellen könntest, falls er irgendwann mal wieder geht. --Benji 01:04, 1. Mär. 2009 (CET)

Google hat die letzte Version vom 24. Februar 2009 im Cache. Die Seite ist also erst seit kurzem nicht erreichbar. Warte bitte noch ein paar Tage mit dem Entfernen, da es sich vermutlich nur um ein vorübergehendes Problem handelt. -- net 01:11, 1. Mär. 2009 (CET)

Genau, ich war neulich noch drauf - und so unwichtig wäre die Seite zu dem Thema nicht. Grüße --WissensDürster 20:59, 1. Mär. 2009 (CET)

Hier muss ausgemistet werden!

Was sollen denn die ganzen Scriptbeispiele bei den Grundformen? Das ist nun wirklich überflüssig. Der Artikel ist so schon viel zu lang. Reicht es nicht, die darstellbaren Grundkörper aufzuzählen? Selbst wer tiefer in die Materie einsteigt, wird kaum selbst per Hand eine SVG-Datei schreiben. Die Codebeispiele sind somit überflüssig und nur für eine Hand voll Leute (Programmierer von Grafikprogrammen usw.) interessant. Und diese Leute holen sich ihre Informationen sicher nicht aus der Wikipedia. 139.20.53.46 11:05, 2. Apr. 2009 (CEST)

Wer sagt, dass kaum jemand SVGs manuell erstellt? ich mache dass durchaus, wenn ich etwas exaktes haben will und finde die Auflistung hier sehr nützlich. Falls du mich jetzt als Programmierer betrachtest, muss ich dich enttäuschen, diesen Titel kann ich mir (noch) nicht anmaßen. Es ist einfach so, dass selbstgeschriebene Graphiken beliebig genau sind (bei einem Zeitstrahl kann ich beispielsweise ein Ereignis auf den Tag genau markieren, auch wenn selbiger nur einige cm lang ist und mehrere Jahre darstellt); dass lässt sich prinzipiell zwar auch mit Inkscape und ähnlichen Programmen machen, ist aber deutlich aufwendiger. Außerdem: wer sagt, dass sich Programmierer ihre Infos nicht aus der WP holen? Selbige wird mittlerweile recht häufig vor Gericht zitiert; wobei du wahrscheinlich insofern recht hast, dass die das Zeug meist auf der Uni gelernt haben dürften, wodurch sie es nicht nötig haben. MfG, --Dr. Al. K. Lisch ?!  +/- 19:17, 10. Jul. 2009 (CEST)

Full ACK. --Benji 02:32, 12. Jul. 2009 (CEST)

Ziel: Lesenswert

Hallo.

Seit einiger Zeit beachte ich mit etwas Enttäuschung, dass an dem Artikel schon soviel gearbeitet wurde und soviel Inhalt zugefügt wurde, er aber nicht als lesenswert ausgezeichnet ist und von der Auszeichnung auch noch ein gutes Stück entfernt ist. Da ich mit SVG recht firm bin und jetzt etwas Zeit habe, plane ich, den Artikeln in den nächsten Tagen so zu überarbeiten, dass er das Bapperl erhalten kann.

Ich kündige dies an, weil einige Abschnitte dabei anders gewichtet werden müssen und ich eine etwas andere Struktur vorschlage. Hier meine Vorschläge:

1. Die Elemente der Grafik müssen in ihrem Umfang im Artikel reduziert werden
   1. Die grafischen Primitive in einem Absatz zusammengefasst, Codebeispiele in größten Teilen raus, gemäß WP:WWNI#9
   2. Analog einzelne Abschnitte zu Scripting, Animation und grafischen Effekten (jeweils ein Abschnitt)
2. Die Unterstützung von SVG in Software und Browsern hat in meinen Augen auch einen zu großen Anteil am Artikel. Dies ist schon irgendwie interessant für diejenigen, die mit Interesse beobachten, ob und wie sich dieser Standard durchsetzt, ist aber für das allgemeine Verständnis der Thematik nicht in der Form relevant, wie es aktuell Platz im Artikel einnimmt. Hier ggf. auch etwas kürzen, das weiß ich aber noch nicht so genau.
3. Bevor der Geschichtsartikel kommt, sollte erst ein allgemeiner Abschnitt zu Struktur, Inhalt, Vor- und Nachteilen kommen.
4. Abschnitt zu Koordinatensystem- und angaben ist auch zu lang und berührt schon wieder die Grenze von WP:WWNI#9. Hier würde ich auch etwas kürzen.
5. Struktur. Die Artikelstruktur stelle ich mir demnach wie folgt vor:

SVG
- Allgemein
- - Profile
- Geschichte
- Dokument
- - Struktur
- - Koordinatensystem
- - Elemente
- - - Grafische Primitive
- - - Grafische Effekte
- - - Animation
- - - Scripting
- Verbreitung
- - Unterstützung in Software
- - Unterstützung in Browsern
- Konferenzen
- Logo
- Literatur
- Weblinks
- Einzelnachweise

So erhielte der Artikel auch eine etwas logischere Struktur. Meinungen dazu? Ich werde in Kürze beginnen. Gruß, norro ^wdw 14:24, 5. Aug. 2009 (CEST)

Meinerseits keinerlei Einwände gegen deine Vorschläge, werde in jedem Fall über deine Änderungen rüberschauen und ggf. korrigieren. Ich würde nach deiner generellen Überarbeitung vermutlich aber erst ein mal noch vor die KLA ein Review schieben, wenn das erfolgreich verläuft direkt hinterher die KLA. --Vanger ^!–!? 15:35, 5. Aug. 2009 (CEST)

Stimmt. Das sollte man machen. Gute Idee. Gruß, norro ^wdw 16:32, 5. Aug. 2009 (CEST)

So, die Struktur habe ich nun entsprechend angepasst, sieht für mich schon deutlich besser aus. Die grafischen Elemente habe ich etwas verdichtet. Folgendes steht jetzt noch an:

1. Abschnitt „Verbreitung“ ist noch etwas hässlich, da zwischen den Überschriften bislang noch kein Text steht. Dort stelle ich mir Angaben zur tatsächlichen Verbreitung von SVG vor.
2. Mir ist aufgefallen, dass im Moment noch Transformationen und Clipping fehlen.
3. Das Beispiel habe ich erstmal im Artikel belassen, bin mir aber nicht wirklich sicher, ob es tatsächlich zum Verständnis beiträgt.

Außerdem allgemeine Überarbeitung und Glättung des Textes. Gruß, norro ^wdw 16:27, 8. Aug. 2009 (CEST)

So, das Dickste ist getan, ich stelle den Artikel mal ins Review. Für Anmerkungen bin ich dankbar. Gruß, norro ^wdw 09:56, 28. Aug. 2009 (CEST)

Review vom 28. August 2009

(übernommen von [9])

Der Artikel liegt seit Monaten mit viel Inhalt aber etwas ausgewuchert und unstrukturiert in der Wikipedia rum. Ich habe deshalb in den letzten Wochen dem Artikel versucht, etwas Struktur und Schliff zu verpassen, damitz er die Lesenswert-Hürde nehmen kann. Ich würde mich über Anmerkungen freuen, was vielleicht noch fehlt/ungereimt ist/verbessert werden sollte/kann. Danke und Gruß, norro ^wdw 10:06, 28. Aug. 2009 (CEST)

Die Einleitung und der Abschnitt "Allgemein" lesen sich sehr holprig. Die Einleitung sollte sich nicht nur darauf beschränken, welche Browser wie SVG unterstützen. "Syntax" besser ohne Artikel. "kann von den meistverwendeten Webbrowsern, mit Ausnahme des Internet Explorer" ist ein bisschen Paradox. Die Überschrift "Allgemein" ist ein bisschen unglücklich und wirkt eher ein Sammelsurium an Infos, die besser woanders stehen sollten. Die Logik von "Sie sind abwärtskompatibel, da manche Elemente nicht implementiert sind." erschließt sich mir nicht. Das wäre ein Grund gegen Aufwärtskompatibilität, aber nicht für Abwärtskomp. Das technische Zeug weiter unten ist dagegen gut geschrieben. Konzentriere dich also erstmal auf die ersten beiden Abschnitte. -- Jonathan Haas 11:37, 28. Aug. 2009 (CEST)

• Einleitung: "Beim Internet Explorer ist die Darstellung durch ein Plug-in wie den SVG-Viewer von Adobe möglich."

  Sollte raus, der Adobe SVG-Viewer ist bei weitem nicht die einzige Möglichkeit zur Darstellung von SVG im IE. Abgesehen davon steht's ja schon weiter unten im Unterstützungs-Abschnitt.

• Abschnitt "Allgemein":
  • "Die empfohlene Dateiendung ist .svg oder, wenn die Datei mit gzip komprimiert ist, .svgz. Der MIME-Typ ist image/svg+xml."

    Kann raus, die Informationen stehen bereits in der Infobox und müssen nicht unbedingt noch einmal wiederholt werden.

  • Die Unterschiede zwischen SVGF, SVGB und SVGT detaillierter ausarbeiten. Wenn man der englischen Sprache mächtig ist versteht man dass "Tiny" der kleinste gemeinsame Nenner ist und "Full" die Komplettausführung - ohne Englischkenntnisse wird es aber schwierig das zweifelsfrei zu verstehen.
  • Es wird sowohl zu Beginn des Abschnitts "Allgemein" als auch beim Abschnitt "Dokument" darauf eingegangen dass SVG auf XML basiert - das kann man zusammenfassen.
• Die Grafiken im Abschnitt "Dokument" rutschen bei größeren Thumbnails zusammen; will heißen: Der Kreis steht bei mir auf Höhe der der Linie. Lösen lässt sich das indem man auf eine der beiden Koordinaten-Grafiken verzichtet oder die SVG-Beispielgrafik in einen anderen Abschnitt auslagert - zum Beispiel nach "Allgemein" sofern dieser Abschnitt weiterbestehen sollte. Alternativ könnte man eine der größeren oder die Elemente-Beispielgrafiken linksbündig anordnen.
• Das Scripting-Beispiel ist in meinen Augen wenig sinnvoll, wenn ein Beispiel im Artikel vorkommt ist es notwendig dem Leser auch bekannt zu machen wie das Ganze dann aussieht - so wie beim Beispiel des Potenziometers. Das Beispiel entweder entfernen oder eine animierte Grafik einfügen auf der man erkennen kann wie das Ganze dann mit der Mausbewegung interagiert.
• Abschnitt "Verbreitung":
  • "Viele Desktop-Umgebungen benutzen zunehmend SVG" und zwei Sätze weiter: "Generell ist zu bemerken, dass viele Betriebssysteme auf ihren grafischen Benutzeroberflächen vermehrt Vektorgrafiken benutzen"
  • Bei der Programmauflistung aus dem "frei" ein "freie Software" mit einmaliger Verlinkung zum entsprechenden Artikel machen. Nicht jeder wird sofort wissen was mit "frei" gemeint sein soll.
  • "Browser-Erweiterungspack": ??
  • Die Unterstützung mittels Adobe SVG Viewer wird bereits im Text erläutert, die Spalte kann dem entsprechend aus der Tabelle raus. Abgesehen davon gibt es, wie bereits weiter oben geschrieben, verschiedene Möglichkeiten SVG auch im IE zu verwenden.

Ansonsten schließe ich mich Jonathan Haas an. Gute Arbeit, der Artikel ist auf einem sehr guten Weg! :-) --Vanger ^!–!? 13:47, 28. Aug. 2009 (CEST)

Ich danke euch für die Anmerkungen. Ich habe sie umgesetzt udn außerdem die Grafiken noch etwas aufgeräumt. Ich warte noch ein paar Tage, dann gehts zu WP:KALP. Gruß, norro ^wdw 14:08, 29. Aug. 2009 (CEST)

Ich denke, für eine Auszeichnung müsste noch etwas mehr "Außensicht" in den Artikel: Vergleich mit anderen Vektorgrafik-Formaten, Vor- und Nachteile, Kritik usw.--91.13.168.199 13:22, 30. Aug. 2009 (CEST)

Jetzt habe ich den Artikel nochmal etwas genauer gelesen. Dabei sind mir außerdem noch folgende konkrete Punkte aufgefallen:

• Der Satz mit dem IE sollte auch meiner Meinung nach aus der Einleitung raus. Dafür lieber noch etwas Allgemeines zur Bedeutung/Verbreitung.
• Die Überschrift Allgemein ist mir zu allgemein. Vielleicht kann man das, was dort steht, auch irgendwo anders einbauen.
• Geschichte ist mir noch etwas zu knapp. Wie bzw. wie stark unterscheiden sich die Versionen? Wie sieht es mit der Kompatibilität der Versionen aus?
• Beim Koordinatensystem verstehe ich nicht ganz, wie das mit den Einheiten läuft. Im Artikel steht ein Pixel als Einheit, aber passt das zu den Millimetern von width und height? Oder sind die Einheiten egal, wegen skalierbar?
• Bei der Abbildung zum Koordinatensystem sollten die Koordinaten dann auch wirklich an den Pixelgrenzen stehen.
• Bei den Elementen hätte ich gerne noch etwas zum Füllen von Pfaden gelesen.
• Animation finde ich ziemlich schwer verständlich und unanschaulich. Ich denke hier wäre ein kurzes Beispiel hilfreich.
• Bei Verbreitung wäre doch vor allem die Verbreitung auf Webseiten interessant und wie sich die entwickelt.
• Warum ist die Browsertabelle so aufgeteilt? Ich hätte eine Aufteilung nach tiny/basic/full bzw. Version 1.0/1.1/1.2 erwartet.
• Der Abschnitt Konferenzen ist unklar, was der überhaupt dem Leser sagen will. Wenn's wichtig ist, kann das nicht zu Geschichte?
• Logo sollte vielleicht weiter nach vorne.

Ich hoffe, meine Anmerkungen helfen den Artikel zu verbessern.--91.13.254.185 18:17, 1. Sep. 2009 (CEST)

Ich danke Dir, für Deine Anmerkunegn. Die Wahl der Einheiten ist tatsächlich weitestgehend frei, es gibt mehrere verschiedene Möglichkeiten. Werde ich noch in den Artikel einbauen. Ob ich etwas zur Verbreitung auf Websites und dessen Entwicklung finde, weiß ich nicht, werd ich versuchen. Beispiel für die Animationen ist schwierig, weil diese Animationen hier in der Wikipedia nicht dargestellt werden können. Ich werde aber versuchen, eien anschauliche Grafik herzustellen. Nochmals danke, norro ^wdw 12:43, 3. Sep. 2009 (CEST)

Ich habe Deine Anmerkungen in weiten Teilen umgesetzt, habe sogar den Abschnitt zu den Animationen durch eine Grafik zu veranschaulichen versucht. Einige der Punkte bzgl. Erweiterung gehe ich noch nicht an, weil das Ziel erstmal nur die Lesenswert-Auszeichnung ist, merke sie mir aber für später. Gruß, norro ^wdw 14:25, 3. Sep. 2009 (CEST)

Diskussion im Zuge der Kandidatur

Wie schon bei der Kandidatur, etwas unverständlich, gesagt habe: Die Browser-Unterstützungs-Tabelle bereitet mir Kopfzerbrechen. Woher stammen die Bewertungen vollständig, teilweise und keine Unterstützung? Ich nahm an die Daten stammen von hier, da dieser Link der einzige ist der etwas in diese Richtung aussagt. Dort werden Daten zur Browser- und Pluginunterstützung für SVG angegeben. Was mir nicht klar ist ist der Zusammenhang der Daten dieser Seite mit denen in der Tabelle. Einige Vergleiche:

• Konqueror 4.1 -> 29% -> "vollständig"
• Firefox 3.0 -> 60% -> "vollständig"
• Chrome Beta -> 81% -> "teilweise"
• Safari 4 -> 82% -> "vollständig"

Die Angaben sind leider ohne Quelle und stimmen mit dem einzigen, von mir als mögliche Quelle gedeuteten, Weblink nicht überein. Mir ist deshalb bisher nicht klar geworden was diese "Bewertungen" genau aussagen. Ich hoffe so ist es Verständlicher was ich genau meine ;) --AleXXw •שלום!•disk 00:45, 4. Sep. 2009 (CEST)

Okay, jetzt hab ichs verstanden. Also: Ich glaube nicht, dass die genannte Website Quelle für die hiesige Tabelle ist. Ich werde das aber recherchieren, auch um Quellen für die Tabelle angeben zu können. Zudem handelt es sich auf der verlinkten Seite um Tests. Hier ist also angegeben, wieviel Prozent der Tests bei den unterschiedlichen Browsern erfolgreich verlaufen, nicht wieviel % des SVG-Standards unterstützt wird. Das muss nicht das gleiche sein und kann sogar massiv unterschiedlich sein. Einzelne Tests können zum Beispiel mehrere Dinge kombiniert testen, andere Aspekte können gänzlich ungetestet sein. Laut Angabe auf der Website handelt es sich bei den Tests um die W3C-Test-Suite. Ich werde mir das einmal anschauen. Soweit ich sehe, ordnet sie verlintke Seite die Unterstützung auch nicht einzelnen Aspekten (Grundformen, Animation, Scripting) zu, wie es die Tabelle im hiesigen Artikel versucht.

Die Problematik lässt sich aber wohl ohnehin am besten lösen, wenn ich Belege für die Tabelle finden und angeben kann. Ich werde das versuchen. Danke für den Hinweis. Gruß, norro ^wdw 01:11, 4. Sep. 2009 (CEST)

Da sich das Ganze nun schon etwas hinzieht und die KLA ja eigentlich schon in Kürze ausläuft: Wie wäre es wenn wir die Ergebnisse des offiziellen SVG-Tests heranziehen, uns für die Farbgebung an den dortigen "Noten" orientieren (A = grün; C = gelb; F = rot) und alle vom Hersteller noch offiziell unterstützten Entwicklungszweige auflisten? Von den Vorschauversionen zu den finalen Versionen dürfte sich an den Ergebnissen eigentlich nichts verändert haben... Blöderweiße sind die Daten halt ziemlich alt auf dieser Seite. Hoffe dass du was besseres findest...

Rendering-Engine	Webbrowser	Unterstützung
Presto	Opera 10.0	93,98 %
WebKit	Safari 4.0	81,93 %
	Google Chrome 2.0	81,39 %
Gecko	Mozilla Firefox 3.5	60,40 %
	Mozilla Firefox 3.0	60,40 %
KHTML	Konqueror 4.2	29,64 %
Trident	Internet Explorer	keine

--Vanger ^!–!? 15:17, 10. Sep. 2009 (CEST)

Die Idee finde ich gut. Ich hatte darüber nachgedacht, die Tabelle ganz einzustampfen, weil ich auch in der Artikelhistorie keine Quellen dafür gefunden habe. Aber so bleibt es übersichtlich und ist belegbar. Willst Du es einfügen? Dann ist es lizenzrechtlich genauer. Gruß, norro ^wdw 15:25, 10. Sep. 2009 (CEST)

Ist es nicht so, dass die Testergebnisse für Internet Explorer ohne Unterstützung durch die Trident-Engine zustande gekommen sind und die Zeile für IE in obiger Tabelle damit irreführend wäre ? --Zipferlak 16:02, 10. Sep. 2009 (CEST)

Genau genommen hat die Unterstützung eigentlich bei keinem der Browser etwas mit dem Browser selbst zu tun sondern nur mit deren Rendering-Engine. Chrome 2.0 beispielsweise hat eine schlechtere SVG-Unterstützung als Safari 4.0 weil Google eine etwas ältere WebKit-Version einsetzt als Apple. Nur verstehen die wenigsten Leser den technischen Unterschied zwischen Rendering-Engine und Browser... Habe die Tabelle nun mal in den Artikel aufgenommen, eine bessere Quelle wäre mir aber dennoch lieber... --Vanger ^!–!? 16:17, 10. Sep. 2009 (CEST)

Die Tabelle ist deutlich besser als die alte. Gratulation allen Exzellenz-Autoren, der Artikel sieht mittlerweile echt toll aus! --Benji 01:04, 11. Sep. 2009 (CEST)

Website svg.org

Wer ist das, und wie kann sie einen Wettbewerb (Logo) ins Leben rufen ? Wer legt fest, dass das abgebildete Logo verwendet werden soll ? --Zipferlak 02:13, 10. Sep. 2009 (CEST)

svg.org leitet auf planetsvg.com weiter, diese Seite besteht aus einer Planet-Installation und einem Forum. Ich nehme an, dass die Seite von Interessenten betrieben wird, die Interesse am SVG-Format haben. Meines Wissens haben diese Interessenten mit ihrem Logo-Wettbewerb ein Logo vorgeschlagen. Von einem offiziellen Logo kann natürlich nicht die Rede sein (wer soll das denn mit welcher Legitimation auch vorschreiben?), aber da sich unter den Interessenten eben auch namenhafte Firmen befinden (siehe Artikel), findet das Logo nun eben auf breiter Linie Verwendung. --Benji 00:51, 11. Sep. 2009 (CEST)

Hmm, das glaube ich ja alles; dennoch fände ich einen Einzelnachweis wünschenswert, der die im Logo-Abschnitt stehenden Informationen belegt. --Zipferlak 02:12, 11. Sep. 2009 (CEST)

SVG Open

Wer organisiert und finanziert die SVG Open ? --Zipferlak 02:15, 10. Sep. 2009 (CEST)

Von [10]: Opera und SlipperyRock University sponsern die SVG Open 2009 mit zusammen 2000$. [11] listet dir die Preise zur Teilnahme auf. Zur Organisation siehe die Auflistung deren Kommitees. Noch Fragen? ;-) --Benji 00:59, 11. Sep. 2009 (CEST)

Danke für die exzellenten Antworten ! --Zipferlak 01:51, 11. Sep. 2009 (CEST)

Kandidatur Scalable Vector Graphics

Scalable Vector Graphics (SVG, deutsch skalierbare Vektorgrafiken) ist ein Standard zur Beschreibung zweidimensionaler Vektorgrafiken in der XML-Syntax. SVG wurde im September 2001 vom W3C als Empfehlung veröffentlicht und ein Großteil des Sprachumfangs kann von den meisten der gebräuchlichen Webbrowser ohne nachträgliche Installation von Erweiterungen dargestellt werden.

Der Artikel lag seit langer Zeit mit viel Inhalt aber wenig Struktur, sowie einigen ausufernden Abschnitten in der Wikipedia herum. Ich habe daher in den letzten Wochen den Artikel inhaltlich und strukturell massiv überarbeitet. Der Artikel hat nun zusätzlich einen Review hinter sich ist meines Erachtens ein lesenswerter Artikel. Als Hauptautor stimme ich gemäß hiesigen Gepflogenheiten nicht mit ab.

Zur Info: Wir haben inzwischen den 3. September.--Thmsfrst 14:45, 3. Sep. 2009 (CEST)

Ups. Danke :) norro ^wdw 15:08, 3. Sep. 2009 (CEST)

Klar  Lesenswert mit der Option zur Exzellenz; auch wenn mir leider keine konkreten Vorschläge dafür einfallen... --Vanger ^!–!? 15:47, 3. Sep. 2009 (CEST)

Ein, zwei Punkte habe ich für Exzellenz noch auf dem Schirm, auch aus dem Review. Die folgen dann in einer weiteren Ausbaustufe. Gruß, norro ^wdw 17:12, 3. Sep. 2009 (CEST)

•  Unklar: Die Browser-Tabelle bereitet mir etwas Kopfzerbrechen. Ich nehme an die Daten stammen von hier. Wie kommt es dass Firefox 3.0 mit 60% als vollständig angegeben unterstützend angegeben wird, Chrome Beta mit 81% aber nur mit teilweise? Ebenso Konqueror 4.1, der in der Tabelle gar nicht auftaucht sondern nur 4.2, wird mit 29% als vollständig unterstützend angegeben... Ich bitte um Aufklärung bzw Quellenangabe, vielleicht denke ich ja nur zu kompliziert... Sonst sieht der Artikel recht solide aus. --AleXXw •שלום!•disk 19:28, 3. Sep. 2009 (CEST)

  Hmmm, ich verstehe Deinen Hinweis noch nicht ganz. Woher kommen die von Dir angegebenen Prozentangaben (60%, 81%, ...)? Entnimmst Du diese dem Artikel? Antwort gerne auf der Artikeldiskussionsseite. Gruß, norro ^wdw 00:27, 4. Sep. 2009 (CEST)

  Die Tabelle ist jetzt überarbeitet und belegt. Gruß, norro ^wdw 16:40, 10. Sep. 2009 (CEST)

  Sehr gut. Meine restliche Meinung zum Artikel bleibt gleich: Solide, keine schweren Fehler zu finden ->  Lesenswert --AleXXw •שלום!•disk 07:46, 11. Sep. 2009 (CEST)

•  Lesenswert : sehr informativ aber oft auch etwas minimalistisch und trocken (ok zu dem Thema kann man nicht omasicher schreiben) zum exzellenten fehlt mir eine Übersicht über die Plugins, etwas mehr zu Animationen, ist PGML in SVG aufgegangen? - VML ja wohl nicht - die prinzipiellen Unterschiede zu VML, etwas mehr über Tools insbesondere Editoren, Verbreitung (insb. im Vergleich mit VML) Einsatzmöglichkeiten abseits des Webs etc. --HelgeRieder 20:48, 3. Sep. 2009 (CEST)

Danke für die Hinweise. Ich nehme es mit auf. Gruß, norro ^wdw 21:23, 3. Sep. 2009 (CEST)

• Abwartend Ich habe den Artikel bis jetzt nur überfliegen können, aber mir fehlt ein Hinweis der SVG-Nutzung bei Wikipedia und ein Hinweis auf die Umrechnung in PNG-Dateien. Auch ein Vergleich (z.B. Vorteile) mit anderen Vektorgrafikformaten wie WMF, PDF und etc. wäre meiner Meinung nach wünschenswert. --Salino01 23:16, 3. Sep. 2009 (CEST)

  Das sind Punkte, die ich durchaus noch für einen Ausbau des Artikels auf dem Radar habe (nicht den Wikipedia-Bezug, Selbstreferenzen mag ich nicht so gerne), aber das sind Randbereiche und daher m. E. für den Lesenswert-Status noch unerheblich. Gruß, norro ^wdw 00:22, 4. Sep. 2009 (CEST)

•  Abwartend Ich sehe in dem Artikel noch folgende Lücke: Eine der in der Praxis wichtigsten Anwendungen des Formates ist doch die dynamische Erstellung des XMLs aus einer Programmiersprache (häufig PHP) heraus, beispielsweise bei der Drstellung von Text als Grafik, etwa zur Anzeige von emailadressen im Web oder bei Captchas. Diese Anwendungsmöglichkeit, die einen signifikanten Beitrag zum Siegeszug dieses Formats geleistet hat, sollte umbedingt erwähnt werden, sonst ist das Lückenhaft. Abgesehen davon finde ich den Artikel sehr gut. --Jeses 00:41, 4. Sep. 2009 (CEST)

• Was mir als mit einem gewissen Hintergrund an Vorwissen als Bildschirm-Junkie auffällt:

• Im Abschnitt fehlt jegliche Vorgeschichte und Motivation für die Installation des Standards.
• Gründe für die Ablehnung von VML und PGML durch das W3CD fehlen.
• Es fehlen Aussagen darüber, welche Aspekte von VML und PGML in SVG übernommen wurden.
• Es fehlt die Tatsache, dass SVG auch als Alternative zu flash gedacht ist.
• Dazu gehört natürlich auch die Feststellung, dass dieser Teil mangels konsistenter Unterstützung der wichtigsten Browser derzeit nicht annähernd erreicht wird.
• Es fehlen Aussagen dazu, warum die Unterstützung des Standards so aufwendig ist, dass jedes Browserprojekt längere Zeit gebraucht hat, um den Standard wenigstens für statische Bilder halbwegs brauchbar zu unterstützen.
• Es fehlt ein Verweis auf den acid2-test für die statischen SVG-Elementem von http://www.webstandards.org . Noch 2005 waren die Ergebnisse für die gebräuchlichen WWW-Browser eher ernüchternd. Lange Zeit war "foobar passes SVG test" eine Pressemeldung wert, die durch die Blogosphäre ging -- Einschließlich hämischer Kommentare, wenn dies nur mit speziellem Tuning möglich war.
• Dass Microsoft sich weigern würde, SVG zu unterstützen, halte ich für ein Gerücht. In diesem MS-Blog von Weihnachten 2007 wird stolz verkündet, dass der IE den acid2 test besteht.

Insgesamt sind mir diese Lücken zu groß, als dass es für ein lesenswert reichen würde. Gerade die geschichtlichen Aspekte und die Hintergrund-Information wären Aufgabe eines Lexikonartikels. Die Falschinformation zu Microsoft ist ein Showstopper. Daher  keine Auszeichnung-<(kmk)>- 03:49, 6. Sep. 2009 (CEST)

Moin, acid2 enthält keine SVG-Tests, die sind erst bei acid3 mit drin. (Siehe etwa hier.) Viele Grüße, —mnh·∇· 03:55, 6. Sep. 2009 (CEST)

Örks. Da habe ich offensichtlich etwas fett falsch verstanden und mir dann flacsh gemerkt. Soviel zu meinem gewissen Vorwissen ---> Ich streiche die entsprechenden Bemerkungen.---<(kmk)>- 06:37, 6. Sep. 2009 (CEST)

Hallo kmk, danke für die Anmerkungen. Ich werde noch versuchen, den Standard zu motivieren. Wieweit ich da wirklich auf PGML und VML eingehen werde, weiß ich noch nicht. Die Aspekte aus VML und PGML, die in SVG eingegangen sind, zu erwähnen, entfernt sich dabei in meinen Augen zu weit vom Artikel. Vielleicht lassen sich dazu ja grundlegende Aussagen treffen, ich werde mal nachsehen. Dass SVG als Alternative zu Flash gedacht ist, habe ich noch nie gehört, sondern eher Gegenteiliges. Hast Du da Quellen, auf die Du mich verweisen kannst? Gruß, norro ^wdw 13:07, 10. Sep. 2009 (CEST)

Klar  Lesenswert aber es fehlen die aktuellen Versionen einiger Browser (Opera 10.0 und Firefox 3.5) in der Implementationtabelle.--Mirko Junge 09:21, 6. Sep. 2009 (CEST)

• Müsste es nicht im Deutschen "Norm" und "Normung" heißen und nicht "Standard" und "Standardisierung".
• Bei einigen Formulierungen, die geradezu danach schreien, fehlen Einzelbelege ("Es wird gelegentlich empfohlen,..").
• Ist "ist ein Standard" ein guter Definitionssatz (unabhängig mal von der Norm/Standard-Frage). "ist ein Dateiformat" hätte ich natürlicher gefunden.
• "Es gibt jedoch auch spezielle Programme zur Bearbeitung" klingt komisch. Als ob SVG-Dateien hauptsächlich mit dem Texteditor erzeigt werden.

--Pjacobi 22:02, 6. Sep. 2009 (CEST)

•  keine Auszeichnung Der Artikel enthält an entscheidenden Stellen Formulierungen, die Fehlinterpretationen herausfordern.
  1. Es wird gelegentlich empfohlen, auf die Angabe des Dokumenttyps zu verzichten, da diese bei der Weiterverarbeitung unnötige Fehler produzieren kann. Dies ist keine angemessene Wiedergabe der Kritik, die zumeist auf falsche Negative bei der Validierung von Dokumenten hinweist. Da ein Validierer aber kein Interpreter ist, ist die Rede von "Weiterverarbeitung" zumindest verwirrend. Das die Angabe einer Quelle für die Kritik fehlt, sei hier nur am Rande angemerkt. [12]
  2. Der Abschnitt Koordinatensystem und -angabe stellt einen Zusammenhang zwischen Koordinatenangaben und Pixeln her, der so nicht existieren muss. Die viewBox beschreibt das dimensionslose interne Koordinatensystem. Erst mit der Angabe dimensionsbehafteter width- und height-Angaben wird in die Einheiten des Ausgabegerätes (viewport) umgerechnet. [13]
  3. Der Abschnitt Styling ist schlicht sachlich falsch. Füllung und die Konturlinie des Elements können sowohl durch Präsentationsattribute angegeben (fill, stroke) als auch auch innerhalb eines style-Tags eingefügt werden. Das macht die entsprechenden Angaben aber nicht zum Teil von CSS: "SVG shares many of its styling properties with CSS and XSL...The following SVG properties are not defined in CSS2." (folgen 45 von 65 Attributen - nur überschlägig gezählt) [14] Es gibt sogar Autoren, die die Verwendung von CSS anstelle der Präsentationsattribute explizit ablehnen. [15]

--Hk kng 19:59, 8. Sep. 2009 (CEST)

Hallo Hk kng. Auch Dir ein Dank für die Anmerkungen. Der Styling-Abschnitt war genaugenommen nicht sachlich falsch, aber unvollständigerweise aufs Styling-Attribut beschränkt und dadurch im Kern stark irreführend. Ich habe jetzt klargestellt, dass CSS nur die Basis dafür bildet, außerdem weitere Styling-Attribute sowie XSL erwähnt. Den Abschnitt zum Koordinatensystem habe ich auch korrigiert. Hier finde ich es etwas schwierig, die Komplexität der Behandlung von Koordinaten in einfache Sätze zu fassen, ohne ausschweifend zu werden. Ich hoffe, so geht es. Die Kritik an der Angabe der DTD habe ich entfernt, da unbelegt, wie Du korrekt feststellst. Ggf. hat sich diese Kritik mittlerweile auch erledigt. Gruß, norro ^wdw 14:35, 10. Sep. 2009 (CEST)

•  keine Auszeichnung - All die Probleme, die SVG bereitet, werden weitgehend unter den Tisch gekehrt. --Marcela 12:02, 9. Sep. 2009 (CEST)

  Ach Ralf, diese Stimme fehlte noch. Danke, ich war schon in Sorge. Wenn Dir trotzdem noch etwas Konstruktives zum Artikel einfällt, oder Du all die Probleme noch konkret benennen könntest, wäre ich Dir dankbar. Am liebsten, ohne mir die Unterschlagung von Informationen zu unterstellen. Gruß, norro ^wdw 01:02, 10. Sep. 2009 (CEST)

Kannst du gerne haben. Die Tabelle "SVG-Unterstützung in Browsern" hat sich ja nun grundlegend geändert. Man sieht, daß der verbreitetste Browser kein SVG unterstützt, warum steht der am Ende, er ist doch im hiesigen Raum wichtigster oder zweitwichtigster je nach Untersuchung? Es wird herausgestellt, daß er schon ... unterstützt wird, es müßte aber heißen, daß SVG (im Gegensatz zu den gebräuchlichen Pixelformaten) immernoch von keinem Browser komplett unterstützt wird. Vorschaubilder im Browser bereiten immer wieder Probleme, das weiß jeder. Und die Weiterverwendung wird aufgrund nicht vorhandener Importmöglichkeit in fast allen wichtigen Vektorgrafikprogrammen unmöglich. Aber auch das habe ich ja schon oft genug geschrieben. Es gehört einfach in den Artikel, daß es sich zwar um ein vom W3C empfohlenes Format handelt, dieses sich aber nur zögerlich und in engen Grenzen durchsetzt. Es steht nichts falsches drin, es wird Falsches suggeriert. Man kann nicht von Verbreitung reden, nur weil ein Programm dieses Formats unter vielen anderen anbietet. Wo spielt dieses Format außerhalb des Wikipedia-Dunstkreises eine nennenswerte Anwendung? Ganz grob benutzen je 50% beim Surfen IE und Firefox, wenn FF 60% und IE 0% dann komme ich auf eine Unterstützung von 30% und nicht 50% --Marcela 00:11, 14. Sep. 2009 (CEST)

•  Lesenswert Warum eigentlich nicht. --Zipferlak 02:17, 10. Sep. 2009 (CEST)
•  Lesenswert Der Artikel ist seit Jahren mein Sorgenkind, nur bin ich nie dazu gekommen, ihn aufzupäppeln. Es ist schön, dass sich jemand dem Artikel erbarmt hat und das Ergebnis ist mehr als lesenswert. --Benji 01:52, 11. Sep. 2009 (CEST)
•  Lesenswert Es wird nicht klar aufgezeigt warum man überhaupt noch andere Grafikformate verwendet, wenn svg all die Vorteile hat. Kompatibilität wird angerissen - Zeitaufwand zur Erstellung, benötigter Speicherplatz z.B. nicht. -- Alexpl 11:11, 11. Sep. 2009 (CEST)
•  keine Auszeichnung

• Ein Eingangsbeispiel, wie es früher enthalten war sollte unbedingt wieder rein, das vermittelt auf den ersten Blick die Vorteile des Formats. Wir hatten das in der Diskussion schon ziemlich ausführlich, dieses Beispiel motiviert stark, mehr über das Format zu erfahren.
• Wenn die Codebeispiele der grafischen Elemente derart massiv im Vergleich zu früher gekürzt werden (finde ich zwar schade, aber eine andere Sicht ist wohl nicht durchsetzbar), dann brauchen auch nicht die nötigen Angaben verbal umschrieben werden (dass zur Definition eines Kreises der Mittelpunkt und Radius nötig ist, ist nicht erwähnenswert). Eine einfache Aufzählung der grafischen Elemente reicht, zu Pfad, Polylinie und Polyeder können ja noch kurze Bemerkungen dazu (Stützlinie könnte dann auch erläutert werden). Worauf definitiv verzichtet werden kann, ist Code-Darstellung der Tags, das bringt ohne die notwendigen Attribute überhaupt nichts.
• Wie schon erwähnt fehlt die viewBox völlig, ein extrem wichtiger Teil im Vergleich zu den diversen Filtern
• Das Beispiel ist nicht schlecht, allerdings ist mir nicht klar, warum für den Schleifer (unnötiger Fachbegriff) eine Polylinie anstelle einer normalen Linie verwendet wird. Weiterhin wird viewBox verwendet, ohne, dass sie im Text erläutert wird. Damit wird das Beispiel noch verwirrender.
• Möglichkeit, mehrsprachige Bilder in Abhängigkeit der Browsereinstellung zu verwirklichen wird völlig verschwiegen, dabei ist dies das wohl herausragende Merkmal im Vergleich zu anderen Bildformaten (und deshalb wäre eine Umstellung der WP auf SVG auch mal ganz nett, aber ich schweife ab).
• Die Wiederverwendbarkeit von Elementen fehlt (bin mir jetzt nicht sicher, ob das im Standard enthalten ist, ist aber definitiv auch eine ziemlich wichtige Sache)

Abschließend noch eine kurze Zusammenfassung: Der Artikel ist durch die Überarbeitung definitiv verbessert worden, es muss mMn auch nicht jeder meiner Punkte für Lesenswert aufgenommen werden, aber in der Summe mit den Punkten von kmk (ich stimme da den meisten zu) sind momentan noch zu viele Lücken im Artikel. --Sepp ^{(ehemals Ff-Sepp)} 12:41, 12. Sep. 2009 (CEST)

 Lesenswert Lesenswert, auch wenn mit Einschränkungen

• Abschnitt Geschichte ist ein wenig dünn. Die Sache mit den "Empfehlungen" ist auch nicht so wirklich klar. Ist irgend etwas von W3C jemals verbindlich gewesen? Gab es in den Versionsänderungen auf 1.1 und 1.2 interessante Neuerugenen?
• "Verbreitung" bezieht sich praktisch ausschliesslich auf Tools. Wer und wie SVG zur Erstellung von Bildern einsetzt, fehlt aber.-- Avron 18:52, 13. Sep. 2009 (CEST)

Auswertung: Der Artikel wurde aufgrund des sehr eindeutigen Votums in die lesenswerten Artikel aufgenommen. Einzelne Kritikpunkte wurden vom Auswerter zur Kenntnis genommen, jedoch als für lesenswerte Artikel tolerabel eingeschätzt (knappe Geschichtsdarstellung und andere kleinere Lücken); für eine Weiterentwicklung sollten diese Punkte aufgegriffen werden. Die Kritikpunkte von Marcela sind von meiner Seite nicht einzuschätzen, machen jedoch den Eindruck persönlicher Abneigung zum Format und wurden nciht weiter belegt - weiß jeder ist kein Argument. In der Summe also lesenswert. -- Achim Raschka 09:08, 14. Sep. 2009 (CEST)

Javascript-Bibliotheken

Moin. Ich hatte damals den Hinweis auf dojo.gfx und Raphael verfasst (http://de.wikipedia.org/w/index.php?title=Scalable_Vector_Graphics&oldid=58882354 - Punkt SVG-Unterstützung in Browsern), und musste eben feststellen, dass dieser zugunsten einer Nennung von SVG Web gewichen ist. Da frage ich mich natürlich, warum wird hier eine Lösung präferiert? Warum behält man hier dem Leser diese Information vor? Ich bin der Meinung, entweder man nennt sie alle namentlich, oder garnicht und belässt es bei dem bloßen Hinweis, dass es solche Libraries gibt. -- Mir 12:57, 19. Sep. 2009 (CEST)

Was würdest Du vorschlagen? Gruß, norro ^wdw 14:06, 19. Sep. 2009 (CEST)

Also für das Format SVG ist ja in aller erster Linie wichtig, dass es diese Möglichkeiten gibt. Insofern war vielleicht meine Beschreibung damals schon zu ausführlich, aber ich wollte auch nicht nur einen einzigen Satz dazu schreiben.

Daher würde ich vorschlagen, dass man einfach die Optionen, die man in Form dieser Bibliotheken hat, namentlich nennt, und die tatsächliche Umsetzung nur sehr vage umschreibt. Genauer gesagt, dass eben über den Umweg Javascript eine dem jeweiligen Browser angepasste Repräsentation generiert wird. Genaueres könnte man dann ja in eigenen Artikeln zu den Libraries schreiben, falls jemandem danach ist. Das halte ich für den diplomatischen Weg. -- Mir 13:26, 20. Sep. 2009 (CEST)

Find ich gut. Machst Du das? Ich denke, svgweb könnte man trotz der knappen und allgemeinen Form namentlich erwähnen, da es aufgrund seines Hintergrunds das größte Potential haben dürfte. Gruß, norro ^wdw 00:17, 6. Okt. 2009 (CEST)

Editoren

Unter "Editoren" ist Paint.NET aufgefüht. Das halte ich für eine Fehlinformation. Auch Gnuplot ist nicht wirklich ein Editor - der kann es nur erzeugen. t34 11:07, 24. Sep. 2009 (CEST)

Dem würde ich zustimmen. Gruß, norro ^wdw 13:18, 15. Nov. 2009 (CET)

SVG im Vergleich

Einer der wichtigsten Punkte im weiteren Ausbau dieses Artikels ist eine knappe, sachliche Einordnung des Formats in den Kontext anderer Vektorgrafik-Formate. Kommerziell, proprietär, Umfang, Verbreitung, … etc. Hat da jemand Zugang zu Quellen oder Erfahrungen? Gruß, norro ^wdw 13:20, 15. Nov. 2009 (CET)

Einen guten Überblick gibt es hier: Liste von Dateiformaten für 2D-Vektorgrafiken. Soweit ich weiß hat unter den offenen Vektorgrafik-Formaten neben SVG nur EPS eine nennenswerte Verbreitung und das auch nur wegen LaTeX. SVG ist daher in seinem Anwendungsgebiet praktisch konkurrenzlos.--Trockennasenaffe 11:06, 12. Feb. 2010 (CET)

Das tut zwar nichts zur Sache, aber ich muss doch heftig widersprechen: Platzhirsch im Haupteinsatzgebiet von SVG (Web) ist doch zweifelsfrei Adobes Flash. Auch in Designerkreisen genießen Adobe-Produkte Monopolstellung. [Nur subjektive Aussage] --Benji 22:58, 13. Feb. 2010 (CET)

dimensionslos

Habe wieder etwas gelernt beim Lesen der Seite. Vielen Dank! Aber ich bin über dimensionsloses Koordinatensystem mit einer X- und Y-Koordinate gestolpert. Das macht für mich keinen Sinn. Die Dimension ist doch immer 2. Was will man mit diesem Begriff ausdrücken? --Zuphilip 11:21, 23. Nov. 2009 (CET)

Damit ist gemeint dass die Werte keine direkte Messgröße besitzt - also z.B. cm, Pixel, Prozent etc. --+Vanger ^!–!?

Hm...ich finde den Begriff verwirrend. Es gibt ein 2-dimensionales Koordinatensystem und ein 3-dimensionales Koordinatensystem, aber ein dimensionsloses Koordinatensystem würde ich nicht gebrauchen. Was du meinst ist, dass die Graphiken "frei skalierbar" sind, dass das Koordinatensystem losgelöst ist von irgendwelchen konkreten Massen. Aber die Dimension ist immer noch 2. Wenn dann wäre es ein "massloses Koordinatensystem", aber ich glaube kaum, dass man diesen Begriff gebrauchen kann. --Zuphilip 15:22, 24. Nov. 2009 (CET)

Es ist leider so: Der physikalische Begriff dimensionslos für Messgrößen, die nur aus einer Maßzahl ohne Einheit bestehen, ist gängig. Andererseits wird der Begriff Dimension in der Mathematik in einer leicht anderen Bedeutung verwendet. Siehe BKL Dimension.--Rotkaeppchen68 14:45, 19. Dez. 2009 (CET)

- 2010 -

Weblinks

[16] und [17] sind sicher keine schlechten Seite(n) zum Thema, sogar Gute. Anschaulich (man kann alles mal ausprobieren und anschaun) und auf deutsch. Ist bei den anderen Links nicht gegeben. Gute Links gehören in erster Linie in den Wikipediartikel. Das ODP kann diese Links dann gerne ergänzen aber nicht ersetzen... - Metoc ☺

Gibt eine besser Adresse: http://www.selfsvg.info/?toc -- 78.50.18.119 22:13, 19. Apr. 2010 (CEST) (IP-Adresse)

- 2011 -

Artikel des Tages

Ich habe diesen Artikel für den 05.09.2011 als Artikel des Tages vorgeschlagen. Gruß, --Gamma127 14:03, 30. Jan. 2011 (CET)

Neue Literatur?

Kann jemand deutsch- oder englischsprachige Literatur empfehlen, die etwas neuer als 2001/2002 ist und vielleicht auch auf neuere Browser und ihre Unterstützung eingeht?--193.98.224.221 20:54, 12. Mai 2011 (CEST)

Konvertierung

Leider kein Wort über mögliche Konvertierung in und aus anderen Vektorformaten bzw. vorallem Postscript oder PDF und LaTeX oder speziellen Formaten wie z.B. solche für Musiknoten. --Itu 21:01, 30. Jul. 2011 (CEST)

Fundstück --Itu 21:07, 30. Jul. 2011 (CEST)

Abschnitt Transformation

Kann jemand erklären, wie man von den sechs Parametern bei der Funktion matrix(...) auf die 3×3-Matrix kommt?--Sinuhe20 09:08, 6. Sep. 2011 (CEST)

Eigentlich braucht man nicht über eine 3x3-Matrix zu gehen, eine 2x3-Matrix tut's auch. Das W3C spricht zwar auch von 3x3-Matrizen und hängt jedem Vektor (x,y) noch eine 1 an, aber wir müssen's ja nicht komplizierter machen, als es ist. Ich versuche das mal zu vereinfachen. --Zupftom 21:08, 6. Sep. 2011 (CEST)

Quatsch, ich erzähle Unsinn. Erst überlegen, dann schreiben. --Zupftom 21:14, 6. Sep. 2011 (CEST)

Ich nehme mal an, dass die Parameter die ersten beiden Zeilen der Matrix darstellen (von oben nach unten) und das die letzte Zeile immer (0, 0, 1) lautet, aber auf den ersten Blick sieht man es irgendwie nicht. In dem Artikel Homogene Koordinaten wird es glaub ich ganz gut erklärt, deshalb hab ich ihn nochmal im Artikel verlinkt…--Sinuhe20 21:28, 6. Sep. 2011 (CEST)

Intro

SVG basiert aber nicht auf XML. Es ist eine Untermenge von XML. Und, bitteschön, dem Leser lieb mitteilen, dass SVG auf semantischer Ebene mit XML genauso viel zu tun hat wie alte Schallplattenaufnahmen von Enrico Caruso mit Aufnahmen von Brahmanen-Hymnen. (Hört sich vielleicht so ähnlich an, ist aber...). ML ! --Yanestra 17:47, 6. Sep. 2011 (CEST)

Mir würde so was wie "SVG ist ein XML-Format" besser gefallen, aber nach der Kategorie:XML-basierte Sprache zu urteilen ist es hier Konvention, das so zu nennen. --Zupftom 20:57, 6. Sep. 2011 (CEST)

Unverständlicher Satz

"Bei rasterbasierten Ausgabemedien, zum Beispiel einem Monitor, bezeichnet eine SVG-Angabe wie (x = 100, y = 200) nicht den ganzen Bildschirmpixel, sondern die Grenze zwischen den Pixeln." Nennt mich blöd, aber ich kriege nur Knoten ins Hirn, wenn ich diesen Satz verstehen will. Welche Grenze zwischen welchen Pixeln ist da gemeint? Ein Pixel hat 8 Nachbarn an 4 Kanten und 4 Ecken. Was bezeichet x=100, y=200 in SVG? Einen idealisierten Punkt? Eine Kante zwischen Pixeln? Einen Punkt in der Mitte eines Pixels? Verwirrt --80.246.32.33 15:48, 6. Sep. 2011 (CEST)

Als Beispiel existieren die folgenden durchnummerierten 3x3 Pixel:

_______
|1|2|3|
|4|5|6|
|7|8|9|

Die Koordinate x=0, y=0 beschreibt hierbei den äußersten Rand ganz links oben. Die Koordinate x=1, y=1 beschreibt die Kante rechts unten des 1. Pixels (entspricht gleichzeitig auch der linken oberen Kante des 5. Pixels). Die Koordinate x=3, y=2 beschreibt die rechte untere Kante des 6. Pixels bzw. die rechte obere Kante des 9. Pixels. Die Kante ganz rechts unten ist die Koordinate x=4, y=4. Das gilt natürlich nur wenn man auch Pixel als Maßeinheit verwendet (d.h. im svg-Tag wird als width/height eine Angabe in Pixeln gemacht) und die Grafik nicht skaliert. Koordinaten müssen in SVG aber nicht ganzzahlig sein, die Koordinate x=0.5, y=0.5 beschreibt so z.B. den Mittelpunkt des 1. Pixels. --Vanger ^!–!? 16:56, 6. Sep. 2011 (CEST)

Immer noch unverständlich: Warum sprichst Du einmal von Rand (für mich etwas Eindimensionales), dann von Kante (ebenso etwas Eindimensionales), dann von (Mittel)Punkt (für mich Nulldimensional)? Bezeichnen denn nicht alle SVG Koordinaten Punkte? Kann man das bitte mathematisch klar und unzweideutig mit den Begriffen Punkt/Strecke beschreiben? Der Begriff Kante ist jedenfalls unverständlich. --80.246.32.33 17:14, 6. Sep. 2011 (CEST)

Hier wäre anzumerken, dass man mit dem Begriff "Kante" etwas vorsichtiger umgehen sollte. In der Anmerkung von Vanger sollte es also m. E. heißen: Die Koordinate x=0, y=0 beschreibt hierbei die äußerste Ecke ganz links oben (von Pixel 1). Die Koordinate x=1, y=1 beschreibt die rechte untere Ecke des Pixels 1 und damit gleichzeitig die linke obere Ecke von Pixel 5. Die Koordinate x=3, y=2 beschreibt die rechte untere Ecke des Pixels 6 und gleichzeitig die rechte obere Ecke des Pixels 9. Die Ecke ganz rechts unten (von Pixel 9) hat die Koordinate x=3, y=3 (!). ... Zur Begriffsbildung vgl. http://de.wikipedia.org/wiki/Eulerscher_Polyedersatz . ---Hll001 17:24, 6. Sep. 2011 (CEST)

Ja, richtig. Natürlich ist unten rechts x=3, y=3... Ja, die Begrifflichkeit ist etwas schwierig, Kante trifft es wohl eher nicht so richtig. Endgültig klar wird das Ganze aber mit dem hier: „Die Koordinate x=1, y=1 beschreibt die rechte untere Ecke des Pixels 1 und damit gleichzeitig die linke obere Ecke von Pixel 5.“ Es geht beim Koordinatensystem immer um Punkte, nie um Strecken.

Denke doch einfach im ganz normalen zweidimensionalen Koordinatensystem von Mathematik zur Schulzeit... Ist zwar schon eine Weile her, im Grund weiß man das aber ja noch. Denke einfach nicht in Pixeln... Das ist bei SVG vollkommen unnötig. --Vanger ^!–!? 23:26, 6. Sep. 2011 (CEST)

Das ist mir alles klar (bin Physiker und SW-Ingenieur). Mir geht es um die Begrifflichkeit. Wenn man in einem Satz die SVG Koordinate (x=100,y=200) nennt, dann ist es völlig unverständlich, von Grenze, Kante, Rand oder sonstwas zu reden, weil die SVG Koordinate einen Punkt bezeichnet, nämlich die obere linke Ecke eines Pixels. (Und das auch nur unter zwei zusätzlichen ungenannten Bedingungen: wenn die Koordinateneinheit Pixel ist und ganzzahlig.) Kannst Du erkennen, dass der Satz so wie er dasteht, unterirdisch schlecht und eines technischen Artikels nicht würdig ist? --80.246.32.33 10:21, 7. Sep. 2011 (CEST)

Müssten nicht Pixel völlig herausgenommen werden, es kommt doch auf die Viewbox an. Pixel haben bei irgendwelchen Definitionen von SVG meiner Meinung nach gar nichts zu suchen. --Sepp 12:22, 7. Sep. 2011 (CEST)

Es geht in dem Satz ja nicht darum das Koordinatensystem zu erklären, das wurde es ja schon vorher. Der Versuch ist das Ganze im Verhältnis zu Rastergrafiken zu erläutern. „die obere linke Ecke des Pixels mit der Pixelkoordinate (1,1)“ ist imho aber noch unverständlicher, da stellt sich einem Leser nämlich die Frage von was für „Pixelkoordinaten“ plötzlich die Rede ist. Da wäre „die obere linke Ecke des äußersten Pixels in der oberen linken Ecke der Grafik“ besser, hört sich dank dem Doppelt-Gemoppelt auch nicht besser an. Der Satzanfang „In Pixeleinheiten“ wäre übrigens auch Doppelt-Gemoppelt, davon ist im vorherigen Satz ja sowieso schon die Rede. Meinungen? --Vanger ^!–!? 13:26, 7. Sep. 2011 (CEST)

Ich sehe das auch so wie Sepp. Da Vektorgrafiken generell unabhängig von der Auflösung des Zielmediums sind und man durch die Viewbox und Transformationen häufig gar nicht in Pixeln denken kann, sollte man das mit den Ecken und Kanten rausschmeißen. Man könnte den Unterschied so formulieren, dass bei Rastergrafiken mit den Koordinaten eine kleine quadratische Fläche angesteuert wird, während man bei SVG einen flächenlosen Punkt adressiert. --Zupftom 13:30, 7. Sep. 2011 (CEST)

Mathematisches zum Abschnitt "Ellipse"

Ich halte die Begriffsbildung "Halbachsenradien" für höchst unglücklich. Ich würde "Länge der Halbachsen" (evtl. auch: "Größe der Halbachsen") vorziehen. Mit "Radius" wird gewöhnlich der Abstand eines beliebigen Kurvenpunktes einer geschlossenen Kurve zu dem Mittelpunkt des von der Kurve eingeschlossenen Gebietes bezeichnet (sofern diese Begriffsbildung bei der Kurve überhaupt sinnvoll ist - wie etwa bei der Ellipse, wo diese Begriffe noch anschaulich und vernünftig definiert sind). Wie man an der Ellipse sieht, ist der Radius womöglich längs der Kurve nicht konstant (wie - als kennzeichnende Eigenschaft - beim Kreis). In diesem Sinn sind der größte bzw. kleinste bei der Ellipse auftretende Radius die große bzw. kleine Halbachse der Ellipse (und der Begriff "Halbachsenradius" ist ein Pleonasmus).
Des Weiteren wäre es hilfreich, im Abschnitt "Ellipse" anzumerken, dass damit nur eine Ellipse mit achsenparallelen Halbachsen definiert werden kann ( vgl. etwa http://www.princexml.com/doc/7.0/svg/ ), zur Herstellung einer Ellipse in allgemeinster Lage auf der Zeichenebene also ggf. noch eine Rotation der entstandenen Figur um ihren Mittelpunkt mit einem beliebigen (geeigneten) Winkel erforderlich ist.
--Hll001 17:06, 6. Sep. 2011 (CEST)
Ergänzend dazu habe ich mal mit einem bekannten Suchprogramm das Web nach dem Wort "Halbachsenradius" durchsucht. Bis auf ganz wenige (< 5) Ausnahmen wird dieser Begriff ausschließlich im Zusammenhang mit SVG benutzt. Da ist es m.E. angebracht, auf die üblichen Begriffe zurückzugreifen, die die Mathematik schon seit Jahrhunderten für die große und kleine Halbachse einer Ellipse benutzt. Es ist ja beileibe nicht so, dass SVG mit dem Begriff "Halbachsenradius" auch gleich ein neues Objekt erfunden hätte. Andererseits ist es für die allgemeine Verständlichkeit des Artikels durchaus förderlich, wenn allgemein verständliche Begriffe statt der etwas eigenartigen Begriffsbildung in der Definition von "Ellipse" bei SVG benutzt werden.
---Hll001 22:27, 7. Sep. 2011 (CEST)

Scripting/Programmierung

Zur Hin-und-Her-Rückgängigmachung zwischen mir und Sunks: Du hast natürlich recht, dass Skripte Programme sind. Da aber Programme im Allgemeinen keine Skripte sind fand ich, dass die konkretere Unterkategorie hier passender ist. Ich habe zu dem Zeitpunkt aber nicht daran gedacht, dass DOM-Manipulation natürlich auch mit Nicht-Skriptsprachen möglich ist, das kommt in dem Abschnitt bisher nicht vor. Um weiterem Knirschen im Gebälk vorzubeugen, hier ein Vorschlag:

SVG kann mit Hilfe des Document Object Model (DOM) dynamisch erzeugt oder verändert werden und auf Ereignisse wie Mausklicks reagieren. Ab Version 1.2 wird die DOM-Schnittstelle für SVG stark erweitert und umfasst mehr grafikspezifische Methoden. Im Browser wird mit ECMAScript (einer standardisierten Variante von JavaScript) auf die DOM-Schnittstelle zugegriffen.

Ist das konsensfähig? Und was wird aus der Überschrift? --Zupftom 14:14, 8. Sep. 2011 (CEST)

JavaScript, ECMAScript und SVG

Im Artikel steht der Satz "Mittels ECMAScript (einer standardisierten Variante von JavaScript) können in SVG Programme geschrieben werden" und ich vermute, dass er falsch ist. Um meine Vermutung zu überprüfen, habe ich testweise in ein Script ein yield (als Element eines pythonic generators aus JavaScript 1.7) eingebaut und das <script>-Tag durch <script type="application/javascript;version=1.7"> ersetzt. Das Ergebnis war, dass das Script im Firefox mit dem meiner Meinung nach nur in JavaScript, aber nicht in ECMAScript vorhandenen Programmierelement funktioniert.

Da ich mich ganz gut mit JavaScript, aber nicht so gut mit ECMAScript (und vor allem nicht mit ActionScript, dem anderen ECMAScript-Dialekt) auskenne, und SVG erst seit 3 Wochen kenne, möchte ich hier keine Halbwahrheiten verbreiten. Ich denke aber, dass man den Satz in "Mittels JavaScript können in SVG Programme geschrieben werden" ändern sollte. Gibt's hier SVG-Experten, die das abnicken würden? (Oder andernfalls den Originalsatz begründen würden?)

Gruß, --Wortverdreher 11:54, 29. Okt. 2011 (CEST)

Der SVG-Standard definiert nur ECMAScript-Anbindung. Genauso wie der DOM-Standard für HTML und allgemeines XML ebenfalls nur eine ECMAScript-Anbindung definiert. Natürlich benutzen die Browser in beiden Fällen ihr jeweiliges JavaScript, das ja ohnehin eine Übermenge von ECMAScript sein sollte. Ob man so darauf rumreiten muss ist die Frage. Das könnte leicht zum Eindruck führen, dass für SVG eine andere Sprache zum Einsatz kommt als für HTML.

Bei der Gelegenheit: Gibt's noch irgendwelche Rückmeldungen zu meinem Umformulierungsversuch ein Stück weiter oben in der Diskussion? --Zupftom 21:36, 29. Okt. 2011 (CEST)

Danke für die schnelle Reaktion! Ich habe den Satz jetzt in "Mit Hilfe der jeweiligen Implementierung des SVG-Viewers von ECMAScript (im Browser ist dies im allgemeinen eine Version von JavaScript) können in SVG Programme geschrieben werden." geändert. Ich denke, das ist so in Ordnung sein müsste.

Zum Thema "Scripting / Programmierung" kann ich leider nichts sagen, denn die SVG-Spezifikationen kenne ich nicht.

-- Wortverdreher 13:28, 30. Okt. 2011 (CET)

- 2012 -

Vandalismus

Ich hatte ein Problem mit SVG und deswegen folgenden Diskussionsbeitrag hier eingestellt:

Verwendung in IrfanView?

IrfanView kann leider mit SVG-Dateien nichts anfangen, und wenn ich eine von einer SVG-Darstellung in Wikipedia erzeugte PNG-Datei abspeichere, wird der Hintergrund schwarz.

Was kann man dagegen tun?

Der wurde kommentarlos gelöscht, zuletzt soeben von User:BlackSophie mit der Begündung "(Änderung 100447514 von 92.224.241.55 wurde rückgängig gemacht. weil Wiki nicht die Auskunft ist)"

Ja, was glaubt User:BlackSophie denn, wofür ein (Online-)Lexikon da ist, wenn nicht, Informationen für Problemlösungen zu bekommen? Selbstverständlich ist ein Lexikon "die Auskunft".

Die Lösung habe ich übrigens inzwischen selbst gefunden: Es liegt nicht per se an den SVG-Files, sondern daran, daß bei IrfanView eine passende Einstellung vorgenommen werden muß: Über "Ansicht" -> "Vollbild-Optionen anzeigen" -> "Anzeige" muß der Punkt "PNG/TIF/TGA/DDS Alpha/Transparenz anzeigen" angehakt werden, dann wird der transparente Hintergrund in der eingestellten Hintergrundfarbe dargestellt.

Danke für die freundliche Hilfe, es ich werde es bei meiner nächsten Spende an Wikipedia zu schätzen wissen! :-(

(Wahrscheinlich wird das hier vom nächsten Wikipedia-Blockwart wieder umgehend gelöscht.) (nicht signierter Beitrag von 92.224.241.55 (Diskussion) 07:09, 4. Mär. 2012 (CET))

Die Diskussionsseite eine Artikels dient dazu, Verbesserungsmöglichkeiten der Seite zu diskutieren. Sie ist nicht als Forum und Hilfe für den im Artikel besprochenen Inhalt gedacht. Stell dir vor, wir fangen unter der "Diskussion: Windows" an, alle Windowsprobleme auszutauschen. Von daher war die Löschung in Ordnung und kein Vandalismus. Bitte wende dich mit solchen Fragen an eines der vielen Foren. -- Schotterebene (Diskussion) 10:54, 4. Mär. 2012 (CET)

Es wäre also keine Verbesserung des Artikels, auf naheliegende Probleme bei der Verwendung des SVG-Formats in einem Satz hinzuweisen? (nicht signierter Beitrag von 92.224.241.55 (Diskussion) 14:17, 4. Mär. 2012 (CET))

Nein. Zum einen hat dein Problem wenig mit SVG zu tun, sondern mit IrfanView (und es gibt viele andere Anwendungen wie Gimp, Photoshop, Paint.NET). Zum anderen soll ein Lexikon vorrangig einen Überblick verschaffen und kann gar nicht den Anspruch haben, für jedes Spezialproblem eine Antwort zu haben. Ich werde auch im Beitrag VW Golf keine Hinweise finden, was beim Einfüllen von Bremsflüssigkeit zu beachten ist (so nützlich die Information für den Betroffenen sein mag). Denkbar wäre vielleicht im Beitrag IrfanView ein Link zu weiterführenden Informationen, wo solche und andere Probleme behandelt werden. -- Schotterebene (Diskussion) 15:54, 4. Mär. 2012 (CET)

Umwandlung von SVG-Dateien in andere Formate

Nun habe ich mal längere Zeit im Artikel gelesen und die Weblinks geprüft, doch die Antwort, wie ich eine SVG-Datei, umgewandelt bekomme in ein Format, das ich nutzen kann, findet sich nicht im Artikel. Und genau dafür habe ich einen Weblink eingefügt, der dieses Wikipedia-Problem betrifft. Meines Erachtens ist mein Link nun doch eine wichtige Ergänzung zum Artikel. Andere Weblinks funktionieren anscheinend nicht (oder vorübergehend nicht) oder sind Doubletten.--Venezianer (Diskussion) 19:25, 15. Jun. 2012 (CEST)

Wikipedia ist kein Hilfeforum und bietet auch keine Tutorials. Auf WP:WEB habe ich schon hingewiesen und bitte dich die dortigen Regeln zu beachten. --net (Diskussion) 19:38, 15. Jun. 2012 (CEST)

Ein wichtiger Aspekt von SVG wird in diesem Lesenswert-Artikel nicht behandelt: das Format ist erst einmal unhandlich und scheint wie eine Sackgasse zu sein. Im Artikel selbst wird dies nicht behandelt. Allein die Frage, wie man damit umgeht wird angerissen. Das ist ein Manko des Artikels. Und leider findet sich auch in den verlinkten Seiten kein gut auffindbarer Hinweis darauf, wie man das Format SVG in ein anderes Format umwandeln kann. Und das ist eine Lücke bei den Weblinks, der mir aufgefallen ist.--Venezianer (Diskussion) 23:28, 15. Jun. 2012 (CEST)

Wie ich schon sagte, ist Wikipedia kein Tutorial und ist nicht dafür da, auf alles eine Anleitung zu liefern. Und Weblinks haben sich nun mal genau auf das Thema zu beziehen und weiterführende Informationen zu liefern – Tools zur Formatumwandlung gehören jedoch nicht dazu. So wird das in der gesamten WP gehandhabt und ich sehe keinen Grund, hier eine Ausnahme zu machen. Wer sich mit SVG beschäftigt, muss halt noch weitere Quellen bemühen und auch mal Google nutzen. Davon abgesehen ist SVG nicht wirklich eine Sackgasse und die Browserunterstützung hat mittlerweile eine Breite erreicht, die den nativen Einsatz im Web durchaus zulassen. --net (Diskussion) 23:47, 15. Jun. 2012 (CEST)

Prima, dass du gerade da bist. Sieh meinen Hinweis eher als Anregung, den Artikel zu verbessern und eine offensichtliche Lücke zu schließen. Wie diese Lücke geschlossen wird, ob über einen simplen Weblink oder im Artikel selbst, ist erst einmal nicht wesentlich. Mir ist aufgefallen, dass es im Artikel eine Auflistung gibt von Software, mit der man SVG bearbeiten kann. Da würde ich als Leser auch einen Hinweis vermuten, wie man SVG in andere Graphikformate exportiert, doch finde ich ihn nicht. Und das ist eine Lücke im Artikel, die bestimmt nicht nur mir aufgefallen ist. Google bemühen? Kann ich gut. WP:WEB durchlesen? Kenn ich natürlich. Fünf Weblinks maximal, eher weniger. Und vom Feinsten sollten sie sein. Die jetzige Weblinksabteilung hat da sechs Stück neben den Wikiinternen. Ein Link (svg.org) ist momentan nicht erreichbar. Dann gibt es zwei Tutorials, (würde nicht eines reichen?). Eines davon wird nicht mehr aktualisiert. Das andere findet sich auf einer Unternehmensseite. Dann ist da ein veralteter Link zu uralten Browsern. Und dann gibt es noch eine Linksammlung mit sieben (!) weiterführenden Links aus einer extremen Webstandardseite. In dieser Linksammlung finden sich dann auch die zwei Tutorials. Willste meine Meinung wissen? Richtig knackig überzeugend wirken die Weblinks nicht für einen Artikel, der das Babberl Lesenswert hat. Könnte man überarbeiten.--Venezianer (Diskussion) 00:26, 16. Jun. 2012 (CEST)

Seh gerade, das waren ja sieben. Einen hast du schon gelöscht. Gut so.--Venezianer (Diskussion) 00:29, 16. Jun. 2012 (CEST)

Was die bestehenden Weblinks angeht – da kann man sicherlich noch einiges ausdünnen und evtl. gibt es ja auch schon bessere Seiten zum Thema, die man verlinken kann. Du kannst hier gerne Vorschläge bringen. Svg.org habe ich jetzt auch noch rausgehauen.

Zum Thema „offensichtliche Lücke“ im Artikel – SVG ist ein Format, welches explizit dazu gedacht ist, nativ verwendet zu werden. Natürlich kann es auch (bspw. als Fallback wie hier in der WP) als Bitmap ausgeliefert werden aber das ist nicht der Einsatzzwecke von SVG. Die Lücke liegt also eher in der immer noch nicht vollständigen Browserunterstützung und nicht im Artikel. Ich sehe hier keinen Mehrwert für den Artikel, dort extra darauf einzugehen, zumal die angegebenen Editoren ja auch allesamt eine Exportmöglichkeit in Bitmap-Formate anbieten. --net (Diskussion) 09:45, 16. Jun. 2012 (CEST)

Bei den Weblinks würde ich lediglich die Linkliste lassen. Sie ist gut kommentiert und enthält beide Tutorials. Wenn ein Tutorial bei den Weblinks mit dabei sein soll, würde ich intuitiv das Tutorial, das nicht mehr aktualisiert wird, herausnehmen, (das ist mir beim Anklicken gleich negativ an den Weblinks aufgefallen). WP:WEB ist nicht mehr als eine Richtlinie, die aber im Einzelfall immer ausgelegt werden muss. Persönlich finde ich eine gute Aufzählung von Weblinks immer hilfreich, auch dann wenn es mal deutlich mehr sind als fünf Links. Die Umwandelbarkeit von SVG in andere geläufige Formate ist schon wichtig. Im konkreten Fall bin ich also nicht bei den Weblinks fündig geworden. Dann habe ich die Softwareliste überflogen, um eine flinke Lösung zu finden für meinen Umwandelungswunsch, (der hier von der Wikipedia ausgelöst worden ist mit einer SVG-Graphik). Der letzte Softwarevorschlag hat gut geklungen: SVG-Edit, ein Online-Grafikeditor. Ich rufe also die Seite auf und finde mich wieder im Nirwana einer Programmleiche, die meinen Browser nicht unterstützt. Na gut, kann passieren. Also starte ich den Firefox und schon wieder habe ich ein Programmfenster, wo alle Menüs leer sind. Menno, der Firefox soll doch unterstützt werden? In diesem Moment habe ich das Vertrauen in den Wikipedia-Artikel verloren und mich auf die Suche gemacht nach einer einfachen Lösung. Das hat ein wenig gedauert, weil es nicht leicht ist, SVG in ein JPG umzuwandeln. Doch die Lösung, die ich gefunden habe, gefällt mir.[18] Der Converter ist schnell und simpel zu bedienen und auf jeden Fall einer für die Weblinks, wenn er denn nicht bei der Software genannt wird. Netspy, wenn es da eine fehlende Browserunterstützung bei 50 % der Internetnutzer gibt und die Wikipedia hat zahllose SVGs in Benutzung, dann ist mein Wunsch, glaube ich nicht, marginal. Wenn du dir aber sicher bist in diesem Punkt, dann bleibt es eben so. Letztlich wirst du ja den Artikel weiter beoachten und nicht ich.--Venezianer (Diskussion) 12:57, 16. Jun. 2012 (CEST)

Ich habe mir die letzte Diskussionspunkte durchgelesen. Meine Empfehlung ist, dass man auf Diskseiten keine Beiträge löscht, selbst wenn man es darf. Wenn freundlich gefragt wird, ist eine freundliche Antwort immer eine gute Wahl. Schon 2006 hat es eine Frage zur Umwandlung von SVG in andere Formate gegeben, benji hat freundlich geantwortet[19]. Bei der Lesenswertkandidatur hat es mehrere Hinweise auf die Lücken im Artikel gegeben. Hier einmal ein Zitat:

• Abwartend Ich habe den Artikel bis jetzt nur überfliegen können, aber mir fehlt ein Hinweis der SVG-Nutzung bei Wikipedia und ein Hinweis auf die Umrechnung in PNG-Dateien. Auch ein Vergleich (z.B. Vorteile) mit anderen Vektorgrafikformaten wie WMF, PDF und etc. wäre meiner Meinung nach wünschenswert. --Salino01 23:16, 3. Sep. 2009 (CEST)

  Das sind Punkte, die ich durchaus noch für einen Ausbau des Artikels auf dem Radar habe (nicht den Wikipedia-Bezug, Selbstreferenzen mag ich nicht so gerne), aber das sind Randbereiche und daher m. E. für den Lesenswert-Status noch unerheblich. Gruß, norro ^wdw 00:22, 4. Sep. 2009 (CEST)

Netspy, ich glaube nicht, dass du richtig liegst.--Venezianer (Diskussion) 15:28, 16. Jun. 2012 (CEST)

Bedeutung

Hallo,

Mir als Nicht-Infomatiker fehlen in dem Artikel ein paar zusammenfassende Sätze zur Bedeutung von SVG. Was leistet das Format im Gegensatz zu anderen Grafikformaten (jpg usw.)? Wofür ist es geeignet und wofür nicht? Vor- und Nachteile usw. Einiges kann man erschließen, wenn man das Kapitel "Dokument" durcharbeitet. Aber als Laie würde man gern wissen, warum man diese Arbeit auf sich nehmen soll. Ich stelle mir ein paar einführende Sätze in der Einleitung vor und ein größeres Kapitel entweder vor "Dokument" oder gleich als erstes oder aber ganz am Schluß. Gruß --Rarus (Diskussion) 17:47, 4. Okt. 2012 (CEST)

Naja; das gibt es schon, allerdings unter Vektorgrafik #Eigenschaften. SVG ist nur ein Format unter vielen, wenn auch inzwischen wohl das häufigste. Dementsprechend stellt diese Seite (SVG) die Besonderheiten und Geschichte dieses einen Formats dar, während die grundsätzlichen Vorteile von Vektorgrafiken gegenüber Rastergrafiken (jpg usw.) allgemein dort dargestellt sind. Vielleicht kann man darauf in einem Nebensatz deutlicher verweisen? --PerfektesChaos 18:07, 4. Okt. 2012 (CEST)

Stimmt, das habe ich irgendwann auch entdeckt. Allerdings meinte ich nicht die prinzipiellen Unterschiede Vektor-/Pixelgrafik, sondern das spezielle Einsatzgebiet. Wenn ich es richtig verstanden habe, werden SVG-Grafiken vor allem in HTML-Seiten eingebunden, was mit pdf und Postscript nicht möglich zu sein scheint (??). Sie stehen also nicht in Konkurrenz zu anderen Vektorgrafiken, sondern vor allem zu png, gif, aber offensichtlich nicht jpg (oder doch?). Dadurch ergibt sich eine Situation, die mit Postscript usw. nicht unbedingt zu vergleichen ist. Man ahnt etwas von diesem Einsatzgebiet in der Einleitung "Einige der gebräuchlichsten Webbrowser können ohne nachträgliche Installation von Erweiterungen einen Großteil des Sprachumfangs darstellen..." Zu dieser speziellen Eigenschaft gehört zB, daß, wenn ich in LibreOffice eine Grafik mit Text in SVG umwandle, der Text im Browser mit einem anderen Font angezeigt wird - die Erklärung kann man aus dem Kapitel "Elemente" erschließen ("Text in einer bestimmten Schriftart, die dem Render-Programm zur Verfügung stehen muss."). Das ist in Postscript und pdf anders und hängt mit der davon verschiedenen Funktion von SVG zusammen - falls ichs richtig verstanden habe.

Falls das alles Blödsinn ist, nimm es für die Mißverständnisse eines Laien, der sich einen Reim zu machen versucht. Das wäre dann ein Hinweis, daß Erklärungsbedarf besteht. Gruß --Rarus (Diskussion) 02:02, 9. Okt. 2012 (CEST)

Mit PostScript und PDF ist es bezüglich Fonts nicht unbedingt anders. Nur wenn die Fonts eingebettet sind, wird auch immer der richtige angezeigt. Auch in SVG können Fonts eingebettet werden, nur werden die nicht von allen Viewern unterstützt (insbesondere nicht von Firefox - mit etwas dubiosen Begründungsversuchen).

Wie in der Einleitung steht ist eine wichtige Eigenheit von SVG, dass es verschiedene Animationstechniken unterstützt (SMIL, DOM-Skripting, CSS). Sie können auch gut dynamisch generiert werden, sei es auf dem Client per JavaScript oder XSLT, oder auf dem Server per PHP, XSLT oder was auch immer dort zum Einsatz kommt. --Zupftom (Diskussion) 08:33, 9. Okt. 2012 (CEST)

Auch Verständnisfehler können zur Verbesserung des Artikels beitragen. Ich befasse mich heute morgen mal nicht mit irreführenden oder missverständlichen Formulierungen, sondern kläre in Erweiterung zu Zupftom die Sachverhalte. Im Einzelnen:

• SVG-Grafiken vor allem in HTML-Seiten eingebunden, was mit pdf und Postscript nicht möglich zu sein scheint
  • SVG-Grafiken vor allem in HTML-Seiten eingebunden
    • SVG entstand ursprünglich als lizenzfreies und einfaches Format aus dem Internet für das Internet. HTML-Seiten sind weiterhin ein Hauptanwendungsgebiet, aber auch außerhalb inzwischen ein sehr beliebtes Format.
  • PDF und PostScript
    • Dieses sind beide sehr, sehr komplexe Formate.
    • Sie benötigen komplizierte Viewer, die nicht in jeder Browser-Umgebung vorhanden wären.
    • Die Datenmengen sind sehr groß, nur um schließlich eine Briefmarke anzuzeigen. Vor einer Anzeige in konkretem Kontext sind aufwändige Berechnungen erforderlich.
    • Beide ermöglichen Dokumente aus mehreren Seiten. Wie soll man 357 Seiten gleichzeitig in einer HTML-Seite einbinden? Würde man das wollen?
• stehen also nicht in Konkurrenz zu anderen Vektorgrafiken, sondern vor allem zu png, gif, aber offensichtlich nicht jpg
  • stehen also nicht in Konkurrenz zu anderen Vektorgrafiken
    • SVG entstand ursprünglich als lizenzfreies und einfaches Format aus dem Internet für das Internet. Dementsprechend unterstützten es alle freien Browser, die jedoch kein anderes Vektor-Format darstellen, während Microsoft schmollte. Eine weiteres lizenzfreies Vektor-Format als Konkurrenz kam daneben nicht auf.
    • Alle anderen Vektor-Formate Ende letzten Jahrhunderts waren potentiell lizenzgebührenpflichtig. Das betraf die Viewer, um es im Browser anzeigen zu können; insbesondere aber die Software, um die komplizierten Formate generieren zu können. Das wurde als Hemmschuh angesehen. Insbesondere wäre es möglich, schon das Format zu patentieren, so dass man für jedes Bild Gebühren zahlen muss, das entsprechend formatiert wäre (Causa Compuserve/GIF). Außerdem waren die anderen Formate kompliziert, produktspezifisch und nicht menschenlesbar; deshalb schwer ohne das Originalprodukt zu pflegen.
  • Konkurrenz vor allem zu png, gif, aber offensichtlich nicht jpg
    • PNG und GIF: Diese beiden Formate werden oft für menschengemachte „Grafik“ eingesetzt, etwa Balkendiagramm, Tortengrafik: Relativ wenige Farben, und Grafisches Primitiv hast du ja bereits entdeckt. In diesen Fällen ist eine Umwandlung in Vektor-Elemente gut möglich und dann kommt die Vektorgrafik als Alternative in Betracht (Skalierbarkeit; manchmal Datenmenge). Die Beobachtung betreffend „png/gif“ ist also zutreffend.
    • JPG: Wenn man Ahnung hat, setzt man dies vorrangig für Fotos und dergleichen ein: Millionen von Farben; jedes Pixel individuell; keine Primitiva. Würde man hierauf Vektorgrafik anwenden, bekäme man Andy-Warhol-Siebdrucke; oder Millionen von Pointillismus-Elementen à la mode du Roy Lichtenstein. Die Beobachtung betreffend „nicht jpg“ ist also zutreffend.
• Text im Browser mit einem anderen Font angezeigt wird … in Postscript und pdf anders
  • Das kommt darauf an. PDF insbesondere, aber auch PostScript bieten die Möglichkeit, Fonts „einzubetten“. Irgendwo hat man in seinem PDF-Generator ein Häkchen und eine Standardeinstellung „Fonts einbetten“. Daraufhin wird in jedes einzelne PDF-Dokument für jedes tatsächlich auftretende Schriftzeichen in jeder jeweils betroffenen Schriftart die grafische Definition (üblicherweise eine Vektorgrafik) mit aufgenommen. Deaktiviert man diese Einstellung, wird bei der Anzeige des PDF-Dokuments im Zielsystem nach einer stilistisch ähnlichen Schriftart gesucht und die Fonts des Zielsystems werden von PDF benutzt. Bei PostScript läuft es prinzipiell ähnlich.
  • SVG bettet normalerweise keine Fonts ein, sondern macht im Prinzip das gleiche wie HTML: Es wird der reine Text als Zeichenfolge aufgenommen. Dazu können Darstellungsoptionen vermerkt werden, analog denen von CSS und HTML. Genauso arbeitet dann ein Browser bei der Darstellung einer HTML-Seite.
  • Weil aber die Schriftzeichen geometrische Primitiva sind, deren Definition auf dem erzeugenden System oft als Vektorgrafik vorliegt (etwa TrueType), kann man analog diese Font-Vektorgrafiken auslesen und für die tatsächlich benötigten Schriftzeichen in die SVG einbetten. Ob man das will, ob das optisch erforderlich ist, ob der Viewer das dann berücksichtigt oder auf die einfache Standard-Darstellung zurückgreift, ist eine andere Sache. Auch Pixel-Grafiken aus den Fonts ließen sich einbetten, wäre aber unphilosophisch.
  • Die Beobachtung betreffend einer „davon verschiedenen Funktion von SVG“ ist also zutreffend. SVG ist speziell zugeschnitten auf schnelle Darstellung in unterschiedlichsten Browsern auf diversen Endgeräten. PDF und PostScript zielen auf sehr papiergetreue Darstellung ab; möglichst mit kostenpflichtiger Software zumindest für die Erzeugung. Die Darstellung einer PostScript-Seite bedarf spezieller Software und kann eine ganze Weile dauern; danach druckt man es einmal aus und heftet es ab.

Blödsinn habe ich keinen gefunden; die Prinzipien hast du richtig aufgefasst.

Liebe Grüße --PerfektesChaos 09:47, 9. Okt. 2012 (CEST)

Hi,

Vielen Dank. Das beantwortet meine Fragen erschöpfend. Die Erklärung finde ich schon artikelreif. Jedenfalls kann ich mir vorstellen, daß auch viele andere, die ihre ersten Schritte in dem Gebiet machen (und dann keinen weiteren, weil es doch ziemlich viele Fachgebiete gibt . . .) genau diese Fragen haben. Liebe Grüße --Rarus (Diskussion) 02:21, 10. Nov. 2012 (CET)

Pfeil bei den Editor-Programmen

Hallo liebe Community, mir erschließt sich nicht ganz das Prinzip mit dem grünen Strich und dem schwarzen Dreieck drauf, was wohl einen Pfeil darstellen soll. Abgesehen davon, dass es sich zwei mal um die gleiche Grafik handelt und nicht um unterschiedliche mit verschiedener Größe würde ich gerne Wissen, was der Zweck davon sein sollte, das erschließt sich mir nicht ganz!? Beste Grüße 217.5.205.2 10:27, 9. Nov. 2012 (CET)

Das bezieht sich wohl auf den Satz: "Die von Editoren erzeugten SVG-Dateien sind in der Regel wesentlich komplexer als manuell erzeugte Dateien (siehe Abbildung zum Vergleich)." Und soll wahrscheinlich demonstrieren, wie unterschiedlich groß die SVG-Beschreibungen bei gleichem Ergebnis sind. --Schotterebene (Diskussion) 10:47, 9. Nov. 2012 (CET)

Ja; es gibt auch keine Differenz (mehr).

• Der Unterschied lag in den Bildunterschriften:
  • Sodipodi: 2.952 Byte
  • manuell: 194 Byte
• Die erste ist seit 10. Dezember 2011 Weiterleitung auf die zweite Datei. Da hatte jemand auf Commons bemerkt, dass beide das Gleiche darstellen, und auf die effizientere umgeleitet; die alte 3kB war die hier
• Es ist nicht möglich, (auch noch in der deutschsprachigen Wikipedia) unmittelbar ein Bild anzuzeigen, das nur archiviert (und auf Commons) liegt. Ich habe mal Links drangebaut.
• Nachfolgend die beiden Quellcodes zum Vergleich, die wohl die Überlegenheit menschlicher visueller Gaben über eine automatisierte Generierung aus einer Pixelgrafik mittels eines Tools illustrieren sollen.

<svg xmlns="http://www.w3.org/2000/svg" width="500" height="500">
<path d="M200,0H300V500H200z" fill="green">
<path d="M250,110L106,365H393z">
</svg>

und dagegen Clem mit Sodipodi

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Created by Bernina for Wikipedia -->
<svg
   xmlns:dc="http://purl.org/dc/elements/1.1/"
   xmlns:cc="http://web.resource.org/cc/"
   xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#"
   xmlns:svg="http://www.w3.org/2000/svg"
   xmlns="http://www.w3.org/2000/svg"
   xmlns:sodipodi="http://sodipodi.sourceforge.net/DTD/sodipodi-0.dtd"
   xmlns:inkscape="http://www.inkscape.org/namespaces/inkscape"
   width="500"
   height="500"
   viewBox="0 0 500 500"
   preserveAspectRatio="none"
   id="svg2"
   sodipodi:version="0.32"
   inkscape:version="0.45.1"
   sodipodi:docname="BSicon_fSTRSummit.svg"
   sodipodi:docbase="C:\Documents and Settings\Clem\My Documents\SandBox\FPicon"
   inkscape:output_extension="org.inkscape.output.svg.inkscape">
  <metadata
     id="metadata13">
    <rdf:RDF>
      <cc:Work
         rdf:about="">
        <dc:format>image/svg+xml</dc:format>
        <dc:type
           rdf:resource="http://purl.org/dc/dcmitype/StillImage" />
      </cc:Work>
    </rdf:RDF>
  </metadata>
  <defs
     id="defs11" />
  <sodipodi:namedview
     inkscape:window-height="668"
     inkscape:window-width="853"
     inkscape:pageshadow="2"
     inkscape:pageopacity="0.0"
     guidetolerance="10.0"
     gridtolerance="10.0"
     objecttolerance="10.0"
     borderopacity="1.0"
     bordercolor="#666666"
     pagecolor="#ffffff"
     id="base"
     inkscape:zoom="0.76"
     inkscape:cx="33.450995"
     inkscape:cy="318.43972"
     inkscape:window-x="75"
     inkscape:window-y="-9"
     inkscape:current-layer="svg2" />
  <title
     id="title4">
 BS: Strecke
</title>
  <g
     stroke-miterlimit="10"
     id="g6"
     style="fill:#008000;fill-rule:evenodd;stroke:none;stroke-width:10;stroke-linecap:butt;stroke-linejoin:miter;stroke-miterlimit:10"
     transform="translate(0,1.3157895)">
    <rect
       width="100"
       height="500"
       x="200"
       y="0"
       id="rect8"
       style="fill:#008000" />
  </g>
  <path
     sodipodi:type="star"
     style="opacity:1;color:#000000;fill:#000000;fill-opacity:1;fill-rule:nonzero;stroke:none;stroke-width:1px;stroke-linecap:butt;stroke-linejoin:miter;marker:none;marker-start:none;marker-mid:none;marker-end:none;stroke-miterlimit:4;stroke-dasharray:none;stroke-dashoffset:0;stroke-opacity:1;visibility:visible;display:inline;overflow:visible;enable-background:accumulate"
     id="path2195"
     sodipodi:sides="3"
     sodipodi:cx="-300"
     sodipodi:cy="34.210526"
     sodipodi:r1="168.59059"
     sodipodi:r2="83.310097"
     sodipodi:arg1="0.52301831"
     sodipodi:arg2="1.5702159"
     inkscape:flatsided="false"
     inkscape:rounded="0"
     inkscape:randomized="0"
     d="M -153.94736,118.42106 L -299.95164,117.52061 L -445.95478,118.59056 L -372.17283,-7.4026388 L -300.09786,-134.38004 L -227.87553,-7.4863929 L -153.94736,118.42106 z "
     transform="translate(552.63158,244.73684)" />
</svg>

HGZH --PerfektesChaos 13:30, 9. Nov. 2012 (CET)

Ich habe es gestrafft, weil ich den Punkt in der Ausführlichkeit weder für verständlich noch für wichtig halte. --Schotterebene (Diskussion) 15:41, 9. Nov. 2012 (CET)

Okay, vielen Dank für die Aufklärung, jetzt verstehe ich es auch. Beste Grüße 217.5.205.2 12:37, 18. Nov. 2012 (CET)

Gerne, und danke fürs Feedback... Viele Grüße --Schotterebene (Diskussion) 14:18, 18. Nov. 2012 (CET)

erledigtErledigt

Einbindung von SVG in HTML

Mir ist aufgefallen, dass mit dem <img>-Tag eingebundene SVG-Dateien ihre interaktiven Eigenschaften verlieren, obwohl der gleiche Browser die per Javascript eingebaute Dynamik "spielen" kann, wenn er das SVG direkt darstellt. Die Lösung scheint das <object>-Tag zu sein. (Ich taste mich langsam vor) --B-greift (Diskussion) 23:08, 17. Mai 2014 (CEST)

SVG-Unterstützung in Browsern veraltet?

Angesichts der Versionsnummern der Browser (Jahr 2011?) scheint dieser Abschnitt überprüfungswert. (nicht signierter Beitrag von 194.59.36.73 (Diskussion) 12:00, 24. Mär. 2015 (CET))

Das dachte ich mir auch gerade, zumal ja nichtmal mehr die Browserliste halbwegs in die heutige Welt passte (Edge? Mobil-Browser?). Eine aktuellere Übersicht der Ergebnisse der offiziellen Testsuite habe ich nicht gefunden, deshalb habe ich die prominente Tabelle aus dem Artikel entfernt und nur den besten und schlechtesten Wert in den Text übernommen, mit Stand-Angabe. Auch den Satz "Verschiedenen Quellen zufolge wird SVG bei ca. 80 % der Internet-Nutzer mindestens rudimentär interpretiert" habe ich entfernt - hier etwa wird für 94,75 % der verwendeten Browser volle und zumindest für 96,46 % zumindest teilweise Unterstützung angegeben, wobei sich das auf einen "basic support" bezieht, ohne dass dabei ganz klar wird, ob damit das Basic-Profil von SVG gemeint ist und ob "full" bzw. grün tatsächlich etwa die 100% in der SVG Test Suite meint oder nach eigenen Kriterien ermittelt wurde.

Da der Artikel schon vorher den Acid3-Test als praxisnäheren Indikator für SVG-Unterstützung nannte, habe ich bei jener Nennung mal ergänzt, seit wann die Mainstream-Browser dort jeweils die 100 % erreichen (das war bei drei von 5 übrigens schon deutlich vor dem Datum unserer Test-Suite-Ergebnisübersicht, bei der diese zwischen 82 und 95 % erreichten). --YMS (Diskussion) 15:49, 29. Dez. 2015 (CET)

Wenn ich das richtig in Erinnerung habe, testet Acid3 primär Skriptinterpretation und auf SVG bezogen auch nur sehr rudimentär, das sagt noch weniger als die offiziellen Test-Suiten des W3C zu SVG darüber aus, wie gut die Interpretation wirklich ist. Im deutschen wikibook zu SVG gibt es zu jedem Element oder Attribut grobe Angaben zu gängigen Programmen. Ich war da aber auch nicht sehr motiviert, das immer wieder zu aktualisieren, denn zwar ändern sich bei diversen Programmen die Versionnummern inwischen sehr schnell, die Interpretation von SVG stagniert aber mehr oder weniger in den letzten Jahren. Eine 5 Jahre alte Statistik ist also nicht zwangsläufig so schlecht, einfach weil in fünf Jahren nicht so viel verändert wurde. Auch die von mir veröffentliche systematische Testumgebung zur Animation mit SVG aktualisiere ich nur sporadisch mal, auch weil sie an den Fehlern der Programme wenig ändert, bei Firefox teste ich da inzwischen nur noch jede zwölfte Version, auch weil es recht aufwendig ist, die Ergebnisse aber immer sehr ähnlich. Bei Microsoft, WebKit, Mozilla ist man einfach nicht motiviert, das Fornat in irgendeiner Version oder irgendeinem Profil korrekt und vollständig zu interpretieren, man wählt eben willkürlich aus, was man implementiert und das dann jeder Anbieter etwas anders oder auf anderen Bibliotheken basierend, woraus sich dann ergibt, daß man über Jahre dieselben Fehler und Lücken findet, an denen gar nicht gerarbeitet wird. Doktorchen (Diskussion) 18:23, 31. Dez. 2015 (CET)

Abschnitt Animation

In dem Abschnitt stehen einige verwirrende Behauptungen, etwa:

a) 'Da eine SVG-Datei intern eine DOM-Struktur aufweist, kann diese durch die vorhandenen Browser-Techniken, wie ECMAScript und CSS immer zur Laufzeit verändert und dadurch eine animierte Grafik generiert werden.'

Man kann für SVG-Dokumente über das XML-DOM und die SVG-Erweiterungen dazu etwa mit Skripten die DOM-Repräsentation und damit dann gegebenenfalls auch die Präsentation zeitabhängig ändern, nicht aber die Datei selbst oder im engeren Sinne eine Animation durchführen. Speichert man mit einem geeigneten Programm die manipulierte DOM-Repräsentation wieder ab, hat man wieder ein statisches Dokument, wenn man nicht über die DOM-Manipulation selbst Animations-Elemente hinzugefügt hat. Das eine hat mit dem anderen nur bedingt etwas zu tun. Die Animation kann insbesondere deklarativ über die dafür in SVG verfügbaren Elemente realisiert werden. Diese reichen zwar auch aus, um etwa anwendbare CSS-Eigenschaften zu animieren, für beides ist aber eigentlich nicht gefordert, daß ein Darstellungsprogramm eine bestimmte Skriptsprache interpretieren müßte oder eine DOM-Struktur verwenden müßte. Mit CSS ist bei den tiny-Varianten zudem gar nichts machbar, weil dafür nur Präsentationsattribute vorgesehen sind und keine alternativen Stilvorlagen per CSS. Bei SVG 1.1 ist wiederum genau angegeben, welche CSS-Eigenschaften anwendbar sind - und die beinhalten keine Funktionalität für Animationen (allenfalls mit :hover oder :focus kann man etwas per CSS ändern). Für Skripte und Stilvorlagen gibt es doch eigene Abschnitte, von daher sind Anmerkungen dazu in diesen Abschnitten sicher besser aufgehoben.

b) 'Die Entwickler von Webkit haben auch einen Entwurf für CSS-Animationen entwickelt, der in den offiziellen CSS3-Standard beim W3C einfließen soll.[9][10]'

Das ist ja zum einen noch in Arbeit, zum anderen auf SVG 1.1 oder SVG 1.2 nicht anwendbar, daher hier wohl nicht relevant. Über die Jahre haben da bereits viele Leute ihren Senf dazugegeben, was die Arbeitsentwürfe verändert hat, ich auch schon. Für SVG 2 könnte es mal relevant werden, aber für den Arbeitsentwurf SVG 2 sollte man dann wohl einen eigenen Abschnitt spendieren, das ist ja keine Empfehlung. Für Animation arbeitet im übrigen inzwischen eine spezielle Arbeitsgruppe an einer vereinheitlichten Schnittstelle, die intern in dem Programmen diverse Varianten von Animationen abdecken können sollen (die fx-Gruppe). Anmerkungen über CSS-Arbeitsentwürfe sind dann wohl auch besser in einem Artikel über CSS aufgehoben, insbesondere wenn sie für derzeitige aktuelle Empfehlungen zu SVG gar nicht anwendbar sind (unabhängig davon, ob einige Darstellungsprogramme fehlerhaft arbeiten mögen und das trotzdem vielleicht auf Dokumente in den Versionen 1.1 oder 1.2 anwenden).

c) 'Zustände, welche animiert werden können, sind Transformation, Position, Sichtbarkeit, Farbe und Größe.'

Da gibt es wohl deutlich mehr und das sollte man wohl nicht verwirrend als Zustände bezeichnen, sondern präziser: Zum einen sind Attribute und Eigenschaften im einzelnen gekennzeichnet, welche animierbar sind - und das sind ziemlich viele, die über diese paar Sachen hinausgehen, zum anderen kann man mittels animateMotion Elemente bewegen, was nicht direkt von der Animation von Attributen abhängt.

d) 'Wichtig für das Verständnis von Animationen sind die Begriffe „Darsteller“ (das zu animierende Objekt) und „Drehbuch“ (die Zeitspanne der Animation).'

Der Satz hat mich schon lange erstaunt, SVG-Animationen schreibe ich seit 2004, war sogar einige Zeit eingeladener Experte der SVG-Arbeitsgruppe des W3C, habe eine große, systematische Testumgebung zur deklarativen Animation, Begriffe wie „Darsteller“ und „Drehbuch“ haben da aber nie eine Rolle gespielt. Woher stammt die Idee, daß die Begriffe wichtig für das Verständnis sind? Da wären ganz andere Begriffe wichtig. Animiert werden eben Attribute, Eigenschaften oder die Position von Elementen entlang eines Pfades, keine Darsteller. Der präzise Zeitablauf ist in der SMIL-Empfehlung beschrieben und wird vom Autor mit Attributen in den Animationselementen festgelegt, nicht in einem Drehbuch.

e) 'Im nebenstehenden Beispiel ist die Füllung (style-Attribut) eines Rechtecks sowie dessen Transformation (transform-Attribut) über die Dauer von fünf Sekunden animiert. ...'

Das Beispiel enthält doch gar keine Animation. Die Füllung kann man zudem ganz unabhängig davon animieren, ob sie irgendwo als Attribut oder Eigenschaft notiert ist, die Priorität der Animation muß nur hoch genug sein, damit man einen sichtbaren Effekt hat. Das Attribut style kann man natürlich nicht animieren.

Doktorchen (Diskussion) 16:12, 30. Jun. 2015 (CEST)

'Teilrevert' Dokumenttypdeklaration

Ich halte die vorherige Formulierung für angemessen. Technisch problematisch für die Präsentation war die Dokumenttypdeklaration nie. Bekannt ist natürlich seit langem, daß mit einer DTD viele Strukturen, besonders einige Gebote der Verschachtelung und auch die möglichen Attributwerte nicht korrekt abgebildet werden können. Andere Schema-Sprachen können etwas mehr, aber auch nicht alles leisten. Von daher ist es eine Binsenweisheit, daß die Prüfung lediglich Hinweise auf einige mögliche Fehler liefern kann. Wer weitere Namensräume verwendet, weiß natürlich auch, daß diese nicht in der DTD berücksichtigt sind - oder nicht präzise abgebildet. Mit derartigen Fehlalarmen muß man bei einer Validierung immer umgehen können, auch bei anderen Schema-Sprachen, daher gibt es ja die Prosa-Spezifikationen, wo man dann die Meldung prüfen kann.

Da die Formulierung nur in einer Empfehlung zu finden ist, in anderen nicht, der Artikel aber allgemein um SVG geht, erscheint es mir weiterhin plausibel, auf den Sachverhalt kurz einzugehen und die Möglichkeiten zu erläutern, statt aus einer überarbeiteten Version einen nicht normativen Satz herauszupicken und deswegen das gesamten Konzept der Prüfung in Frage zu stellen - ohne hat man noch ärgere Probleme mit der Qualität von Dokumenten, das entwickelt sich dann leicht zu der Markierungssuppen-Katastrophe, die von HTML hinlänglich bekannt ist, mit allen Folgeproblemen, denen man heute in HTML begegnet, einschließlich HTML5.

Daher also nicht nur einseitig das Problem benennen, sondern neutral den Stand der Dinge erläutern.

Doktorchen (Diskussion) 09:40, 30. Okt. 2017 (CET)

Geprüft werden sollte tunlichst vor der Verwendung. Dafür ist aber die Angabe der DTD im Dokument unnötig.

Ad "nur in einer Empfehlung zu finden, in anderen nicht": Das ist wohl eine Frage der Zeit. Aber ich kann mich natürlich irren und für SVG 2.0 wird wieder eine DTD angegeben. Warten wir ab? --Rainald62 (Diskussion) 15:30, 30. Okt. 2017 (CET)

Fraglich, ob SVG 2.0 in näherer Zukunft zur Empfehlung wird, vom den ursprünglichen Anforderungen steht ohnehin kaum noch etwas drin, was die Bezeichnung 2.0 rechtfertigt und selbst beim Rest haben die Entwickler der Browser jedenfalls auch keine Lust zur Umsetzung. Im Sinne einer Weiterentwicklung von SVG für Autoren war das ein Schuß in den Ofen, eine Menge vergeudete Zeit, auch leider von mir.

Eine DTD wird es da auch wohl nicht geben, nach dem, was ich so mitbekommen habe oder wo ich mitdiskutiert habe.

Die Empfehlungen sind ja nicht zeitabhängig, nach meiner Meinung auch ein Mangel, daß die Überarbeitungen von 1.1 nicht mit einer neuen Version versehen wurden, ist schlampiges arbeiten, denn das führt zu Widersprüchen in der Interpretation von Dokumenten, ist ja nicht klar, welcher Empfehlung dann gefolgt wird. Aber da herrscht beim W3C eher die Schlamperei jener Entwickler vor, die sich mit HTML5 auch an (X)HTML vergangen haben ;o)

Im Text jedenfalls könnte ich kurz und etwas genauer darauf eingehen, wo der Haken der DTDs und der Prüfungen ist. Die Deklaration steht nun einmal in vielen bereits veröffentlichten Dokumenten mit Version 1.0 und 1.1. Von daher sollten die Leser im Text auch erfahren, wozu das ursprünglich gedacht war - und dann auch, warum man es heute bei veröffentlichten SVGs eher nicht mehr braucht, es aber auch nicht wirklich schadet. Der Artikel beschreibt ja eher, was ist, nicht zwangsläufig, wie es optimal laufen sollte, worauf man der Referenz folgen kann und neutral drauf hinweisen. Hilft dann vielleicht eher, die Angabe der DTD bei erneuten Veröffentlichungen zu streichen.

Prüfen kann natürlich jeder, auch nach der Veröffentlichung, die Angabe erleichtert das jedenfalls in dem Maße, wie eine SVG-Datei mit dem Schema prüfbar ist. Mit anderen Schemata mag man dann vielleicht mehr prüfen könnten, eine normative Einbindung einer Referenz zu einem anderen Schema hat man aber bislang beim W3C wohl versäumt.

Doktorchen (Diskussion) 20:50, 31. Okt. 2017 (CET)

Die Ergänzung erscheint mir an der Stelle, wo ich sie gelöscht hatte, unangemessen. Vielleicht als eigener Absatz vor oder nach dem Absatz #SVG-Interpretation_in_Darstellungsprogrammen. --Rainald62 (Diskussion) 23:44, 4. Nov. 2017 (CET)

Änderungsvorschlag zur „Interoperabilität bei Office-Software“

Hier mein Vorschlag für den Abschnitt. Der SVG-Import wurde wohl erstmal durch ein Update von Office 2016 eingeführt. Ob das dann aber nur die Windows-Version oder auch die von Android, iOS und macOS mit umfasste kann ich auf die Schnelle nicht finden. Vielleicht weiß da jemand mehr. --net (Diskussion) 09:12, 23. Jul. 2019 (CEST)

Interoperabilität bei Office-Software

Der Import von SVG ist ab Microsoft Office 2016 möglich und steht mittlerweile auf allen Plattformen zur Verfügung.. Ebenso unterstützen LibreOffice und Apache OpenOffice den Import von SVG.

Aktuelle Änderungen am Abschnitt Pfad

Also, R und B sind leider bereits wieder (wie fast alle neuen Merkmale) aus SVG 2 gestrichen worden (weil nicht oder fast nicht implementiert). Das kann also sicherlich wieder weg. Zudem ist SVG 2 derzeit offenbar wieder mehr oder weniger im Stadium eines Arbeitsentwurfs eines Editors, da wird also vermutlich aus der Empfehlung so schnell nichts, daher lohnt es sich wohl wegen der zahlreichen Streichungen nicht mehr, irgendwas von SVG 2 in einem solchen Übersichtsartikel zu erwähnen.

Zu den elliptischen Bögen: Da wird nichts abgebrochen, wenn die Parameter nicht passen, die werden automatisch angepaßt, steht im Detail im Anhang der Empfehlung: [20]

Doktorchen (Diskussion) 16:54, 3. Jan. 2021 (CET)

R und B würde ich vorerst drin lassen. Bei falschen parametern ist das Ergebnis nicht immer so, wie in diesem Dokument beschrieben. Kann man aber erwähnen. ÅñŧóñŜûŝî (Ð) 18:04, 3. Jan. 2021 (CET)

Ich meine, für R ist sich die Arbeitsgruppe bislang nicht einmal einig, was das bedeuten soll. An der Diskussion habe ich mich vor Jahren auch mal beteiligt, konkrete Vorschläge gemacht. Was für Autoren wirklich hilfreich sein könnte, insbesondere bei geschlossenen Kurven, ist aber bei einigen Arbeitsgruppenmitgliedern der Brauser-Anbieter nicht auf Begeisterung gestoßen, weil man sich dazu vor der Präsentation alle Daten eines Unterpfades ansehen müßte. Doug Schepers hat danach wohl nie wie vorgesehen einen konkreten Vorschlag ausgearbeitet, das Unternehmen R hängt also. Vermutlich ist Doug Schepers wie ich und einige andere Leute, welche mal in der Arbeitsgruppe waren oder noch sind, derweil ziemlich frustriert über die Stagnation von SVG-Implementierungen, daraus ergibt sich nicht viel Motivation, die Spezifikationen noch voranzubringen. Zu Zeiten von SVG tiny 1.2 (da war ich noch eingeladener Experte der Arbeitsgruppe) wurde noch effizient gearbeitet, heute sieht mir das leider nicht mehr so aus. Teils scheint sogar sabotiert zu werden, weil einige Leute gar keinen weitergehenden Standard mehr möchten, lieber ihr Konzern-eigenes Süppchen kochen, was auch bei CSS und (X)HTML der Fall ist, insgesamt also eher ein Verfall des W3C.

B wurde ausgearbeitet, stand auch mal im Entwurf, wurde aber wieder rausgeworfen. In einem philosophisch ausgerichteten Buch zum Thema Historie von SVG kann man das wohl erwähnen, in solch einem Artikel ist es aber bloß Spekulation über die mögliche Zukunft des Formates, für welche es keine hinreichenden Belege gibt. Ob SVG 2 jemals eine Spezifikation wird, scheint auch zweifelhaft zu sein - nachdem sowieso alles relevant Neue bereits wieder gestrichen wurde, die einstigen Anforderungen sowieso nie erfüllt wurden. Was jedenfalls seit 2011 wieder gestrichen wurde, kommt bei SVG 2 nicht mehr rein, bestenfalls in zig Jahren mal in SVG 3, sofern damit jemals begonnen wird.

Für elliptische Bögen habe ich selbst mal ausgiebig getestet, sogar für die Nutzer der tiny-Variante mal eine Näherung mit kubischen Bögen entwickelt - da habe ich nie irgendwelche Probleme gesehen, allerdings können die Ergebnisse korrekter Implementierungen überraschend für Autoren sein, was man besonders bei Animationen solcher Pfaddaten merkt - das überraschende Verhalten stimmt bei den von mir getesteten Brausern aber mit der Spezifikation überein - ich meine, es gibt insbesondere bei der Animation auch noch Implementierungsfehler. Davon gibt es aber auch sonst sehr viele. Es ist insgesamt auch nicht sinnvoll, auf alle Fehler von Programmen in solch einem Artikel einzugehen.

Beim wikibook zu SVG habe ich teilweise auf einige Probleme hingewiesen, da sind ausführliche Informationen besser untergebracht als hier. Bei wikipedia gibt es ja eher die Tradition, auch Trivialitäten per Referenz belegen zu sollen, das wäre ja nun mindestens fällig, wenn irgendwelche fehlerhaften Implementierungen wirklich derart relevant sein sollten, daß man sie hier erwähnen müßte - denn die haben ja sehr wenig mit dem Format zu tun und können in anderen Programmversionen schon wieder behoben sein, da bräuchte es also Verweise zu Testergebnissen einer passenden Testsuite. Meine hat eher den Schwerpunkt Animation, hilft also nur bedingt weiter, wenngleich man die Implementierungsfehler beim d-Attribut gerade bei Animation sehr gut erkennen kann.

Doktorchen (Diskussion) 18:53, 3. Jan. 2021 (CET)

Ich sehe hier kein großes Problem darin, dass das in Bewegung ist (oder auch nicht). Solange das nicht offiziell abgeblasen wird, kann es m. E. drin bleiben. ÅñŧóñŜûŝî (Ð) 04:44, 4. Jan. 2021 (CET)

Wir können auch mal andersherum fragen: Wozu sollte das hier gut sein, wenn diese Kommandos in keiner Empfehlung zu SVG stehen, sie also faktisch für die nächsten zig Jahre gar nicht zu SVG gehören? Da gäbe es haufenweise andere Merkmale, die mal angedacht waren, aber eben nicht aufgenommen wurden. Gibt es denn irgendein dir bekanntes Programm, welches dies interpretiert? sind diese Kommandos in den Anleitungen zu diesem Programmen dokumentiert? Selbst wenn, gehört das noch immer nicht zu SVG, solange es in keiner Empfehlung steht. Da es weder formal zu SVG gehört noch praktisch in gängigen Darstellungsprogrammen funktionieren dürfte (habe es selber nie getestet), verwirrt dies doch eher die Leser des Artikels statt irgendeine relevante Information bereitzustellen. Es fehlen also mindestens Belege, daß das zu SVG gehört und wo das praktisch funktioniert, besser entsprechend auch Testbeispiele, etwa in der offiziellen Testsuite der SVG-Arbeitsgruppe des W3C, anhand der nachvollzogen werden kann, ob ein Darstellungsprogramm die Kommandos korrekt interpretiert. Zum derzeitigen Zeitpunkt (inklusive mindestens der nächsten 10 Jahre) scheint mir der Kram praktisch völlig irrelevant zu sein. Wie schon damals 2011 in den Anforderungen zu SVG 2 festgestellt, wären derartige Merkmale enorm nützlich gewesen, trotzdem hat man inzwischen in SVG 2 praktisch auf alles Neue verzichtet, was für Autoren hätte nützlich sein können. Eine Fiktion davon, was hätte sein können, nützt aber den hiesigen Lesern gar nichts, welche wissen möchten, was wirklich ist.

Doktorchen (Diskussion) 10:12, 4. Jan. 2021 (CET)