Kniffliges Problem mit arabischem Webfont

[StefanD]

Vielleicht kann mir jemand mit einem Tipp bei folgendem Problem weiterhelfen:

Situation: auf einer Website soll per @font-face ein im Haus produzierter Opentype TT-Font für arabische Texte eingesetzt werden. Im aktuellen Firefox (Win) wird der Font zwar eingebunden und dargestellt, allerdings werden die Glyphen jeweils nur in ihrer isolierten Variante dargestellt. Beim Arabischen kommen ja allerdings verschiedene Varianten je nach Kontext (Wortanfang, -mitte, -ende usw.) zum Einsatz - vereinfacht gesagt ist also die Ligatur der Normalfall. Die Schrift wurde (nicht von mir) im High Logic Font Creator erstellt, die Opentype-Features wurden dann mit VOLT hinzugefügt. Im HTML-Dokument ist das charset auf utf-8 gesetzt und die Sprache auf "ar".

Viusalisierung des Problems:

Falsch:

Korrekt:

Beobachtungen:

• Ist der Font normal installiert, werden die arabischen Texte korrekt* anzeigt.
  
• Im aktuellen Opera als auch im Firefox 3.5 (portable) wird der Font korrekt angezeigt.
  
• Im Google Chrome wird der Font gar nicht angezeigt, sondern durch die arabische Standardschrift ersetzt
  
• Im Fontlab erscheinen mir die OpenType-Features der Schrift leer zu sein:
  
  
• Test anderer Schriftarten: ScheherazadeRegOT.ttf und DroidNaskh-Regular.ttf funktionieren anstandslos, Arial Unicode MS hat dagegen (wenn nicht installiert, sondern per @font-face verlinkt) auch dieselben Probleme.
  

Meine Vermutung:

Da der Text im FF 3.5 bzw. bei installierter Schrift korrekt dargestellt wird, vermute ich, dass es irgendwie mit den Opentype-Features und deren Zusammenspiel mit Harfbuzz zu tun hat. Oder hat jemand eine andere Idee?

Im Besonderen hätte ich auch noch folgende konkrete Fragen:

• Wie genau verhält sich Harfbuzz? Steuert das nur die Umsetzung der Opentype-Features von Schriften, die über @font-face eingebunden sind? Oder auch die der installierten Schriften? Gibts dazu irgendwo Infos im Web?
  
• Wo sieht man sich am besten den Code der Opentype-Features an? (Ich habe dazu bisher Fontlab genutzt)
  
• Können Opentype-Features so geschrieben sein, dass sie in der einen Applikation funktionieren und in der anderen nicht?
  
• Gibt es andere Mechanismen in einer Opentype TT-Datei, die dafür sorgen, dass Ersetzungen vorgenommen werden - außer den Opentype-Features?
  

Ich weiß, ein sehr kniffliges Problem, bin aber für jede Antwort, jeden kleinen Tipp oder neuen Ansatzpunkt sehr dankbar!

_____________________________________________________

*korrekt heißt hier immer: in der richtigen Schriftart mit den richtigen Ersetzungen und Positionen der Glyphen.

[Ralf Herrmann]

OpenType-Features werden aktuell nur extrem unzureichend von Browsern unterstützt. Da hast du also ein sehr generelles Problem, dass sich auch kurzfristig nicht wirklich umgehen lässt.

Hier ein paar Infos, wie man die OT-Features im Browser aktivieren kann, aber wie gesagt: das ist eher experimentell und alles andere als Browser-übergreifend nutzbar …

http://blog.fontdeck.com/post/15777165734/opentype-1

[StefanD]

Danke schonmal für den Hinweis, das werde ich gleich mal lesen.

Der Punkt ist ja aber der, dass es arabische Fonts (siehe oben) gibt, die sich über @font-face einbinden lassen und korrekt funktionieren. Also prinzipiell scheint das zu gehen. Hab jetzt sehr viel zu OpenType gelesen und da drauf geschaut. Wie siehts denn aber generell bei TTFs aus: gibts da noch andere Möglichkeiten, Informationen zur kontextsensivitiven Erstetzung von Glyphen abzulegen? Oder geht sowas im Hinblick auf TTF ausschließlich mit OpenType-Features?

[Ralf Herrmann]

