'mkmk' mit Fontforge zum Laufen bekommen?

[[Mitglied carb…]]

Hallo,

das hier ist mein erster Beitrag in diesem Forum. Wie aus dem Threadtitel hervorgeht, habe ich eine Frage zum Thema kombinierende Diakritika und ihre Umsetzung mit Fontforge. Ich habe schon ein bisschen im Internet gesucht, aber bin bisher nicht fündig geworden.

Auf die Gefahr hin, dass ich ausgelacht werde... Ich habe vor einigen Jahren ein Schriftsystem erfunden, das einige Anleihen an indischen Schriften nimmt, d.h., es ist ein Abugida. Nur, dass Vokale nicht nur als Diakritika über, sondern auch unter Zeichen auftauchen können. Das ganze wird auf dieser Seite dokumentiert und ist hoffentlich so verständlich. Die ganzen "nativen" Bezeichnungen für die Diakritika einfach ignorieren, das soll bloß dem Lokalkolorit dienen. Trotz des ganzen Fantas(ie|y)-Gedöns, was da dranhängt, ist meine Frage grundsätzlich: Wie bekomme ich es hin, dass Programme, die OpenType unterstützen, meine Definitionen für 'mark' und 'mkmk' erkennen, und wie setze ich das mit Fontforge um?

Nun bin ich schon seit einiger Zeit immer wieder am Herumprobieren, wie ich dieses System am besten in den Computer bekomme. Ich habe vor einiger Zeit einen Font gebastelt (nicht besonders schön, mehr Proof-of-Concept), der bisher allerdings nur die ganzen Zeichen ansich, nicht aber Kombinationsregeln usw. enthält, also im Grunde nutzlos ist. Nachdem einige Experimente mit der Private Use Area nicht funktioniert haben und Experimente mit Graphite zwar soweit einigermaßen erfolgreich waren, mich das System aber aufgrund seiner mangelnden Unterstützung frustriert hat, bin ich vor kurzem auf die Idee gekommen, dass ich ja die ganzen Konsonantenbuchstaben in den Latin-Bereich packen könnte und die ganzen Diakritika in den Combining-Diacritics-Bereich. Bei Charis/Doulos SIL und der Dokumentation zu Fontforge habe ich mir dann abgeschaut, wie das mit Ankern funktioniert. Für das 'mark'-Feature geht das soweit auch wunderbar (außer in OpenOffice, wahrscheinlich weil hier keine oder nur wenige grundsätzliche OpenType-Features unterstützt werden): Einzelne Vokalzeichen können ohne Probleme genau da über Konsonanten platziert werden, wo ich sie haben will. Nun ist allerdings die Sache die, dass Diakritika auch gestapelt werden können sollen, wozu ja scheinbar das 'mkmk'-Feature zuständig ist, mit dem ein Diakritikum an ein anderes gebunden werden kann. Innerhalb von Fontforge scheint das auch kein Problem zu sein:

(Silbe <tīe> in Fontforge. <i> oben ("gravecomb"), der Tüddel unter dem Konsonant ("uni0339") ist das Längenzeichen, der Haken darunter ("uni0321") das <e>.)

Wenn ich mir das ganze dann allerdings in Fontmatrix, Inkscape oder sogar InDesign CS3 angucke, sieht es so aus:

Es scheint, als ob der 'mkmk'-Anker nicht erkannt oder umgesetzt wird, aber ich weiß nicht, woran das liegt und hatte daher gehofft, dass mir hier vielleicht weitergeholfen werden kann. Bei Doulos und Charis funktioniert es ja schließlich auch, sogar in OpenOffice, wobei das evtl. daran liegen könnte, dass hier Graphite zusätzlich eingebaut ist, das ja von OpenOffice als eine der wenigen Programme unterstützt wird. Von daher bin ich etwas ratlos.

Falls sich jemand die Schrift genauer ansehen möchte:

• Fontforge-Projektdatei
  
• TTF-Datei daraus
  

Viele Grüße

carbeck

bearbeitet August 6, 2011 von carbeck

[[Mitglied Josh…]]

OpenOffice unterstützt meines Wissens kein OpenType, da brauchst Du also gar nicht testen. Versuche es mal in Wordpad (Windows).

Prüfe auch, welche Sprachen in der mkmk-Funktion eingetragen sind, und stelle dann eine entsprechende Sprache in InDesign ein.

[[Mitglied carb…]]

OpenOffice unterstützt meines Wissens kein OpenType, da brauchst Du also gar nicht testen. Versuche es mal in Wordpad (Windows).

Ja, das mit OpenOffice und OpenType weiß ich (und ärgert mich). Das Längenzeichen, bei dem der Anker in einem anderen mark-Lookup als die unteren Vokalzeichen definiert ist, wird in Wordpad nicht richtig platziert, und mkmk funktioniert auch nicht. Das Problem ist ja im Prinzip ein grundsätzliches und bei den beiden Fonts, von denen ich abgeguckt habe, sind auch unterschiedliche Klassen von kombinierenden Diakritika in unterschiedlichen Lookups, deswegen war ich davon ausgegangen, dass das kein Problem sein sollte.

Prüfe auch, welche Sprachen in der mkmk-Funktion eingetragen sind, und stelle dann eine entsprechende Sprache in InDesign ein.

Da habe ich glaub ich einfach die Werte aus Doulos SIL übernommen, DFLT{dflt} latn{IPPH,ROM ,VIT ,dflt}. Für mark ist es bloß DFLT{dflt} latn{dflt}. In InDesign scheint es egal zu sein, welche Sprache ich einstelle. Mkmk wird ignoriert, wie oben geschrieben. Genauso auch z. B. Firefox 5 (seit FF4 sollte ja OpenType soweit funktionieren).

[[Mitglied Geor…]]

Hallo!

Ich hab mir das ein bisschen angeschaut. Interessantes Projekt! Ich spiele mich auch gern mit Schriftsystemen und hab auch ein paar Entwürfe herumliegen, bin aber bis jetzt noch nie soweit gekommen, das auch zu digitalisieren.

Dein Problem mit kombinierenden Diakritika konnte ich so lösen, indem ich eine Kopie von uni0321 (uni0321.comb) angelegt habe und in dieser Kopie nur den mkmk-mark-Anker belassen, den mark-Anker aber gelöscht habe und dann mit dem ccmp-Feature folgende Ersetzung eingeführt hab:

lookup CCMP {
    sub uni0339 uni0321' by uni0321.comb;
} CCMP;

feature ccmp {
    lookup CCMP;
} ccmp;
[/CODE]

Mit XeLaTeX bekomme ich dann die gewünschte Ausgabe

3290

Das .tex-Dokument dazu sieht so aus:

[CODE]\documentclass{article}
\usepackage{fontspec}
\begin{document}
\fontsize{50}{50}\fontspec{Tahano Hikamu Java Sans}b\char"0300\char"0339\char"0321 \\
\end{document}[/CODE]

Die Wahl von Latein als Basisschriftsystem könnte aber problematisch werden, wenn es um die Glyphenposition von uni02b0 geht. Für das Umsortieren muss wohl fast was südostasiatisches herhalten. Was Firefox angeht, hab ich es leider jetzt nicht geschafft, dass es korrekt angezeigt wird. Die Fontdatei, die ich erstellt habe, findest du unter www.georgduffner.at/thjs.ttf

thjsr.pdf

[[Mitglied carb…]]

Ah, vielen Dank! Dann werd ich mir das mal dahingehend angucken, ob das so vielleicht besser funktioniert (warum auch immer).

Mit der aktuellen Version der Schrift in meiner Dropbox, allerdings ohne Deine Änderungen, hab ich's auch irgendwie geschafft, dass InDesign die mkmk-Platzierung erkennt. Ich habe die mark-Subtables einfach statt in mehrere Gruppen alle in eine gesteckt. Außerdem habe ich für Windows eingestellt, dass Westlich und Vietnamesisch als Encodings vorhanden sein sollten. Vietnamesisch, dachte ich, wäre vielleicht nicht falsch, wegen der vielen gestapelten Akzente. Für die Lookups ist weiterhin latn{dflt} definiert. Was davon allerdings wirklich notwendig ist, weiß ich nicht. In anderen Programmen (WordPad, Notepad, Fontmatrix, Firefox, Inkscape) funktioniert es mit diesen Änderungen weiterhin leider nicht, wie es mit ccmp aussieht, habe ich noch nicht ausprobiert.

bearbeitet August 8, 2011 von carbeck

[[Mitglied Geor…]]

Ah, vielen Dank! Dann werd ich mir das mal dahingehend angucken, ob das so vielleicht besser funktioniert (warum auch immer).

Ich hab da mit meiner Garamond einiges herumgespielt und scheinbar haben die mark-Anker Vorrang vor den mkmk-Ankern – dh, wenn ein Diakritikum mit mark-Anker auf ein Basiszeichen mit solchem trifft, wird es daran ausgerichtet, egal ob da auch noch ein mkmk-Anker vorhanden wäre. Wenn ich das jetzt schreibe kommt mir gerade der Gedanke, dass man vielleicht einfach die Reihenfolge der Lookups umdrehen könnte, dann wäre das vielleicht auch kein Problem mehr. Ich werd mir das nachher mal ansehen.

Mit der aktuellen Version der Schrift in meiner Dropbox, allerdings ohne Deine Änderungen, hab ich's auch irgendwie geschafft, dass InDesign die mkmk-Platzierung erkennt. Ich habe die mark-Subtables einfach statt in mehrere Gruppen alle in eine gesteckt. Außerdem habe ich für Windows eingestellt, dass Westlich und Vietnamesisch als Encodings vorhanden sein sollten. Vietnamesisch, dachte ich, wäre vielleicht nicht falsch, wegen der vielen gestapelten Akzente. Für die Lookups ist weiterhin latn{dflt} definiert. Was davon allerdings wirklich notwendig ist, weiß ich nicht. In anderen Programmen (WordPad, Notepad, Fontmatrix, Firefox, Inkscape) funktioniert es mit diesen Änderungen weiterhin leider nicht, wie es mit ccmp aussieht, habe ich noch nicht ausprobiert.

Das Vietnamesisch brauchst du nicht, du brauchst eigentlich gar keine Sprache definieren (außer den defaults). Sowohl mkmk als auch mark sollten laut Spezifikation immer an sein. Und wenn du in den Lookups Vietnamesisch nicht explizit mit aufführst, werden diese dafür nicht verwendet!

EDIT:

Bingo! In der GPOS-Tabelle einfach die mkmk-Lookups vor die mark-Lookups reihen, dann funktioniert es genauso.

Was ich mich allerdings frage: warum codierst du die Zeichen nicht nach der Transkription? Das würde eine ganze Menge vereinfachen.

bearbeitet August 8, 2011 von Georg Duffner

[[Mitglied carb…]]

Das Vietnamesisch brauchst du nicht, du brauchst eigentlich gar keine Sprache definieren (außer den defaults).

Ah, OK.

Bingo! In der GPOS-Tabelle einfach die mkmk-Lookups vor die mark-Lookups reihen, dann funktioniert es genauso.

Das hatte ich vorher schon probiert, aber irgendwie hat es zumindest bei mir dann immer noch nicht in den Programmen funktioniert, mit denen ich das getestet habe. Kann vielleicht auch daran liegen, dass ich hier noch ein altes Windows XP SP3 in einer VM habe, in der mit Sicherheit keine allzu aktuelle uniscribe.dll installiert ist. Auf Linux funktoniert es aber genauso wenig (ich glaube, Gnome benutzt Pango?).

Was ich mich allerdings frage: warum codierst du die Zeichen nicht nach der Transkription? Das würde eine ganze Menge vereinfachen.

Das stimmt. Ich hab mich allerings an die ptkbdg..-Reihenfolge gewöhnt. Heißt ja nicht, dass sich das nicht umbauen lässt.

EDIT: Fontmatrix 0.6.99 kann scheinbar mit mkmk auch nicht richtig umgehen. Bei anderen, sonst funktionierenden Fonts, werden zwar vielleicht die Akzente verschoben, aber trotz allem falsch positioniert.

bearbeitet August 8, 2011 von carbeck

[[Mitglied Geor…]]

Ich hab jetzt noch mehr herumgespielt. Für Firefox scheint es problematisch zu sein, dass die Vokalzeichen als Diakritika definiert sind (cave: alles was ich sage beruht auf Schlussfolgerungen aus Beobachtungen!). Um mir das Spielen zu erleichtern (ich bin faul) hab ich kurzerhand die drei Diakritika auf leere Großbuchstabenslots gelegt und siehe da, es funktioniert. Allerdings braucht Firefox scheinbar die ccmp-Ersetzung, sonst geht’s nicht.

Meine Testseite: http://www.georgduffner.at/thjsr-test.html

[[Mitglied carb…]]

Allerdings braucht Firefox scheinbar die ccmp-Ersetzung, sonst geht’s nicht.

Hmm... Dann werd ich mir das mit ccmp mal angucken. Ist zwar vom Ansatz her nicht ganz so elegant, aber wahrscheinlich immer noch machbar. Solange ich nicht alle Zeichen vorkombinieren muss, wie im Koreanisch-Block in Unicode... Danke für Deine Hilfe, jedenfalls!

[[Mitglied Geor…]]

