Accesskey n springt zur Seitennavigation. Springe zum Inhalt.

Dieses Dokument ist eine Übersetzung. Im Falle von Abweichungen oder Fehlern sollte das aktuelle englische Original als maßgeblich angenommen werden. Das W3C besitzt das Copyright am Original, wie unten beschrieben.

Übersetzer: German Translation Team, Trusted Translations, Inc.

s_gotoW3cHome Internationalisierung
 

SVG Tiny-Seiten in arabischer, hebräischer und mit anderen von rechts nach links geschriebenen Schriften erstellen

Zielgruppe: Autoren von SVG-Inhalt, die SVG Tiny-Seiten für Rechts-nach-Links-Schriften wie z. B. Arabisch oder Hebräisch einsetzen oder mit eingebettetem Text in Rechts-nach-Links-Schriften arbeiten. Dieses Material ist bei der Erstellung von Dokumenten mit einem Editor oder bei der Verschriftung hilfreich.

Warum sollten Sie dieses Tutorial lesen?

Zu den Rechts-nach-Links-Schriften gehören Arabisch, Hebräisch, Thaana und N'ko, welche weltweit von einer großen Anzahl von Menschen verwendet werden. Falls Sie erstmals mit bidirektionalen Texten arbeiten, könnte es mitunter kompliziert und verwirrend sein, dafür zu sorgen, dass diese korrekt angezeigt werden, was aber nicht unbedingt so sein muss. Falls Sie schon versucht haben oder damit anfangen möchten, sollte dieses Tutorial Ihnen dabei behilflich sein, die beste Vorgehensweise zum Auszeichnen Ihrer Inhalte zu übernehmen. Es wird ausreichend erklärt, wie bidirektionale Algorithmen funktionieren, damit Sie die Grundursache der meisten Probleme besser verstehen lernen. Wir werden auch einige häufige Irrtümer behandeln, die im Umgang mit Auszeichnungen für bidirektionalen Inhalt in Beziehung stehen.

Ziele

Am Ende dieses Tutorials sollten Sie in der Lage sein:

Beispiele von Bidi-Text im Quellcode zu erzeugen ist problematisch, da die meisten Quelltexteditoren keine Auszeichnungssemantik für den Inhalt anwenden oder bei der Bearbeitung die Auszeichnung vom Inhalt getrennt halten. Dies bedeutet, dass der von Ihnen geschriebene Quellcode nicht genauso wie die in diesem Tutorial gezeigten Codebeispiele aussieht. Der Eindeutigkeit halber werden bei diesen Beispielen Auszeichnung und Inhalt getrennt gehalten und der Inhalt wird so ausgegeben, wie Sie ihn letztendlich zu sehen erwarten würden.

Beachten Sie, dass die Spezifikation von SVG Tiny 1.2 am 22. Dezember 2008 als Empfehlung veröffentlicht wurde. Es könnte eine Weile dauern, bis die in diesem Tutorial beschriebene Funktionalität weitgehend eingesetzt werden wird.

Dokumentrichtung einstellen

Dieser Abschnitt umfasst:

Die Grundlagen

Ergänzen Sie direction="rtl" beim svg-Tag, um die Grundrichtung für das Dokument für jedes Mal so einzustellen, dass die allgemeine Dokumentrichtung von rechts nach links ist. Die Grundrichtung legt den allgemeinen direktionalen Kontext für den Text innerhalb des Elements, in dem dieser angegeben wird, fest.

Im Fall von Dokumenten, die überwiegend von links nach rechts geschrieben werden, müssen Sie die Grundrichtung nicht ausdrücklich definieren, da diese standardmäßig eingestellt ist.

Anschließend ist keine weitere Richtungsauszeichnung in Ihrem Inhalt erforderlich. Der Wert der direction-Eigenschaft, welcher im svg-Element festgelegt wird, wird für das gesamte Dokument von textbezogenen Elementen übernommen. Ein Großteil der Umordnung, die für die Anzeige des Texts erforderlich ist, wird automatisch vom bidirektionalen Unicode-Algorithmus ('Bidi-Algorithmus') übernommen. Dies wird im nachfolgenden Beispiel dargestellt.

Beispiel: Die direction-Eigenschaft, welche beim svg-Tag eingestellt wird. [Live-Code]
<svg xmlns="http://www.w3.org/2000/svg"
	width="100%" height="100%" viewBox="0 0 400 400"
	direction="rtl" xml:lang="fa">
	<title>...</title>
	<desc>...</desc>
	<text x="200" y="200"
		font-size="10">داستان SVG Tiny 1.2 طولا ني است.</text>
	</svg>

Dies wird den Text in der folgenden (richtigen) Reihenfolge anzeigen, immer wenn die Anwendung eine Bearbeitung von Bidi-Text zulässt:

Scan des persischen Texts

Ohne die direction-Eigenschaft würde der Text so aussehen:

