e ? ?

Es handelt sich nämlich hierbei um das sog. “estimated e” auf Verpackungen. Dieses ist ein Sonderzeichen, welches Windows, Mac und Linux eigentlich unbekannt ist und sich in Word und HTML aber herbei zaubern lässt. Des Rätsels Lösung lautet Unicode: Hier hat das Estimated Symbol die Position 8494 bzw. U+212e und dementsprechend die HTML-Entität ℮ bzw. ℮.

Wenn jetzt dieses “magische e” in einem HTML-Formular eingegeben wird und das Formular in PHP weiterverarbeitet wird, hat man ein Problem. Denn wie ich nach langem Suchen herausfinden konnte, wird dieses magische e bereits vom Browser in die numerische HTML-Entität umgewandelt, bevor der Request an den Server übermittelt wird. Herausfinden konnte ich das im Übrigen mit der genialen Firefox-Erweiterung “Live HTTP-Headers“.

Zurück zu meinem Problem: Es wurde also in einem HTML-Formular dieses böse ? eingegeben und diese Eingabe sollte später in einer E-Mail-Benachrichtigung ihren Platz finden. Da bereits der Browser die Umwandlung in eine HTML-Entität durchführte, musste diese nun PHP-seitig wieder rückgängig gemacht werden. Leichter gesagt als getan. Denn eine String-Konvertierung mittels mb_convert_encoding führte nicht zum Ziel. Egal, ob ich nach ISO-8859-1, ISO-8859-15, Windows-1252 oder auch UTF-8 konvertierte, das Ergebnis blieb das gleiche: Aus ? wurde ?

Nach Rücksprache mit dem Kunden habe ich dann eines gemacht:

$msg = str_replace('℮','e',$msg);

Da das ? kaum von einem normalen e zu unterscheiden ist, steht zukünftig ein normales e in den Benachrichtigungs-Mails geschrieben.

Die letztendliche Implementierung hat nicht lange gedauert. Die Suche, warum sich das ? so seltsam verhält, allerdings über zwei Stunden

Eine Sache störte mich allerdings wirklich: Im Firefox 3.0.x war es so, dass auch der letzte Tab immer als Tab angezeigt wurde (Einstellungen => Tabs => “Tab-Leiste immer anzeigen” angewählt). Zusätzlich konnte ich den letzten Tab mittels eines kleinen Icons schließen, ohne dass sich der Firefox beendet, und es wurde anstelle des geschlossenen Tabs ein leerer Tab angezeigt. Ich fand das ganz praktisch, denn so konnte ich den Firefox anweisen, dass er nach jedem Start die zuletzt geöffneten Tabs wieder öffnet – eben auch den leeren Tab. Und genau dieses Verhalten vermisste ich schmerzlich in der neuen Version.

Die Lösung fand ich nach einigem Suchen im Netz. Die Lösung besteht allerdings aus zwei Teil-Lösungen, da es anscheinend auch zwei verschiedene Probleme sind, die es zu lösen gilt:

1. Bei Schließen des letzten Tabs, soll der Firefox sich nicht mehr schließen.
   1. Dazu gibt man in der Adresszeile about:config ein und bestätigt die evtl. angezeigte Warnung, um an die erweiterten Firefox-Einstellungen zu gelangen.
   2. Man füttert die Filter-Zeile mit
      browser.tabs.closeWindowWithLastTab
   3. Als Standard ist der Wert
      browser.tabs.closeWindowWithLastTab
      auf true eingestellt. Den Wert ändert man auf false. Dazu reicht ein einfacher Doppel-Klick auf den Wert.
2. Damit der letzte Tab immer den “Schließen-Button” anzeigt, muss man sich eine eigene userChrome.css basteln.
   1. Im Profil-Verzeichnis (also z.B. C:\Dokumente und Einstellungen\WINDOWSBENUTERNAME\Anwendungsdaten\Mozilla\Firefox\Profiles\abcdefgh.default\ unter Windows XP) gibt es einen Unterordner chrome
   2. In diesem Ordner gibt es eine Beispiel-Datei namens userChrome-example.css
   3. Diese Datei kopiert man in das gleiche Verzeichnis und benennt die Kopie userChrome.css
   4. Am Ende dieser Datei fügt man die folgende CSS-Anweisung hinzu:

      .tab-close-button {display: -moz-box !important;}

      Bei mir steht da der folgende Sermon (inkl. Kommentar, damit ich auch noch in zwei Monaten weiß, warum ich den Eintrag gemacht habe):

      1 2 3 4 5 6 7

      /* Letzter Tab soll auch einen Schliessen-Button behalten Besonders geschickt mit der Einstellung browser.tabs.closeWindowWithLastTab = false in der about:config */ .tab-close-button {display: -moz-box !important;}

