Beispiele und Tests zur Animation mit SVG

Status des Projektes

2005-08 habe ich mit dem Projekt begonnen. Systematische Stichproben sind weitgehend bis Ende 2005-12 fertiggeworden. Von Zeit zu Zeit werden ein paar Beispiele ergänzt, verfeinert oder korrigiert.
Die derzeitige Arbeit besteht darin, mehr quantitative Tests anzubieten. Entweder sollte es direkt möglich sein festzustellen, ob ein Darstellungsprogramm einen Fehler macht oder durch Lesen der kurzen Beschreibung, ohne in den Quelltext zu gucken. 2005 war folgende Frage im Zentrum des Interesses: Animiert es? Die aktuelle Arbeit ist bereits mehr auf die Fragen konzentriert: Wie genau ist die Animation? Welches Beispiel ist nützlich, um zügig zwischem korrektem und falschem Verhalten zu unterscheiden, ohne in die Details des Quelltextes zu sehen? Dies sollte diese Tests verbessern, sowohl in Richtung höherer Genauigkeit und Qualität der Testbeispiele als auch der Darstellungsprogramme.

Wie steht es um SVG-tiny 1.2? Einige Teile von SVG-tiny 1.1 sind beseitigt worden, einige neue Fähigkeiten sind ergänzt oder von basic übernommen worden. Andere sind verändert worden, bedingt durch Änderungen in SMIL oder direkt in der SVG-tiny-Spezifikation. Tests werden als Ergänzungen der SVG 1.1 Tests angeboten, nicht als unabhängige Zusammenstellung.

Zu beachten ist, daß die Tests typisch älter als die zweite Ausgabe von SVG 1.1 (2011-08-16) sind, daher, falls nicht anders angegeben und falls es rückwärtsinkompatible Änderungen in der der zweiten Ausgabe gibt, wird nur die erste Ausgabe getestet - ich werde mich um das Problem kümmern. Die erste Ausgabe zu testen, ist sinnvoll, weil viele Versionen von Darstellungsprogrammen auch vor der zweiten Ausgabe veröffentlicht worden sind.

Und bitte - falls Fehler oder Fehlinterpretationen in diesem Dokument entdeckt werden, bitte ich darum, mir diese unverzüglich zur Kenntnis zu bringen. Selbst wenn der Zweifel nicht gesichert werden konnte, werde ich über das Problem nachdenken. Inzwischen habe ich selbst bereits verschiedene Fehler entdeckt und beseitigt, oft ist es allerdings nicht einfach, Fehler in eigenen Dokumenten zu finden.
Wie bereits aus der Lehre an Universitäten bekannt ist, lernt der Dozent mehr als die Studenten, wenn er eine neue Vorlesung vorbereitet ;o)

Navigation, Gestaltung und Zugänglichkeit

Sofern das Darstellungsprogramm selbst ein Seitennavigationsmenü anbietet (wie dies bei einer kompletten Interpretation von HTML2, HTML3.2, HTML4.01, XHTML1.0, XHTML1.1, XHTML+RDFa1.0 der Fall sein sollte), kann dieses zur Navigation im kompletten Projekt bequem genutzt werden. Wenn nicht, so sind Verweise zu Kapiteln, Abschnitten und Unterabschnitten oben zu finden. Kapitel und der Index sind ebenfalls über den kleinen Navigationsbereich auf jeder Seite erreichbar.
Falls das Darstellungsprogramm CSS interpretiert: Neben dem hellen 'minimal-Stil' sind zur Annehmlichkeit als alternativer Stil auch ein 'dunkler Stil' und 'kein Stil' verfügbar. Einfach mal in die Stil-Navigation des Darstellungsprogrammes gucken. Falls das Darstellungsprogramm kein XHTML oder keine XML-Stilvorlagen-Verarbeitungsanweisungen versteht, ist auch das CSS ohne Bedeutung.

Tests

Systematische Tests wurden vor allem mit verfügbaren Darstellungsprogrammen auf Debian-Linux (zuererst vor allem auf Version 3, dann auch auf 5 und 6, aktuelle stabile Variante) durchgeführt.

Zusätzlich wurden die Stichproben mit dem Prüfprogramm (Validator) von W3C getestet. Das bedeutet, die Beipiele haben die Prüfung bestanden, es handelt sich also um einen Test der Dokumente, nicht des Prüfprogrammes. Allerdings prüft dieses Programm nicht die Werte aller Attribute und mit diesem Test ist nicht garantiert, daß die Beschreibungen zu den Beispielen korrekt sind.

Anbieter anderer bislang nicht getesteter Darstellungsprogramme möchten ihre Produkte eventuell ebenfalls hier getestet haben. Dies kann ich tun, wenn ein (stabiles) Debian-Programmpaket angeboten wird. Ein einfach zu installierendes statisches tar.gz (komprimiertes Archiv) mag ebenfalls funktionieren. Seit 2009-01 ist windows vista ebenfalls verfügbar.

