PNGs und JPGs sind zwei beliebte Bildformate im Internet - das eine kann Transparenz, das andere komprimiert Bilder gut. Das Problem ist, man kann es nicht kombinieren.

So die Theorie, und eigentlich stimmt es auch. Aber was macht man, wenn man wie im ECCO-Projekt schöne große freigestellte Zoom-Bilder auf elegante Bühnen stellen will? 4MB oder gar 12MB dem Nutzer zumuten? Wohl kaum.

Eine Lösung musste her, der Screen sah einfach zu gut aus, als dass er an der Technik scheitern durfte. Und wir fanden eine Lösung: Wir schnitten den inneren Teil aus jedem Schuh und zerteilten ihn in Rechtecke, die komplett opaque waren und sich damit als JPG gut komprimieren ließen. Der Rest, die halbtransparente Hülle, blieb in einem PNG, das nun nicht mehr viel Bildmaterial enthält und dadurch ebenfalls klein ist.

Das klingt total wild, reduziert aber den Platzbedarf tatsächlich um mehr als zwei Drittel, z.B. von 970KB auf 250KB. Bei größeren Bildern sogar im Verhältnis noch besser. Es lohnt sich.

Und so läuft das Verfahren im Detail, und zwar komplett automatisiert:

Zuerst wird das Ausgangsbild auf die vorgegebenen Minimal- und Maximalgröße für Zooms heruntergerechnet. Dies geschieht mithilfe der Thumbnail-Factory des Commerce-Frameworks, die mit nur wenigen Zeilen Code komprimieren, herunterskalieren, croppen, auf Hintergründe stellen und das Format wechseln kann.

Nun wird das Zoombild in Kacheln zerteilt und auf Transparenz untersucht. Kacheln, die ausschließlich aus vollständig opaquen Pixeln bestehen, können in das JPG verschoben werden. Damit die Anzahl der späteren Requests reduziert wird, werden dabei nicht mehrere JPGs erzeugt, sondern nur eins mit denselben Maßen wie das Zoom-PNG.

Hier das Ergebnis nach dem Kacheln und Verschieben:

Als weiterer Analyseschritt werden zusammenhängende Kacheln gesucht und Rechtecke gebildet. Für jedes dieser Rechtecke wird ein absolut positioniertes DIV mit dem JPG im Hintergrund erzeugt. Das JPG stellt dabei ein Sprite dar, jedes DIV zeigt einen Ausschnitt. Ach ja, und das PNG natürlich noch dazu, und schon wird ein Schuh draus.

Die Lösung existiert als wiederverwendbarer Java-Code unter Verwendung von JAI, das Verfahren ist aber technologieunabhängig, es gibt also keine Ausreden mehr für große, transparente Bilder.

Der Funktionsumfang von Firebug ist schon beachtlich, umso erstaunlicher und erfreulicher ist die Tatsache, dass der Funktionsumfang von Firebug noch durch verschiedene Add Ons und/oder kleinerer Tricks erweitert werden kann.

Solch eine nützliche Erweiterung ist beispielsweise FirePHP - mit deren Hilfe man PHP debuggen kann. Ein weiteres AddOn genannt YSlow ist ein Firebug AddOn aus dem Hause Yahoo. Kurz zusammengefasst geht es hierbei, wie es der Name (gesprochen wie: Why Slow?) schon sagt, der Frage "Warum eine Seite so langsam ist" nach. Neben Zeitangaben zum Seitenaufbau, erhält der Entwickler detaillierte Angaben wie sich diese Zeit zusammensetzt und an welcher Stelle etwas ggf. verbessert werden kann.

Der nachfolgende Screencast als Ergebnis eines weiteren SinnerSchrader Technik Tracks beschreibt verschiedene Debugging AddOns zu Firebug.



Addons zum Debugging mit Firebug
from vimeorookie on Vimeo.