3. Jetzt nur noch den Firefox neu starten und alles läuft wieder wie gewohnt

Manche Leute mögen ja vielleicht Klötzchen-Grafik – aber nicht in Google Earth!

Aus PHP heraus rufen wir ImageMagick sowohl unter Windows als auch unter Linux per exec() auf. Nicht gerade besonders elegant, aber wirkungsvoll Vor allem ist das Ansprechen per exec() in einer Objekt-orientierten Umgebung alles andere als intuitiv. (Wir setzen bei besagtem Projekt Symfony als Framework ein). So haben wir uns also eine Adapter-Klasse geschrieben, die den Zugriff auf ImageMagick hübsch objektorientiert verpackt.

Unter Linux bereitet diese Art der Einbindung von ImageMagick uns keinerlei Kopfschmerzen. ImageMagick ist ebenso wie GhostScript auf den meisten Linux-Servern schon installiert oder mit geringem Aufwand über die Distributions-eigene Paketverwaltung schnell nachinstalliert. Auch die Performance lässt sich sehen. Und unter Windows? Die Installation von IM und GS klappt mit den grafischen Installern noch ohne Probleme. Aber die Performance von ImageMagick lässt per PHP und exec() doch ein wenig zu wünschen übrig (für das Rendern einer Vorschau benötigt unsere Applikation die doppelte bis dreifache Zeit unter Windows – trotz schnellerem Prozessor und mehr Hauptspeicher). Man merkt halt schon, für welche Plattform sowohl IM als auch GS entwickelt wurden.

Als native Schnittstelle gibt es schon seit Jahren das PECL-Paket Imagick. Es wurde jedoch seit 2004 nicht mehr weiter entwickelt. Erst im Frühjahr dieses Jahres haben sich wieder zwei Entwickler der Weiter-Entwicklung angenommen. Mittlerweile ist Imagick auch als Version 2.0.x stabil. Die 2er-Version wurde konsequent auf PHP5 und Oojekt-Orientierte Programmierung ausgelegt, so dass es keine Probleme bereiten sollte, Imagick in vorhandenen Projekten einzusetzen. Einziges Problem unter Windows ist jedoch, das PECL-Pakete nicht in PHP, sondern in C implementiert sind und man deshalb entweder vorkompilierte DLLs benötigt, oder selber den Compiler anwerfen muss. Da ich nicht über Microsoft Visual Studio verfüge und auch sonst ein wenig mit C auf Kriegsfuß stehe, blieb nur noch Variante eins übrig.

Der Finne Mikko Koppanen, seines Zeichens einer der beiden Entwickler von Imagick, hat aber über sein durchaus lesenwertes Blog die vorkompilierten DLLs für Windows bereitsgestellt. Die passende DLL herunter zu laden und in mein PHP-Extensions-Verzeichnis zu speichern war noch nicht wirklich schwierig. Aber den Kram ans Laufen zu bekommen schon. Das alte HowTo, auf welches auch Mikko hingewiesen hat, war nur ansatzweise hilfreich. Vor allem hat es irgendwie das Layout zerschossen und ich kann daher nur jedem nahe legen, der sich dieses HowTo durchlesen möchte und Firefox mit installierter Web-Developer-Toolbar zur Verfügung hat, die Funktion zum Deaktivieren von Inline-Styles zu nutzen. Andernfalls lassen sich manche Quotes nicht lesen…

Nach Studium des o.g. HowTos habe ich mich dann an die Arbeit gemacht, Imagick auf meinem Notebook (Windows XP Pro, Apache 2.2.4 als Service, PHP 5.2.3 als CGI) ans fliegen zu bekommen:

• Die heruntergeladene DLL php_imagick_dyn-Q8.dll landet im Extensions-Verzeichnis meiner PHP-Installation (bei mir C:\php5\ext)
• Die DLL muss natürlich in der php.ini aktiviert werden:
  extension=php_imagick_dyn-Q8.dll dem Block mit den Erweiterungen hinzufügen
• Eine info.php mit folgendem Inhalt ins htdocs-Verzeichnis gelegt:
  <?php
