Rumänisches Akzentproblem

[[Mitglied Bern…]]

Hallo Typedesigner und Schriftexperten,

ich bin gerade dabei, eine Schrift auszubauen und bin bei den rumänischen Glyphen auf ein Problem gestoßen.

Sehr oft variieren in der rumänischen Sprache die Akzente unter dem »S« und dem »T« ... manchmal besitzen diese Glyphen ein Cedille und manchmal ein Kommaakzent (unten).

Laut dieser Seite ist die Komma-Variante die richtige. Also so:

Șș Țț

... und dies sind die (zumindest für die rumänische Sprache) falschen Zeichen:

Şş Ţţ

Warum wird das so oft falsch gemacht?

Kann ich mich auf diese Seite verlassen und ruhigen Gewissens die Kommavariante verwenden? Oder hat die Seite Unrecht und beides ist richtig? (z.B. durch locale Unterschiede – bei typeit werden ja auch beide Varianten angeboten)

Ich hoffe, ihr könnt mir weiterhelfen!

[[Mitglied Seba…]]

Das Scomma (etc.) war bis zu Unicode 3.0 nicht als eigenes Zeichen registriert. Wer es tippen wollte, hatte ein ganz praktisches Problem: es war in praktisch keinem Font enthalten, außer vielleicht in Spezialitäten-Varianten für Rumänien, und dort an einem "falschen" Platz, meist eben auf dem Scedilla.

Lösungen waren entweder, ein "S" zu tippen, oder ein Scedilla, oder sich das Scomma aus S und Comma-Accent zusammenzusetzen (in Textvarbeitungen unpraktikabel). Scedilla hat sich wohl als praktischste und am "wenigsten falsche" Variante durchgesetzt.

Wenn du heute einen Font baust, gibt es zwei Möglichkeiten:

- Willst du auch zu alten Unicode-Standards kompatibel sein, und hast Opentype zur Verfügung, kannst du die Scomma-Variante ohne Unicode-Wert als Glyphe anlegen (oder mit Codepoint - siehe unten), und über das locl-Feature für die Sprache Rumänisch eine Ersetzung Scedilla > Scomma anlegen. Indesign & Freunde ersetzen dann Scedilla durch Scomma, wenn du die Sprache auf Rumänisch stellst.

- Inzwischen ist das Zeichen standardisiert und liegt in der Latin Extended B-Range (Problem für Schriftanwender weiterhin: die B-Range wird auch in generell eigentlich gut ausgebauten Fonts nicht immer abgedeckt). Den Großbuchstaben findest du auf Codepoint 0218, den kleinen auf 0219. Tcomma findet sich auf 021A, und tcomma auf 021B. Wenn deine Anwender und deren Software dann noch davon wissen, können sie dieses Zeichen direkt und korrekt eingeben.

[[Mitglied Seba…]]

... Wikipedia hätte es wohl besser erklärt :)

http://en.wikipedia.org/wiki/S-comma

http://en.wikipedia.org/wiki/T-comma

Bzw. hier ist das Problem und die zwei Lösungen sehr genau beschrieben:

http://diacritics.typo.cz/index.php?id=9

[[Mitglied Þors…]]

Ich würde mal sagen, dass – wenn man die Zeichen denn erstellt – es unumgänglich ist, sie auch auf die entsprechenden Unicode-Positionen zu legen (also Ș auf U+0218 usw. usf.). Macht man das nicht, tippt ein die Schrift benutzender Rumäne dann nämlich auf die Ș-Taste seines Keyboards und nichts passiert. (Ich hab’s gerade mal getestet, und das rumänische Standard-Keyboard-Layout erzeugt ganz selbstverständlich Ș, ș, Ț und ț – mit AltGr-S/s/T/t. Windows soll das ab Vista auch so machen.)

Die Ersetzung Ş → Ș etc. mittels locl kann man dann noch zusätzlich einbauen. So aufwendig ist das bei den vier Buchstaben nicht, es ist eine nette Geste und es kann wohl auch nichts schaden. Ob es wirklich wichtig ist, diese Funktion zu haben, mag ich nicht beurteilen. Immerhin sind die korrekten Formen seit ein paar Jahren relativ einfach verfügbar. Andererseits gibt es Software mit OpenType-Unterstützung auch noch nicht so lange. Ob es da eine nennenswerte Überschneidung gibt (also Leute, die zwar moderne OpenType-Software besitzen, aber keine Möglichkeit haben, Ș und Ț korrekt einzugeben)?

[[Mitglied Pach…]]

Warum wird das so oft falsch gemacht?

Es scheint hier auch in der Fachwelt einige Verwirrung zu geben. So schreibt z. B. Alisch:

