Die Geschichte vom unscharfen Text

Windows Presentation Foundation, kurz WPF, ist eine relativ neue Technologie von Microsoft, um für .NET-Programme grafisch anspruchsvolle Benutzeroberflächen zu bauen. Ein wie ich finde sehr gelungenes Beispiel einer mit Hilfe von WPF erstellten kommerziellen Applikation (also etwas in der Art, wie die Megos auch Software anbietet), findet man hier.

Es gibt bei WPF allerdings ein Problem, und je nach dem, wen man fragt, sogar ein ziemlich gewichtiges: WPF verwendet für sämtliche Textausgaben Anti-Aliasing, mit dem Resultat, dass Text mehr oder weniger unscharf wird, je nach Monitor, Bildschirmauflösung, Schrift und dem Sehvermögen des Betrachters. Ich habe hier zwei WPF-Buttons mit ihren Beschriftungen in fast unfairer Weise vergrössert, damit man das Phänomen in seiner ganzen Pracht sieht (in Originalgrösse sehen die Buttons brauchbar aus):

Ein weiteres Beispiel findet man hier.

Anti-Aliasing bei Textausgabe muss nicht schlecht sein, und schon seit einiger Zeit leistet die ClearType-Fonttechnologie auf Windows XP z.B. auf gewissen Notebook-Displays gute Dienste. Aber: Man kann es bei WPF nicht ausschalten, auch in der neuesten Framework-Version 3.5 nicht, und es ist eine von ClearType unabhängige, unterschiedliche Implementation, die offenbar nicht immer gleich gut ist.

Wie man dieser Diskussion in einem MSDN-Forum entnehmen kann, bitten gewisse Entwickler Microsoft nun schon seit über 2 Jahren inständig darum, man möge doch einen Schalter einführen, um die Sache abzuschalten. Passiert ist offenbar in der ganzen Zeit – ausser einigen Erklärungsversuchen von Microsoft und Zusicherungen, man nähme das Problem ernst – nichts.

Es handelt sich um eine Sache, die vielschichtiger ist, als man nach dem ersten Blick meint. Die in der WPF verwendete Technologie ermöglicht es, Buchstaben quasi genauer als nur auf Pixel genau zu positionieren, und das kann wichtig sein bei dynamischen Layout- und Grössenänderungen, wie sie WPF unterstützen möchte.

Man kann auch relativ schnell mit einem Argument von Microsoft einig gehen, dass Anti-Aliasing auf Monitoren mit hoher Pixeldichte (Anzahl Pixel pro Distanz), also z.B. nicht mit den üblichen 96 Pixels pro Inch, sondern 200 oder noch mehr, wunderbar aussieht.

Man könnte sich trotzdem relativ einfach auf den Standpunkt stellen, dass etwaige “Nebenwirkungen” des Abschaltens des Anti-Aliasing voll auf den Schultern des Programmierers lasten, welcher abschaltet, und ich denke, die Leute in der erwähnten Diskussion wären damit auch sofort einverstanden. Trotzdem hatte Microsoft bisher kein Einsehen.

Solche Geschichten faszinieren mich oft, weil ich mich unweigerlich frage, was wohl jeweils die Geschichte hinter der Geschichte ist. Ich spekuliere gerne über die “Wahrheit”, die oft ziemlich wenig mit Technik und ziemlich viel mit Psychologie zu tun haben dürfte. Es muss fast mehr dran sein als einfach nur ein “Informatik-Problem”, sonst wäre die Sache schon längst ausgestanden.

Darf ich also mal ein bisschen spekulieren, und ein paar Verschwörungstheorien über den nach wie vor unscharfen WPF-Text in die Welt setzen? (Und es sind Spekulationen, ich weiss nicht mehr als Sie!)

Irgend ein hohes Tier bei Microsoft ist Fan von Anti-Aliasing, will von Kritik einfach nichts wissen und ist so mächtig, dass er oder sie nicht überstimmt werden kann.

Microsoft möchte Druck ausüben auf die Hersteller von LCD-Panels, damit diese tatsächlich dazu übergehen, in Richtung hoher Pixeldichten zu entwickeln, was sie im Moment eher nicht tun – die Displays werden meistens einfach nur grösser.

Irgend jemand bei Microsoft mit viel Einfluss und Reputation hat sich am Anfang dermassen stark gemacht für Anti-Aliasing, dass er oder sie jetzt unmöglich eine Fehleinschätzung zugeben kann.

Das ungeliebte Anti-Aliasing bleibt drin sozusagen als Bestrafung für jemanden, der es zu verantworten hat. (Sobald der oder die “weggemobbt” ist, kommt der geforderte Aus-Schalter.)

Microsoft spekuliert, auf die Entwickler Druck ausüben zu können, wenn man WPF-Applikationen sofort als solche erkennt, unter anderem eben am Anti-Aliasing, so in der Art von “Was, Du arbeitest noch mit Windows Forms?”

Wie dem auch sei, ein glückliches Ende der Geschichte vom unscharfen Text ist im Moment offenbar nicht in Sicht…

Erstkontakt mit XmlSerializer

Ich habe mich diese Woche zum ersten Mal näher mit dem Thema XML-Serialisierung in .NET mit Hilfe der Klasse XmlSerializer auseinandergesetzt und hatte bei diesem “Erstkontakt” eine lustige kleine Verständnis-Schwierigkeit.

Ich ging mit der mehr oder weniger stillschweigenden Grundannahme an die Sache heran, ich könne mit Hilfe des XML-Serializers eine beliebig grosse Menge von (an sich unabhängigen) Objekten in ein XML-File speichern, eines um das andere, und suchte deshalb in der Dokumentation nach Informationen und Ratschlägen darüber, wie es am besten organisiert beim De-Serialisieren, damit man weiss, welche Objekte in welcher Reihenfolge sich im XML-File befinden.