Wie der persische Text aussehen würde, wenn nicht in einem RTL-Kontext.

Natürlich treten Situationen auf, bei denen eine weitere Auszeichnung erforderlich ist. Diese Situationen werden nachstehend beschrieben. Auch wird das Hinzufügen von direction="rtl" beim svg-Element einige automatische Auswirkungen auf text-align- und text-anchor-Eigenschaften haben, welche wir auch kurz beschreiben werden.

Sprachkennzeichnung.

Vergessen Sie bei der Festlegung der Richtung des Dokuments im svg-Tag nicht, die Sprache des Dokuments mittels des xml:lang-Attributs festzulegen (siehe Sprachtags bei HTML und XML).

Verfallen Sie jedoch nicht den Irrtum zu vermuten, dass Sprachfestlegungen die Richtung festlegen oder umgekehrt!

Selbst wenn ein Schriften-Subtag im Sprachattributwert verwendet wird, hat dies keine Auswirkungen auf die Richtung des Textes im User-Agent. Sie müssen die Richtung immer mittels des dir-Attributs festlegen.

Gehen Sie logisch vor, nicht visuell

Eine visuelle Anordnung des hebräischen Texts war bei (sehr) alten HTML-User-Agents, welche nicht den bidirektionalen Unicode-Algorithmus unterstützten, weit verbreitet. Der Text wurde im Quellcode in der selben Reihenfolge gespeichert, wie Sie ihn zu sehen erwarten. (Diese Methode war so nicht üblich für Texte in arabischer Schrift, da sie die zusammengehörenden arabischen Zeichen durcheinander brachte).

Mittels der logischen Anordnung wird der Text so im Speicher aufgenommen, wie er normalerweise getippt (und normalerweise ausgesprochen) wird. Der bidirektionale Unicode-Algorithmus wird daraufhin vom Browser eingesetzt um eine korrekte visuelle Anzeige zu erbringen. Heutzutage stehen fast alle Texte im Internet in der logischen Reihenfolge.

Sie sollten Ihren Rechts-nach-Links-Inhalt stets in der logischen Reihenfolge eingeben und sich auf den bidirektionalen Algorithmus und der Auszeichnung verlassen, dass der Text richtig angezeigt wird. Falls Sie dies nicht tun, wird es nicht möglich sein, Ihren Text zu suchen, den Text wieder zu verwenden oder Ihren Inhalt leicht aufrechtzuerhalten.

Beispiel

Im Bild unten erscheint der Satz "פעילות הבינאום, W3C" (oben in blau) so wie er normalerweise erscheinen würde, wenn er in einem Rechts-nach-Links-Absatz angezeigt würde. Die nummerierten Pfeile zeigen die Leserichtung an. Sie lesen die Sequenzen in der Reihenfolge der Nummern.

Logische Speicherreihenfolge im Gegensatz zur visuellen Speicherreihenfolge.

In der zweiten Zeile wird die Reihenfolge der Zeichen im Speicher im Falle einer logisch verschlüsselten Reihenfolge aufgeführt (ausgehend davon, dass das erste Zeichen sich im Speicher links befindet und die darauffolgenden Zeichen immer rechts daneben stehen).

Die dritte Zeile zeigt die Reihenfolge der Zeichen im Speicher der visuellen Verschlüsselungsreihenfolge (mit der selben Annahme bezüglich der Reihenfolge im Speicher).

Mit den Text- und Textarea-Elementen arbeiten

Dieser Abschnitt umfasst:

Wie wird Inhalt auszeichnet

Nachdem die Grundrichtung in der Stufe des svg-Elements festgelegt wurde, sollten Sie nicht die direction-Eigenschaft bei anderen Elementen anwenden, außer wenn Sie die Grundrichtung für dieses Element ändern möchten.

Ein unnötiger Gebrauch der direction-Eigenschaft hat einen Einfluss auf die Bandbreite und kann möglicherweise zusätzliche Arbeit bei der Seitenwartung bewirken.

Die Grundrichtung, die über die direction-Eigenschaft festgelegt wird, betrifft jedoch die Weise, wie Sprachtext und Zeichensetzung innerhalb eines text- oder textArea-Elements geordnet wird (dies wird weiter unten detailgetreu beschrieben). Von Zeit zu Zeit möchten Sie bestimmt die Grundrichtung für eines dieser Elemente ändern, falls diese in einer anderen Sprache als der Rest der Seite verfasst sind.

Wenden Sie hierzu einfach die direction-Eigenschaft für dieses Element an oder für ein gruppierendes Element, das den relevanten Inhalt umgibt.

Beispiel: Die Richtung eines Block-Elements ändern. [Live-Code]

In diesem Beispiel wenden wir ein gruppierendes Element um mehrere text-Elemente an, welche eine Grundrichtung von links nach rechts erfordern, um richtig auszusehen. Durch Anwendung eines gruppierenden Elements wird der Arbeitsaufwand, um das gewünschte Ergebnis zu erzielen, reduziert. Die eingestellte Richtung wird von den umgebenen text-Elementen übernommen.

