SVG/ SVG im Web

Verwendung von SVG im Internet

SVG ist als Format für die Verwendung im Netz konzipiert. Der einfachste Fall ist die Verwendung als eigenständige Dateien. Jedes Format, welches auf andere Dokumente per URI/IRI verweisen kann (englisch: hyperlinking), kann auch auf eigenständige SVG-Dateien verweisen. Sofern in dem jeweiligen Format das Pseudoprotokoll 'data:' verwendet werden kann, können zudem damit wie auch in SVG selbst externe Dateien direkt in der URI/IRI des Verweises notiert werden, somit auch SVG-Dateien.

Daneben gibt es zahlreiche weitere Möglichkeiten, wie SVG-Dokumente innerhalb von anderen Formaten als eigenständige Dateien eingebettet werden können oder auch als Dokumentfragmente in einem XML-Dokument mit anderen XML-Formaten gemischt werden können.

SVG als Fragment in XHTML

SVG kann als XML-Format zusammen mit anderen XML-Formaten gemeinsam in einem Dokument verwendet werden.

Da auch XHTML ein XML-Format ist, geht dies auch dort. Das X in XML und XHTML steht für eXtensible, weil es erweiterbar ist. Ein XHTML-Dokument kann also insbesondere mittels eines Fragmentes aus dem Namensraum SVG erweitert werden.

Beispiel - ein Dokument in der aktuellen XHTML-Version XHTML+RDFa 1.1 mit eingebettetem SVG:

<?xml version="1.0" encoding="utf-8"?>
<html xmlns="http://www.w3.org/1999/xhtml"
      version="XHTML+RDFa 1.1"
      xml:lang="de">
<head>
<title>Freude schöner Götterfunken…</title>
</head>
  <body>
    <h1>Freude schöner Götterfunken…</h1>
     <div class="svg">
     <svg xmlns="http://www.w3.org/2000/svg" 
          xmlns:xlink="http://www.w3.org/1999/xlink" 
          version="1.1" width="810" height="540">
       <title>Sterne als Götterfunken</title>
       <defs>
	     <g id="s">
		   <g id="c">
		     <path id="t" d="M0,0v1h0.5z" transform="translate(0,-1)rotate(18)"/>
			 <use xlink:href="#t" transform="scale(-1,1)"/>
		    </g>
			<g id="a">
			  <use xlink:href="#c" transform="rotate(72)"/>
			  <use xlink:href="#c" transform="rotate(144)"/>
			</g>
			<use xlink:href="#a" transform="scale(-1,1)"/>
		  </g>
		 </defs>
         <rect fill="#039" width="810" height="540"/>
		 <g fill="#fc0" transform="scale(30)translate(13.5,9)">
		 <use xlink:href="#s" y="-6"/>
		 <use xlink:href="#s" y="6"/>
		 <g id="l">
		   <use xlink:href="#s" x="-6"/>
		   <use xlink:href="#s" transform="rotate(150)translate(0,6)rotate(66)"/>
		   <use xlink:href="#s" transform="rotate(120)translate(0,6)rotate(24)"/>
		   <use xlink:href="#s" transform="rotate(60)translate(0,6)rotate(12)"/>
		   <use xlink:href="#s" transform="rotate(30)translate(0,6)rotate(42)"/>
		 </g>
		 <use xlink:href="#l" transform="scale(-1,1)"/>
		</g>
     </svg>
     </div>
     <p>
     Ein Text, welcher anderen XHTML-Inhalt repräsentiert.
     </p>
   </body>
</html>

Die Idee ist ebenso einfach wie brillant - durch Angabe der Namensräume für XHTML, XLink und SVG werden die jeweiligen Elemente, Kindelemente und Attribute den jeweiligen Namensräumen zugeordnet, so dass das Darstellungsprogramm diese eindeutig identifizieren und korrekt darstellen kann. Bei der obigen XHTML-Version kann sogar die Semantik von Inhalten durch Verwendung eigener Namensräume genauer festgelegt werden. Dazu werden die gleichen Attribute von RDFa verwendet wie in SVG tiny 1.2, die beiden Formatversionen harmonieren also bereits hervorragend, um inhaltlich qualitativ hochwertige Dokumente zu erstellen.