Testergebnisse sind mit 'ok' oder 'ko' ('fail') gekennzeichnet. Letzteres gibt ein Scheitern des Tests, also einen Fehler an und die Hintergrundfarbe ist modifiziert (nur in CSS) - rot steht für 'komplett falsch oder ignoriert', orange für 'teilweise richtig' und gelb gibt an, daß kleinere Fehler vorliegen, nicht im Hauptaugenmerk des Tests. Wenn was falsch ist, wird meist ein kurzer Kommentar angefügt, woran man den Fehler erkennen kann. Allerdings sollte der Nutzer in den Quelltext des Beispiels sehen, wenn er das Verhalten selbst beurteilen möchte.
Eine Zusammenfassung aller Tests wird im Kapitel 'Testergebnisse und Anzeigewahrscheinlichkeit' angeboten.
Derzeit vernachlässigen alle Tests progressives Darstellen. Effekte durch progressives Darstellen zu Beginn eines Dokumentes sind kein Anzeichen für einen fehlgeschlagenen Test und können für solche Tests vernachlässigt werden.

Die Tests werden mit zusätzlichen Indikatoren markiert. Dies kann genutzt werden, um zu identifizieren, welche Art von Test erwartet werden kann. Der Gesamtindikator beginnt mit § gefolgt von Einzelindikatoren. Die Reihenfolge ist wichtig, es beginnt mit dem wichtigsten Indikator für das Testen.
Ein Beispiel ist: §M(1)PU.
Die folgende Tabelle erläutert die Bedeutung der Indikatoren:

Bedeutung der Testbeispielindikatoren

Indikator	Bedeutung	Erklärung
P	Präzisionstest	Hiermit ist es möglich, sehr genau zu sehen, ob eine Animation korrekt abläuft.
Q	Qualitativer Test	Es wird nicht erwartet, daß Tester in der Lage sind, die Animation sehr genau zu testen, die Frage ist eher: Animiert es irgendwie plausibel?
U	Unterhaltung, Lehrbeispiel	Der Schwerpunkt dieses Beispieles ist es zu sehen, ob etwas in einem komplizierteren Beispiel ebenfalls funktioniert, eventuell nützlich, um etwas über SVG-Animation oder über das Thema der Animation selbst zu lernen.
A	Anwendung	Beispiele dieses Typs sind dem U-Typ ähnlich, eventuell kann dies zu einer Anwendung führen oder kann bereits als Anwendung genutzt werden.
F	Fehlerbehandlung	Tests dieses Typs sind nicht als nützliche Beispiele gedacht, sie testen hauptsächlich die Fehlerbehandlung von fehlerhaften Dokumenten, falls dies von einer Fehleranzeige abweicht.
X	eXperimentell	Diese Beispiele zielen hauptsächlich auf einige (für mich) unklare Bereiche der Spezifikation. Ich bin mir nicht sicher, ob sie wirklich für SVG relevant sind. Wer mehr weiß, schicke mir bitte eine Nachricht.
S	Spezifikation	Diese Beispiele kümmern sich um Inkonsistenzen und Fehler in den Spezifikationen. Manchmal können die Fehler aufgelöst werden, um trotzdem ein richtiges Verhalten zu erhalten, manchmal sind auch nur Indikatoren angegeben, was die Probleme sind und welches Verhalten inkonsistent ist.
I	Interaktion	Beispiel mit Interaktion, nicht warten, wie im Text beschrieben handeln. Interaktive Elemente sind oft mit einem blauen Rand gekennzeichnet.
M(1)	fauler, Müder Tester Modell 1	Dies ist speziell für schnelle Tests ausgelegt. Farben und Verhalten sind immer die gleichen - das animierte Objekt ist blau, Trajektorien und Hilfsobjekte sind grau und falls etwas Rotes auftaucht, ist der Test fehlgeschlagen.
M(2)	fauler, Müder Tester Modell 2	Ähnlich M(1), aber die Indikation mit rot für Fehlschlag ist nicht oder nur teilweise möglich. Bei Farbanimationen kann für stroke auch der gleiche sichtbare Effekt wie für fill mit einfacheren Mitteln realisiert sein, es darf dann also keine Unterschiede zwischen fill und stroke geben.
M(3)	fauler, Müder Tester Modell 3	Dies ist ein Modell für korrelierte Animationen. Das unabhängige Element ist dunkelblau, das abhängige hellblau. Die Farben sind grau, wenn das Element nicht in der aktiven Dauer der Animation ist. Bei Farbanimation wird die Korrelation für fill gestestet, während stroke den gleichen sichtbaren Effekt ohne Korrelation aufweist.