Ich bin kein Experte für Arabisch und kann auch nichts davon lesen, aber ich habe es immer eher so verstanden, dass z.B. Systemschriften einfach so gestaltet sind (bzw. waren), dass sie auf das Nichtvorhandensein von OpenType-Ersetzungen ausgelegt sind und also schon so entworfen sind, dass sie sich auch ohne OpenType einigermaßen verbinden und dann nicht überall die ausgeprägten unverbundenen Einzelformen »rumstehen«.

Das klassische TrueType-Format bietet überhaupt keine Smartfont-Technologien – genau deshalb verfügten ja auch Systemfonts lange Zeit über keine entsprechenden Automatismen.

Plattform-übergreifend möglich wurde das erst durch OpenType (ttf/otf) und über die entsprechenden OT-Features. Wie aber bereits gesagt, wirst du die aktuell nicht für alle Webseiten-Besucher zufriedenstellend anzeigen lassen können. Das geht aktuell einfach nicht.

[Mach]

Wie genau verhält sich Harfbuzz? Steuert das nur die Umsetzung der Opentype-Features von Schriften, die über @font-face eingebunden sind? Oder auch die der installierten Schriften? Gibts dazu irgendwo Infos im Web?

Harfbuzz steuert, denke ich, beides. Im Übrigen ist Firefox dank Harfbuzz eines der zuverlässigsten Programme bei der Umsetzung von OpenType-Features.

Wo sieht man sich am besten den Code der Opentype-Features an? (Ich habe dazu bisher Fontlab genutzt)

Ich verwende dazu FontForge. Ich vermute aber, dass Fontlab wohl über ähnliche Fähigkeiten verfügt.

Können Opentype-Features so geschrieben sein, dass sie in der einen Applikation funktionieren und in der anderen nicht?

Es ist eher umgekehrt: Applikationen können so geschrieben sein, dass OpenType-Features funktionieren oder nicht!

Gibt es andere Mechanismen in einer Opentype TT-Datei, die dafür sorgen, dass Ersetzungen vorgenommen werden - außer den Opentype-Features?

Ja. Die intelligente Schriftdarstellung in OpenType-Schriftarten kann etwa auch über Apple Advanced Typography (AAT) funktionieren oder über SIL Graphite. Ich denke, der Hintergrund ist der, dass OpenType-Fonts modular gebaut sind und praktisch beliebige zusätzliche Tabellen enthalten können. Ein Programm wird jedoch nur diejenigen zusätzlichen Tabellen auch korrekt interpretieren können, die es tatsächlich kennt. Deshalb funktioniert SIL Graphite nur auf wenigen Programmen (z.B. LibreOffice und XeTeX) oder AAT nur auf Mac.

Mit dem Einsatz von Harfbuzz ist Firefox zwar einerseits viel mächtiger geworden, was die korrekte Umsetzung von OpenType-Features angeht. Andererseits bringt Harfbuzz aber auch mit sich, dass nur noch bestimmte, zum Voraus zugelassenen OpenType-Tabellen interpretiert werden. Die übrigen Tabellen werden ignoriert, was der Sicherheit des Browsers dient. Dies bedeutet beispielsweise, dass Firefox ≥ 3.6 auf Mac OS X im Gegensatz zu früheren Versionen kein AAT mehr interpretiert, weil AAT in nicht zugelassenen Tabellen definiert ist (morx oder so was).

Ohne die Schriftart gesehen zu haben, würde ich also mutmassen, dass das VOLT-Instrument keine richtigen OpenType-Features anlegt – daher die leeren OpenType-Features –, sondern irgendwelche andere Features in speziellen Microsoft-Tabellen. Bis zu Version 3.5 interpretiert Firefox diese Tabellen und stellt die arabischen Zeichen richtig dar (unter Windows), während ab Version 3.6 Harfbuzz diese Tabellen nicht mehr zulässt, so dass die Darstellung auch nicht mehr funktioniert.

PS: Nochmal zur Unterscheidung: Einerseits OpenType-Schriftart (Dateiendung OTF oder TTF) – andererseits OpenType-Features, eine von verschiedenen Technologie zur Darstellung von Schriftintelligenz (etwa neben AAT oder Graphite), die in einer OpenType-Schriftart enthalten sein können.

[Jens Kutilek]

Der Punkt ist ja aber der, dass es arabische Fonts (siehe oben) gibt, die sich über @font-face einbinden lassen und korrekt funktionieren.