Für den Autor ist die Angelegenheit denkbar einfach, das SVG-Fragment wird in das XHTML-Dokument an eine passende Stelle kopiert und fertig, schon funktioniert es in allen Darstellungsprogrammen, die SVG und XHTML interpretieren. Zu beachten ist beim Kopieren von Fragmenten allerdings immer, dass die Zuordnung zu den Namensräumen erhalten bleiben muss, im Zweifelsfalle sind entsprechende Angabe also zusätzlich zu kopieren oder anzupassen. Bei obigem Beispiel stehen alle für das SVG-Fragment relevanten Angaben allerdings bereits im svg-Element und die für XHTML im Element html.

In XHTML sollten die direkten Kindelemente von body immer Blockelemente sein, weswegen hier noch ein div um das SVG-Fragment gelegt ist. Durch die Verwendung von class ergibt sich ferner die einfache Möglichkeit der Positionierung und Skalierung mit CSS.

Ein Problem ergibt sich allenfalls bei alten Darstellungsprogrammen. Alte, kaum noch verwendete Programm wie der Internet-Explorer von Microsoft bis Version 8 oder auch Netscape 4 können weder XHTML noch SVG interpretieren, können also mit obiger Lösung auch nichts anfangen. Ohne weitere Tricks könnrn solche Programme auch das XHTML nicht als HTML interpretieren und das SVG darin an ein Plugin durchreichen.

Formal korrekt ist ein solches Dokument immer als application/xhtml+xml oder application/xml auszuliefern. Ohne Angabe eines Dokumenttyps mag der Microsoft-Internet-Explorer bis Version 8 im zweiten Falle das Dokument sogar als XML interpretieren, weiß dann aber nicht, was die Elemente in den Namensräumen von XHTML und SVG zu bedeuten haben, kann sie also auch nicht sinnvoll darstellen. Netscape 4 kann gar kein XML interpretieren.

Es ist teilweise auch üblich, XHTML wie HTML als text/html auszuliefern, das ist dann allerdings eben fehlerhaftes HTML und kein XHTML mehr. Wenn es aber geschickt genug gemacht wird, fallen die Fehler nicht auf, weil ein HTML-Markierungssuppen-Interpretierer mit kleineren Fehlern ganz gut zurechtkommt und sie vor dem Betrachter verbirgt. Allerdings ist HTML4 nicht erweiterbar, so dass darin kein SVG vorkommen kann. Das seit 2014-10-28 als Empfehlung verfügbare HTML5 sieht das Einbetten von MathML und SVG auch in der Markierungssuppen-Variante von HTML5 vor. Für HTML5 ist allerdings auch ein Notation als XML vorgesehen, wird dann also zum XHTML, wo das Einbetten von Fragmenten aus anderen Namensräumen dann wie gehabt ohnehin kein Problem darstellt.

Die Möglichekeit der Einbettung ändert allerdings nichts daran, dass Programme, die SVG nicht interpretieren, auch innerhalb von HTML5 nicht von alleine beginnen werden, dies zu tun.

Einbetten einer SVG-Datei

Damit ein Darstellungsprogramm in (X)HTML selbst entscheiden kann, ob es das SVG selbst interpretiert oder ob womöglich ein Programm-Ergänzung (englisch: plugin) verwendet werden kann, kann auch die Verwendung des Elementes object in Erwägung gezogen werden. Das SVG-Dokument bleibt dann eigenständig, was gegenüber der Einbettung als Fragment einige Unterschiede nach sich zieht. Bei einem Dokument kann etwa eine Stilvorlage auf alle Fragmente gemeinsam wirken, bei einzelnen Dokumenten wirken sie auf jene, wo die Stilvorlagen eingebunden oder referenziert ist.

Als Inhalt des Elementes object kann ein Ersatzbild oder eine Textalternative angegeben werden, für jene Programme, die kein SVG interpretieren. Mit einem direkten Verweis auf die SVG-Datei darin erhält der Betrachter ferner die Chance, sich das SVG mit einem externen Programm anzusehen.

