Gentium Plus

[Axel Jagau]

Auf http://scripts.sil.org/cms/scripts/page.php?item_id=GentiumPlusTest ist seit gestern eine Testversion der erweiterten Gentium zum Herunterladen vorhanden. Neu hinzugekommen sind – soweit ich das auf die Schnelle sehen konnte – ein kompletter kyrillischer Zeichensatz und Kapitälchen, dazu ein paar „Variant Glyphs“.

[RobertMichael]

danke für den tipp und willkommen im forum.

[Mach]

Grossartig, noch mehr Gentium, und noch mehr Font-Intelligenz! Mir ist allerdings nicht ganz klar, warum diese Neuheiten nicht in den normalen Gentium-Font integriert werden, oder ob so eine Integration dereinst geplant ist. Was nützt eine Multiplizierung der Gentium-Fonts?

[Axel Jagau]

Ich denke schon, daß die „Plus“-Variante dann zum Schluß wohl als einzige übrigbleiben wird. Im Moment ist es ja eben nur eine Testversion.

[Typ Ø]

Seh ich das richtig, dass Ligaturen derzeit nur in der Kursiven enthalten sind?

[Sebastian Nagel]

Seh ich das richtig, dass Ligaturen derzeit nur in der Kursiven enthalten sind?

Also laut Fontlab-Datei sind fi, fl, ff, ffi, ffl in beiden Fonts enthalten, regular und italic.

Allerdings haben sie laut vfb-Quell-Datei kein LIGA-Feature eingebaut. Wenn die Ligaturen also auftauchen, dann macht das Satzprogramm das selbstständig.

[Þorsten]

Es gibt Glyphen für die gängigen f-Ligaturen und sie werden auch standardmäßig aktiviert (»liga«). Die Glyphen sehen nur nicht aus wie typische f-Ligaturen (die waagerechten Striche sind bei ff nicht verbunden; der i-Punkt bei fi ist noch da …).

[Axel Jagau]

Naja, in den Gentium-FAQ heißt es dazu:

In Gentium-Regular there is really no need for a ligature, and because of the design of the f and i, a ligature would tend to look out of place. But if you look in Gentium-Italic, you'll see 'fi' and 'ffi' ligatures. They still have a separate dot on the 'i', but are connected.

[Þorsten]

Sicher, aber trotzdem sind Ligaturen vorhanden und standardmäßig aktiviert. Sie sind nur visuell identisch zu den Einzelbuchstaben. Warum? Keine Ahnung. Gibt’s da irgendwelche technischen Gründe? Mir fallen eher Nachteile ein, z.B. wenn Text gesperrt werden soll. Den z.B. beim Fraktur-ck beabsichtigten Effekt will man bei den f-Ligaturen ja gerade nicht haben.

[Mach]

Da die Ligaturen im OpenType-Feature "liga" definiert sind, sollte eigentlich kein nachteiliger Effekt beim Sperren auftreten – solche Ligaturen sollten beim Sperren nicht gesetzt werden. Allerdings geschieht dies trotzdem in einigen Programmen, etwa in TextEdit.app oder Firefox auf Linux oder Windows (Firefox auf Mac OS X hingegen oder InDesign tun es korrekt). Die obligatorischen Fraktur-Ligaturen ch, ck, ?t und tz werden im Unterschied dazu im OpenType-Feature "rlig" definiert, so dass sie beim Sperren erhalten bleiben.

Was das Sperren angeht, ist also an dieser Codierung in Gentium Plus eigentlich nichts auszusetzen (wozu man allerdings Gentium Plus sperren sollte, wäre eine andere Frage).

[Sebastian Nagel]

Warum? Keine Ahnung. Gibt’s da irgendwelche technischen Gründe? Mir fallen eher Nachteile ein, z.B. wenn Text gesperrt werden soll. Den z.B. beim Fraktur-ck beabsichtigten Effekt will man bei den f-Ligaturen ja gerade nicht haben.

Die Standard-f-Ligaturen sind teil des Basiszeichensatzes einer Schrift. Manche (alte, opentype-dumme) ligaturfähige Programme erwarten diese Zeichen an ihrem gewohnten Platz, und zeigen Platzhalter oder gar nichts, wenn sie eine Ligatur generieren, diese aber im Font nicht vorhanden ist, selbst wenn die Einzelzeichen da wären.

