Schriftarten

In den vergangenen Jahren kam ich gelegentlich immer wieder mit dem Thema “Größenverhältnisse” von GUI Elementen in Berührung. Und bis heute gibt es keine Formel, kein Konzept und keine Regel, die mich davon überzeugt hätte, im allgemeinen Fall als “richtig” zu gelten.

Doch in Webseiten hat mit CSS eine Regelung Einzug gehalten, die ich zumindest aus Sicht des Benutzers für sinnvoll erachte.

Alles orientiert sich an der Standard Schriftart. Ist diese gut gewählt, können Abstände und andere Elementgrößen daraus abgeleitet werden. Dieses Konzept ist auch die Basis von vielen Responsive-Designs im Web.


In den meisten nativen APIs dreht sich alles um Pixel Also wie überträgt man das auf die Schnittstellen der Betriebssysteme?

Aus Sicht des Programmierers wird es in Windows hier etwas kompliziert. Schriftarten werden gerne in “Points” gemessen, die sich aus der eingestellten Anzahl der “Punkte pro Zoll” (Dots per Inch oder DPI) ableiten. Und zu allem Übel gibt es hier noch die relative Höhe des Durchschnittszeichens und die absolute (maximale) Höhe der Schriftart.

Mit der absoluten Höhe lässt sich am besten arbeiten, da aus diesem Rahmen kein Pixel herausfallen kann. Es ist quasi die kleinste Hülle um einen Text.

Wir fragen also das Betriebssystem nach der eingestellten Standardschrift und deren absoluter Höhe. SystemParametersInfo() liefert uns unter Windows diese Info mit der Konstante SPI_GETICONTITLELOGFONT und zwar als negative Zahl. Negative Zahlen sind absolute und positive sind relative Höhenangaben. Und somit wissen wir, wie hoch eine Zeile in Pixel ist.

Anstatt nun zu sagen, ein Fenster wäre fix 300 mal 200 Pixel groß, behaupten wir einfach, es wäre z.B. 25 x 17 Zeilenhöhen groß.

Falls jemand einen großen Monitor besitzt, der über eine hohe Auflösung verfügt, sind oft die Dots per Inch (DPIs) ebenfalls höher konfiguriert, womit das OS alle Schriftarten automatisch vergrößert um besser lesbar zu sein.
Und genau so schaffen wir eine primitive Form von “responsive Design” auch unter klassischen Desktop Anwendungen.

Natürlich lässt sich dieses Spiel beliebig erweitern, wenn wir die Ausmaße des Bildschirms oder eines UI-Elements durch die Schriftzeilenhöhe dividieren und basierend auf diesen Zahlen andere Anordnungen von internen UI Elementen vorsehen.
Genau so wie es im Web mit CSS mit den Media Queries ebenfalls funktioniert.

Größere UI Frameworks nutzen ähnliche Effekte, wo es errechnete “Standardabstände” gibt, die zwischen Elementen entsprechend aufsummiert werden um automatisch eine schöne Ausrichtung von Elementen zu erzielen.


Fazit

Man kann also durchaus gute Konzepte der Webentwicklung auf klassische Anwendungen übertragen.
Einziger Nachteil ist, dass man dennoch oft Positionen selbst berechnen oder zumindest formal beschreiben muss.
Desktopanwendungen waren über lange Zeit nur Pixel-basierte Formulare, weshalb auch deren Tools auf diese Sichtweise eingeschränkt ist.

Moderne UIs, die durch XML beschrieben werden, wie z.B. UWP XAML oder Android Layouts nehmen uns aber dieses Problem elegant ab.

📧 📋 🐘 | 🔔
 

Meine Dokus über:
 
Weitere externe Links zu:
Alle extern verlinkten Webseiten stehen nicht in Zusammenhang mit opengate.at.
Für deren Inhalt wird keine Haftung übernommen.



Wenn sich eine triviale Erkenntnis mit Dummheit in der Interpretation paart, dann gibt es in der Regel Kollateralschäden in der Anwendung.
frei zitiert nach A. Van der Bellen
... also dann paaren wir mal eine komplexe Erkenntnis mit Klugheit in der Interpretation!