Probleme mit »krummen« usWeightClass-Werten?

[Þorsten]

Folgendes Problem: In Linux/X11-Systemen¹ ist es anscheinend nicht möglich, sowohl den Light- als auch den Thin-Stil der Yanone Kaffeesatz zu installieren. Der Grund: Die Light hat einen usWeightClass-Wert von 300 (entspricht Light); die Thin hat aber den »krummen« Wert 250, der zwischen den Stufen Ultra-light (200) und eben Light liegt. Um korrekte Stil-Namen zu generieren, »rundet« der Fontserver anscheinend nicht durch 100 teilbare Werte auf glatte Hunderter. Jedenfalls wird der der 250-er Schnitt ungeachtet seiner internen Namensgebung als Kaffeesatz Light angezeigt (statt Kaffeesatz Ultra-light oder Kaffeesatz Thin, was passender wäre) – und damit gibt es einen Namenskonflikt mit der eigentlichen Light (die den Wert 300 hat). (Ändere ich den Wert der Thin auf 200, kooexistiert sie problemlos mit der Light.)

Frage: Ist es sinnvoll, solche »krummen« Werte zu vergeben (zumindest bei Schriftarten, die nicht mehr als drei Stärken haben als normal – und die Kaffeesatz hat ja nur derer zwei)?

Mit der tatsächlichen geometrischen/visuellen Stärke einer Schrift korrespondieren diese Werte wohl ohnehin nicht (dazu gefundenes Zitat: The usWeightClass in the OS/2 and Windows Metrics table should not be confused with the ’style’ or typographic weight of the font.).

Na ja, ich wollte bloß mal fragen, ob hier jemand damit Erfahrungen hat, bevor ich Linux/X11/KDE/GNOME-Bugs einreiche oder den Herrn Yanone nerve.

, Thorsten

¹ getestet mit KDE (Kubuntu); das Problem tritt anscheinend aber auch bei GNOME-basierten Systemen auf

[Soc]

Ja, ich habe genau das gleiche Problem mit Lucas de Groot's TheAntiqua (OpenType).

Insgesamt habe ich da 14 Schnitte (von Light bis Black + Kursiven) von denen nur 6 tatsächlich unter Gnome anwählbar sind. Die WeightClass-Werte sind größtenteils in 30er-Schritten (und einmal glaube ich in 50er Schritten) angegeben.

In FontForge kann man das "fixen" in dem man die Werte auf die dafür vorgesehenen Werte zurückstellt. Allerdings schraube ich nicht sehr gerne mit FontForge daran herum, da ich mir nie ganz sicher bin, ob er da nur ein paar Metadaten ändert oder gleich die komplette Schrift neu baut.

Ich kann mir vorstellen, dass man das Ganze mit einer entsprechenden Fontconfig-XML beheben kann, allerdings kenne ich mich da nicht gut genug aus.

Hier würde mich mal eine Stellungnahme der Schriftdesigner interessieren:

Was für Gründe gibt es von den Standardwerten abzuweichen?

Oder wird die WeightClass aus irgendwelchen tatsächlichen Glyphenformen errechnet?

[Þorsten]

Ja, ich habe genau das gleiche Problem mit Lucas de Groot's TheAntiqua (OpenType).

Insgesamt habe ich da 14 Schnitte (von Light bis Black + Kursiven) von denen nur 6 tatsächlich unter Gnome anwählbar sind. Die WeightClass-Werte sind größtenteils in 30er-Schritten (und einmal glaube ich in 50er Schritten) angegeben.

Aber da es ohne die Kursiven »nur« 7 Schnitte sind, sollten die prinzipiell in das 100-900er Raster passen.

In FontForge kann man das "fixen" in dem man die Werte auf die dafür vorgesehenen Werte zurückstellt. Allerdings schraube ich nicht sehr gerne mit FontForge daran herum, da ich mir nie ganz sicher bin, ob er da nur ein paar Metadaten ändert oder gleich die komplette Schrift neu baut.

Das größere Problem dürfte sein, dass du das bei den meisten kommerziellen Schriften (und selbst vielen kostenlosen) einfach nicht darfst. Die meisten Lizenzen verbieten jedwede »Modifizierung« der Schrift.

Hier würde mich mal eine Stellungnahme der Schriftdesigner interessieren:

Was für Gründe gibt es von den Standardwerten abzuweichen?

Ich bin kein Schriftdesigner, aber prinzipiell erscheint mir das nur begründet, wenn eine Schriftart tatsächlich mehr als 9 Stärken hat/haben könnte oder eben Abstufungen, die nicht ins Raster passen (also z.B. irgendeine Zwischenstufe zwischen Book und Regular oder so). Aber sonst?

Vielleicht können die hier mitlesenden Schriftgestalter ihren Stift mal eine Weile beiseite legen und uns erhellen.

Oder wird die WeightClass aus irgendwelchen tatsächlichen Glyphenformen errechnet?

Man kann wohl nicht ausschließen, dass irgendein Schriftgestaltungsprogramm das tatsächlich macht. Andersrum haben die Werte m.W. aber keinen Einfluss darauf, wie die Schriften gerendert werden.

[ThierryM]

Das größere Problem dürfte sein, dass du das bei den meisten kommerziellen Schriften (und selbst vielen kostenlosen) einfach nicht darfst. Die meisten Lizenzen verbieten jedwede »Modifizierung« der Schrift.

?nde eigentlich nur ich das ein absurdes verbot? ich verstehe jedenfalls nicht das interesse des schriftdesigners, mich daran zu hindern, mit der software zu machen, was ich will. oder ist das eher eine ›wo kein kläger …‹-regelung, die keinen freelancer für das anpassen von ein paar kerningpaaren in seiner einzellizenz belangen will, sondern sicherstellen soll, dass der designer etwas rechtlich bindendes in der hand hat, wenn jemand anfängt, modi?kationen seiner schrift zu vertreiben oder anderweitig in umlauf zu bringen? ich bin zwar der typ, der sich bei reklamationen an die foundry wendet, aber ich kann nicht behaupten, dass mich eine eula besonders interessieren würde, wenn ich etwas für den hausgebrauch ändern wollte.

bye

thierry

[Þorsten]

ich verstehe jedenfalls nicht das interesse des schriftdesigners, mich daran zu hindern, mit der software zu machen, was ich will.

Wenn du selbst kleinste Probleme an einer Schrift (oder jeder anderen Software) nicht selbst beheben kannst, hast du vielleicht keine andere Wahl als eine neue Version zu kaufen.

[Sebastian Nagel]

Wirklich eine Antwort geben kann ich auch nicht, aber was ich hier lese:

"The FontWeights values correspond to the usWeightClass definition in the OpenType specification. The usWeightClass represents an integer value between 1 and 999. Lower values indicate lighter weights; higher values indicate heavier weights."

scheint es "erlaubt" zu sein, auch andere Werte zu verwenden?

Ich würde zwar auch nicht auf die Idee kommen, "krumme" Werte zu verwenden, wenn nicht notwendig, aber wenn nur 100er-Schritte erlaubt wären, gäbe es dann nicht einfach eine Skala von 0 bis 9?

Klar, eine Zuordnung Gewichtsnummer zu Schnittnamen ist immer eine Gratwanderung, aber in den Schriften selbst ist diese Zuordnung in der Regel ja auch manuell vom Gestalter gegeben.

Ich habe die zwei Variablen bisher deshalb immer so interpretiert: Manuell vergebene Bezeichnung zur Anzeige (für den User sichtbar), usWeight zur automatischen und eindeutigen Sortierung. Da würden dann auch Werte wie 250 keine Probleme mehr machen ... 200 < 250 < 300 – Reihenfolge ist klar, und die Anzeige so, wie der Schriftgestalter sich das gedacht hat. Ob das System je zur Generierung von automatisierten Schnittnamen gedacht war, oder die Zuordnung von Hunderterwerten zu gängigen Namen nicht einfach nur Konvention sind? Der Zitierte Satz oben lässt auch darauf schließen.

-------------

Thema EULA und Modifikationen:

Vielleicht, weil es den Support wesentlich schwieriger macht, wenn man grundsätzlich "erlaubt", das Produkt zu modifizieren. Wenn ich weiß, dass nichts verändert wurde, und etwas "passt" nicht, ist das meine Sache als Hersteller, den Mangel zu beheben. Wenn der Kunde das Produkt verändert hat, nicht mehr zwingend.

In der Regel ist es ja so, dass wenn man beim Hersteller anfragt, die Erlaubnis doch gegeben wird – nur weiß er dann definitiv, dass die Schrift verändert wurde, und man praktisch einen "Sondervertrag" abgeschlossen hat. Klar, das mag "hart" klingen, aber irgendwo muss man als Hersteller auch eine Absicherung haben, wofür man noch verantwortlich ist, und wofür eben nicht mehr.

Ob es Kalkül ist, ein "fehlerhaftes" Produkt zu verkaufen, um dann hinterher für das Update nochmal abzukassieren? Ich weiß nicht ob sich in der "Fonts-Industrie" wirklich jemand so weit aus dem Fenster lehnen will. Ich habe bisher noch niemanden kennengelernt, der diesen Standpunkt vertritt oder praktiziert.

