Re: Sub-Pixel-gerenderte Fonts in Gnome unter Woody?
Christoph Haas <email@christoph-haas.de> schrieb:
> Geschmackssache. Wenn ich im Mozilla plötzlich was lesen kann, was
> kleiner als 12pt ist, dann finde ich das persönlich einen großen
> Vorteil.
Also normalerweise schaltet man gerade bei kleinen Schriften AA aus, um
die kleinen Konturen nicht noch weiter zu verwischen. Deshalb schaltet
sich als default AA bei Fonts um 8 oder 6 Punkte bei den meisten
Implementierungen auch meist aus und wird erst bei größeren Schriften
aktiv.
Daß man mittels AA sehr kleine Fonts besser lesen könnte ist entgegen
jeder Lehrmeinung und macht Dich vermutlich zu einem physiologischen
Wunder.
> Und das unstable-Rendering sieht Klassen besser aus als
> der Kram von M$. Generell gegen Antialiasing zu sein, halte ich
> für etwas übertrieben. Du liest deine gedruckten Bücher ja auch
> mit 2400dpi ausgedruckt und nicht mit Printfox und 100dpi auf
> einem Matrix-Drucker ausgedruckt.
Buchdrucker machen aber nun einmal kein AA. AA verhilft Dir ja auch
andersherum nicht zu höheren Auflösungen. Äpfel und Birnen.
Ich habe bei AA immer etwas das irritierende Gefühl, daß ich eine Brille
bräuchte, weil es nun einmal unscharf ist. Das ist anstrengend, weil man
zuviel damit zu tun hat, richtig zu fokussieren.
Mögen viele ästhetischer finden, aber anstrengender ist es.
> Da habe ich mich wohl ungünstig ausgedrückt. Gibt es denn immer noch
> Leute, die CRTs benutzen? ;) "Normales" Antialising würde mir ja schon
> reichen.
Das wiederum sieht normalerweise auf einem Panel meist deutlich
schlechter aus, als auf einem CRT. Hier hat das z.B. den Effekt, daß es
aussieht, als hätten alle Buchstaben einen deutlichen Schatten.
Nein, mit einem TFT will man schon subpixel rendering oder gar nichts.
>> Die älteren Fontserver können das nicht und auch alle neueren
>> Implementierungen können das nicht mit Fontservern, sondern haben
>> eigene Methoden entwickelt, da das normale X Fonthandling sich
>> nicht so ohne weiteres auf Glyphen mit Graustufen aufbohren läßt.
>
> Hast du da konkrete Versions-Angaben? Meine Frage zielt ja in die
> Richtung, inwiefern das mit Stable oder Testing möglich ist.
Die Unfähigkeit, Glyphen mit Graustufen zu handeln, ist protokollabhängig
und damit nicht versionsabhängig. X kann halt per Design mit Glyphen nur
als Bitmaps umgehen, also rein schwarz/weiss.
>> Die Netzwerktransparenz ist damit praktisch futsch und X wird
>> verkrüppelt, da nur client-side Fonts halbwegs funktionieren.
>
> Wäre natürlich schön, wenn das direkt mit im X-Protokoll verankert
> wäre.
xft kann tricksen und die Glyphen auch durchs core Protokoll
durchschleusen, aber das ist hochgradig krank. Beim herkömmlichen Ablauf
fordert der letztendlich darstellende Part, jetzt mal client genannt,
beim fontliefernden Part (mal Fontserver genannt) einfach die
entsprechenden Glyphen an und stellt sie dar.
Nutzt man xft mit AA, dann schickt der Client erst mal den Pixelbereich, in
dem die Glyphe später dargestellt werden soll, zum Fontserver, der kopiert
die Glyphe da antialiased rein und schickt das neu zusammengesetzte Bild
wieder zurück, was der Client dann an ansprechender Bildschirmposition
wieder einkopiert. D.h. man fängt sich Latenzzeiten- und
Bandbreitenprobleme ein.
Nein, das ist kein Scherz. Und nein, Brechreiz ist völlig normal, wenn
man das hört.
> Ich verstehe auch nicht, warum das die Font-Server nicht einfach
> selbst machen sollten.
Weil es kein Protokoll gibt, mit dem ein Fontsserver antialiaste
Glyphen, also solche mit Graustufen, zum darstellenden client
transportieren könnte. Das gesamte Fonthandling von X geht historisch
von einfachen Bitmaps aus.
> Wenn mein X-Server über X-Protokoll mitgeteilt wird, dass er eine
> Schrift auf den Bildschirm pinseln soll, dann muss doch der Server
> selbst dafür sorgen, dass das lesbar ist.
Die Glyphen die zur Darstellung genutzt werden, müssen aber
nicht lokalen Ursprungs sein sondern können auch von einem entfernten
Fontserver stammen und da sind antialiaste Glyphen nicht möglich.
> Ist das ein Problem mit X generell? Liegt das am veralteten Font-Server
> in Stable? Oder an der älteren Xfree-Version? Hier würde ich gerne
> konkreteres wissen.
X kann das einfach nicht und es ist im Protokoll einfach nicht
vorgesehen.
>> Remote geht xft theoretisch auch, aber das ist nur krank und kann man
>> vergessen, weil der Overhead über's Netz gigantisch ist.
>
> Bringt xft (alias FreeType) denn eigene Protokoll-Erweiterungen mit?
> Oder wo kommt der Overhead her?
Das habe ich oben schon beschrieben. Es wird halt alles zweimal durchs
Netz gejagt und dabei werden auch noch Unmengen an Grafiken verschickt.
Zudem fällt beim Weg über das core Protokoll übrigens auch noch die
Unterstützung der Render Extension weg, wodurch es nochmal signifikant
langsamer wird.
> Kann man nicht eigentlich das gesamte Font-Management einfach
> freetype/xft übergeben, statt das den xfs machen zu lassen?
Für Deinen privaten Heimrechner mag es ja egal sein, ob Du einen
Fontserver verwendest oder nicht, aber in größeren Installationen kann
man da teilweise nur schwer drauf verzichten.
freetype kann nur mit lokalen Fonts umgehen und xft geht zwar
theoretisch über Netz aber praktisch ist das halt nicht zu gebrauchen.
Ergo fesselt AA einen an die lokal installierten Fonts was völlig gegen
die Grundprämissen von X ist und so nebenbei eines der Hauptargumente
für X gegenüber anderen Lösungen kräftig entwertet.
> Das hört sich nicht gut für mein Weltbild an. Antialiasing ist ja nun
> keine Erfindung dieses Jahrtausends. Wundert mich, dass es da noch
> nichts Einheitliches gibt.
Du vergißt, wie alt X ist. Und so wichtige Sachen wie das Fonthandling
kann man nicht einfach komplett umwerfen. Rückwärtskompatibilität ist
wichtig und wie das aussieht, wenn man sich nicht drum schert, erlebt
man immer wieder aufs Neue bei MS.
Gruß,
Marcus
--
The three Rs of Microsoft support: Retry, Reboot, Reinstall.
eMail: m@followup-to.de
Reply to: