english version
Projekt-Start: 2005-08
Aktueller Stand: 2018-08
Angeboten wird ein Testensemble zur deklarativen Animation mit SVG
Tiny 1.1, SVG 1.1
und SVG Tiny 1.2 mit mehr als
1400 Beispielen für alle animierbaren Attribute und Eigenschaften und alle
Attribute und Elemente zur Animation.
Testergebnisse liegen für folgende Darstellungsprogramme vor:
Amaya, KSVG, das Adobe plugin, Renesis-player, Squiggle/Batik, Opera,
diverse Varianten von WebKit (Safari, Google Chrome, Chromium, QT4-Variante, GTK-Variante), Mozilla Gecko, microsoft internet-explorer.
Die Testergebnisse werden einschließlich einer Wahrscheinlichkeitsangabe für die korrekte
Anzeige eines zufällig gewählten Animationsbeispiels diskutiert.
Eine signifikante Verbesserung der Darstellungsprogramme ist notwendig, damit sich Autoren auf
ihre Werke konzentrieren können und nicht auf die Fähigkeiten der Darstellungsprogramme.
(derzeit nur in englisch)
SVG bietet als standardisiertes Format einem Autor die Möglichkeit, ohne besondere
Werkzeuge Animationen zu realisieren. Wie bei (X)HTML ist auch bei SVG dafür nur
ein einfacher Texteditor notwendig, andere Programme sind aber auch nicht ausgeschlossen.
Ähnlich wichtig ist, daß deklarative Animation eine beschreibende Methode ist,
die Elemente haben eine definierte und verstehbare Bedeutung, SVG beschreibt, was
passieren sollte, legt aber nicht fest, wie dies zu erreichen ist. Dies ist Aufgabe des
Darstellungsprogrammes, nicht des Autors des Dokumentes.
Mit der Digitalisierung geht ja auch ein gewisser Verlust der Kontinuität einher -
mit deklarativer Animation ist das nicht der Fall, eine kontinuierliche Animation
bleibt im Dokument kontinuierlich, ganz egal, wie sie letztlich dargestellt wird.
Derzeit ist das praktisch immer eine Abfolge von Einzelbildern, aber warum sollte
es in Zukunft nicht Techniken geben, die kontinuierliche Abläufe auch
kontinuierlich darstellen können? Ein klassisches Oszilloskop kann das
bereits heute. Und SVG ist ein Format, mit dem ein Autor bereits heute
formulieren kann, was kontinuierlich dargestellt werden sollte.
Gleichzeitig eignet sich dieses Format besonders für Anwendungen im internet.
All dies galt für bisherige Formate wie GIF-Animationen oder
macromedia flash nur eingeschränkt.
Deklarative SVG-Animationen sind für Autoren und Nutzer komplett zugänglich.
Bei der Nutzung von SVG habe ich allerdings beobachtet, daß viele
Darstellungsprogramme insbesondere mit
deklarativer Animation verschiedener SVG-Attribute noch Probleme
haben. Manchmal ist es nicht einfach, ein Beispiel für die Animation eines nicht so
allgemein gebräuchlichen Attributes zu finden, um Darstellungsprogramme zu
testen oder auch nur eine Animation zu realisieren.
Die offiziellen Testeinrichtungen für SVG bieten lediglich eine
kleine Auswahl von Beispielen für wenige Attribute an.
Daher habe ich mich entschieden, einfach Beispiele oder
Stichproben zur Animation aller Attribute anzubieten, die in
SVG-tiny enthalten sind,
ferner klar davon getrennt weitere Stichproben für alle weiteren Attribute
in SVG 1.1, die nicht Teil von SVG-tiny
sind.
Die hiesigen Kapitel sind mit denen der SVG-Spezifikation durch den Titel korreliert, nicht durch die Numerierung, weil es für die Nutzer einfacher ist, mit einfacheren Beispielen zu grundlegenden Formen zu beginnen, wobei angenommen wird, daß die SVG-Interpretation ohne Animation bereits weitgehend korrekt ist.
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)
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.
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:
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. |