Klar, das ganze ist nicht OSS-Denkweise, sondern eine Variante innerhalb des "klassischen/alten" Systems, das man auch in aller Härte oder mit kundenfreundlichen Abfederungen auslegen kann. Ich glaube, die Schriftenhersteller sind in der Regel auf Anfrage eher kundenfreundlich, sichern sich aber gegen Kunden ab, die selbst gerne "hart" spielen.

[Soc]

@Sebastian: Ich gehe mal davon aus, dass Deine Aussage bedeutet "Ja, krumme Werte sollten funktionieren".

D. h. Thorsten und ich sollten jetzt den Fontconfig-/Gnome-/KDE-Menschen damit auf den Geist gehen, weil das deren Fehler ist.

@Thorsten: Ich werde mal suchen wo der entsprechende fehlerhafte Code sich versteckt.

Falls Du noch mehr Infos hast, am besten alles in diesen Thread (Links zu Bug-Reports, Spezifikationen, Patches, etc.), damit ich mitlesen kann und wir nicht Bugs doppelt melden.

Danke!

[Sebastian Nagel]

@Sebastian: Ich gehe mal davon aus, dass Deine Aussage bedeutet "Ja, krumme Werte sollten funktionieren".

D. h. Thorsten und ich sollten jetzt den Fontconfig-/Gnome-/KDE-Menschen damit auf den Geist gehen, weil das deren Fehler ist.

Naja ... ich habe die Spezifikationen nicht gemacht, nur interpretiert, was ich finden konnte.

Die Frage ist, warum aus diesen Werten überhaupt irgendwelche Schnitt-Bezeichnungen generiert werden sollen - Wenn es wirklich 999 mögliche Zustände gibt, sind Unschärfen und Kollisionen in den Begrifflichkeiten vorprogrammiert.

Wie schon gesagt: der Schriftgestalter kann ja selbst Begriffe für jeden Schnitt vergeben, die ihm am passendsten erscheinen. Die Nummern dienen eigentlich nicht als Vorlage dafür, sondern eben für andere, technischere Funktionen. Wenn die Nummern zur Anzeige herangezogen werden, könnte man auch gleich die Nummern selbst dafür verwenden - also z.B. statt "Fontname Bold" > "Fontname 700"?

[Ajan]

Hallo zusammen,

nachdem ich lange nur gelesen habe, finde ich jetzt mal die Möglichkeit, auch meinen Senf dazu zu geben.

Die Opentype Spezifikation sieht eindeutig nur die Werte 100-900 vor:

usWeightClass

Format: 2-byte unsigned short

Title: Weight class.

Description: Indicates the visual weight (degree of blackness or thickness of strokes) of the characters in the font.

Comments:

Value Description C Definition (from windows.h)

100 Thin FW_THIN

200 Extra-light (Ultra-light) FW_EXTRALIGHT

300 Light FW_LIGHT

400 Normal (Regular) FW_NORMAL

500 Medium FW_MEDIUM

600 Semi-bold (Demi-bold) FW_SEMIBOLD

700 Bold FW_BOLD

800 Extra-bold (Ultra-bold) FW_EXTRABOLD

900 Black (Heavy) FW_BLACK

Zu finden unter http://www.microsoft.com/typography/otspec/os2.htm#wtc

[Sebastian Nagel]

Hmmm, stimmt auch wieder.

Zumindest fast ... die Zuweisung der Hunderterschnritte zu den Schnittnamen scheint festgelegt zu sein. Ob andere Werte nicht erlaubt sind, und wofür es sonst 999 Stufen gibt, steht auch da wieder nicht. Sind sie für Truetype, aber nicht für Opentype gedacht?

(Ich will keinesfalls das "Ergebnis" in meine Richtung drängen, aber ein Beweis in dem Sinne ist es noch nicht ...)

Hier scheint noch jemand das Problem zu kennen:

http://hacks.mozilla.org/2010/11/firefo ... e-support/

In einem Kommentar (fast ganz unten, einfach nach "usweight" suchen) fragt jemand danach, ob das Problem mit den Zwischenwerten für FF4 unter Linux gelöst wurde. Das Thema/Problem scheint also bekannt zu sein ... (Oder drehen wir uns hier grade im Kreis, und das ist jemand von uns, der dort nachfragt?)

PS. Willkommen im Forum :)

[Soc]

Hi Sebastian!