Hmm... Dann werd ich mir das mit ccmp mal angucken. Ist zwar vom Ansatz her nicht ganz so elegant, aber wahrscheinlich immer noch machbar. Solange ich nicht alle Zeichen vorkombinieren muss, wie im Koreanisch-Block in Unicode... Danke für Deine Hilfe, jedenfalls!

Bitte gern geschehen, ich spiel ja auch gern mit Sprache und Schrift :)

Alles wirst du so sicher nicht vorkombinieren müssen, aber ohne Shaper für dein Schriftsystem wird dir wohl mancher Umweg nicht erspart bleiben. Die pre-base Diakritika wirst du wohl als Ligaturersetzung Vorkombinieren müssen.

[[Mitglied carb…]]

Versteh ich das mit dem ccmp richtig, dass da einfach die Vokaldiakritikum-Glyphe mit beiden Arten von Ankern mit einer Kopie ersetzt wird, die nur einen mkmk-Mark-Anker hat, wenn sie auf ein unten rechts am Konsonanten andockendes Diakritikum (wie das Längenzeichen) folgt? Die jeweilige Zuordnung für die Ersetzung ist dann in der "Single Substitution Lookup"-Subtable? Und seh ich das richtig, dass Fontforge ccmp als Feature für "Contextual Chaining Substitutions" laut Menüauswahl gar nicht vorsieht?!

bearbeitet August 10, 2011 von carbeck

[[Mitglied Geor…]]

Ja, du siehst das richtig.

Fontforge folgt bei der Menüauswahl dem, was MS als »Recommended Implementation« angibt. Diese Empfehlungen stammen laut Thomas Phinney und John Hudson aus den Anfangszeiten von Opentype und sind nicht als exklusive Empfehlungen zu verstehen. Du kannst aber die Menüauswahl bleiben lassen und Featuretags direkt eintippen. Ich umgehe das ganze, indem ich die Features in einer Textdatei schreibe und diese dann von Fontforge einbinden lasse (Datei>Merge Feature Info). Ich finde das deutlich übersichtlicher, außerdem habe ich Fontforge schon öfter mit den Lookupmenüs zum Absturz gebracht.

Das Featurefile mit dem ich auch den steigenden Diphthong (zumindest unter Firefox) zum Laufen gebracht habe, sieht so aus:

languagesystem DFLT dflt;         # Deklaration der Schriftsysteme und Sprachen
languagesystem latn dflt;

lookup CCMP {                     # Lookup für die Ersetzung von /e/ durch ein Zeichen, das nur
    sub [H uni0339] [F uni0321]' by [E uni0321.comb];        # mkmk Anker enthält*
} CCMP;

lookup CCMP_POS {                 # Lookup, das Position und Laufweite der Basiszeichen vor einem
    pos [ a-z braceleft ]' < 320 0 320 0 > slash ;           # steigenden Diphthong ändert
} CCMP_POS;

feature ccmp {                    # Einbinden der Lookups in ein Feature
    lookup CCMP;
    lookup CCMP_POS;
} ccmp;[/CODE]

* Die Ersetzung von F durch E ist so natürlich keine saubere Sache, ich hab das für Testzwecke so gemacht. Eine Ersetzung durch kodierte Glyphen sollte vermieden werden, also korrekterweise wäre statt E ein unkodiertes F.comb angebracht.

Zum Präfix: das ist ein kontextuelles GPOS Lookup, graphisch findest du es dort, wo du auch die mark und mkmk Lookups findest (bei mir stürzt FF aber leider immer ab, wenn ich da hinein will). Die Werte <320 0 320 0> sind für links, oben, rechts und unten. Der Wert für links verschiebt das Zeichen innerhalb seiner Box nach rechts, somit ist davor Platz für das Diakritikon. Der Wert für rechts erweitert die Box des Zeichens um diesen Wert, somit ragt das Zeichen nicht in das folgende.

Die Syntax für die Featurefiles findest du hier: http://www.adobe.com/devnet/opentype/afdko/topic_feature_file_syntax.html

Die negative Position der Präfixe ist übrigens nicht unbedingt nötig, da sie sowieso per mark platziert werden. Ich hab auch deinen aktuellen Blogpost gelesen. #2 der Lösungen kann nicht funktionieren, weil es in Fonts keine Zeichen mit negativer Breite gibt. Was du links des Ursprungs positionierst, ragt immer in das vorhergehende Zeichen hinein, und du kannst auch den rechten Seitenrand (der die Laufweite definiert) nicht über den Ursprung hinaus ziehen. Dass das in manchem Programm funktioniert (hat) liegt eher an einer fehlerhaften Implementierung.