Firefox 3.0 ohne verbesserte Bildskalierung unter Linux

Gerade habe ich Firefox 3.0 unter Windows und unter Linux installiert. Neben vielen positiven Dingen muss ein für Linux Anwender sehr enttäuschender Punkt angesprochen werden:

Im jetzigen Release 3.0 funktioniert das “smooth image scaling”, das im Vorfeld so viel Furore machte, unter Linux überhaupt nicht, während es unter Windows wirklich beeindruckende Ergebnisse zeitigt.

Inzwischen wurde bereits ein Mozilla-Bug zu dieser Thematik eröffnet. In einem Kommentar zur Bugmeldung wird allen Ernstes empfohlen, sich bei den Linux-Distributoren zu beschweren, da im X-Server benötigte Features fehlen würden. Dazu ist aus Anwender-Sicht Folgendes zu fragen bzw. anzumerken:

1) Fehlt nun etwas in Xorgs X-Server oder implementieren die Packages der Distributoren X nur eingeschränkt?
2) Man versteht als unbedarfter Mensch nicht, was X überhaupt mit der Thematik zu tun haben soll. Müsste dieses Thema nicht eine Ebene höher angegangen werden? Firefox ist doch unter Linux wohl GTK basiert und liefert GTK nicht etliche Funktionen, um eine ordentliche bikubische Interpolation von Images durchzuführen?

Egal wie: Als Linux User bin ich erstmal enttäuscht. Das wird jeder verstehen, wenn er folgende zwei Bilder vergleicht – das erste wurde im FF 3.0 unter Linux gemacht, das zweite im FF 3.0 unter Windows (das natürlich im VMware-Fenster läuft) – bei gleicher Vergrößerungsstufe :

anracon_logo_FF_linux anracon_Logo_windows

Die Enttäuschung ist umso größer, als hier eine Opensource-Firma die Anwender des Opensource-Betriebssystems Linux offenbar als Anwender zweiter Klasse behandelt. Denn dass eine gute Bildskalierung unter Linux ein prinzipielles und ernsthaftes Problem darstellen soll, glaube ich nicht. Das Gegenteil ist durch GIMP, Scribus und diverse PDF-Programme bereits bewiesen. Vielleicht lassen sich aber die Windows-spezifischen Algorithmen nicht 1 zu 1 auf X, KDE und Gnome übertragen. Man müsste wohl eigene Lösungen entwickeln. Die Veröffentlichung des jetzigen Releases zeigt aber wohl, dass die Mozilla-Entwickler dies bislang versäumt haben. Ein schnelles Windows-Release ist inzwischen wohl wichtiger als gute Qualität auf verschiedenen Betriebssystemen ……

KGpg – Schlüsselimport mit Fehlern

Man müht sich ab, seinen Kunden beizubringen, wichtige Informationen im Internet verschlüsselt zu übertragen. Eine Voraussetzung dafür, dass der Kunde sich mit den entsprechenden Verfahren anfreundet, ist, dass das Erzeugen eines Schlüsselpaares und das Verteilen des öffentlichen Schlüssels ohne größere Schwierigkeiten durchgeführt werden kann – unter Linux wie unter Windows. Leider können hier auch unter Linux Schwierigkeiten auftreten, die den Anfänger überfordern.

Vor kurzem konnte ich die Probe aufs Exempel machen – ein Kunde, der Thunderbird unter Windows einsetzt, lud sich das Enigmail-Plugin und GnuPG für Windows herunter. Die Installation verlief problemlos. Ebenso nach einer kurzen Einweisung die Suche nach meinem “public key” und der Import des Schlüssels von einem PGP-Server in den Schlüsselring. Der Kunde konnte mir dann auch ohne Schwierigkeiten verschlüsselte Mails schicken. So weit so gut.