Ja, wir drehen uns im Kreis. Die Person, die dort gefragt hat, war ich.

Auch der Post auf den Thorsten sich im ersten Beitrag bezieht auf design.canonical.com ist von mir ...

Die Welt (bzw. Google) ist irgendwie verdammt klein :?

[Ajan]

Zumindest für die Windows Presentation Foundation sind tatsächlich definitv alle Werte zugelassen:

FontWeight: If ‘OS/2’ table is present, use ‘usWeightClass’: if 1 <= usWeightClass && usWeightClass <= 9, usWeightClass = usWeightClass * 100 if usWeightClass < 1 || usWeightClass > 999 reject the font file as malformed set FontWeight to usWeightClass value (WPF supports all values between 1 and 999). else use ‘macStyle’ from ‘head’ table: if macStyle bit 0 is set, FontWeight is set to Bold else FontWeight is set to Normal

5

WPF directly supports all numeric font weight values between 1 and 999 in both WPF API and markup. In addition, WPF provides a set of named constants for commonly used font weight values, and using such constants is equivalent to using corresponding numeric values. WPF font weight name OpenType weight value Thin 100 ExtraLight 200 UltraLight 200 Light 300 Normal 400 Regular 400 Medium 500 DemiBold 600 SemiBold 600 Bold 700 ExtraBold 800 UltraBold 800 Black 900 Heavy 900 ExtraBlack 950 UltraBlack 950

Quelle:

http://www.google.de/#hl=de&source=hp&q ... 8ad5fcd1b0

[Jens Kutilek]

Die Opentype Spezifikation sieht eindeutig nur die Werte 100-900 vor:

Nein, tut sie nicht. Die dortige Zuordnung steht unter »Comments« und ist somit nicht Teil der OT-Spezifikation. Sie gibt nur eine Implementierung wieder, nämlich eine von Windows (die aber wie schon erwähnt, z.B. von WPF nicht benutzt wird).

Der tatsächliche Wertebereich von usWeightClass geht aber aus der Spezifikation hervor: Das Feld ist vom Typ ushort, also sind Werte zwischen 0 und 65535 möglich.

Trotzdem sollte man natürlich die verbreitetsten Implementierungen berücksichtigen, wenn man die Werte für eine Fontfamilie wählt. Deshalb benutzt man in der Praxis Hunderterschritte. Dabei gibt es aber noch ein paar Einschränkungen:

400 entspricht Regular. Theoretisch sind als leichtere Fettegrade nun 100, 200 und 300 möglich. Man könnte in einer Fontfamilie also 3 Schnitte haben, die leichter als Regular sind.

Praktisch ist es aber so, daß Fonts mit den Werten 100 und 200 in Windows-GDI-Applikationen künstlich gefettet werden, z.B. in Word, was die Benutzung dieser Werte praktisch unmöglich macht. Also bleibt für einen Font, der leichter als Regular ist, nur der Wert 300 übrig.

Was macht man aber, wenn es mehrere dünne Schnitte, wie Hairline, Thin, ExtraLight und Light gibt? In dem Fall muß man von den 100er-Schritten abweichen.

Man könnte auch manche Werte für mehrere Fonts vergeben, dann lassen sie sich aber unter Umständen numerisch nicht mehr eindeutig ansprechen. Ein eher kosmetischer Effekt ist, daß Fonts mit gleichen WeightClass-Werten im Schriftmenü von InDesign nicht mehr korrekt nach Fettegrad, sondern alphabetisch sortiert werden.

Nach oben hin gibt es ein ähnliches Problem: Z.B. wenn es einen Book-Schnitt gibt, der zwischen Regular und Medium liegt. Dort bleibt nichts anderes übrig, als einen Wert von 450 zu vergeben.

[Soc]

Praktisch ist es aber so, daß Fonts mit den Werten 100 und 200 in Windows-GDI-Applikationen künstlich gefettet werden, z.B. in Word, was die Benutzung dieser Werte praktisch unmöglich macht. Also bleibt für einen Font, der leichter als Regular ist, nur der Wert 300 übrig.

Hast Du da einen Link dazu? Passiert das in allen Word-/Office-Versionen?

Was hat sich MS dabei bloß wieder gedacht ...

[Jens Kutilek]

Hast Du da einen Link dazu? Passiert das in allen Word-/Office-Versionen?

Nen Link hab ich: http://www.adobe.ca/devnet/opentype/afd ... t_win.html

Und ich habe das auch schon mal gesehen. War glaub ich Office 2003 auf Windows XP. Ob es in Office 2010 auch noch so ist, müßte ich morgen mal im Büro ausprobieren. Ich vermute schon, weil MS ja Bugs auch aus Kompatibilitätsgründen ewig mitschleppt ....