<svg xmlns="http://www.w3.org/2000/svg"
	width="100%" height="100%" viewBox="0 0 400 400"
	direction="rtl" xml:lang="he">
	<title>...</title>
	<desc>...</desc>
	<text x="200" y="20"
		font-size="10">כתובת לפניות באנגליה:</text>
	<g direction="ltr">
		<text x="100" y="40"
			font-size="10">3, Tennyson House</text>
		<text x="100" y="50"
			font-size="10">17 Clairbourne Road,</text>
		<text x="100" y="60"
			font-size="10">Harpenden AL5 4SD</text>
		</g>
	</svg>

Ohne Richtungsauszeichnung beim g-Element wird dies den Text ungefähr folgenderweise anzeigen:

Scan des Ergebnis.

Sobald die direction-Eigenschaft festgelegt wurde, wird der Text wie beabsichtigt aussehen.

Scan des Ergebnis.

Vielleicht haben Sie bemerkt, dass die Ausrichtung des Textes bezüglich der x-Koordinate für beide Beispiele oben anders ist. Dies wird nun erörtert.

Richtung und Textausrichtung

Die text-align-Eigenschaft wird mit dem textArea-Element angewendet, und dessen Werte sind start, middle und end. Es ist wichtig daran zu denken, dass der erste und der letzte Wert vielmehr in einer logischen Weise als in einer physikalischen Weise mit dem Text in Beziehung stehen.

start bedeutet der Ort, an dem Sie normalerweise eine Zeile zu lesen beginnen würden in Anbetracht der gegenwärtigen Grundrichtung. Wenn die Grundrichtung von links nach rechts ist, bedeutet das links vom textArea-Element. Falls die Grundrichtung andererseits von rechts nach links ist, bedeutet das die rechte Seite des textArea-Elements.

Drehen Sie dies für end einfach um.

Dies ist intuitiv, wenn Sie CSS mit HTML angewendet haben, da die direction-Eigenschaft bei CSS automatisch den Text rechtsbündig in einem Block-Element ausrichtet.

Beispiel: text-align auf start gesetzt für RTL-Text. [Live-Code]

In diesem Urdu-Beispiel wird die beim svg-Element eingestellte Rechts-nach-Links-Richtung vom Element textArea übernommen.

<svg xmlns="http://www.w3.org/2000/svg"
	width="100%" height="100%" viewBox="0 0 400 400"
	dir="rtl" xml:lang="ur">
	<title>...</title>
	<desc>...</desc>
	<textArea x="20" y="20" width="200">
		فعالیت بین‌المللی‌سازی، W3Cنا
‎        عالمگیر ویب کو حقیقی طور پر عالمگیر بنانا
		</textArea>
	</svg>

Bei der Ansicht sollte der Text wie unten aufgeführt innerhalb des Feldes textArea rechtsbündig ausgerichtet sein, da der Standardwert von text-align start ist, was für eine Grundrichtung von rechts nach links rechtsbündig ausgerichtet bedeutet.

Scan des Ergebnis.

Richtung und Textanker

Die text-achor-Eigenschaft wird mit dem text-Element angewendet, und dessen Werte sind start, middle und end. Erneut stehen der erste und der letzte Wert vielmehr in einer logischen Weise statt einer physikalischen Weise mit dem Text in Beziehung.

Falls Sie keine Grundrichtung oder direction="ltr" angegeben haben und falls text-anchor auf start, gesetzt ist, wird der Text bis zur rechten Seite der x-Koordinate reichen. Falls Sie direction="rtl" eingestellt haben, wird der Text bis zur linken Seite der x-Koordinate reichen. Standardmäßig ist text-anchor auf start gesetzt.

Für end gilt das Gegenteil.

Beispiel: Textanker in verschiedenen Texten mit verschiedenen Grundrichtungen. [Live-Code]

In diesem englischen/arabischen Beispiel verwenden wir zwei Textelemente, beide mit derselben x-Koordinate und beide mit dem selben Standardwert für text-anchor.

<svg xmlns="http://www.w3.org/2000/svg"
	width="100%" height="100%" viewBox="0 0 400 400"
	xml:lang="en">
	<title>...</title>
	<desc>...</desc>
	<text x="200" y="10"
		font-size="10">Internationalization activity, W3C</text>
	<text direction="rtl" x="200" y="20"
		font-size="10">نشاط التدويل، W3C</text>
	</svg>

Auch wenn die x-Koordinate für beide Textelemente dieselbe ist, wird dies den Text ungefähr folgenderweise anzeigen:

Scan des Ergebnis.

Sie sollten berücksichtigen, dass die Richtung, in der sich der Text vom x-Punkt (siehe vorheriges Beispiel) aus erstrecken wird, von der Grundrichtung abhängt, d. h. dem Wert der direction-Eigenschaft, und nicht davon, ob es sich um lateinischen oder arabischen (oder hebräischen) Text handelt. Das ist wichtig.