Ergo: die Ligaturen müssen technisch vorhanden sein - ob sie dann optisch anders sind als die Einzelzeicheen, ist eben eine Gestaltungsfrage.

[Þorsten]

Die Standard-f-Ligaturen sind teil des Basiszeichensatzes einer Schrift. Manche (alte, opentype-dumme) ligaturfähige Programme erwarten diese Zeichen an ihrem gewohnten Platz

Was bedeutet »an ihrem gewohnten Platz«? Dass f-Ligaturen manchmal über ihre Unicode-Werte eingefügt werden (und das deshalb z.B. auf Position U+FB00 – dem Wert für »ff« – was stehen sollte), kann ich noch nachvollziehen. Aber gibt es auch (nicht-OT-fähige) Software, die das über die Glyphnamen macht? Gentium Plus hat z.B. gleich zwei ff-Ligaturen: einmal auf U+FB00 den Glyphen »ff« und dann nochmal ohne Unicode-Wert den Glyphen »f_f«. Beide sehen identisch zu den Einzelbuchstaben »ff« aus. Aber OK, wenn bestimmte Software nach diesen Glyphennamen sucht, soll man das halt auch einbauen. Bloß was ich absolut nicht verstehe ist, warum dann auch noch eine liga-Tabelle angelegt werden muss. Gibt’s dafür irgendeinen technischen Grund?

[Sebastian Nagel]

Die Standard-f-Ligaturen sind teil des Basiszeichensatzes einer Schrift. Manche (alte, opentype-dumme) ligaturfähige Programme erwarten diese Zeichen an ihrem gewohnten Platz

Was bedeutet »an ihrem gewohnten Platz«? Dass f-Ligaturen manchmal über ihre Unicode-Werte eingefügt werden (und das deshalb z.B. auf Position U+FB00 – dem Wert für »ff« – was stehen sollte), kann ich noch nachvollziehen. Aber gibt es auch (nicht-OT-fähige) Software, die das über die Glyphnamen macht? Gentium Plus hat z.B. gleich zwei ff-Ligaturen: einmal auf U+FB00 den Glyphen »ff« und dann nochmal ohne Unicode-Wert den Glyphen »f_f«. Beide sehen identisch zu den Einzelbuchstaben »ff« aus. Aber OK, wenn bestimmte Software nach diesen Glyphennamen sucht, soll man das halt auch einbauen. Bloß was ich absolut nicht verstehe ist, warum dann auch noch eine liga-Tabelle angelegt werden muss. Gibt’s dafür irgendeinen technischen Grund?[/quote:1beo2f2l]

Die "neue", anerkannte Methode, Ligaturen abzulegen, ist die Benamung mit _ (f_f) und *kein* Unicode-Wert. Grundsätzlich sollte man alle Mitglieder einer Zeichengruppe gleich behandeln, d.h. alle Ligaturen nach diesem Schema ablegen, nicht die einen so, und die anderen ("alten") noch auf die alte Methode, also mit eigenem Codewert.

Da man aber gleichzeitig kompatibel sein will/muss (man weiß ja nie wo und wie die Schrift eingesetzt wird), sollte man der Glyphe auch nach ihrem bisherigen Namen benennen und einen Codewert geben ...

Ein unlösbares Dilemma, man schleppt entweder die alte Methode bis in alle Ewigkeiten mit, oder wird sofort inkompatibel – wenn man nicht einfach zwei Glyphen anlegt, eine "alte" ff-Ligatur, und eine "neue" f_f-Ligatur, die sich optisch gleich verhalten, aber technisch nicht.*

So gibt man Opentype-fähigen, Glyphennamen-fähigen Programmen die offizielle Methode, alle Ligatur-Glyphen gleich zu generieren (im liga-Feature wird das f_f ohne Code verwendet) und später auch zu exportieren (sonst hat unter ungünstigen Umständen das ff im PDF einen Codepoint, währen f_j keinen hat - womit wir wieder bei durchsuchbarem Text etc. wären).