Während die Entwicklung von Javascript relativ einfach und umkompliziert
vonstattengeht, gestaltet sich das Debugging durch die limitierten
Debugging Funktionen umso schwieriger. So gab es bis vor kurzem keinen
effektiven Weg, um Debugging Nachrichten anzuzeigen bzw. auszugeben. Wenn überhaupt, dann nur in Form einer Sammlung verschiedenster Alert Fenster oder zigfacher Document.write() Befehle.

Die Lösung des Problems besteht im Einsatz eines Debuggers in Form eines Firefox Plugins, wodurch der Entwickler einen im Web Browser integrierten Debugger erhält.

Es wird also nur der Firefox Browser sowie das Firebug Plugin benötigt.

Firebug bietet eine ganze Menge an spannenden Funktionen wie z.B.
Seitenauskuft über HTML- und DOM-Elemente, das Ändern von CSS oder HTML Elementen on the 'fly', eine Konsole mit Kommandozeile und noch viele weitere Funktionen sowie eine Firefox Unabhängige Lite Version, die
auf der offiziellen Webseite näher beschrieben werden.

Der nachfolgende Screencast als Ergebnis eines SinnerSchrader Technik
Tracks beschreibt das Debugging von JavaScript mit Hilfe von Firebug.



Javascript Debugging mit Firebug from vimeorookie on Vimeo.

Wozu braucht man animierte Favicons?

Hier ein Beispiel: http://www.dhl-usa.com/home/Home.asp
(anschauen mit Firefox)

Vor kurzem las ich ein neues Fachbuch gegen, in dem die Autorin riet, man solle bei der Platzierung von Seitenelementen auf den sichtbaren Bereich achten. Auch unter Kunden ist dieser Begriff sehr beliebt. Man achtet auf den "sichtbaren Bereich".

Mich erinnert das immer an den Falz der Tageszeitung. Es zeigt ein Missverständnis in Bezug auf das Internet. Natürlich gibt es Bereiche einer Webseite, die beim Laden der Seite nicht direkt sichtbar sind. Man muss scrollen, um sie zu erreichen. Aber die Fomulierung "sichtbarer Bereich" wird immer so gewählt, als handele es sich dabei um eine feste Größe. Streng genommen können wir nur von 200 bis 300 Pixeln Höhe ausgehen, die sich im initialen sichtbaren Bereich befinden. Alles andere ist von den Besuchern abhängig. Welche Auflösung hat mein Monitor? 1024x768 wie mein Notebook oder 1920x1200 wie mein Rechner an der Arbeit oder 1280x1024 wie mein Rechner zuhause oder gar nur 800x480 wie mein EeePC?

Welche Höhe soll ich nun als "sichtbaren Bereich" festlegen? DIe sichtbare Höhe wird zusätzlich dadurch beeinfußt, ob ich Browserleisten wie die Google-Toolbar installiert habe und ob ich den Browser maximal augefahren habe oder nicht. Auf meinem 1920er Display schiebe ich mir die Browser immer so in der Größe zurecht, wie ich es für richtig halte.

Die Stärke des Internet sind die Vielfalt und die Flexibilität der Darstellungsmöglichkeiten. Das ist auch gleichzeitig die Herausforderung für die, die für das Internet arbeiten. Der "sichtbare Bereich" ist in der gewünschten absoluten Höhe ein Mythos! Die Menschen scrollen, wenn sie etwas lesen wollen und noch relevanten Content erwarten.

Reflow bezeichnet den Prozess bei dem die Layout Engine des Browsers die Geometrie und Position der darzustellenden Elemente berechnet. Dieser Prozess wurde bei der Entwicklung von Gecko 1.9 deutlich verbessert. Diese neue Gecko Version ist Bestandteil von Firefox 3.

Und wer schon immer mal wissen wollte, wie der Firefox die Seiteninhalte berechnet, sollte einen Blick auf folgende Videos werfen. Satoshi Ueyama hat das Programm "Inside Gecko" in Processing geschrieben, das den Seitenaufbau verzögert darstellt.

Reflow von Mozilla.org:

Reflow von Google.co.jp:

Reflow von Wikipedia: