Auszeichnungssprachen wie HTML und XML haben die Besonderheit, dass man in ihnen nicht malen kann wie in einem Layoutprogramm oder einer Präsentationssoftware. Stattdessen werden Bilder referenziert. Sie liegen fix in fertig in einem Ordner – und an der Stelle im Text, an der das Bild gezeigt werden soll, liegt ein Link (<img…>).
Das bedeutet aber auch, dass die Bilder, bevor sie in den Text verlinkt werden können, bereits fix und fertig vorhanden sein müssen, und man ein weiteres Programm benötigt, um die Bilder zu erstellen und zu bearbeiten. Allerdings heißt das auch, dass im Text der Auszeichnungssprache kein Hinweis darauf zu finden ist, wie groß das Bild denn angezeigt werden soll. Das Programm (und auch ein Browser) gehen daher immer von der Größe aus, die das Bild liefert: ein Bild mit den Maßen 2000 x 2000 Pixel wird halt genau so groß dargestellt.
Das ist allerdings häufig nicht gewollt. Zum einen, weil damit Bilder teilweise über den Rand hinausragen und nicht mehr vollständig sichtbar sind, zum anderen, weil der Bildinhalt mit der Bildgröße oft wenig gemein hat, wie beispielsweise bei Icons oder Symbolen: Warum sollte man ein Hinweispiktogramm seitenfüllend darstellen, nur weil es 2000 x 2000 Pixel groß ist?
Früher gab es dazu zwei Möglichkeiten, das Problem zu lösen:
- Man hat die Bildgröße vorgegeben, indem man die Bilder mit einem entsprechenden Programm zurechtgeschnitten oder skaliert hat. Das funktioniert prima, wenn die Seitengröße feststeht, wie im Druck oder in einer PDF, geht aber völlig daneben, wenn das Bild auf einem Tablet oder Smartphone betrachtet werden soll und sich dazu automatisch an die Bildschirmbreite anpassen soll.
- Man hat jedes Bild im Editor nachbehandelt und dazu beispielsweise im HTML die Werte für Höhe und Breite zum Element <img..> dazu geschrieben. Das mag für ein einziges Bild noch funktionieren, für eine große Anzahl Bilder ist das Unfug – und auch dann passen sich die Bilder nicht an die unterschiedlichen Geräte an.
Beide Methoden stammen noch aus der Zeit vor dem „responsive Design„, als man auch Internetseiten nicht anders behandelt hatte als gedruckte Seiten.
Glücklicherweise ist das aber längst vorbei.
Moderne Editoren wie MadCap Flare nutzen dazu HTML5 mit CSS, um darin für bestimmte Bildgrößen eine flexible Anpassung vorzusehen. Damit ist es möglich, für jede gewünschte Bildgröße von vornherein eine bestimmte Höhe und/oder Breite vorzusehen und diese unterschiedlichen Maße als „Klassen“ (Eigenschaftsgruppen) zusammenzufassen und den Bildern zuzuweisen. Dadurch erhalten beispielsweise alle Bilder eine einheitliche Breite (z.B. 50% der Textbreite). Klassen dieser Art lassen sich für jede Bildgröße in beliebiger Komplexität anlegen (mit Schatten, Rand, gerundeten Ecken, Rahmenfarbe oder Abstand und Position).
Sobald man dem Bild eine andere Klassen zuweist oder die Werte in der Klassen ändert, werden automatisch alle weiteren Eigenschaften auf das Bild angewendet. Ein Bild mit der Klasse „.inline“ wird unabhängig von der Ausgabe immer die halbe Textbreite einnehmen und den Abstand zu den umliegenden Objekten (padding) einhalten:
<img src="../../.." class="inline" />Hinter der Angabe zum Ort des Bilds (src=“…“) folgt die Klasse „inline“, die abhängig von der Ausgabe (HTML oder PDF) die folgenden Eigenschaften besitzt:
Im Text sieht das dann beispielsweise so aus:
Bei Icons, die im Text verwendet werden, bedeutet das einen großen Effizienzgewinn, denn ein einziges Piktogramm lässt sich dadurch sowohl als großes Icon wie auch als kleines Icon im Text verwenden, ohne dass dafür jedesmal im Text eine ganze Gruppe von Eigenschaften wie Höhe und Grundlinienabstand eingestellt werden muss – und das unabhängig vom Ausgabeformat.
Oder kurz: bevor man Zeit in die passende Skalierung von Bildern investiert, sollte man sich in Flare einen Satz unterschiedlicher Bildklassen anlegen, die man global mit einer einzigen Einstellung anpassen kann.
Brain matters.