»Die unterschiedlichen Zeichen semicerc, circumflex und sedilă dürfen bei den Versalien nicht weggelassen werden: Ă, Î, Ș, Ț.«

Er schreibt also sedilă, zeigt aber ein Scomma. Das heißt offensichtlich, daß er beides gar nicht unterscheidet.

[[Mitglied Seba…]]

Kurze Ergänzung: Wenn man sich die Mühe macht, das für lng ROM zu machen, kann man es auch gleich für lng MOL erledigen, dann haben die Schriftanwender in Moldawien auch ihren Comma-Akzent.

Und Þorsten hat natürlich recht: das Zeichen sollte nicht mehr als Codepoint-lose Glyphe angelegt werden, sondern gleich auf ihrem richtigen Platz, und dann ggf. noch mit der Opentype-Sprachweiche ersetzt werden.

Aber das steht eh sehr schön beschrieben auf dem letzten Link von oben.

bearbeitet Januar 19, 2011 von Sebastian Nagel

[[Mitglied Mach…]]

Die Ersetzung Ş → Ș etc. mittels locl kann man dann noch zusätzlich einbauen. So aufwendig ist das bei den vier Buchstaben nicht, es ist eine nette Geste und es kann wohl auch nichts schaden.

Anscheinend schadet es eben doch: Bei Fonts wie Ubuntu oder Crimson Text ist genau dieses Extra als schädlicher Bug gemeldet und daraufhin entfernt worden, vgl. – inklusive Begründung, warum man das nicht machen sollte – unter Bug #635615 in Ubuntu Font Family: “Technical: Remove Romanian language glyph substitution for characters U+015E, U+015F, U+0162, U+0163 ('locl' table)” bzw. Crimson Text: Detail: 3160191 - Remove the Scedilla for Romanian "hack".

[[Mitglied Þors…]]

Aber das steht eh sehr schön beschrieben auf dem letzten Link von oben.

tl;dr

Anscheinend schadet es eben doch

Au weia! Das müsste man mal genauer testen. Ich war bisher davon ausgegangen, dass locl nur greift, wenn man es in einem OpenType-fähigen Programm explizit aktiviert. Die Kommentare lesen sich allerdings so, als ob beim Einsatz von Fonts mit der betreffenden locl-Ersetzung das auch automatisch/systemweit passieren könnte. Das wäre dann in der Tat problematisch.

Allerdings sollte man solche – letztendlich vereinzelten – Kommentare m.E. mit Vorsicht genießen. Außenstehende wie wir (oder haben wir hier Rumänen bzw. Rumänischexperten?) können oft schlecht beurteilen, ob da eine Mehrheitsmeinung widergespiegelt wird oder das Gegenteil.

Am besten wäre natürlich eine Empfehlung irgendeines normativen rumänischen Gremiums.

[[Mitglied Mach…]]

Ich war bisher davon ausgegangen, dass locl nur greift, wenn man es in einem OpenType-fähigen Programm explizit aktiviert. Die Kommentare lesen sich allerdings so, als ob beim Einsatz von Fonts mit der betreffenden locl-Ersetzung das auch automatisch/systemweit passieren könnte. Das wäre dann in der Tat problematisch.

Es ist gerade der Witz bei diesen Ersetzungen, dass sie automatisch durchgeführt werden, wenn nur die Sprache bekannt ist, z.B. in einer Internetseite wie dem serbian example (korrekt angezeigt derzeit nur auf Firefox 4 Beta).

Allerdings sollte man solche – letztendlich vereinzelten – Kommentare m.E. mit Vorsicht genießen. Außenstehende wie wir (oder haben wir hier Rumänen bzw. Rumänischexperten?) können oft schlecht beurteilen, ob da eine Mehrheitsmeinung widergespiegelt wird oder das Gegenteil.

Das lässt sich aber mit gleichem Recht auch von den letztendlich ebenso vereinzelten Beispielen sagen, wo mitttels eines derartigen locl-Tag die Charaktere ş/ţ angezeigt werden wie die Charaktere ș/ț. Auch die sind mit Vorsicht zu geniessen. Im Zweifelfall halte ich es für besser, nichts zu tun, als eine Glyphenersetzung durchzuführen.

bearbeitet Januar 19, 2011 von Mach

[[Mitglied Josh…]]

Kann man diese locl-Ersetzung denn auch für Textteile abschalten?

Es könnte ja nämlich sein, daß ein Rumäne ş/ţ eingeben will — beispielsweise weil er ein Fremdwort setzt oder weil er darauf hinweisen möchte, daß man diese Zeichen ncht verwenden soll.

[Ralf Herrmann]

Kann man diese locl-Ersetzung denn auch für Textteile abschalten?

Das wird vollautomatisch über die ausgewählte Sprache des Textteils gesteuert, ist also meines Wissens nach auch nur auf diese Weise indirekt steuerbar – und genau deshalb wohl auch kritisch. Ist eben immer die Frage, wie viel Satzlogik im Font drinstecken sollte. (Siehe auch der Problematik automatischer Ligaturen für deutschen Satz)

[[Mitglied Josh…]]

Wenn ein Rumäne schreiben wollte: „Früher wurde gelegentlich ş und ţ benützt, weil ș und ț nicht verfügbar waren.“ müßte er dann also für ş und ţ eine andere Sprache einstellen.

Ich finde, man sollte die Kompatibilität zu alten Texten/veralteten Eingabemethoden auch nicht überbewerten und nur ihretwegen solche Tricks einbauen, die selbst wieder zu Problemen führen.

[[Mitglied Þors…]]

Es ist gerade der Witz bei diesen Ersetzungen, dass sie automatisch durchgeführt werden, wenn nur die Sprache bekannt ist, z.B. in einer Internetseite wie dem serbian example (korrekt angezeigt derzeit nur auf Firefox 4 Beta).

Offenbar vollzieht sich gerade ein Wandel darin, wie Software mit locl umgeht. Noch vor kurzem war mit keine Applikation oder Betriebssystem bekannt, dass locl-Ersetzungen automatisch vorgenommen hätte. Wenn sich das jetzt ändert bzw. geändert hat, ist das natürlich sehr wichtig für die Schriftentwickler.

Das lässt sich aber mit gleichem Recht auch von den letztendlich ebenso vereinzelten Beispielen sagen, wo mitttels eines derartigen locl-Tag die Charaktere ş/ţ angezeigt werden wie die Charaktere ș/ț. Auch die sind mit Vorsicht zu geniessen. Im Zweifelfall halte ich es für besser, nichts zu tun, als eine Glyphenersetzung durchzuführen.

Logo. Ich habe mich schon vor einiger Zeit dafür ausgesprochen, locl standardmäßig zumindest in Satz- und Textverarbeitungsprogrammen zu aktivieren, weil ich das grundsätzlich für sinnvoll halte. Anscheinend haben viele Schriftentwickler die Funktion aber anders verstanden, so dass jetzt einiges an Nacharbeit anstehen könnte, wenn sich das FF-Verhalten wirklich durchsetzt.

Kann man diese locl-Ersetzung denn auch für Textteile abschalten?

Es könnte ja nämlich sein, daß ein Rumäne ş/ţ eingeben will — beispielsweise weil er ein Fremdwort setzt oder weil er darauf hinweisen möchte, daß man diese Zeichen ncht verwenden soll.

Eben, genau das ist der Knackpunkt. Ob das Verhalten konfigurierbar ist, hängt von der konkreten Software ab.

[[Mitglied Mach…]]

Ich habe mich schon vor einiger Zeit dafür ausgesprochen, locl standardmäßig zumindest in Satz- und Textverarbeitungsprogrammen zu aktivieren, weil ich das grundsätzlich für sinnvoll halte.

... und weil es so definiert ist, vgl. Tag: 'locl' im OpenType Layout tag registry.

[[Mitglied Bern…]]

Vielen Dank euch allen für die informativen Antworten – hat mir echt geholfen!

[[Mitglied Þors…]]

... und weil es so definiert ist, vgl. Tag: 'locl' im OpenType Layout tag registry.

Tja, das hat bisher bloß noch (fast?) niemand gemacht. Außerdem wird dort zumindest angedeutet, dass dieses Feature, auch wenn es standardmäßig aktiviert sein soll, vom Nutzer ein- und somit auch ausschaltbar sein soll. Und genau daran hapert es bei Firefox.

[[Mitglied Seba…]]

... , dass dieses Feature, auch wenn es standardmäßig aktiviert sein soll, vom Nutzer ein- und somit auch ausschaltbar sein soll. Und genau daran hapert es bei Firefox.

Ob es möglich ist, das mit dem CSS-Befehl " -moz-font-feature-settings:" zu beeinflussen (smcp funktioniert da ja z.B.).

Dann könnte man sowohl als Webdesigner als auch als User ein bestimmtes Verhalten erzwingen.

Als Designer hat man ja noch die Möglichkeit, mit dem lang-Attribut die Sprache vorzugeben. FF scheint sich daran zu halten (z.B. bei Türkisch für Smallcaps-Ersetzung ja ganz nützlich - oder gibt es dort auch Untiefen?). Aber das ist eigentlich eine andere Baustelle.

bearbeitet Januar 20, 2011 von Sebastian Nagel