Viele Grüße,

Jens

[Þorsten]

Praktisch ist es aber so, daß Fonts mit den Werten 100 und 200 in Windows-GDI-Applikationen künstlich gefettet werden, z.B. in Word, was die Benutzung dieser Werte praktisch unmöglich macht.

Wie dämlich! Aber das erklärt, warum Yanone den Wert 250 für die Kaffeesatz Thin gewählt hat. Dass das Probleme in Linux bereitet, ist dann offensichtlich das kleinere Übel.

Ich denke mal, dass für die Linuxseite ein Bugreport in Fontconfig ansteht.

Gibt es Anlass zur Hoffnung, dass der GDI-Bug in absehbarer Zeit behoben wird?

[Sebastian Nagel]

Ich denke mal, an GDI wird - wie wir MS kennen aus Kopatibilitätsgründen und weil veraltet - gar nichts mehr repariert werden ...

[Þorsten]

Mit den Innereien von Windows kenne ich mich nicht aus, aber zumindest in der Wikipedia ist von GDI und GDI+ auch in Windows 7 die Rede. Sollte das Problem mit neueren Windowsversionen nicht mehr auftreten?

[Sebastian Nagel]

Seit Win7 gibt es Direct2D (Grafik) / Directwrite (Textrendering), das zwar noch GDI-abwärtskompatibel ist, aber auch in einem "nativen" Modus angesprochen werden kann (das ist natürlich Sinn der Sache). Ich bin aber auch kein Programmierer, die Details muss ich dir also schuldig bleiben.

Sichtbare Vorteile für Typografen: Hardware-beschleunigt (=schnell), wesentlich bessere Textdarstellung, auch wenn dieser transformiert ist (gedreht, Pfadtext, ...) und Opentype-Features systemweit. FF4 und IE9 verwenden die API schon, wenn sie denn verfügbar ist (also unter Windows Vista und 7).

Nachdem das das neue System ist, und Microsoft peinlichst auf Kompatibilität bedacht ist, selbst wenn diese mit Bugs behaftet ist, fürchte ich, dass Fehler in der Textdarstellung von GDI/GDI+ nicht mehr behoben werden.

[Þorsten]

Zumindest in meinem Vista hier existiert der Bug noch. Hier ein Screenshot von OOo Writer, in der die Thin – mit einem usWeightClass-Wert von 200 – fetter erscheint als die Light.

Zum Vergleich noch mal mit unveränderten Thin:

(Da kann man übrigens auch noch mal sehen, wie toll ClearType – mit allen Optimierungen – ist.)

Mit den Schriften erzeugte PDFs sehen um Welten besser aus. Die Stärke ist bei beiden Thin-Versionen identisch, aber komischerweise ist die Laufweite unterschiedlich. Ein anderer Bug?

[Sebastian Nagel]

Sieht sehr hübsch aus :)

Zu Vista: man benötigt offenbar ein "Platform Update for Windows Vista", um Direct2D und DirectWrite generell im System zu haben.

Dann muss das Programm diese API auch verwenden, und ich denke man muss hoffen, dass es keine "Alleingänge" macht (wer weiß, was Word alles selbst vermurkst?). Soweit ich weiß, verwendet die aktuelle Beta7 von FF4 und die aktuellen IE9-Previews Directwrite, auch paint.net soll es verwenden, wenn es im System installiert ist. Ich nehme an, dass auch Office 2010 dann darauf aufbauen wird, 2007 aber sicher noch nicht, und OOo wahrscheinlich auch noch nicht.

Jedenfalls ist das Textrendering das du hier zeigst typisch für Cleartype in großen Schriftgraden (Treppen in fast-Waagrechten).

Da ich kein Vista betreibe, kann ich all das nicht testen :)

[Jens Kutilek]

Ich hab das jetzt noch in Windows 7 ausprobiert.

Die gute Nachricht: Word 2010 stellt einen Thin-Schnitt mit WeightClass 200 korrekt dar.

Die schlechte Nachricht: In OpenOffice wird er immer noch künstlich gefettet.

Viele Grüße,

Jens

[Þorsten]

Ich würde empfehlen, auch mit WordPad und evtl. anderen Windows-System-Apps zu testen – einfach um auszuschließen, dass das Problem nicht bei Anwendungen von Drittanbietern liegt.

Ich hatte vergessen zu schreiben, dass in meinem Vista-Test auch WordPad 200er Schnitte künstlich und hässlich fettbrezelt.