Dies bedeutet, dass zum Beispiel eine Liste von Begriffen, die sowohl lateinische als auch mittelöstliche Wörter enthält, die Elemente nicht unerwartet falsch ausrichtet.

Beispiel: Die Schrift spielt keine Rolle bei der Textausrichtung. [Live-Code]

Die folgenden Beispiele enthalten abwechselnd in Hebräisch und Lateinisch geschriebene Zeilen:

<svg xmlns="http://www.w3.org/2000/svg"
	width="100%" height="100%" viewBox="0 0 400 400"
	direction="rtl" xml:lang="he">
	<title>...</title>
	<desc>...</desc>
	<text x="200" y="20"
		  font-size="10">פעילות הבינאום, W3C</text>
	<text x="200" y="30" xml:lang="en"
		  font-size="7">(Internationalization Activity, W3C)</text>
	<text x="200" y="50"
		  font-size="10">ליצור מהרשת רשת כלל עולמית באמת</text>
	<text x="200" y="60" xml:lang="en"
		 font-size="7">(Making the World Wide Web worldwide)</text>
	</svg>

Alle Elemente in der Adressliste werden dennoch rechtsbündig ausgerichtet. Wir müssen nichts Besonderes bei den nur lateinischen Zeilen vornehmen, damit diese mit dem Rest ausgerichtet sind:

Scan des Ergebnis.

Sie sollten jedoch daran denken, dass Sie, falls Sie aus irgendeinem Grund direction="ltr" für eines der text-Elemente anwenden, auch text-anchor="end" für dieses Element angeben müssen, damit es weiterhin zu den anderen Elementen ausgerichtet verbleibt.

Textrichtung inline mischen

Dieser Abschnitt umfasst:

In den vorherigen Abschnitten erwähnten wir, dass es gelegentlich nicht ausreicht, nur Richtungsinformationen beim svg-Tag zu ergänzen. In diesem Abschnitt werden wir sehen, warum und wann mehr Kontrolle erforderlich ist, und im Besonderen, wie man tspan-Elemente für eine bestimmte Richtung auszeichnet (wofür es notwendig ist, die unicode-bidi-Eigenschaft einzufügen).

Grundkenntnisse des Bidi-Algorithmus

Direktionaler Kontext (Grundrichtung)

Das Ergebnis der Anwendung des bidirektionalen Algorithmus hängt von der allgemeinen Grundrichtung des Satzes, des Abschnitts, des Blocks oder der Seite, in der dieser angewendet wird, ab. Die Grundrichtung legt den direktionalen Kontext fest, auf den der Bidi-Algorithmus bei vielen Punkten Bezug nimmt, um zu entscheiden, wie der Text behandelt werden soll.

Die Grundrichtung wird entweder ausdrücklich durch das nächst gelegene ursprüngliche Element bestimmt, welches die direction-Eigenschaft anwendet, oder sie wird ohne einen solchen Ursprung von der Standard-Direktionalität des svg-Tags übernommen, welche von links nach rechts verläuft.

Beachten Sie, dass für Block-Elemente nur über die direction-Eigenschaft eine Grundrichtung von rechts nach links eingestellt werden kann.

Zeichen und direktionale Eingabe

Wir sind uns im Klaren, dass eine Reihenfolge lateinischer Zeichen eines nach dem anderen von links nach rechts ausgegeben (angezeigt) wird (dies können wir auf dieser Seite sehen). Andererseits wird der Bidi-Algorithmus eine Reihenfolge stark typisierter RTL (Rechts-nach-Links)-Buchstaben einer nach dem anderen von rechts nach links ausgeben.

Dies ist unabhängig von der derzeitigen Grundrichtung und funktioniert, weil jeder Buchstabe im Unicode über eine zugehörige direktionale Eigenschaft verfügt. Die meisten Buchstaben werden stark als LTR typisiert. Buchstaben der Rechts-nach-Links-Schriften werden stark als RTL typisiert.

Direktionale Typisierung.

Direktionale Textflüsse

Wenn ein Text mit verschiedener Direktionalität inline vermischt wird, gibt der Bidi-Algorithmus jede Zeichenfolge mit der selben Direktionalität wie ein separater direktionaler Textfluss aus.

Im folgenden Beispiel werden drei direktionale Textflüsse dargestellt:

Direktionale Textflüsse.

Eine andere Weise dies zu sehen ist, dass Richtungsänderungen die Grenzen der direktionalen Textflüsse markieren. Beachten Sie, dass dafür keine Auszeichnung oder Styling erforderlich ist.

Es ist besonders wichtig, zu verstehen, dass die Reihenfolge, in der direktionale Textflüsse entlang der Seite angezeigt werden von der allgemein geltenden Grundrichtung abhängen.

Die Wörter auf der Abbildung unten sind separate direktionale Textflüsse. Die obere Zeile steht in einem Kontext, in dem die Grundrichtung LTR ist und bei der unteren RTL ist. Die Buchstaben in beiden Zeilen der Abbildung werden in der selben Reihenfolge gespeichert, aber die visuelle Reihenfolge der direktionalen Textflüsse wird, wenn angezeigt, umgekehrt.

Die Auswirkungen der Grundrichtung auf die Anzeige von direktionalen Textflüssen.

Neutrale Zeichen

Leerzeichen und Satzzeichen werden im Unicode weder als LTR noch als RTL stark typisiert, da sie in beiden Schrifttypen angewendet werden. Daher werden Sie als neutral eingestuft.

Hier wird es interessant. Wenn der Bidi-Algorithmus auf Zeichen mit neutralen direktionalen Eigenschaften stößt (wie z. B. Leerzeichen und Satzzeichen) wird er ausarbeiten, wie diese durch Prüfung der umliegenden Zeichen behandelt werden sollen.

Ein neutrales Zeichen zwischen zwei stark typisierten Zeichen desselben direktionalen Typs werden auch diese Direktionalität übernehmen. Daher wird ein neutrales Zeichen zwischen zwei stark typisierten RTL-Zeichen selbst als ein RTL-Zeichen angesehen und wird die Auswirkung haben, den direktionalen Textfluss zu verlängern. Darum werden die drei arabischen Wörter in diesem LTR-Satz (nur durch Leerzeichen getrennt, welche eine neutrale Direktionalität aufweisen) von rechts nach links als einziger direktionaler Textfluss gelesen. (Das erste arabische Wort, dass Sie lesen, ist مفتاح dann معايير und dann الويب).

Neutrale Zeichen als Teil eines direktionalen Textflusses.

Beachten Sie, dass dafür immer noch keine Auszeichnung oder Styling erforderlich ist. Und, dass hier immer noch nur drei direktionale Textflüsse vorhanden sind.

Der wirklich interessante Teil kommt, wenn ein Leerzeichen oder ein Satzzeichen zwischen zwei stark typisierten Zeichen mit unterschiedlicher Direktionalität gelangt, d. h. an der Grenze zwischen direktionalen Textflüssen. In solchen Fällen wird das oder die neutralen Zeichen so behandelt, als hätten sie die Direktionalität der Grundrichtung.

Selbst wenn sich zwischen den zwei verschiedenen stark typisierten Zeichen mehrere neutrale Zeichen befinden, werden diese auf die gleiche Weise behandelt.

Neutrale Zeichen.

Ziffern

Nummern verlaufen in RTL-Schriften von links nach rechts innerhalb des Rechts-nach-Links-Flusses, sie werden aber ein bisschen anders vom Bidi-Algorithmus behandelt als Wörter. Sie werden als mit schwacher Direktionalität betrachtet. Die zwei Beispiele in der Abbildung veranschaulichen diesen Unterschied.

Ziffern.

Im ersten Beispiel werden europäische Ziffern angewendet, '1234', im zweiten wird die selbe Zahl in arabisch-indischen Ziffern dargestellt, ١٢٣٤. In beiden Fällen werden die Ziffern innerhalb der Nummer von links nach rechts gelesen.

Da sie schwach typisiert wird, wird die Nummer als Teil des arabischen Texts angesehen, weshalb die zwei arabischen Wörter auf beiden Seiten der Nummer als Teil des selben direktionalen Textflusses angesehen werden - sogar wenn die Reihenfolge der Ziffern auf dem Bildschirm in Richtung LTR verlaufen.

Beachten Sie auch, dass bestimmte sonst neutrale Zeichen, wie z. B. Währungssymbole, zusammen mit der Nummer als Teil der Nummer und nicht als neutral betrachtet werden.

Neutrale Zeichen zwischen unterschiedlichen direktionalen Textflüssen

Der Bidi-Algorithmus wird den Text in den meisten Situationen sehr gut behandeln und normalerweise ist keine spezielle Auszeichnung oder andere Vorrichtung außer der Einstellung der allgemeinen Richtung für das Dokument erforderlich. Sie würden jede Menge Glück haben, wenn dies immer so einfach wäre. Hier ist unser erstes Beispiel einer Situation, bei der der bidirektionale Algorithmus ein bisschen Hilfe benötigt.

In der ersten Zeile auf dieser Abbildung ist ein Ausrufezeichen aufgeführt, welches zum eingebetten arabischen Text gehört und sich an der falschen Stelle befindet. Die zweite Zeile zeigt das gewünschte Ergebnis.

Neutrale Zeichen zwischen bidirektionalen Textflüssen könnten dort enden, wo sie nicht enden sollten.

Gemäß unserer vorherigen Behandlung des Bidi-Algorithmus ist leicht zu verstehen, warum dies so geschah. Weil das Ausrufezeichen zwischen dem letzten RTL-Buchstaben '?' (links)? und dem LTR-Buchstaben 'i' (des Wortes 'in') eingegeben wurde, wird dessen Direktionalität von der Grundrichtung des Abschnitts bestimmt (hier LTR). Beachten Sie, dass es keinen Unterschied macht, dass dort eigentlich zwei Satzzeichen und ein Leerzeichen stehen - sie sind alle neutrale Zeichen und sind daher gleichermaßen betroffen. Da das Ausrufezeichen als LTR betrachtet wird, begleitet es den bidirektionalen Textfluss, der den Text 'auf arabisch' einbezieht.

Wie gelangt das Satzzeichen dann in die richtige Position?

Eine Antwort wäre, das arabische Zitat in einem tspan-Element unterzubringen und die direction-Eigenschaft anzuwenden, um die Grundrichtung innerhalb des tspan auf RTL umzustellen.

Anders als bei den vorher behandelten Container-Elementen müssen Sie bei tspan die unicode-bidi-Eigenschaft und die direction-Eigenschaft eingeben, damit die Änderungen der Grundrichtung wirksam werden. Der erforderliche Wert ist embed. (Wir werden auf die Anwendungsweise von bidi-override später zurückkommen).

<text>The title is "<tspan direction="rtl" unicode-bidi="embed" xml:lang="ar"> ... !</tspan>" in Arabic.</text>
[Live-Code]

Die von Ihnen angewendete Bearbeitungsumgebung könnte das Ausrufezeichen nicht an der richtigen Stelle im Quellcode anzeigen, dies sollte aber bei der Anzeige stimmen.

Beachten Sie, wie der span-Tag zwischen die Zitatmarkierungen gelangt - die Zitate sind Teil des umgebenden englischen Textes.

Eine andere Möglichkeit wäre, ein unsichtbares, stark typisiertes RTL-Zeichen nach dem Ausrufezeichen einzugeben. Auf dieser Weise würde das Ausrufezeichen als RTL interpretiert und den arabischen direktionalen Textfluss begleiten.

Gerade dafür gibt es solch ein Zeichen - das Unicode-Zeichen U+200F, die RECHTS-NACH-LINKS-MARKIERUNG (RLM) genannt. Auch gibt es ein ähnliches Zeichen, U+200E, welches LINKS-NACH-RECHTS-MARKIERUNG (LRM) genannt wird. Da dieses Zeichen unsichtbar ist, sollten Sie es bevorzugen tatsächlich eine Zeichenreferenz einzugeben ()

Dieses Zeichen gerade hinter dem Ausrufezeichen einzugeben wird das gewünschte Ergebnis bewirken.

<text>The title is "... !‏" in Arabic.</text>

Falls schon eine Auszeichnung um das Zitat vorhanden ist, könnte es sinnvoll sein, dort einfach nur die direction statt dem Kontrollzeichen anzuwenden. Anderenfalls könnte es einfacher sein, das Kontrollzeichen anzuwenden.

Neutrale Zeichen zwischen gleichen direktionalen Textflüssen

Die obere Zeile der nachfolgenden Abbildung zeigt, was bei einer Liste von RTL-Elementen innerhalb eines LTR-Satzes geschehen würde, wenn wir uns nur auf den bidirektionalen Algorithmus verlassen würden (d. h. wenn wir die direction-Eigenschaft nicht anwenden würden, um die Grundrichtung festzulegen). Bei unserem Beispiel stimmt die Reihenfolge der Liste nicht, weil die ersten zwei arabischen Wörter umgedreht werden müssen und das Komma zwischen den Wörtern, welches ein Teil des englischen Textes ist, gleich rechts neben dem ersten Wort stehen müsste.

Die zweite Zeile in der Abbildung zeigt das gewünschte Ergebnis.

Neutrale Zeichen zwischen Texten der selben Richtung könnten unpassend als Teil eines einzigen Textflusses angesehen werden.

Grund dieses Fehlers ist, dass der bidirektionale Algorithmus das neutrale Komma* bei einem stark typisiertem Rechts-nach-Links (RTL)-Zeichen auf beiden Seiten als Teil des arabischen Textes ansieht. Er interpretiert die ersten beiden arabischen Wörter und das Komma als eine Liste auf arabisch. Eigentlich ist das Komma aber Teil des englischen Textes und sollte die Grenze zwischen zwei direktionalen Textflüssen auf arabisch markieren.

* Eigentlich ist das Leerzeichen neben dem Komma auch ein neutrales Zeichen und wird genauso wie das Komma behandelt, obwohl wir nur das Komma im Text erwähnen, um die Erklärung deutlich zu machen.

Im vorherigen Abschnitt dachte das neutrale Zeichen, dass es Teil des direktionalen Kontexts ist, welcher von der Grundrichtung bestimmt wird, dies war aber nicht der Fall; in diesem Abschnitt denkt das neutrale Zeichen, dass es Teil des direktionalen Textflusses ist, es ist hier aber in Wahrheit Teil des allgemeinen direktionalen Kontexts.