Die Überraschung kam nach dem Generieren des eigenen Schlüssels. Die Erzeugung des Schlüsselpaares verlief wie erwartet. Der Kunde sah den Schlüssel, dessen Kennung (die letzten 8 Ziffern des Fingerprints) und bei einer Detailansicht auch den gesamten Fingerprint. Der Kunde versuchte dann seinen öffentlichen Schlüssel auf einen PGP-Server hochzuladen. Auch dies war ohne Problem möglich. Dann suchte der Kunde zur Probe nach seinem Schlüssel – zunächst mittels eines Statements der folgenden Art:

http://pgpkeys.pca.dfn.de/pks/lookup?op=vindex&hash=on&fingerprint=on&search=0x{16 Hex-Ziffern}

wobei “{16 Hex Ziffern }” durch die letzten 16 Hexadezimal – Ziffern des Schlüssel-Fingerprints zu ersetzen ist. Der Schlüssel wurde einwandfrei identifiziert und angezeigt. Dann probierte der findige Kunde jedoch folgendes Statement, bei der er dem “search”-Parameter nur die letzten 8 Stellen der Schlüssel-Kennung übergab (nur diese werden nämlich typischerweise in den Key-Verwaltungsprogrammen angezeigt):

http://pgpkeys.pca.dfn.de/pks/lookup?search=0x{8 Hex Ziffern = Schlüsselkennung}&fingerprint=on&hash=on&op=vindex

Wie es der (unwahrscheinliche) Zufall so will, kamen als Antwort 2 Schlüssel mit derselben 8-stelligen Kennung hoch – der des Kunden und einer, der im Jahre 1998 angelegt wurde. Diese “Konkurrenz” bzgl. der 8 stelligen Schlüsselkennung fand der Kunde sehr beunruhigend. Ich demonstrierte ihm dann, dass sein Schlüssel dennoch von dem des “Konkurrenten” verschieden war und dass die Schlüsselkennung und der Fingerprint ja eigentlich mehr als 8 Hex-Stellen umfassen. So zeigt z.B. KGpg unter KDE in der Detailansicht eines Schlüssels nicht 8 sondern die hinteren 16 Hex-Stellen des Fingerabdrucks an.

Der wirkliche Ärger begann aber, als ich versuchte, den öffentlichen Schlüssel des Kunden unter Linux/KDE in meinen eigenen Schlüsselring zu importieren. Das misslang unter KDE KGpg bei Einsatz des Standardimports von einem PGP-Server auf wirklich schlimme Weise:

Obwohl ich die eindeutige 16 stellige Kennung im Such/Import-Dialog angab, importierte KGpg beide Schlüssel – den des Kunden und des Konkurrenten. Noch schlimmer: In der Detailansicht wurde bei beiden Namen ein und derselbe Fingerprint (der des Kunden), aber die falsche Kennung (die des Konkurrenten) angezeigt. KGpg hatte also die beiden Schlüssel beim Import intern nicht sauber getrennt.

So etwas ist katastrophal! KGpg ist offenbar nicht in der Lage den Standard-Import von Schlüsseln zu regeln, wenn die letzten 8 Hex-Stellen der Kennung mit denen eines anderen Schlüssels identisch sind. Das Gleich geschah übrigens auch, wenn man nach der dem Schlüssel zugeordneten Namen bzw. der Web-Adresse suchte.

Testweise versuchte ich dann den Import unter Windows mit Thunderbird und den dahinter liegenden OpenPG-Programmen. Auch hier werden zwar zwei Schlüssel importiert – offensichtlich reagieren die Programme nur auf die letzten 8 Hex-Stellen. Aber der Import verlief mit der richtigen Zuordnung der Schlüssel zu den Namen und Webadressen.

Eine Lösung des Problems unter KGpg besteht darin, den Import des Kundenschlüssels manuell über die Zwischenablage durchzuführen. Für Einsteiger wäre das aber nicht zumutbar.

Skalierbare Web-Seiten unter Firefox 2

Mehrere unserer Webkunden haben explizit den Wunsch geäußert, das man Ihre Webseiten auch unter Firefox 2.0 skalierbar gestalten möge. Diesen Wunsch haben wir erfüllt. Es gibt aber einige Fallstricke, die wir hier kurz diskutieren wollen. Die Ausführungen sind vielleicht aber auch von generellem Interesse für diejenigen, die mit “em” als Größeneinheit statt “px” arbeiten.

Grundlagen
Die einheitliche (!) Skalierbarkeit aller Objekte einer Webseite im Firefox (vor Vers. 3.0) kann man durch zwei Dinge gewährleisten:

  1. Definition einer Standardschriftgröße im BODY-Tag nach dem Muster <body style=”font-family:…..; font-size:10px;”>
  2. Bemaßung aller Objektgrößen in den zugehörigen Style- oder Klassendefinitionen statt mit “px” mit “em”. Bsp.:
    <div style=”width:10.0em; height:20.0em;”>

Der Vorteil der Standardisierung auf die Schriftgröße 10px im Body-Tag ist eine vereinfachte Umrechnung:
Die “em”-Werte x 10 entsprechen in der nichtskalierten Seitenversion gerade dem herkömmliche Wert der Ausdehnung in Pixel.

Fallstrick 1: Sukzessive Mehrfachskalierung vermeiden!
Gibt man in einem Tag nicht nur die Geometriegrößen, sondern auch eine abweichende Fontgröße vor, z.B.
<div style=”position:absolute; width:6.0em; height:8.0em; font-size:1.2em; “>,
so wird das DIV keineswegs mit der Größe 60×80 dargestellt, sondern um einen Faktor 1.2 vergrößert. Es zählt immer die aktuelle Fontgröße, die für ein Tag gesetzt ist!

Gegenmittel: Um diesem Problem zu entgehen, kann man die Texte in <span>-Tags einbauen, für die man per CSS vorgefertigte Schriftgrößen definiert. Bsp:

<div style=”position:absolute; width:6.0em; height:8.0em; font-size:1.2em; “><span style=”font-size:12px;”>das ist der text im DIV<span></div>

Schwieriger ist das bei Formularelementen – hier muss man wirklich vorab Berechnungen zur resultierenden Größe anstellen. Formularelemente unterliegen aber ohnehin browserspezifischen Einschränkungen bzgl. der Darstellung. Ein Test in jedem Zielbrowser ist daher angebracht.

Fallstrick 2: Die minimale Schriftgröße im Browser
Hat der Anwender eine minimale Schriftgröße für seinen Browser eingestellt und unterschreitet (!) die im BODY definierte Standardschriftgröße die minimale Schriftgröße, so wird bei einer Seite, die konsequent mit “em”-Größeneinheiten designed wurde, die Geometrie insgesamt mit dem Faktor
“Minimale Schriftgröße des Browsers” / “Standardschriftgröße im BODY”
heraufskaliert.

Beachte: Selbst wenn die Schriftgröße im BODY nicht unter die minimale Schriftgröße des Firefox fällt, so kann doch für einzelne Tags eine andere kleinere Fontgröße definiert sein (s. Fallstrick 1). Für diese Tags wirkt sich dann die minimale Schriftgröße separat aus. Hat man das Vorgehen zu Fallstrick 1 nicht beachtet, so führt dies evtl. zu Schwierigkeiten bei der spezifischen Tagdarstellung oder gar der Seitendarstellung.

Fallstrick 3: Integrierte Flash-Movies
Typischerweise integriert man Flash-Movies W3C-konform mit SWFObjects (Version 1.5 oder 2.0) und verwendet ein zu Container-DIV. In der Version 2.0 wird der Container ersetzt, dessen Bemaßung wird aber übernommen). Hier ist es wichtig, dass der SWF-Film mit der Höhen- und Breiten-Angabe “100%” integriert wird. Dann werden die Maße des Containers beachtet – und wenn diese in “em”-Einheiten vorgegeben sind, so skaliert das SWF-Movie mit.

Wir wünschen viel Spaß beim Ausprobieren!

Eine Seite, die nach diesen Prinzipien von uns entworfen wurde, ist z.B.
http://www.med-aktiv.de