phpinfo();
?>
  und im Browser aufgerufen.
• Und was ist passiert? Nichts! Kein Imagick wird mir unter den aktivierten PHP-Erweiterungen angezeigt. Wenn ich PHP auf der Kommando-Zeile anspreche, dann bekomme ich die Fehlermeldung angezeigt, dass es nicht möglich wäre die besagte DLL zu laden.
• Dem obigen Howto konnte ich entnehmen, dass der Pfad zu ImageMagick-Installation der PATH-Umgebungsvariable von Windows hinzuzufügen sei. Gesagt, getan, aber der Kram will immer noch nicht.
• Der Vorschlag mit dem Setzen von
  SetEnv MAGICK_HOME="C:/Programme/ImageMagick"
  in der httpd.conf des Apache will auch nicht so richtig funktionieren.
• Letztendlich hat es dann damit geklappt, indem ich die Umgebungsvariable MAGICK_HOME mit dem Wert C:\Programme\ImageMagick Windows beigebracht habe.
• Aber erst nach einem Windows-typischen Neustart konnte ich endlich das Ergebnis meiner Bemühungen nach Aufruf der info.php im Browser bewundern:
  

  

Nachdem jetzt alles läuft, wollte ich doch mal ausprobieren, ob der Performance-Zuwachs tatsächlich so toll ist, wie es Mikko als Ergebnis seines “Micro-Benchmark” in seinem Blog gepostet hat. Das Ergebnis war doch etwas ernüchternd: Teilweise hat es mit Imagick doppelt so lange gedauert, als über den Aufruf von convert via exec().

Ich werde mal ein wenig an ein paar Stellschrauben drehen (z.B. wie sich das Einstellen der “Ressource Limitations” auswirkt) und was ich noch mit den ganzen anderen Parametern anstellen kann, die im Manual zu Imagick genannt, aber kaum bzw. nicht weiter beschrieben sind.

Auch werde ich demnächst ein wenig Code und Beispiel-Dateien posten, mit denen meine Versuche nachvollzogen werden können.

Mit der FF-Erweiterung “Live HTTP Headers” bin ich allerdings dem Fehler recht schnell auf die Spur gekommen: Der Firefox schickt anstelle von “application/pdf” den MIME-Type “text/html” mit. Warum er das macht kann ich noch nicht ganz nachvollziehen. Fakt ist aber, dass der sfFileValidator bei der Prüfung auf den MIME-Type des vom Browser mitgesendeten MIME-Type validiert und nicht auf den Tatsächlichen. Wenn alle Stricke reißen, muss ich wohl einen eigenen Validator schreiben, der dann “richtig” den MIME-Type prüft und sich nicht auf die Informationen des Browsers verlässt.

Ich schalte also in den BIOS-Einstellungen in freudiger Erwartung die Virtualisierung ein, das BIOS warnt mich davor, weil HP vor dem Einsatz warnt (warum bauen die dann erst Prozessoren ein, die dieses Feature anbieten *kopfkratz*) und boote den Rechner wieder. Windows meldet zwar kurz, dass sich seit dem letzten System-Start die Hardware-Konfiguration geändert hat, startet dann aber wie gewohnt. Erst als ich danach Virtual PC starte, bekomme ich etwas zu sehen, dass ich schon lange nicht mehr zu Gesicht bekommen habe: Den Bluescreen of Death! Schon seit ewigen Zeiten habe ich ihn nicht mehr gesehen. Weder auf meinem alten Notebook (lief noch unter Windows 2000) noch auf meinem Desktop-Rechner (ca. 1,5 Jahre alt mit WinXP) habe ich seit langem mehr ins Blaue geblickt.

Es kommt aber noch besser: Da sich der Rechner nach seinem blauen Exitus sofort zu einem Neustart aufrafft, schalte ich sofort im BIOS die Virtualisierung wieder ab (HP hatte wohl mit der Warnung nicht ganz unrecht) und Windows startet wieder. Wieder starte ich Virtual PC und sofort raucht der Rechner wieder ab. Ich möchte nur zu gerne wissen wieso?

Wie dem auch sei: Ich habe den Virtual PC erst einmal deinstalliert und werde ihn bald neu installieren. In der Zwischenzeit werde ich mal Ausschau halten, ob es irgendwo ein BIOS-Update, Howto und ähnliches gibt, damit ich doch noch Virtual PC mit der Prozessor-Virtualisierung ans fliegen bekomme.