Als ich darüber nichts fand, schrieb ich ein kleines Testprogramm, öffnete einen Stream und speicherte mit Hilfe zweier Serializers direkt zwei verschiedene Objekte hinein. Dieses Testprogramm lief durch, erzeugte aber ein ungültiges File, denn dessen Inhalt entsprach einfach zwei kompletten XML-Files aneinandergehängt.

Ich modifizierte das Programm und verwendete einen XmlWriter. Dieser merkte beim Serialisieren des zweiten Objekts, das etwas nicht stimmte, und verursachte eine Exception, allerdings mit einem ziemlich nichtssagenden Fehlertext, so in der Art “geht nicht”.

Erst dann dämmerte es mir langsam, dass ich mit meiner Grundanahme einer völligen Freiheit beim Serialisieren wohl danebenlag. Ich stellte danach fest, dass die Dokumentation eigentlich ganz klar ausdrückt, dass man nur genau ein Objekt in ein XML-File serialisieren kann, denn bei der Methode Serialize steht die Information Serializes the specified Object and writes the XML document to a file. Man beachte das Wort “document”.

Ich habe bei einer Suche im Internet per Google alle möglichen Texte über verschiedenste Limitationen von XmlSerialize gefunden, aber keinen, wo jemand demselben Irrtum unterlag wie ich und schliesslich zur Erkenntnis gelangte, nein, mehr als 1 Objekt geht nicht.

Ich habe mich auch gefragt, ob das nun innerhalb des .NET-Frameworks ein Beispiel von schlechtem Klassen-Design sei, wenn man so leicht völligen Unsinn anstellen kann und erst zur Laufzeit abgefangen wird. Ich sehe aber nicht, wie man die beteiligten Klassen und Methoden so definieren könnte, dass man gar nicht in die Versuchung kommen kann, mehrere Objekte ins selbe File zu serialisieren.

Natürlich könnte man anstelle eines Stream-Objekts der Methode Serialize alle Angaben mitgeben, damit sie intern einen Stream erzeugen kann (den man dann eben als Programmierer gar nicht zur Verfügung hätte, um zu versuchen, noch etwas anderes hineinzuschreiben), aber das ist nicht sinnvoll.

Am interessantesten an der ganzen Sache war, mich selbst dabei zu beobachten, wie viel es manchmal braucht, um quasi auf den richtigen Weg zurückzufinden, wenn man bereits früh falsch abgebogen und eine Weile falsch marschiert ist!

Wo steht Mono heute?

Das Open-Source-Projekt Mono implementiert C# und grosse Teile des .NET-Frameworks auf Nicht-Windows-Plattformen wie Linux und Mac OS/X.

Ich finde dieses Projekt faszinierend und habe seit seinem Bestehen immer wieder mal nachgeschaut, wie es denn so läuft; selber angewendet habe ich Mono allerdings noch nicht.

Interessant ist unter anderem die kontroverse Situation, in der sich Mono befindet: Es geht darum, Technologien des “Erz-Rivalen” Microsoft nachzubauen, um sie der Welt der “freien” Software verfügbar zu machen. Bisher steht Microsoft offenbar der ganzen Sache wohlwollend gegenüber, aktuell unter anderem vielleicht deswegen, weil das Projekt mit Moonlight Silverlight-Programme auf mehr Plattformen ausführbar macht. Sollte Microsoft hingegen der Sache je überdrüssig werden, dürfte es jede Menge Möglichkeiten geben, um Mono das Leben ganz schön schwer zu machen.

Also, wo steht Mono heute? Wie man hier sieht, hat das Projekt einen beeindruckenden Umfang angenommen. WinForms-Unterstützung ist nahezu komplett, so dass man viele auf Windows unter Microsoft .NET entstandene Programme mit Hilfe von Mono einfach so unter Linux laufen lassen kann. Ein Visual-Basic-Compiler scheint auf guten Wegen, und wie gesagt entsteht gerade in Form von Moonlight ein Gegenstück zu Silverlight. Es existiert mittlerweile sogar ein Tool, das .NET-Projekte auf Kompatibilität mit Mono hin untersucht.

Auf der anderen Seite ist mir aber beim Studium der Mono-Website erst so richtig klargeworden, welchen Umfang das Original mittlerweile angenommen hat. Microsoft scheint bei der Weiterentwicklung von .NET ein Tempo vorzulegen, das auch bei einem Open-Source-Projekt mit breiter Unterstützung wie Mono nur schwer zu halten ist: Ich habe den Eindruck gewonnen, dass die “Verfolgungsjagd” eine schwierige Sache ist. Und bei WPF haben offenbar die Verantwortlichen des Projekts einen Punkt gesetzt und explizit beschlossen, diese Technologie nicht nachzubauen.

Da ich ziemlich viel mit Architektur- und Design-Fragen von Software-Systemen zu tun habe, beschäftigt mich auch die Frage, ob es wirklich eine gute Idee ist, sich im wesentlichen darauf zu beschränken, 1-zu-1 die Microsoft-Vorgaben nachzubauen. Auf der einen Seite ist natürlich C# eine sehr gute Programmiersprache, und das .NET-Framework eine über weite Strecken sauber konzipierte Klassen-Bibliothek – es gäbe eine Menge viel dümmerer Dinge, die man nachbauen könnte.

Aber auf der anderen Seite habe ich das Gefühl, dass hier die Innovation etwas auf der Strecke bleibt: Was hätten die Schöpfer von Mono zu Stande gebracht, wenn sie sich zwar von Microsoft hätten inspirieren lassen, aber etwas Eigenes geschaffen hätten? Wir werden es leider nie wissen…