<object type="image/svg+xml" data="test.svg" width="400" height="300">
 <p><img src="test.png" width="400" height="300" alt="Textäquivalent zum PNG" /></p>
 <p>Offenbar ist kein eingebetteter Betrachter für SVG verfügbar, 
    mit einem externen Programm versuchen:
 <a href="test.svg" type="image/svg+xml">Test</a></p>
</object>

Wenn beim Microsoft-Internet-Explorer indes ein bestimmtes sogenanntes Service-Pack2 installiert ist und der Nutzer des Erweiterunbgsprogrammes von Adobe für installiert hat, ist hingegen bekannt, dass der Microsoft-Internet-Explorer die Anzeige des SVG im object sabotieren wird. Insofern kann es auch sinnvoll sein, den direkten Verweis auf die SVG-Datei außerhalb des object anzuordnen, denn dann funktioniert das Erweiterunbgsprogrammes von Adobe ohne Einbettung auch im Microsoft-Internet-Explorer.

Es ist natürlich auch möglich, ein SVG als eigenständiges Dokument mit dem iframe-Element einzubetten. Der Inhalt des iframe kann analog zum object verwendet werden.

<iframe src="test.svg" width="400" height="300" name="imap">
Alternativtext oder -bild
</iframe>

Wie im Standard festgelegt, sollte ein SVG auch mit dem Element img referenziert präsentiert werden, bei älteren Darstellungsprogramm-Versionen kann es damit allerdings Probleme geben. Bei aktuellen funktioniert aus Sicherheitsgründen dann aber kein Ecma-Script im SVG, selbst wenn der Nutzer die Skriptinterpretation aktiviert haben sollte.

<img src="test.svg" width="400" height="300" alt="Textäquivalent zur SVG-Testdatei" />

Eine weitere Möglichkeit zur Nutzung von SVG-Dokumenten als dekoratives Hintergrundbild ergibt sich bei Verwendung von CSS:

body {background: blue url(deko.svg)}

Ein Darstellungsprogramm, welches kein SVG interpretiert, wird einfach blauen Hintergrund darstellen, eines mit SVG-Interpretation (als CSS-Hintergrundbild) wird hingegen das SVG auf dem blauen Hintergrund darstellen. Leider gibt es in CSS 2 keinen Mechanismus, mit dem man ein Ersatzbild in einem anderen Format angeben kann. Allenfalls ließe sich etwas Ähnliches durch Verschachtelung von Elementen mit Hintergrundbildern in verschiedenen Formaten erreichen.

WebSVG: Versuch der Konversion zu Flash

Es gibt einige Leute, die sich einmal um das Problem der antiken Versionen des Microsoft-Internet-Explorer bemüht haben, obgleich Microsoft bereits in der Version 9 selbst eine Interpretation von SVG integriert hat. Die Bemühungen gehen in die Richtung, das SVG für ältere Versionen in ein anderes Format zu konvertieren, um es darstellbar zu machen.

Einen Konversionsversuch gibt es mit WebSVG. Damit wird eine Konversion zu Flash versucht.

Ein prinzipielles Problem der Formatkonversion ist neben dem Aufwand das Problem, dass nicht alles, was in SVG möglich ist, sich gut in jedes andere Format konvertieren lässt. Zudem beruht die Idee auf der Hypothese, dass das andere Format eine bessere Verfügbarkeit hat als SVG selbst. Das mag für Formate wie PNG, JPEG/JFIF oder (X)HTML (Textalternative!) zutreffen, in Zukunft vermutlich aber nicht mehr für das bei WebSVG bevorzugte Flash. Außerdem kann auch in einem alten Darstellungsprogramm eine Erweiterung (englisch: plugin) verfügbar sein, die eine Darstellung von eingebetteten SVG-Dokumenten ermöglicht, eventuell auch in besserer Qualität als solch ein automatisch konvertiertes Dokument.

Zum Testen von WebSVG kann das Paket einfach unter http://code.google.com/p/svgweb/ geladen werden.