Und Programme, die hard-coded Codekombinationen durch andere Codewerte austauschen (statt "nur" gegen Glyphen) und von Glyphennamen keine Ahnung haben, finden ihre alte Ligatur.

* Sowas ähnliches muss auch gemacht werden, um ein Kapitälchen-Versal-ß in Indesign CS2 zum laufen zu kriegen – hier ist hard-coded eine Ersetzung ß --> SS eingebaut, die man nur weg kriegt, indem man eine Kapitälchen-Glyphe erstellt, die optisch zwar ein Kapitälchen-ß darstellt, technisch aber nicht ... Das Programm darf einfach nichts davon merken.

[Sebastian Nagel]

Ergänzung: ein ganz ähnlicher Fall sind ja die ganzen diakritischen Zeichen.

Sinnvoll wäre, den ganzen Ballast der vorgefertigten Zeichen rauszuwerfen, und nur noch mit combining marks zu arbeiten. Aber dann würde halt die Mehrheit der Programme dumm aussehen - und die Schrift obendrein, weil nicht kompatibel mit der Realität.

[Mach]

Bloß was ich absolut nicht verstehe ist, warum dann auch noch eine liga-Tabelle angelegt werden muss. Gibt’s dafür irgendeinen technischen Grund?

Der Grund könnte sein, dass auf diese Art und Weise für den normalen und den kursiven Schnitte genau dieselben OpenType-Definitionen verwendet werden können. Tatsächlich verwenden beide Schnitte identische GSUB-Definitionen, und zwar eine grosse Menge – die Feature-Datei, die ich mit FontForge aus den Schriftarten exportiert habe, enthält 3548 Zeilen GSUB-Definitionen. Bei einem derart umfangreichen Code ist es wohl ein Vorteil, dass er ohne Änderung in den verschiedenen Schnitten verwendet wird.

[Sebastian Nagel]

Bloß was ich absolut nicht verstehe ist, warum dann auch noch eine liga-Tabelle angelegt werden muss. Gibt’s dafür irgendeinen technischen Grund?

Der Grund könnte sein, dass auf diese Art und Weise für den normalen und den kursiven Schnitte genau dieselben OpenType-Definitionen verwendet werden können. Tatsächlich verwenden beide Schnitte identische GSUB-Definitionen, und zwar eine grosse Menge – die Feature-Datei, die ich mit FontForge aus den Schriftarten exportiert habe, enthält 3548 Zeilen GSUB-Definitionen. Bei einem derart umfangreichen Code ist es wohl ein Vorteil, dass er ohne Änderung in den verschiedenen Schnitten verwendet wird.

Stimmt, das könnte ein weiterer Grund sein.

Wobei das ganze ziemlich "verkrampft" werden kann – Kursive und Aufrechte haben doch teils unterschiedliche "Bedürfnisse" was Ersetzungen angeht.

[Þorsten]

Bloß was ich absolut nicht verstehe ist, warum dann auch noch eine liga-Tabelle angelegt werden muss. Gibt’s dafür irgendeinen technischen Grund?

Der Grund könnte sein, dass auf diese Art und Weise für den normalen und den kursiven Schnitte genau dieselben OpenType-Definitionen verwendet werden können.

Gut, das kann ich mir vorstellen. Sind wir uns einig, dass es praktischer sein kann, das einfach zu übernehmen, es aber keine technischen Gründen gibt, liga-Einträge zu haben, wenn die Glyphen sich nicht unterscheiden?

[Þorsten]

Ein unlösbares Dilemma, man schleppt entweder die alte Methode bis in alle Ewigkeiten mit, oder wird sofort inkompatibel – wenn man nicht einfach zwei Glyphen anlegt, eine "alte" ff-Ligatur, und eine "neue" f_f-Ligatur, die sich optisch gleich verhalten, aber technisch nicht.

Schon klar.

So gibt man Opentype-fähigen, Glyphennamen-fähigen Programmen die offizielle Methode, alle Ligatur-Glyphen gleich zu generieren (im liga-Feature wird das f_f ohne Code verwendet) und später auch zu exportieren (sonst hat unter ungünstigen Umständen das ff im PDF einen Codepoint, währen f_j keinen hat - womit wir wieder bei durchsuchbarem Text etc. wären).