Dann müßtest Du mal die funktionierenden Fonts analysieren. Aber mit FontLab geht das nicht, wie Du schon richtig bemerkt hast, weil es die Features nicht interpretieren kann. ttx aus den FontTools oder DTL OTMaster könnte helfen.

[StefanD]

Vielen Dank für die ausführlichen Rückmeldungen! Insbesondere der Tip von Jens, DTL OTMaster zu verwenden, war sehr nützlich, damit sehe ich nämlich endlich mal die Opentype-Features im von uns erstellten Font und somit auch die Unterschiede z.B. zu ScheherazadeRegOT.ttf.

So ist die Ersetzung des ersten Buchstabes am Wortanfang der Zeile bei uns nämlich so abgelegt (laut "Text Dump" in OTMaster):

(im AlternateSubstitutionTable)

Subsitute GlyphID 443 <uni0628> by one of these 1 IDs: 652 <uniFE91>[/CODE]

In der ScheherazadeRegOT.ttf dagegen:

(im SingleSubstitutionTable)

[CODE]# 10: sub GID 321 <uni0628> by GID 785 <uni0628.init>[/CODE]

Vielleicht ist das ja eine Spur. Beide sind jedoch jeweils mit dem OT-Feature "init" korrekt verknüpft. Sagt mir jedenfalls der GPOS/GSUB-Table Viewer.

Im Moment verdächtige ich auch wie Mach das VOLT von Microsoft, allerdings ist ja auch die OT-Spezifikation ursprünglich von Microsoft (und Adobe). Daher bin ich mir nicht ganz sicher, ob das Programm tatsächlich irgendwelche OT-Tables fehlerhaft im Sinne der Spezifikation erstellt. Im einem Blog wird das Programm sogar ausdrücklich für die Erstellung von arabischen Fonts empfohlen (neben Fontlab) [1]. Vielleicht liegts auch eher an Harfbuzz. Ein Vergleich der OT-Spezifikation mit Harfbuzz hilft hier aber vielleicht weiter.

Werde die Spur mal nächste Woche weiterverfolgen.

_________________________________

[1] http://29letters.wordpress.com/2007/05/15/generating-arabic-fonts/

[Mach]

Ich halte es für unwahrscheinlich, dass Harfbuzz Probleme mit arabischen Schriften haben sollte. Immerhin ist Behdad Esfahbod selbst Iraner und empfiehlt IranNastaliq, eine Schriftart in Nastaʿlīq, eine besonders kursive Variante der ja ohnehin schon ausgesprochen kursiven arabischen Schrift, die in Firefox auch tadellos dargestellt wird.

Korrektur zu meinem vorigen Post: Es ist nicht Harfbuzz, das die nicht unterstützten OpenType-Tabellen eliminiert, sondern der OTS (OpenType Sanitiser), vgl. Mozilla Foundation Security Advisory 2010-78.

[StefanD]

@Mach: Danke für den Tip mit dem Opentype Sanitizer (OTS)! In der Tat verhindert nämlich der OTS, dass unser Font komplett und korrekt heruntergeladen wird. Da man den OTS mit gfx.downloadable_fonts.sanitize in about:config ausschalten kann, war das gut testen. Es erklärt auch, warum der Font auch nicht in Google Chrome funktioniert - der OTS ist nämlich eigentlich ein Chromiumprojekt und wird dort ebenfalls eingesetzt. Nur verhindert Google Chrome anscheinend den gesamten Download (deshalb dann das Erscheinen der Systemschrift), während FF die validen Teile anscheinend durchlässt und weiterverwendet. Jetzt muss ich nur noch rausfinden, was genau an den Opentypefeatures nicht korrekt ist ...

[Mach]

Da man den OTS mit gfx.downloadable_fonts.sanitize in about:config ausschalten kann, war das gut testen.

Das habe wiederum ich nicht gewusst – ein sehr hilfreicher Tipp, vielen Dank!

[Ralf Herrmann]

Wenn man die Fonts lokal testet, springt der OTS übrigens auch nicht an.

[StefanD]

Wenn man die Fonts lokal testet, springt der OTS übrigens auch nicht an.

Also bei mir im Firefox auf Win mit der arabischen Schrift tut er das zumindest. Vielleicht behandelt er aber lokale vorhandene (jedoch nicht installierte) Schriften nochmals differenzierter? D.h. das dann bestimmte Tabellen(-teile) doch erlaubt sind. Merkwürdig...