Auf dem Dienstrechner wird davon das Verzeichnis '/src' benötigt. Das Beispiel von oben sieht mit WebSVG als 'HTML5-Dokument' nach den Angaben der Entwickler von WebSVG so aus (es handelt sich um kein gültiges HTML4-Dokument! Selbst ohne das SVG ist es kein gültiges HTML4-Dokument, nach den Empfehlungen und Intentionen ist es auch für HTML5 als problematisch anzusehen; wegen philosophischer Probleme der W3C-Arbeitsgruppe für HTML5 ist es auch gar nicht möglich anzugeben, dass es sich um ein 'HTML5-Dokument' handelt):

<!DOCTYPE html>
<html>
<head>
<title>Freude schöner Götterfunken…</title>
</head>
  <body>
    <head>
    <meta name="svg.render.forceflash" content="true">  
    <script src="./src/svg.js"  data-path="./src/"  data-debug="true"></script>
  </head>
<body>

    <h1>Freude schöner Götterfunken…</h1>
	<script type="image/svg+xml">
     <svg xmlns="http://www.w3.org/2000/svg" 
          xmlns:xlink="http://www.w3.org/1999/xlink" 
          version="1.1" width="810" height="540">
       <title>Sterne als Götterfunken</title>
       <defs>
	     <g id="s">
		   <g id="c">
		     <path id="t" d="M0,0v1h0.5z" transform="translate(0,-1)rotate(18)"/>
			 <use xlink:href="#t" transform="scale(-1,1)"/>
		    </g>
			<g id="a">
			  <use xlink:href="#c" transform="rotate(72)"/>
			  <use xlink:href="#c" transform="rotate(144)"/>
			</g>
			<use xlink:href="#a" transform="scale(-1,1)"/>
		  </g>
		 </defs>
         <rect fill="#039" width="810" height="540"/>
		 <g fill="#fc0" transform="scale(30)translate(13.5,9)">
		 <use xlink:href="#s" y="-6"/>
		 <use xlink:href="#s" y="6"/>
		 <g id="l">
		   <use xlink:href="#s" x="-6"/>
		   <use xlink:href="#s" transform="rotate(150)translate(0,6)rotate(66)"/>
		   <use xlink:href="#s" transform="rotate(120)translate(0,6)rotate(24)"/>
		   <use xlink:href="#s" transform="rotate(60)translate(0,6)rotate(12)"/>
		   <use xlink:href="#s" transform="rotate(30)translate(0,6)rotate(42)"/>
		 </g>
		 <use xlink:href="#l" transform="scale(-1,1)"/>
		</g>
     </svg>
	 </script>

     <p>
     Ein Text, welcher anderen XHTML-Inhalt repräsentiert.
     </p>
   </body>
</html>

Achtung!: WebSVG funktioniert nicht lokal wegen der Konversion zu Flash. Die Dateien müssen also auf einem Dienstrechner liegen und zum Beispiel über Protokolle wie HTTP oder HTTPS abgerufen werden. Weitere Hinweise gibt es in der WebSVG-Dokumentation.

Unser Beispiel hier verwendet immer Flash für die Darstellung, auch wenn das Darstellungsprogramm das SVG selbst besser interpretieren kann oder kar keine Erweiterung für die Präsentation von flash-Dateien verfügbar oder aktiviert hat. So ist die Verwendung von WebSVG also sicher nicht sinnvoll! Das Beispiel zeigt also somit, wie man es sicht nicht machen soll, auch wenn es von den WebSVG so vorgeschlagen wird.

Wenn dies dennoch verwendet werden soll, sollte auf dem Dienstrechner eine interaktive Abfrage eingebaut sein, bei welcher der Nutzer explizit solch eine Konversion anfordert, alle anderen Nutzer sollten das originale SVG-Dokument zu sehen bekommen.

Zu beachten ist bei vorherigem Beispiel, dass dies als ein 'HTML5-Dokument' angesehen wird, was es genaugenommen gar nicht gibt. Gemäß der Empfehlung zu HTML5 ist es nicht notwendig, SVG in einem script-Element zu verstecken (siehe weiter unten), noch ist es an sich notwendig, das mit Skripten zu interpretieren, das kann gemäß HTML5 auch so funktionieren.

