Dialog mit eigenem Font bei erhöhter Lesbarkeit verzerrt
-
Ich habe eine eigene DialogBox-Routine geschrieben, die eine gewöhnliche Dialog-Ressource lädt und derart präpariert, dass der Font umgestellt wird auf den Font, der mit SystemParametersInfo(SPI_GETNONCLIENTMETRICS, ... ) als MenuFont erhältlich ist.
Unter Win7 z.B. "Segoe UI(9)". Ist viel schöner und lesbarer als mit "MS Shell Dlg". 2- bzw. 4-Byte-Boundaries der DLGTEMPLATEEX, Unicode usw. werden natürlich gemäß SDK beachtet. Der Aufruf erfolgt dann mit DialogBoxIndirectParam(). Soweit so gut.Wenn die Lesbarkeit unter Win7 nun von 100% höher gestellt wird, z.B. 125%, wird der Dialog und die Schrift zwar größer, aber der Dialog in der Höhe mehr als in der Breite. Ein quadratisches Control wird hochformatig. Dadurch passen auch viele Texte nicht mehr in die Control-Rechtecke. Die Schrift selbst ist nicht verzerrt.
Es sieht so aus, als wenn Win7 bei einer Änderung des Lesbarkeitsfaktors den speziell gesetzten Dialog-Font nicht richtig berücksichtigt. Mit "MS Shell Dlg" geht es. Dieses Phänomen kann ich auch im Visual Studio 2010 beobachten. Im Optionen-Dialog sind bei erhöhter Lesbarkeit viele eigentlich einzeilige Controls zweizeilig geworden oder Texte abgeschnitten. Die verwenden dort auch den Segoe UI für Dialoge.
Ist das ein Win-Bug oder haben die Studio-Entwickler dasselbe falsch gemacht wie ich?
-
Du verstehst DLUs falsch!
In Dialogen werden Dialogbase Units verwendet.
Diese messen sich alleine an den Font Werten. Und man kann nicht davon ausgehen, dass Quadrat von 1x1 DLU etwas quadratisches ergibt!8 DLU in der Höhe ergeben eine Zeichne Höhe. 4 DLU in der Breite sind die "durchschnittliche Zeichenweite" bei dem eingestellten Font.
Stellst Du also einen Font ein, der breiter ist aber die gleiche Höhe hat, wird der Dialog automatisch breiter.
Das es entsprechende Verschiebungen bei Text gibt, dfamit musst Du rechnen.
Unsere Software wird in Deutsch, Englisch, Französich, Ungarisch und Türkisch übersetzt. Auch hier müssen wir extrem auf Platz für die Bezeichner achten.Es ist genau umgekehrt der Fall: Weil Windows die Fontgröße berücksichtigt entsteht dieser Effekt.
-
Hallo Martin,
ich verstehe die DialogBaseUnits schon so, wie du sagst. Aber auch wenn der neue zugrunde liegende Font ein ganz anderes durchschnittliches Höhen-/Seiten-Verhältnis besitzt, sollten sich ja alle Controls und der Dialog selbst genauso wie der ausgegebene Text verhalten. Das bewirkt ja gerade, dass dann alles weiterhin in seine Rechtecke passt. Ein paar Pixel Rundungsabweichungen, gerade bei langen Textzeilen, kann es vom FontMapper natürlich immer geben. Die sollte man zugeben.
Übrigens besitzt "Segoe UI(9)" gegenüber den "MS Shell Dlg"-Substitutionen kein sichtbares anderes Verhältnis, sondern macht den Dialog nur proportional größer. Es funktioniert ja auch alles.Das Problem liegt aber nicht im Wechsel zu einem anderen Dialog-Font, sondern im Wechsel auf eine andere Lesbarkeitsstufe, die in der Systemsteuerung/Anzeige/Textgrößen... eingestellt wird. Der Font bleibt ja derselbe. Das Resultat ist aber eine Verzerrung der System-DLU-Skalierung. Bei 100% macht Windows es richtig (alles so wie du es sagst), aber bei 125% ist es schon falsch und zwar eklatant. Scheinbar vertikal korrekt, aber horizontal zu wenig vergrößert (ich schätze um ein Drittel!).
-
Ich habe bisher leider immer nur 125% als Beispielwert für eine Lesbarkeitsvergrößerung ausgewählt. Ich musste jetzt feststellen, dass bei 150% und selbst definierten Werten alles zur Zufriedenheit funktioniert. Win7 scheint nur bei 125% eine ganz besondere logische Vergrößerung durchzuführen, die nicht ganz richtig funktioniert. Für andere Werte wird scheinbar auch außerhalb von Dialogen eine Bitmap-Skalierung durchgeführt: Sehr verwirrend!
Ich schätze, die wenigsten Anwender haben sich jemals mit dieser Einstellung ungleich 100% eingehend beschäftigt.
Vielen Dank.