Eine einfache Lösung wäre, ein anderes unsichtbares Unicode-Zeichen anzuwenden, dieses Mal die LINKS-NACH-RECHTS-MARKIERUNG neben dem Komma. Dies stellt unser neutrales Satzzeichen zwischen zwei stark typisierte RTL- und LTR-Zeichen und zwingt es dazu, die Direktionalität der Grundrichtung anzunehmen, welche die Links-nach-Rechts-Richtung des englischen Textes ist. Dies teilt die arabischen Wörter in zwei separate direktionale Läufe auf, welche entsprechend der maßgeblichen Richtung des Abschnitts LTR verlaufen.

<text>The names of these states in Arabic are ...,‎ ... and ... respectively.</text>

Erneut könnten Sie der Sichtbarkeit halber ein NCR () anwenden.

Die nächste Abbildung zeigt ein weiteres Beispiel, bei dem keine Auszeichnung notwendig ist und ein Unicode-Kontrollzeichen viel leichter die Arbeit erledigen wird. Erneut zeigt die obere blaue Zeile das Ergebnis, wenn man sich einfach nur auf den bidirektionalen Algorithmus verlässt, und die zweite Zeile zeigt das gewünschte Ergebnis.

Das gewünschte Ergebnis wurde durch Platzierung von neben der Klammer erreicht, welche als Teil des hebräischen Kontextes betrachtet wurde, sich aber zwischen zwei Bereichen lateinischen Textes befindet. Das Ergebnis der RLM-Markierung ist die Aufteilung des lateinischen Textes in drei separate direktionale Textflüsse, welche entsprechend der RTL-Grundrichtung geordnet werden.

Ein weiteres Beispiel der Anwendung von RLM oder LRM, dieses Mal in einem hebräischen Kontext.

Gespiegelte Buchstaben

Vielleicht haben Sie bemerkt, dass eine der Klammern im vorherigen Beispiel nicht nur die Position sondern auch die Form gewechselt hat. Dies war komplett automatisch und ereignet sich so, weil diese Zeichen bei Unicode gespiegelte Zeichen genannt werden.

Gespiegelte Zeichen sind üblicherweise Zeichenpaare, wie z. B. runde Klammern, eckige Klammern und Ähnliches, deren Form bei der Ansicht davon abhängt, ob sie einem LTR- oder RTL-Inhalt angehören. Sie müssen das Zeichen nicht ändern, damit sich die Form ändert. Die Enden einer offenen Klammer sind immer Richtung Textfluss gerichtet. In der Abbildung unten ist die rot umkreiste Klammer in der oberen Zeile nach rechts gerichtet, da diese als eine offene Klammer eines lateinischen Textes behandelt wird. In der unteren Version des Textes wird dasselbe Zeichen (erneut rot umkreist) als eine offene Klammer in Beziehung mit dem hebräischen Text betrachtet (d. h. der Expanded Name folgt dem Akronym in der Leserichtung) und wurde daher umgedreht.

Gespiegelte Zeichen.

Dies bedeutet, dass Sie, egal ob der gespeicherte Inhalt arabische/hebräische oder lateinische Schrift ist, dasselbe LINKE KLAMMER-Zeichen zu Beginn des Textes in Klammern anwenden würden. In anderen Worten, sollten Sie gespiegelte Zeichen so behandeln, als würde ein Wort links im Namen 'Öffnung' und rechts 'Schließung' bedeuten.

Verschachtelte direktionale Textflüsse

Der Unicode Bidi-Algorithmus und die LRM-/RLM-Markierungen funktionieren ziemlich gut, wenn nur eine Stufe gemischten Textes vorhanden ist. Falls eine Situation auftritt, bei der zwei oder mehr verschachtelter Stufen direktionaler Text vorhanden sind, wird eine andere Lösung erforderlich sein. Diese Abbildung stellt einen lateinischen Satz dar, welcher ein hebräisches Zitat enthält, welches wiederum sowohl hebräischen als auch lateinischen Text enthält ('W3C').

Die Reihenfolge der zwei hebräischen Wörter stimmt, aber der Text 'W3C' sollte auf der linken Seite des Zitats und das Komma zwischen dem hebräischen Text und 'W3C' erscheinen.

Eine Auszeichnung anzuwenden, um eine neue Einbettungsstufe zu öffnen und so die gewünschte Darstellung zu erreichen.

Das Problem tritt auf, weil die direktionalen Flüsse entsprechend der LTR-Grundrichtung des Abschnitts geordnet sind. Innerhalb des hebräischen Zitats sollte die korrekte Standardordnung jedoch RTL sein.

Um dieses Problem zu lösen, müssen wir eine neue Einbettungsstufe öffnen. Hierzu müssen Sie das Zitat mit einem tspan-Element umbrechen und ihm eine RTL-Direktionalität zuordnen, indem Sie direction- und unicode-bidi-Eigenschaften anwenden.