Diese Transformation in ein flash-Dokument kann zudem bestenfalls funktionieren, wenn beim Betrachter JavaScript aktiviert ist und die Interpretation von Flash aktiviert ist. Es stellt also keine Methode dar, bei der der Autor gut abschätzen kann, was beim Betrachter wirklich angezeigt wird. Hinsichtlich Zugänglichkeit und Barrierefreiheit sind flash und JavaScript keine Methoden, die für Inhalt geeignet werden, taugen also allenfalls für dekorative Zwecke. Wie bereits beschrieben, sollte sich der jeweilige Nutzer immer per Auswahl aktiv dafür entscheiden, konvertierte Inhalte angezeigt zu bekommen.

Auch gibt es Teilbereiche von SVG, die mittels flash nicht nachvollziehbar sind. Flash eignet sich also bestenfalls für eine Teilmenge von SVG-Dokumenten. Die Interpretation von SVG als Skriptsprache innerhalb des script-Elementes ist jedenfalls eine sehr gewagte Interpretation von SVG und HTML, die mindestens semantisch fragwürdig ist, hier aber immerhin andeutet, dass das SVG mehr dekorativen und keinen inhaltlich relevanten Charakter hat, weswegen eine Interpretation auch nur optional zu sein braucht.

Für inhaltlich relevante Graphik ist diese Konstruktion keinesfalls geeignet, auch nicht, wenn der Autor zuverlässig vorhersagen möchte, was sich daraus bei einem Nutzer für eine Anzeige ergibt. Die Konstruktion ist eher als experimentelle Spielerei anzusehen, welche eine SVG-Interpretation im Darstellungsprogramm selbst nicht ersetzen kann.

SVG in HTML5

Und so sieht die Verwendung von SVG in HTML5 ohne Anwendung fragwürdiger Tricks in der Markierungssuppen-Variante (Inhaltstype 'text/html') aus (für die XML-Variante gilt das schon lange gültige Beispiel vom Anfang, unterscheidet sich also nicht von der Einbettung von SVG in andere Sprachversionen von XHTML):

<!doctype html>
<html>
<head>
<title>SVG eingebettet in text/html</title>
</head>
<body>
<p>
 Ein grüner Kreis:
 <svg> <circle r="50" cx="50" cy="50" fill="green"/> </svg>
</p>
</body>
</html>

Dies ist für Autoren eine auf den ersten Blick recht einfache Konstruktion. Allerdings werden Angaben zu Namensräumen innerhalb von HTML5 (genauer der Markierungssuppen-Variante davon) nicht interpretiert. Aufgrund der Komplexität eines HTML5-Markierungssuppen-Interpretierers und der fehlenden Zuordnung zu den Namensräumen unterliegt die Verwendung von SVG und MathML in der HTML5-Markierungssuppen-Variante jedoch gewissen Einschränkungen. Elemente mit gleichem Namen in HTML5 und SVG (oder MathML) können problematisch sein, auch die Verwendung von Elementen aus anderen Namensräumen im SVG-Fragment, was in der Markierungssuppen-Variante einerseits nicht zulässig ist, für gewisse maschinenlesbare Metainformationen aber notwendig sein kann. Werden SVG-Elemente in der Markierungssuppen-Variante nicht korrekt geschlossen, wird das bei der Interpretation nicht wie bei der XML-Variante notwendig als Fehler offenbart, woraus weitere komplexe Probleme entstehen können - entweder folgender HTML5-Markierungssuppen-Inhalt wird nicht dargestellt, weil dieser noch als zum SVG-Fragment gehörig interpretiert wird - oder umgedreht, taucht ein Element von HTML5 auf, wird das SVG-Fragment vorzeitig geschlossen, obgleich die (X)HTML-Elemente eventuell nur zur semantischen Strukturierung in den Elementen title, desc, metadata, foreignObject verwendet werden.

Mögliche Fehler im SVG-Fragment können also vom HTML5-Markierungssuppen-Interpretierer vertuscht werden - was nicht zwangsläufig zu einer sinnvollen Interpretation des Elementes im Sinne des Autors führen muß. Sollte der Autor das Fragment später kopieren wollen, um es in anderen (XML-)Dokumenten oder eigenständig zu verwenden, können die vertuschten Fehler zu Problemen führen. Allerdings ist für HTML5-Markierungssuppen-Interpretierer, welche auch solches 'HTML5-SVG' interpretieren, vorgesehen, dass diese eine Ausgabe anbieten müssen, welche das korrigierte SVG zur Weiterverwendung darstellt. Diese korrigierte Ausgabe sollte dann weiterverwendet werden, nicht der originale, möglicherweise fehlerhafte Quelltext des HTML5-Originaldokumentes.

Zudem ist es auch bei der HTML5-Markierungssuppen-Variante keine Voraussetzung, dass ein HTML5-Markierungssuppen-Interpretierer SVG oder MathML interpretieren können muss. Es ist lediglich formal erstmals für eine HTML-Version überhaupt möglich, MathML oder SVG darin einzubetten.

Aufgrund der in HTML5 reichlich vorhandenen Altlasten ist die Kombination in der HTML-Markierungssuppen-Variante problematisch und die Sprache selbst ist nur schwierig allgemein durch den Autor erweiterbar. Allerdings gibt es auch zu HTML5 eine XML-Variante (Inhaltstyp 'application/xhtml+xml'), bei der die direkte Kombination mit Elementen aus verschiedenen Namensräumen problemlos funktioniert, weil dort die Angabe von Namensräumen problemlos möglich ist. Zur Vermeidung von Komplikationen und Einschränkungen ist es also bei HTML5 empfehlenswert, die Variante mit XML-Notation korrekt mit der Angabe der zutreffenden Namensräume zu verwenden und nicht die Markierungssuppen-Variante, insbesondere wenn Fragmente aus anderen Formaten wie SVG oder MathML eingebunden werden sollen.

Als Java-Anwendung

Die Apache-Organisation bietet mit Batik/Squiggle eine Java-Anwendung an, mit der ebenfalls SVG dargestellt werden kann oder eine Konversion von SVG in Pixelgraphik erfolgen kann, sofern das inhaltlich möglich ist. Batik/Squiggle interpretiert bereits größere Teilbereiche von SVG 1.1, hat aber ebenso wie andere Programme teils noch größere Lücken oder Fehler in der Interpretation.

Es gibt auch andere Anbieter, die SVG-Darstellungsprogramme auf Basis von Java anbieten, insbesondere auch für Mobiltelephone.

Konfiguration eines HTTP- oder HTTPS-Dienstprogrammes anhand des Dienstprogrammes Apache

Ein prinzipielles Problem von Dateiformaten ist, wie dem Darstellungsprogramm vermittelt wird, um welches Format es sich handelt.

Das Problem ist größtenteils historisch bedingt und resultiert letztlich daraus, dass Dateisysteme meist nicht über die Möglichkeit verfügen, standardisiert vielfältige Metainformationen einer jeden Datei zuzuordnen.

In den Anfängen der Computer gab es auch nur wenige Formate und kleine Speichermedien, so dass es dem Nutzer zumutbar war, die Zuordnung zu kennen. Teils haben auch die Programme versucht, das Format anhand der ersten paar Bytes einer Datei zu raten.

Ein anderer Ansatz bestand darin, eine Abkürzung für das Format am Ende des Dateinamen zu notieren, bevorzugt mit einem Punkt separiert, auch Dateiendung genannt. Teils werden mehrere Endungen angehängt. Mit der Zeit gibt es allerdings sehr viele Formate und keine Eindeutigkeit der Abkürzungen mehr, auch weil es nie eine zentrale Registrierung für solche Abkürzungen gab. Auch heute noch basiert die Formaterkennung vieler Programme auf dieser unzuverlässigen und fehleranfälligen Methode.

Mit dem Aufkommen des Netzes und von digitalen Briefen (englisch: email, e-mail) hat sich das Problem verschärft, weil nun auch Dateien zwischen verschiedenen Rechnern ausgestauscht wurden. Das hat dazu geführt, dass für ausgereifte angesehene Formate eindeutigen Kennzeichnungen registriert wurden, ursprünglich MIME-Typen genannt, heute allgemeiner Inhaltstypen. Ist einem email-Programm oder allgemein einem Dienstprogramm also das Format einer Datei und der Inhaltstyp bekannt, kann diese Information dem Empfänger der Datei als Metainformation vermittelt werden, bevor die Datei gesendet wird, eventuell kann auch ausgehandelt werden, welches Format der Empfänger interpretieren kann, wenn mehrere Formate verfügbar sind - oder bei digitalen Briefen, welches Programm zur Darstellung eines Anhangs geeignet sein könnte. So wird nur Metainformation über das Format ausgetauscht und nicht notwendig gleich große Dateien, um die Interpretierbarkeit festzustellen.

