Dr. O. Hoffmann
Je weiter die Menschheit kommen würde,
desto wissenschaftlicher die Kunst wird.
Gustave Flaubert
Ausschneiden von Inhalten, englisch 'clipping' ist mit
dem clipPath
-Element und der Eigenschaft clip-path
möglich. Der Pfad schränkt das Gebiet ein, in welchem gezeichnet werden
kann. Mit der Eigenschaften clip-path
wird beim betroffenen Element
der Ausschnitt referenziert, der zuvor festgelegt wurde. Mittels clip-rule
mit den Werten nonzero, evenodd oder inherit
wird entsprechend fill-rule
festgelegt, wie bei
Überschneidungen vorzugehen ist.
Mit dem Attribut clipPathUnits
= "userSpaceOnUse"
"objectBoundingBox" wird angegeben, welche Koordinaten verwendet werden sollen.
Die mobile-Spezifikation erwähnt nur SVG basic in Zusammenhang mit diesem Element, woraus
wohl geschlossen werden soll, daß SVG tiny dieses Element nicht enthält,
daher mit Opera 8 auch nicht nachvollziehbar, mit Version 9 schon.
Mit den KSVG-plugin oder dem adobe-plugin ist die Darstellung kein Problem.
Ausschneiden 1 -
Vergleichsbild mit eingezeichneten clip
-Pfaden
(Quelltext zum
Ausschneiden 1)
Ausschneiden 2 -
Vergleichsbild mit eingezeichneten clip
-Pfaden
(Quelltext zum
Ausschneiden 2)
Auf Elemente, welche einen eigenen 'viewport' haben, kann statt clip-path
clip
entsprechend CSS angewendet werden:
clip
= "rect(oben rechts unten links)". In Beispielen und
in CSS2.1 wird hingegen clip
= "rect(oben, rechts, unten, links)"
verwendet - ist also ungewiß, wie dies korrekt zu notieren ist, die Variante mit Kommata scheint
bei der Mehrheit der Darstellungsprogramme besser zu funktionieren.
Dabei bezeichnen die Werte jeweils, wieviel vom Rand aus gesehen abgeschnitten wird, zum Merken
ist die Reihenfolge im Uhrzeigersinn, oben angefangen. CSS2.1 definiert eine andere Bedeutung der Werte.
Das ermöglicht es insbesondere, bei einem per image
eingebundenen
Bild den angezeigten Ausschnitt festzulegen:
Bildausschnitt
(Quelltext zum
Bildausschnitt).
Animierter Bildausschnitt
(Quelltext zum animierten
Bildausschnitt).
Man beachte, daß Opera seit Version 9.5 clip
falsch interpretiert.
Bei Opera 9.0x, 9.1x, 9.2x, Batik/Squiggle und dem adobe-plugin funktioniert es richtig, wird aber nicht animiert.
Die Opera-Probleme hängen vermutlich damit zusammen, daß CSS2.1 den Wert der
Eigenschaft anders definiert als CSS2.0 (auf welches sich SVG 1.1 bezieht), diese
Inkonsistenzen in CSS2.1 können dazu führen, daß die Eigenschaft
für fünf oder zehn Jahre für Autoren praktisch komplett unbrauchbar wird. Man wird
also in der Praxis eher beim clip-path
bleiben, um die CSS2.1-Problemen
zu umgehen. Der Hauptvorteil von clip
liegt in der einfacheren und kürzeren
Schreibweise. Die Vorteile von clip-path
liegen in der Flexibilität der
Pfadwahl und der zuverlässigeren Syntax, die nicht durch CSS2.1-Probleme korrumpiert
werden kann.
Bildausschnitt mit clip-path
(Quelltext zum
Bildausschnitt mit clip-path
).
Animierbar ist der Bildausschnitt natürlich auch:
Animierter Bildausschnitt mit clip-path
(Quelltext zum animierten
Bildausschnitt mit clip-path
).
Man beachte auch, daß nur die Pfadangaben relevant sind, sonstige Eigenschaften bei den clip-Pfaden sind
bedeutungslos:
Bildausschnitt mit clip-path
(2)
(Quelltext zum
Bildausschnitt mit clip-path
(2)).
Man beachte, daß Opera 9 und Batik/Squiggle 1.7 offenbar Probleme haben, wenn display
oder visibility
gesetzt werden - die Objekte in clipPath
sollten also nicht
dekoriert sein, will man Probleme vermeiden.
Ähnlich wie beim Ausschneiden können Inhalte auch maskiert werden.
Das Element zur Definition heißt mask
, ebenso die
Eigenschaft zur Referenzierung.
Der Helligkeitswert der Maske dient zur Ermittlung der Teiltransparenz, also nicht
nur wie beim Ausschneiden der Pfad.
Ein weiterer Unterschied zum Ausschneiden liegt darin, daß bei dieser das
ausgeschnittene Gebiet immer ganz transparent ist, beim Maskieren ist auch Teiltransparenz
möglich.
maskContentUnits
gilt entsprechend zu clipPathUnits
.
Mit maskUnits
zusammen mit den Attributen x
,
y
, height
und width
kann auch eine Maske direkt angegeben werden.
Zusammen mit dem oben beschriebenen Farbverlauf ist es auch möglich,
die Teiltransparenz innerhalb der Maske zu variieren.
Folgendes Beispiel veranschaulicht das Vorgehen beim Maskieren - je dunkler die Maske, desto transparenter
das Ergebnis:
Maskieren - Veranschaulichung
(Quelltext zum
Maskieren - Veranschaulichung)
Maskieren - Veranschaulichung (2)
(Quelltext zum
Maskieren - Veranschaulichung (2))
Weitere etwas kompliziertere Beispiele:
Maskieren 1
(Quelltext zum
Maskieren 1)
Maskieren 2
(Quelltext zum
Maskieren 2)
Maskieren 3
(Quelltext zum
Maskieren 3)
Maskieren 4
(Quelltext zum
Maskieren 4)
Auch dieses Element ist in SVG tiny nicht vorhanden oder mit Opera 8 nicht nachvollziehbar, mit Opera 9 schon, ebenso mit adobe-plugin, Gimp oder Inkscape. Bei Gecko 1.9, Batik/Squiggle 1.7 und KSVG wird die Maske leicht fehlerhaft berechnet.
Die Kombination von einem Farbverlauf mit einer Maske kann gut verwendet werden, eine Überblendung
zwischen zwei Bildern oder einem Bild und seinem Spiegelbild zu realisieren, dazu wird das obenliegende
Bild so maskiert, daß es im Überlagerungsbereich immer transparenter wird, je weiter es ins andere
Bild hineinragt.
Überblendung beim Bild
(Quelltext zur Überblendung beim Bild).
Es kann auch interessant sein, das Bild nach außen hin auszublenden:
Bild nach außen ausblenden
(Quelltext zu Bild nach außen ausblenden).
Jenseits von SVG tiny gibt es auch sogenannte Filter, mit denen sich noch deutlich
andere Veränderungen bewerkstelligen lassen als mit Farbverläufen und Masken.
Zu beachten ist, daß besonders bei den Filtern fast alle Darstellungsprogramme
noch Lücken oder Fehler aufweisen, so daß ein
systematisches Arbeiten damit schwierig wird. Allerdings sind SVG-Filter eigentlich so
aufgebaut, daß es dem Autor immer möglich ist, die zentrale Information
immer zugänglich zu halten und zusätzlich mit dem Filtern dekorative
Effekte zu bieten, änlich wie mit CSS.
Der eigentliche Filter
ist ein Element, welches mit der Eigenschaft
filter
referenziert wird. Das funktioniert analog zum
mask
-Element und -Attribut. Die eigentlichen Eigenschaften
der Filter werden durch sogenannte primitive Filter beschrieben,
die recht komplex zum endgültigen Filter kombiniert werden.
Beispiele für primitive Filter ist die Faltung mit einer Gaußfunktion,
Beleuchtungseffekte, Transformationen und diverse Matrizen-Effekte. In der
Spezifikation sind einige hilfreiche Beispiele angegeben. Hier zeige ich nur wenige
Beispiele:
Filter
(Quelltext zum
Filter)
Polygon mit Filter
(Quelltext zum
Polygon mit Filter)
Einfache Formen mit roter Beleuchtung als Filtereffekt (1)
(Quelltext zu einfachen Formen mit roter Beleuchtung als
Filtereffekt (1))
Einfache Formen mit roter Beleuchtung als Filtereffekt (2)
(Quelltext zu einfachen Formen mit roter Beleuchtung als
Filtereffekt (2))
Polygon und Logo mit Filter
(Quelltext zum
Polygon und Logo mit Filter).
Es gibt einige Eigenschaften, mit denen die Art der Anzeige beeinflußt werden kann.
Unter 'Text' habe ich schon eines davon erwähnt.
color-rendering
nimmt Einfluß auf die Präzision der
Umsetzung von Farbangaben, mögliche Werte sind: auto, optimizeSpeed,
optimizeQuality, inherit.
Wie die Bezeichnungen schon andeuten, geht es um zügige Darstellung oder die Qualität der Darstellung oder
bei auto einem Kompromiß zwischen beidem mit leichter Bevorzugung der Qualität. Bei inherit wird
die Eigenschaft vom Elternelement vererbt, nützlich wenn man etwa mit CSS Angaben von
XML überschreiben möchte. Voreinstellung ist auto.
shape-rendering
hat die Werte auto, optimizeSpeed,
crispEdges, geometricPrecision und inherit und steht
für die Darstellung von Formen wie Kurven und Pfade, Ellipsen, Rechtecken etc.
crispEdges entspricht einem hohen Kontrast an den Kanten, auto gibt wieder
einen Kompromiß mit leichter Bevorzugung der geometischen Präzision. Voreinstellung ist auto.
image-rendering
hat die Werte auto, optimizeSpeed, optimizeQuality, inherit und ist für das Element image
gemeint, die
Bedeutungen gelten sinngemäß wie für color-rendering
.
Solche Eigenschaften werden vom Elternelement vererbt, die Voreinstellung wirkt also nur, wenn in keinem
Elternelement das Attribut gesetzt ist - oder umgekehrt, man kann sie für eine ganz Gruppe mit g
setzen oder für das ganze Dokument im Element svg
.
SVG sieht auch explizit die verlustfreie Kompression
von SVG-Dateien vor, dazu ist wie bei XHTML gzip vorgesehen.
Ohne Kompression hat eines der obigen IFS-Fraktale eine Größe
von etwa 5kB, mit Kompression nur noch etwa 1kB. Insbesondere bei größeren
Mengen Quelltext lohnt sich das enorm. Die Dateiendung einer so komprimierten
Datei ist dann nicht mehr .svg sondern .svgz.
Der MIME-Typ ist wie gehabt "image/svg+xml".
Auch mit PHP kann eine solche Kompression durchgeführt werden, dazu gibt es dort die Zlib mit einigen Funktionen.
Eine einfache Variante ist bereits im Abschnitt Grundformen angegeben.
Dazu wird die gesamte Ausgabe entweder in den Ausgabespeicher oder in eine einfache
Zeichenkette geschrieben, ähnlich wie bei den
image
-Funktionen der GD-Bibliothek in PHP und dieser wird dann nach dem Senden
des headers
komprimiert ausgegeben.
Das HTTP sieht ohnehin als Möglichkeit vor, zwischen Dienstprogramm und Darstellungsprogramm komprimierte Daten auszutauschen, bei einer günstigen Einstellung des Dienstprogrammes würde dies die eigene Kompression weitgehend erübrigen.
Allenfalls wenn der Nutzer SVG-Dateien dauerhaft speichern möchte, bleibt eine Kompression mit gzip vorteilhaft:
gziptes Ellipsen-Gesicht,
gziptes Ellipsen-Gesicht mit Dateiendung .svg.gz (problematisch etwa
für den Konqueror, der einen Entpacker aufruft, statt das selbst darzustellen),
gziptes IFS-Fraktal mit SVG, noch ein
gziptes IFS-Fraktal mit SVG und noch ein
gziptes IFS-Fraktal mit SVG.
Ist der Betreiber des servers unwillig, den server korrekt zu betreiben, werden die Dateien zum
Herunterladen oder als Klartext angeboten. In solche einem Falle kann es erforderlich sein,
diese auf dem eigenen Rechner zu speichern und dann erst anzusehen.
Alternativ kann der korrekte header per PHP gesendet werden:
gziptes Ellipsen-Gesicht,
gziptes IFS-Fraktal mit SVG, noch ein
gziptes IFS-Fraktal mit SVG und noch ein
gziptes IFS-Fraktal mit SVG.
Beobachtung: Opera 8, Konqueror 3.3.2+KSVG und auch der W3C-Validator scheinen
nicht damit zurecht zu kommen, wenn ein Dienstprogramm den MIME-Typ für SVG zusammen
mit einer gzipten Datei sendet und diese Datei eine PHP-Datei ist, aber keine Kodierungsangabe
gesendet wird.
Opera 8 und Konqueror zeigen immerhin gzipte Dateien mit der Endung .svgz an.
Da scheint es auch noch Fehler oder Inkonsistenzen bei verschiedenen Programmen zu geben.
Amaya und Konqueror 3.3.2 + adobe-plugin etwa beherrschen auch die Anzeige einer gzipten Datei,
wenn der header
mit PHP gesendet wird und Amaya
ist auch mit mir der Meinung, daß es sich um eine valide Datei handelt.
Abhilfe schafft hier die Sendung eines zweiten header
s in der Form
header("Content-encoding: gzip");
für die komprimierten Daten, so daß wir
damit unabhängig von den Mängeln des Dienstprogrammes senden - mit dem
zusätzlichen header
funktioniert es auch mit Opera, Konqueror und dem
Validator, die plötzlich komprimierten Inhalt dekomprimieren können!
Mit dem header
sollte es auch möglich sein, per PHP andere Textformate zu senden,
die mittels gzip komprimiert sind.
Damit läßt sich letztlich bei Projekten mit vielen und großen Textdateien einiges an Datentransfervolumen einsparen, denn je nach Inhalt liegt die Kompression bei Text im Bereich von einem Faktor 2 bis 20!
Interessant ist das bei XHTML und SVG natürlich für jeden, der für das
Transfervolumen bezahlen muß oder dieses limitiert hat - letztlich muß immer
jemand zahlen, also lohnt es sich fast immer.
Machen wir einen kleinen Ausflug nach XHTML:
Neben der Möglichkeit, SVG-Dateien als komplett eigenständige Dokumente
stehen zu lassen und nur mit einem a
-Element auf sie zu verweisen, ist es auch praktikabel,
diese über ein object
-Element innerhalb eines XHTML-Dokumentes
anzuzeigen:
<div class="svgobjekt"> <object data="svgueb/polygonsvg2.php?x=400&y=400&eckenzahl=31&rundenzahl=13&strokeop=0.6&fillop=0.8&strokewidth=10&radius=400&winkel=10&fill=ff00ff&stroke=ff0055&miterlimit=30" type="image/svg+xml" width="400" height="400"> <h5>Regelmäßiges Polygon</h5> <p>Der eingesetzte browser scheint das Format SVG nicht direkt anzeigen zu können und es scheint auch kein eingebetteter Betracher dafür vorhanden oder aktiviert zu sein. Stattdessen kann versucht werden, die Datei durch Aktivieren folgenden Verweises mit einem eigenständigen Programm anzusehen oder auf dem eigenen Rechner erst einmal abzuspeichern:<br /> <a href="svgueb/polygonsvg2.php?x=600&y=600&eckenzahl=61&rundenzahl=23&strokeop=0.8&fillop=0.4&strokewidth=20&radius=400&winkel=10&fill=0000ff&stroke=00ff55&miterlimit=30" title="php-svg-script" type="image/svg+xml">Polygon-Generator</a> </p> <p>Alternativ steht hier auch ein einfaches Bild im Format png zur Verfügung:</p> <p> <img src="svgueb/polygon02svg.png" width="400" height="400" alt="Polygon mit SVG erzeugt, Ersatzgraphik für eine SVG-Datei" /> </p> </object> </div>
Indem ein div
-Element mit einer bestimmten Klasse um das Element object
gelegt wird, kann dieses
gut über CSS dekoriert werden.
Für den Fall, daß SVG im Darstellungsprogramm nicht direkt oder mit einem eingebetteten Betrachter
(plugin) angezeigt werden kann, ist innerhalb des object
-Elementes eine Alternative angegeben -
das ist in diesem Falle ein Verweis auf die Datei, für den Fall, daß jemand ein vom
Darstellungsprogramm unabhängiges Programm zur Anzeige von SVG hat oder das
Darstellungsprogramm zu alt ist, um ein object
-Element richtig zu interpretieren.
Sollte es für den Nutzer keine Möglichkeit geben, das Bild anzusehen,
ist hier immerhin ein PNG-Bild als Alternative angegeben -
und wichtiger noch eine kurze Beschreibung, hier:
Regelmäßiges Polygon, Polygon-Generator, Polygon mit SVG erzeugt,
Ersatzgraphik für eine SVG-Datei.
Adobe empfiehlt übrigens das in HTML4 und XHTML1.x nicht existierende und somit ungültige embed
-Element zur Einbindung von SVG und rät dafür explizit vom korrekten und gültigen object
-Element ab.
Einen Sinn ergibt das allenfalls in XHTML durch eine private Dokumenttyp-Erweiterung um dieses Element, was dann aber immer noch keine inhaltliche Bedeutung hat. In HTML ergibt das gar keinen Sinn.
Die beabsichtigte Bedeutung hat ja aber gerade das object-Element, so daß ein eigenes neues Element nur
für SVG unsinnig ist.
Adobes Aussagen sind also grober Unfug, Unsinn, Schwachsinn.
Niemand sollte das auch nur in Erwägung ziehen!
Adobe zeigt damit komplette Inkompetenz in Sachen (X)HTML. Entsprechend ist es mir bislang auch noch
nicht gelungen, mit Opera 8 dort auch nur ein einziges Beispiel anzugucken, was darauf schließen
läßt, daß es auch mit der Kompetenz in der Erstellung von korrekten SVG-Dokumenten
bei Adobe nicht ganz weit her ist. Das einzig wirklich Brauchbare in der Adobe svg-zone ist das plugin.
Alles andere sollte der Nutzer zu seinem eigenen Nutzen ignorieren oder sich über so viel
Unsinn amüsieren.
In HTML5 gibt es das Element embed
inzwischen sogar, es hat aber keine Möglichkeit,
Alternativen anzugeben, es ist daher unsinnig und somit abzulehnen, aufgrund der Möglichkeit, das deutlich
leistungsfähigere Element object
zu verwenden, ist embed
auch in dieser Version
von HTML komplett überflüssig, es bleibt rätselhaft, warum es dort definiert wurde.
Die Integration von SVG mit dem img
-Element war zunächst
bei den meisten Darstellungsprogrammen nicht angesagt, seit Opera 9.50 alpha bei diesem aber möglich,
ist aber auch für Autoren nicht unbedingt sinnvoll, weil das object
-Element das
img
-Element nicht nur ersetzen kann, sondern deutlich mehr Möglichkeiten bietet, alternative Ansichten anzubieten.
Mittlerweile wird SVG in img
zwar teilweise interpretiert, die Anbieter von
Darstellungsprogrammen haben aber besondere Einschränkungen eingebaut, nicht triviale SVG-Dokumente werden also eventuell nicht so dargestellt, wie vom Autor beabsichtigt, von daher ist eine Verwendung des
Elementes img
für SVG wie gehabt nicht empfehlenswert.
Eine weitere Möglichkeit ist die Nutzung von SVG als CSS-Hintergrundgraphik -
es dürften inzwischen sehr viele Gestalter von Seiten im Netz darauf warten,
daß dies endlich von den Darstellungsprogrammen umgesetzt wird.
Erneut ist Opera das erste Darstellungsprogramm, welches
dies interpretiert, ebenso für andere Graphikeinbindungen per CSS wie etwa Listenpunkte.
Märchen der Prinz und der Gloeckner mit SVG-Hintergrundbild.
Vegetarisches Adventsgedicht mit SVG-Hintergrundbild.
Jahre nach der Verfügbarkeit in Opera ist es auch bei anderen gängigen Programmen verfügbar, diese haben
allerdings meist Probleme, SVG-Graphiken als CSS-Hintergrundgraphik korrekt zu dimensionieren,
wenn sie diese automatisch an die Größe des verfügbaren Platzes anpassen sollen oder auch Einheiten wie
em oder ex verwendet werden, um die Größe zu notieren, auch wenn speziellere Angaben zum Aspektverhältnis vorliegen,
können sich Probleme ergeben, die zu einer unsinnigen Anzeige des Hintergrundes führen.
Auch als XML-Dateninsel kann SVG direkt in ein
XHTML-Dokument integriert werden,
was auch von SVG-fähigen Darstellungsprogrammen durchaus umgesetzt wird, aber nicht
von jenen, die nur über ein plugin verfügen. Ein Beispiel dazu habe ich
im CSS-Bereich erläutert (CSS und XML), weitere
Beispiele sind im Artikel 'Ausgedichtet' zu finden und bei folgenden Vorschlägen zur Erweiterung von SVG:
Polar
Teste Element polarPath
Eine gute Möglichkeit ist es, dem Arbeitsentwurf zum Mischen von XHTML, MathML
und SVG von W3C zu folgen - siehe den entsprechenden Verweis im Abschnitt
Verweise. Diese Variante könnte bereits in einigen Jahren wirklich praxistauglich werden, sofern eine Überprüfung
mit einem Validator erwünscht ist. Dieser Ansatz erfordert eigentlich nur für den Validator die Präfixe für
SVG und MathML, ansonsten reicht die Angabe des jeweiligen Namensraumes, um die
Elemente eindeutig zu identifizieren.
SVG bietet das Element foreignObject
, um Elementen aus anderen Namensräumen
in das SVG-Dokument einzubinden, die dann auch direkt angezeigt beziehungsweise interpretiert werden
können, sofern das Darstellungsprogramm sie überhaupt kennt und interpretiert.
foreignObject
taucht in SVG 1.1 immer in einem Element switch
auf, um die Darstellung einer Alternative vorzubereiten, in SVG tiny 1.2 ist das switch
meist ebenfalls empfehlenswert, aber nicht zwingend notwendig.
Handelt es sich beim einzubindenden Inhalt um ein
(XML)-Format zur Auszeichnung von Text und eine konkrete Anzeige wird vom Autor mittels
CSS vorgeschlagen, so kann bei einem ausgereiften Darstellungsprogramm eine entsprechende
Anzeige des Textes erwartet werden, dennoch gibt es dazu in der Spezifikation keine definitive Festlegung.
Der Validator zumindest kann XHTML in SVG oder umgedreht im Rahmen der dazu
vorliegenden DTD prüfen und empfiehlt zudem, die Datei als
application/xhtml+xml zu senden.
Unabhängig davon sind laut Spezifikation jegliche Elemente aus anderen Namensräumen erlaubt.
Die Attribute x
, y
, width
und
height
dienen zur Positionierung und Dimensionierung des Anzeigebereiches für den Inhalt.
In SVG tiny 1.2 kann ferner mittels xlink:href
eine externe Datei in einem
beliebigen Format referenziert werden, deren Inhalt den Inhalt von foreignObject
ersetzt, ähnlich wie bei
object
von XHTML, nur unabhängig davon, ob der Inhalt interpretierbar ist oder
nicht.
Beispiel foreignObject
mit Gedicht
(Quelltext zum foreignObject
mit Gedicht).
XHTML-Variante:
Beispiel foreignObject
mit Gedicht
(Quelltext zum foreignObject
mit Gedicht).
Opera hat in verschiedenen Versionen Probleme mit dem Beispiel, die Versionen 9.5x oder 9.6x zeigen es allerdings
brauchbar, wenn auch mit einiger Mühe an. Gecko 1.9 (Firefox 3, Iceweasel 3 etc) kommt mal abgesehen von der
fehlenden Animation besser mit dem Beispiel zurecht.
Entscheidend für die Identifizierung der Elemente ist letztlich die korrekte Namensraumangabe, nicht die
DTD. Deshalb ist die abgespeckte Version ebenso in Ordnung und auch notwendig, wenn andere
als die in der DTD definierten Profile verwendet werden sollen. Dies ist dann aber nicht anhand einer DTD
validierbar:
Beispiel foreignObject
mit Gedicht (2)
(Quelltext zum foreignObject
mit Gedicht (2)).
Beispiel foreignObject
mit Gedicht in LML
(Quelltext zum foreignObject
mit Gedicht in LML).
Letzteres Beispiel zeigt, wie ein dem Darstellungsrogramm vermutlich unbekanntes XML-Format mit CSS
komplett dekoriert durchaus anzeigbar sein kann, zudem zeigt es, daß es Formate gibt, die zur semantischen Textauszeichnung weit mehr
ausgereift und geeignet sind als (X)HTML und geradezu ideal für die hier besprochene Anwendung als Ergänzung
von SVG sind.
Ferner kann mit switch
eine Alternative angegeben werden für den Fall, daß das Format
nicht interpretierbar ist. In SVG 1.1 kann dazu das Attribut requiredExtensions
verwendet werden, wo man als Wert dann am besten den jeweiligen Namensraum angibt, für XHTML
zum Beispiel: requiredExtensions
= "http://www.w3.org/1999/xhtml".
Das ist nicht eindeutig so festgelegt, aber eigentlich die einzige plausible Möglichkeit. In SVG tiny 1.2
kann alternativ requiredFormats
verwendet worden, da ist der Wert für Standardformate
und viele weitere Formate eindeutig festgelegt, allerdings nicht versionsspezifisch. Das sieht dann für
XHTML so aus:
requiredFormats
= "applications/xhtml+xml".
Bei Textinhalt ist es natürlich deutlich einfacher, die Alternative mit SVG tiny 1.2 anzugeben:
Beispiel foreignObject
mit Gedicht in LML und Alternative
(Quelltext zum foreignObject
mit Gedicht in LML und Alternative).
Und dann gibt es noch ein Beispiel zu Einbindung einer externen Datei mit SVG tiny 1.2:
Beispiel foreignObject
zum Einbetten von Dateien
(Quelltext zum foreignObject
zum Einbetten von Dateien).
Opera gelingt es nicht, das Dokument mit kompletter Funktionalität beziehungsweise komplettem Layout einzubinden.
Die externe Datei alleine: Trügerische Idylle.
Spannend wird es natürlich ganz allgemein, wenn per foreignObject
Funktionalitäten
eingebunden werden, die in SVG bislang gar nicht verfügbar sind, etwa Formulare von XHTML
oder XForms.
Beispiel foreignObject
mit XHTML-Formular
(Quelltext zum foreignObject
mit XHTML-Formular).
Das Beispiel ist mit Gecko 1.9 (Firefox 3, Iceweasel 3 etc) gut nachvollziehbar, bei Opera 9.x oder 10alpha ist die Anzeige mangelhaft
und das Formular unbrauchbar.
SVG tiny 1.2 bietet neue Elemente um externe Multimediainhalte und externe SVG-Dokumente
zeitabhängig einzubinden. Während SVG 1.1 nur das Element image
hat, um
andere Bildformate in eine SVG-Datei einzubinden, wobei kein präziser Zeitablauf definiert ist, wenn es
sich zum Beispiel um ein animiertes SVG handelt. Wie die Elemente zur Animation haben die neuen
Elemente animation
, audio
und video
Attribute, die den präzisen
Zeitablauf definieren. Dazu gibt es noch das Element discard
, mit dem beliebige Inhalte aus dem Speicher
des Darstellungsprogrammes entfernt werden können, um dieses zu entlasten. Und es gibt auch das Element
prefetch
, mit dem externe Inhalt vorab geladen werden können, um sicherzustellen, daß
sie verfügbar sind, wenn sie gebraucht werden. Mit dem Attribut externalResourcesRequired
kann zudem angegeben werden, ob eingebettete externe Dateien notwendig sind, um die Darstellung des Dokumentes zu
beginnen.
Beispiel Elemente animation
, discard
, prefetch
.
Die Animationen können durch Anklickern des hellblauen Kreises links unten angefangen und sichtbar gemacht werden,
der rosa Kreis daneben beendet sie wieder, dabei bleiben sie allerdings sichtbar.
Durch Anklickern der beiden roten Kreise werden die referenzierten Dokumente aus dem Speicher gelöscht und ist
dann nicht mehr verfügbar und sichtbar.
Ab Opera 9.5x werden zwar einige der Elemente interpretiert, teilweise aber fehlerhaft und unvollständig. Im
Zusammenhang mit discard
neigt Opera zudem zu Abstürzen.
Weil die meisten Audio- und Videoformate bedingt durch Lizenzen in der Nutzung und Implementierung Einschränkungen unterliegen und als proprietär anzusehen sind, gibt es derzeit keine Formate, die garantiert interpretiert werden müssen. Insbesondere das Containerformat OGG wird als lizenzfrei angesehen und könnte ein Kandidat für die direkte Interpretation von Darstellungsprogrammen ohne sonstige Hilfsmittel sein.
Mittels des neuen Attributes requiredFormats
kann eine bedingte Verarbeitung erreicht werden.
Als Attributwert dient eine Liste von benötigten Inhaltstypen.
Die Inhaltstypen (ehemals MIME) für OGG
sind etwa
audio/ogg für Audio, video/ogg für Video optional mit Audio und
application/ogg für kompliziertere Gemische, wobei es bis September 2008
nur letzteren Typ für alles gab. Optional kann auch das verwendete 'codec' angegeben werden, zum Beispiel:
audio/ogg; codecs=speex oder video/ogg; codecs="theora, vorbis".
Wenn das implementiert ist, bietet sich damit jedenfalls eine simple Möglichkeit für Autoren, selbst
und deklarativ mit SVG eine interaktive Abspielhilfe (englisch: player) oder
Audio-Box (Musiktruhe) oder Video-Box nach eigenem Geschmack und mit eigener Anordnung der Bedienelemente und eigenem Layout
anzubieten, ohne dafür auf proprietäre und unzuverlässige plugins oder
Formate wie flash mit unflexiblen undurchsichtigen Abspielhilfen angewiesen zu sein.
Beispiel Element audio
,
Prototyp einer Musiktruhe,
Rudimentäres Musikinstrument.
Opera interpretiert das teilweise seit Version 9.5x, es gibt auch Testversionen, die OGG selbst interpretieren. Das Format audio/wav kann Opera schon länger direkt interpretieren, da sind die Dateigrößen für internet aber eher ungeeignet. Bei den normalen Versionen läd Opera bei OGG alles und verwendet automatisch (!) ein externes Programm (totem bei mir) ohne eine Interaktion abzuwarten, womit somit alles sofort abgespielt wird, sobald es dem externen Programm verfügbar wird, auch gleichzeitig bei mehreren Dateien. Da sind offenbar noch Fehler zu beheben...
Der entsprechende Video-Box Prototyp.
Nachvollziehbar ist das auch mit den speziellen Videovorschauversionen von Opera nicht, die angeblich Videos im
Format OGG selbst darstellen können, dies aber in der Angabe für bedingte Verarbeitung requiredFeatures
nicht angibt. Ohne eine solche Anfrage geht es teilweise.
Maldientste wie Farbverlauf oder Gradient, Muster und Parkettierungen, Mustererstellung, Periodische Parkettierung und ebene kristallographische Gruppen, Aperiodische Parkettierung (Penrose), die ehemals auf dieser Seite zu finden waren, sind auf eine eigene Seite umgezogen: Maldienste.
Im Menü stehen bereits Extrapunkte zu Kurven, Text, Maldienste und Animationen in SVG.
Einige Beispiele zur Kombination mit PHP gibt es schon, mehr wären aber besser, glaube ich.
Ein etwas umfangreicheres Beispiel ist die analoge Uhr, die ebenfalls auf Animationen beruht.
Im Bereich Text kann man auch eigene Glyphen, also Textzeichen definieren, somit mit
SVG eigene Schriftarten entwickeln. Vielleicht führt das ja einmal zu einem Standard für Schriftarten
und der Möglichkeit, auch exotische Schriftarten auf internet-Seiten für spezielle Anwendungen
nutzbar zu machen. Jedenfalls ist das jetzt bereits mit SVG möglich, SVG tiny
sieht allerdings keine eigenen Glyphen vor.
Auf Skriptsprachen wie ecma-script bin ich ebenfalls nicht eingegangen, weil das zwar zusammen mit SVG
verwendet werden kann, aber es sich dabei nicht unmittelbar um SVG handelt, es ferner nicht Bestandteil von
SVG tiny ist und ohnehin vom Nutzer aus Sicherheitsgründen deaktiviert sein kann.
Zahlreiche Anwendungen können
schlicht durch die Kombination von Animationen und PHP ersetzt werden.