Auch klar. Die Frage, die mir bleibt, ist nur, ob es Programme gibt, die Glyphennamen-fähig aber nicht Opentype-fähig sind, die also z.B. ohne zu kucken, ob liga-Tabellen existieren, eigenständig zwei aufeinander folgende fs durch den Glyphen »f_f« ersetzen (ob er nun vorhanden ist oder nicht).

[Ralf Herrmann]

Nein, die Unicode-losen Glyphen sind speziell zur Verwendung in OpenType-Features gemacht; die mit Unicode zur Ansprache über selbigen.

[Mach]

Sind wir uns einig, dass es praktischer sein kann, das einfach zu übernehmen, es aber keine technischen Gründen gibt, liga-Einträge zu haben, wenn die Glyphen sich nicht unterscheiden?

Ich stimme zu: Ich sehe keinen Grund für eine derartige Ligatur-Definition – es sei denn, bei weiteren OpenType-Operationen wäre die Ligatur-Glyphe vorausgesetzt. Ich habe nicht geprüft, ob das zutrifft, aber ich halte es eher für unwahrscheinlich. Übrigens sehe ich genausowenig einen Grund, warum der Font sowohl eine Glyphe ‹???› (U+FB00, LATIN SMALL LIGATURE FF) als auch eine identische Glyphe «f_f» (ohne Unicode-Nummer) enthalten sollte – die OpenType-Operationen liessen sich alle auch mit ‹???› durchführen.

[Ralf Herrmann]

Das hat Sebastian schon überzeugend erklärt.

[Mach]

Klar, er hat Symmetrieüberlegungen genannt. Das sind aber wiederum keine harten «technischen Gründe», wie Þorsten sie genannt hat.

PS: Abermaliges Durchlesen: Pardon, ich hatte es nicht richtig erfasst. Sebastian hatte hingewiesen auf die Möglichkeit, dass ein OpenType-fähiges Programm etwa in einem PDF die Unicode-Charakterfolge ‹f›+‹f› ersetzen würde durch den Unicode-Ligaturcharakter ‹?›, was dann zu Durchsuchbarkeitsproblemen führen könnte. Diese Probleme liessen sich vermeiden, indem man in OpenType eine Glyphe «f_f» verwendet, der keine Unicode-Numer zugeordnet ist, statt dem Unicode-Ligaturcharakter ‹?›. Ich denke, jetzt habe endlich auch ich es verstanden.

[Sebastian Nagel]

Genau, das ist das theoretische(?) Problem. Ob es in der Praxis tatsächlich irgendwo auftritt, kann ich nicht sagen, aber mit der Doppelung der Glyphen (in Unicode-ff und Glyphen-f_f) kommt man mittelfristig aus diesem Dilemma heraus, ohne die Kompatiblität gleich aufzugeben.

Es ist also vermutlich einfach umsichtiges und voraussehendes Vorgehen, was die Gentium-Entwickler hier machen.

[Þorsten]

Nein, die Unicode-losen Glyphen sind speziell zur Verwendung in OpenType-Features gemacht; die mit Unicode zur Ansprache über selbigen.

Das hatte ich auch angenommen, danke für die Bestätigung.

Im Umkehrschluss bedeutet das dann wohl, dass es für die Anwender nicht sinnvoll ist, unicodelose Ligatur-Glyphen wie eben f_f direkt anzusprechen (auch wenn das technisch vielleicht möglich ist, z.B. in XeTeX). Und das sollte wiederum bedeuten, dass es keinen technischen/kmopatibilitätsbedingten Grund gibt, warum Schriftgestalter diese Glyphen in ligaturlosen Schriften anlegen sollten. (Wir können also nur vermuten, warum das in Gentium Plus Regular gemacht wurde.)

(Dass man die historisch entstandenen Unicodepositionen von ff, fi etc. nicht einfach leer lassen sollte, wenn man um 100%ige Kompatibilität bemüht ist, steht ja auf einem anderen Blatt.)

Widerspruch?