<text>The title says "<tspan direction="rtl" unicode-bidi="embed"> ... </tspan>" in Hebrew.</text>

Es stehen auch Unicode-Kontrollzeichen zur Verfügung, welche Sie anwenden können, um dasselbe Ergebnis zu erhalten, da diese eine Grundrichtung für einen Textbereich mit unsichtbaren Grenzen festlegen. Dies wird aber nicht empfohlen.

Zusammenfassung der tspan-Auszeichnung

Kurz gefasst, wo Sie nur die direction-Eigenschaft bei Container-Elementen wie svg, g, text und textArea anwenden, müssen Sie sowohl direction als auch unicode-bidi="embed" bei tspan-Elementen anwenden, da diese inline sind.

Ein weiterer nützlicher Wert des unicode-bidi ist bidi-override. Diesen brauchen Sie jedoch nicht oft anwenden. Er wird im nachstehenden Abschnitt erläutert.

Den Bidi-Algorithmus aufheben

Manchmal gibt es Anlässe, bei denen Sie überhaupt keine vom Bidi-Algorithmus durchgeführte Umordnung haben möchten. In solchen Fällen benötigen Sie eine zusätzliche Auszeichnung, um den Text einzukreisen, den Sie nicht umordnen möchten.

Bei SVG wird dies durch Anwendung des bidi-override-Wertes der unicode-bidi-Eigenschaft zusammen mit der direction-Eigenschaft erreicht. Erneut können Sie Unicode-Kontrollzeichen anwenden, um dasselbe Ergebnis zu erreichen, aber da sie Zustände mit unsichtbaren Grenzen erzeugen, werden sie nicht empfohlen.

Ein Beispiel eines Textes, bei dem Sie den bidirektionalen Algorithmus aufheben möchten.

Das Beispiel in der Abbildung zeigt hebräischen Text wie im Speicher geordnet. Sie können die unicode-bidi-Eigenschaft anwenden, um diesen Effekt zu erreichen, d. h.

<text x="20" y="80" direction="ltr" unicode-bidi="bidi-override"> ... </text>

Unicode-Zeichen oder Auszeichnung?

Unicode stellt spezielle, unsichtbare Formatierungscodes zur Verfügung, um diese als Vorlage zu verwenden oder das Ergebnis des bidirektionalen Algorithmus in Klartext aufzuheben, so wie die SVG-Auszeichnung in diesem Tutorial.

Es stehen bei Unicode einige Kontrollzeichen zur Verfügung, welche angewendet werden können, um den selben Effekt wie durch eine Auszeichnung für bidirektionalen Inline-Text zu gewährleisten. Diese Zeichen werden in der nachstehenden Tabelle aufgeführt:

Zeichen Code Gleichwertige Auszeichnung
RLE U+202B <tspan direction="rtl" unicode-bidi="embed">
LRE U+202A <tspan direction="ltr" unicode-bidi="embed"
RLO U+202E <tspan direction="rtl" unicode-bidi="bidi-override"
LRO U+202D <tspan direction="ltr" unicode-bidi="bidi-override"
PDF U+202C </tspan>

Unicode bei Auszeichnungssprachen rät davon ab, diese zu verwenden, wenn eine Auszeichnung verfügbar ist und rät besonders davon ab, Kontrollcodes und Auszeichnung zu vermischen.

Für weitere Informationen hierzu siehe Unicode-Kontrollen geg. Auszeichnung für Bidi-Unterstützung auf der W3C-Internationalisierung-Webseite.

Es treten jedoch einige Situationen auf, in denen Unicode-Kontrollzeichen das einzige Mittel sind, um die Direktionalität auszudrücken. Dies trifft für Klartextelemente wie title und desc zu. Diese Elemente sind dafür bestimmt, nur Zeichen zu unterstützen, keine Auszeichnung. Es ist daher nicht möglich, die direction- oder unicode-bidi-Eigenschaften für einen Teil des Elementeninhalts anzuwenden.

Attributtext kann auch nicht für Direktionalität ausgezeichnet werden, weshalb Unicode-Kontrollzeichen angewendet werden müssen, um die Direktionalität anzugeben.

Beachten Sie, dass andere Elemente, wie die Sprache, weder für Teile des Klartextinhalts noch für Attributwerte ausgezeichnet werden können.

Sagen Sie uns, was Sie denken (auf Englisch).

Senden Sie uns Anmerkungen

Literaturhinweise

Autor: Richard Ishida, W3C. Übersetzer: German Translation Team, Trusted Translations, Inc..

Übersetzung der englischen Version vom 2009-01-07. Letzte Änderung der übersetzten Version am 2010-12-02 16:37 UTC.

Suchen Sie nach tutorial-svg-tiny-bidi im i18n-Blog, um alle Dokumentänderungen nachzuvollziehen.