Jedenfalls verbleibt das Problem der Zuordnung des Formates auf dem Rechner mit dem Dienstprogramm oder dem email-Programm.

Im Falle des Dienstprogrammes Apache erfolgt die Zuordnung zumeist ebenfalls über Dateiendungen, denen in Listen Kennzeichnungen zugeordnet werden. Damit kann das Programm die entsprechen Metainformation senden, die dann für das Programm relevant ist, welches die Datei angefordert hat.

Bei SVG ist die Kennzeichnung 'image/svg+xml'. Als Dateiendung wird '.svg' empfohlen. Zusätzlich gibt es die Möglichkeit, SVG mittels gzip zu komprimieren, für solche Dateien wird die Endung '.svgz' empfohlen. Zusätzlich zur Kennzeichnung des Formates ist dann als Metainformation allerdings noch anzugeben, dass eine solche Kompression vorliegt.

Bei dynamisch auf dem Dienstrecher zum Beispiel per PHP erzeugten SVG-Ausgaben kann es allerdings sinnvoll sein, für solche Skripte spezielle Endungen einzuführen, um ebenfalls zu gewährleisten, dass automatisch korrekte Metainformationen gesendet werden. Andernfalls sind die Metainformationen bei jeder einzelnen Datei manuell per PHP zu senden.

Bei aktuellen Versionen vom Apache sollten die Zuordnung des Typs für die Endungen '.svg' und '.svgz' bereits korrekt vorliegen.

Nun kann es sein, dass eine ältere Version vom Apache verwendet werden muss oder die Konfiguration nicht geändert werden kann, darf oder soll.

In solchen Fällen kann dem Apache die Zuordnung mit einer Datei namens '.htaccess' definiert werden. Diese Datei wird in dem Verzeichnis untergebracht, für welches die Zuordnung einschließlich aller Unterverzeichnisse gelten soll.

Entsprechend obigen Angaben ergibt sich dann folgender Inhalt:

 AddType image/svg+xml svg svgz
 AddEncoding gzip svgz

Sollen auch PHP-Skripte spezielle Endungen, etwa '.psvg' und '.psvgz' erhalten, so ergibt sich folgender Inhalt:

 AddType application/x-httpd-php psvg psvgz
 AddType image/svg+xml svg svgz
 AddEncoding gzip svgz psvgz

Der Inhaltstyp ist ansonsten in jedem Skript vor jeglicher anderer Ausgabe zu senden:

 <?php
 # sonstiger PHP-Kram ohne jegliche Ausgabe ...
 header("Content-type: image/svg+xml");
 # sonstiger PHP-Kram samt SVG-Ausgabe ...
 ?>

Dies ist auch notwendig, wenn die normale Endung für PHP '.php' verwendet wird.

Sollen und können die Änderungen in den Konfigurationsdateien durchgeführt werden, so sind dies typisch die Dateien httpd.conf oder apache2.conf je nach Version des Apache. Typisch sind diese in folgenden Verzeichnissen zu finden: /etc/httpd/conf/ or /etc/apache2/

Die jeweilige Anleitung zur Version des Apachen ist zu beachten. Die genannten Ergänzungen sollten auch nur vorgenommen werden, wenn sie wirklich nicht bereits vorhanden sind. Quelle der Weisheit für Inhaltstypen ist unter Unix/Linux zumeist eine bestimmte Datei, meistens ist dies /etc/mime.types genannt. Dort sollte 'image/svg+xml svg svgz' bereits notiert sein. Die Datei wird gegebenenfalls auch von anderen Programmen verwendet und wird bei Aktualisierungen des Betriebssystems automatisch ergänzt.