edition W3C.de

HTML 4.01-Spezifikation

Deutsche Übersetzung

Diese Version:
http://www.edition-w3.de/TR/1999/REC-html401-19991224
Aktuelle Version:
http://www.edition-w3c.de/TR/html4
Übersetzer:
Christine Kühnel (Übersetzung, fachliche Kommentierung) <kuehnel@screenexa.net>
Stefan Mintert (Fachlektorat und fachliche Kommentierung) <www.mintert.com/stefan/mail/>
Stefan Schumacher (Übersetzung, fachliche Kommentierung) <sts@schumacher-netz.de>

Bei diesem Dokument handelt es sich um eine Übersetzung eines W3C-Textes. Dieser Text ist urheberrechtlich geschützt; bitte beachten Sie die nachfolgenden Hinweise des Originaldokuments. Die Rechte an der Übersetzung liegen bei den Übersetzern und dem Verlag Addison-Wesley. Die Übersetzung hat keine durch das W3C legitimierte, normative Wirkung. Das einzige maßgebliche Dokument ist das englische Original.

Bitte senden Sie Fehler und Korrekturen zur deutschen Fassung an die Übersetzer.

Kommentare der Übersetzer, die als solche gekennzeichnet sind, unterliegen dem Urheberrecht der Übersetzer. Sie sind nicht Bestandteil des Ursprungsdokuments.

Diese Veröffentlichung ist eine Vorveröffentlichung. Kein Teil dieses Textes darf kopiert werden. Alle Rechte vorbehalten. Nach Abschluss der Arbeit wird das endgültige Dokument unter der oben angegebenen Adresse veröffentlicht. Die jetzige Veröffentlichung während der laufenden Arbeit dient zur Information von Interessierten und zur Prüfung durch die Fachöffentlichkeit. Sollten Sie Fehler finden oder Verbesserungsvorschläge haben, schicken Sie diese bitte per Mail an die Übersetzer.
Folgende Teile liegen noch in Englisch vor und müssen noch in deutscher Fassung generiert werden: (a) Gesamtinhaltsverzeichnis (b) Index


8 Sprachinformation und Leserichtung

Inhaltsverzeichnis

Dieser Abschnitt des Dokuments erörtert zwei wichtige Themen, die die Internationalisierung von HTML betreffen: Die Spezifizierung der Sprache (lang-Attribut) und der Leserichtung (dir-Attribut) von Text in einem Dokument.

8.1 Spezifizierung der Sprache des Inhalts: das lang-Attribut

Attributdefinitionen
lang = Sprachcode [CI]
Dieses Attribut spezifiziert die Basis-Sprache der Attributwerte und des Textinhaltes eines Elements. Der Standardwert dieses Attributs ist unknown.

Durch lang-Attribut spezifizierte die Sprachinformation kann von Benutzerprogrammen auf vielfältige Art genutzt werden, um die Darstellung zu steuern. Einige Situationen, in denen vom Autor bereitgestellte Sprachinformation hilfreich sein können, seien im Folgenden genannt:

Das lang-Attribut spezifiziert die Sprache des Elementinhalts und der Attributwerte; ob es für ein gegebenes Attribut relevant ist, hängt von Syntax und Semantik des Attributs und der daraus resultierenden Operation ab.

Anliegen des lang-Attributs ist es, Benutzerprogrammen zu gestatten, Inhalt auf der Basis üblicher kultureller Gewohnheiten einer gegebenen Sprache sinnvoller darzustellen. Das bedeutet nicht, dass Benutzerprogramme Zeichen, die für eine bestimmte Sprache atypisch sind, in weniger sinnvoller Art darstellen sollen; Benutzerprogramme müssen den besten Weg suchen, um alle Zeichen darzustellen, ungeachtet des in lang spezifizierten Wertes.

Wenn zum Beispiel griechische Buchstaben innerhalb von englischem Text stehen:

<P><Q lang="en">Her super-powers were the result of
&gamma;-radiation,</Q> he explained.</P>

sollten Benutzerprogramme (1) versuchen, den englischen Inhalt in angemessener Art und Weise darzustellen (z.B. in seiner Behandlung der Anführungszeichen) und müssen (2) versuchen, γ -- obgleich kein englischer Buchstabe -- darzustellen.

Anmerkung der Übersetzer:

Die Sprachinformation in obigem Beispiel könnte auch dafür genutzt werden, englische Anführungszeichen um den Inhalt des Q-Elements (quote) zu setzen. Dies ist auch mit CSS möglich. Verwandte Informationen finden Sie in der CSS2-Spezifikation im Abschnitt 5.11.4.

Hiermit in Zusammenhang stehende Informationen finden Sie im Abschnitt 5.4, »nichtdarstellbare Zeichen«.

8.1.1 Sprachcodes

Der Wert des lang-Attributs ist ein Sprachcode, der eine natürliche gesprochene, geschriebene oder auf andere Art zur Verständigung von Menschen verwendete Sprache kennzeichnet. Computer-Sprachen sind explizit von Sprachcodes ausgeschlossen.

[RFC1766] definiert und erklärt die Sprachcodes, die in HTML-Dokumenten verwendet werden müssen.

Kurz gefasst, bestehen Sprachcodes aus einem primären Code und einer -- möglicherweise leeren -- Serie von Unter-Codes:

        language-code = primary-code ( "-" subcode )*

Hier sinde einige Beipiele für Sprachcodes:

Anmerkung der Übersetzer:

Dass es sich bei Klingonisch um eine experimentelle Sprache handelt, sollten Sie niemals gegenüber einem Klingonen behaupten. Die gleiche Behauptung wird bei einer gewissen Gruppe der Cineasten zu einer ebenso ablehnenden Reaktion führen, dürfte aber weniger gefährlich sein als gegenüber einem Klingonen. Wer es ausprobieren möchte, sollte also mit einem Cineasten anfangen. ;-)

Da Sie in Mitteleuropa vermutlich häufiger mit Deutschen und Schweizern als mit Klingonen zusammentreffen, sehen Sie nachfolgend noch ein Beispiel für einen deutschen Satz. Er stammt (hinsichtlich der Auszeichnungen leicht abgewandelt) aus der deutschen XML-Spezifikation:

<p lang="de-DE">In welcher Straße hast du geparkt?</p>
<p lang="de-CH">In welcher Strasse hast du parkiert?</p>

Beachten Sie bitte, dass die Sprachauszeichnung nicht für Dialekte verwendet wird.

Aus zwei Zeichen bestehende Sprachcodes sind für [ISO639]-Sprachkürzel reserviert. Zwei-Zeichen-Codes beinhalten fr (Französisch), de (Deutsch), it (Italienisch), nl (Niederländisch), el (Griechisch), es (Spanisch), pt (Portugiesisch), ar (Arabisch), he (Hebräisch), ru (Russisch), zh (Chinesisch), ja (Japanisch), hi (Hindi), ur (Urdu), und sa (Sanskrit).

Jeder Zwei-Zeichen-Subcode wird als [ISO3166] Ländercode (country code) aufgefasst.

8.1.2 Vererbung von Sprachcodes

Ein Element bekommt Sprachcode-Informationen in folgender Rangfolge (vom höchsten zum niedrigsten):

In diesem Beispiel ist die primäre Sprache des Dokuments Französisch (»fr«). Ein Absatz ist als Spanisch (»es«) deklariert; danach kehrt die primäre Sprache zu Französisch zurück. Der darauffolgende Absatz enthält eine eingebundene japanische Wendung (»ja«), danach kehrt die primäre Sprache zu Französisch zurück.

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML lang="fr">
<HEAD>
<TITLE>Un document multilingue</TITLE>
</HEAD>
<BODY>
...interpretiert als Französisch...
<P lang="es">...interpretiert als Spanisch...
<P>...wieder interpretiert als Französisch...
<P>...französischer Text unterbrochen von <EM lang="ja">etwas
         Japanisch</EM> hier beginnt wieder Französisch...
</BODY>
</HTML>
Anmerkung: Tabellenzellen können lang-Werte nicht von Eltern-Elementen erben, sondern erhalten sie von der ersten Zelle eines Bereiches. Einzelheiten finden Sie im Abschnitt 11.3.2 unter »Vererbung von Ausrichtungsangaben«.

8.1.3 Interpretation von Sprachcodes

Im HTML-Kontext sollten Benutzerprogramme einen Sprachcode eher als Hierarchie von Merkmalen interpretieren denn als einzelnes Merkmal. Wenn ein Benutzerprogramm seine Darstellungsweise gemäß einer Sprachinformation einstellt (sagen wir, durch Vergleich von Stylesheet-Sprachcodes und lang-Werten), sollte es immer exakte Übereinstimmung favorisieren, aber auch passende Primär-Codes als ausreichend ansehen. Ein Benutzerprogramm sollte also, wenn der Wert des lang-Attributs für das HTML-Eelement als »en-US« gesetzt ist, Style-Informationen, die zu »en-US« passen, den zum allgemeineren »en« passenden vorziehen.

Anmerkung: Sprachcode-Hierarchien garantieren nicht, dass alle Sprachen mit einem allgemeinen Präfix von denen ["von den Menschen"] verstanden werden, die eine oder mehrere dieser Sprachen beherrschen. Sie erlauben einem Benutzer, die allgemeinere Form anzufordern, falls dieser Fall [Nicht-Verstehen der Sprache] für den Benutzer vorliegt.

Anmerkung der Übersetzer:

Cockney ist eine Sprache, die in einigen Teilen von London gesprochen wurde beziehungsweise wird. Ein Benutzer, der »en-US« beherrscht, muss »en-cockney« nicht unbedingt verstehen. (Man stelle sich den Klischee-Texaner vor, der London besucht.) Der Benutzer sollte dann aber »en« anfordern können.

Die gängigen Web-Browser erlauben, eine sortierte Vorgabe der bevorzugten Sprachen anzugeben. Zum Beispiel Mozilla:

Sprachauswahl im Mozilla

8.2 Spezifizierung der Richtung von Text und Tabellen: das dir-Attribut

Attributdefinitionen

dir = LTR | RTL [CI]
Dieses Attribut spezifiziert die Basisrichtung von richtungsneutralem Text (d.h., von Text, der keine eigene Richtung, wie in [UNICODE] definiert, hat) im Inhalt eines Elements und Atributwerten. Es spezifiziert auch die Richtung von Tabellen. Mögliche Werte:
  • LTR: Text oder Tabelle, von links nach rechts zu lesen
  • RTL: Text oder Tabelle, von rechts nach links zu lesen

Zusätzlich zur Spezifizierung der Sprache eines Dokuments mit Hilfe des lang-Attributs kann es notwendig sein, dass Autoren die Basisrichtung (von links nach rechts oder von rechts anch links) für Teile des Textes eines Dokuments oder eine Tabellenstruktur usw. spezifizieren. Dies wird mit Hilfe des dir-Attributs erledigt.

Die [UNICODE]-Spezifikation ordnet Zeichen Richtung zu und definiert einen (komplexen) Algorithmus zur Bestimmung der geeigneten Richtung von Text. Wenn ein Dokument kein darstellbares von rechts nach links zu lesendes Zeichen (right-to-left character) enthält, ist es nicht erforderlich, dass ein konformes Benutzerprogramm den [UNICODE]-Bidirektional-Algorithmus anwendet. Wenn ein Dokument von rechts nach links zu lesende Zeichen enthält und das Benutzerprogramm diese Zeichen anzeigt, muss das Benutzerprogramm den Bidirektional-Algorithmus verwenden.

Obgleich Unicode spezielle Zeichen spezifiziert, die sich mit der Leserichtung befassen, bietet HTML höherwertige Auszeichnungskonstrukte an, die dasselbe tun: das dir-Attribut (nicht zu verwechseln mit dem DIR-Element) und das BDO-Element. Um ein hebräisches Zitat auszudrücken, ist es somit intuitiver, zu schreiben:

<Q lang="he" dir="rtl">...ein hebräisches Zitat...</Q>

als dasselbe mit Unicode-Verweisen:

&#x202B;&#x05F4;...ein hebräisches Zitat...&#x05F4;&#x202C;

Benutzerprogramme dürfen das lang-Attribut nicht verwenden, um die Leserichtung zu bestimmen.

Das dir-Attribut ist vererbt und kann überschrieben werden. Details finden Sie weiter unten im Abschnitt über die Vererbung von Informationen zur Leserichtung.

8.2.1 Einführung in den Bidirektionial-Algorithmus

Das folgende Beispiel illustriert das erwartete Verhalten des Bidirektional-Algorithmus. Es umfasst Englisch, eine von links nach rechts zu lesende Schrift, und Hebräisch, eine von rechts nach links zu lesende Schrift.

Betrachten Sie den folgenden Beispieltext:

  english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

Die Zeichen in diesem Beispiel (und in allen verwandten Beispielen) sind im Computer so gespeichert, wie sie hier gezeigt werden: Das erste Zeichen in der Datei ist »e«, das zweite »n« und das letzte »6«.

Wir setzen voraus, die vorherrschende Sprache des Dokuments, das diesen Absatz enthält, ist Englisch. Das bedeutet, die Basisrichtung verläuft von links nach rechts. Die korrekte Präsentation dieser Zeile wäre:

english1 2WERBEH english3 4WERBEH english5 6WERBEH
         <------          <------          <------
            H                H                H
------------------------------------------------->
                       E

Die gestrichelten Linien kennzeichnen die Struktur dieses Satzes: Englisch herrscht vor, etwas hebräischer Text ist eingebettet. Um die korrekte Präsentation zu erzielen, ist keine zusätzliche Auszeichnung erforderlich, weil die hebräischen Passagen von Benutzerprogrammen durch Anwendung des Bidirektional-Algorithmus korrekt umgekehrt werden.

Wenn andererseits hebräisch die vorherrschende Sprache des Dokuments ist, ist die Basisrichtung von rechts nach links. Die korrekte Präsentation hierfür:

6WERBEH english5 4WERBEH english3 2WERBEH english1
        ------->         ------->         ------->
            E                E                E
<-------------------------------------------------
                       H

In diesem Fall wurde der ganze Satz von rechts nach links darestellt und die eingebetteten englischen Passagen vom Bidirektional-Algorithmus richtig umgekehrt.

8.2.2 Vererbung von Informationen zur Leserichtung

Der Unicode-Bidirektional-Algorithmus erfordert eine Basistextrichtung für Textblöcke. Um die Basisrichtung eines Block-Level-Elements zu spezifizieren, setzen Sie das dir-Attribut des Elements. Der Standardwert des dir-Attributs ist »ltr« (von links nach rechts zu lesender Text).

Wenn das dir-Attribut für ein Block-Level-Element gesetzt ist, ist es für dieses Element bis zu dessen Ende und für alle eingeschlossenen Block-Level-Elemente wirksam. Das Setzen des dir-Attributs für ein eingeschlossenes Element überschreibt den ererbten Wert.

Um die Basistextrichtung für ein ganzes Dokument zu setzen, setzen Sie das dir-Attribut im HTML-Element.

Beispiel:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
   "http://www.w3.org/TR/html4/strict.dtd">
<HTML dir="RTL">
<HEAD>
<TITLE>...ein von rechts nach links zu lesender Titel...</TITLE>
</HEAD>
...von rechts nach links zu lesender Text...
<P dir="ltr">...von links nach rechts zu lesender Text...</P>
<P>...wieder von rechts nach links zu lesender Text...</P>
</HTML>

Andererseits erben Inline-Elemente das dir-Attribut nicht. Das heißt, ein Inline-Element ohne dir-Attribut eröffnet hinsichtlich des Bidirektional-Algorithmus keine zusätzliche Einbettungsebene. (Ein Element wird hier in Abhängigkeit von seiner Standardpräsentation als Block-Level- oder Inline-Element betrachtet. Beachten Sie, dass das INS- und das and DEL-Element in Abhängigkeit vom Kontext Block-Level- oder Inline-Elemente sein können.)

8.2.3 Setzen der Richtung von eingebettetem Text

Der [UNICODE]-Bidirektional-Algorithmus kehrt eingebettete Zeichenfolgen gemäß ihrer eigenen Richtung automatisch um (wie im vorangegangenen Beispiel gezeigt). Im Allgemeinen kann jedoch nur eine Einbettungsebene berücksichtigt werden. Um zusätzliche Ebenen eingebetteter Richtungswechsel zu erzeugen, müssen Sie in einem Inline-Element vom dir-Attribut Gebrauch machen.

Betrachten Sie dasselbe Beispiel wie zuvor:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

Wir setzen voraus, die vorherrschende Sprache des Dokuments, das diesen Absatz enthält, ist englisch. Außerdem enthält der obige englische Satz einen hebräischen Abschnitt, der sich von HEBREW2 bis HEBREW4 erstreckt, und der hebräische Abschnitt enthält ein englisches Zitat (english3). Die gewünschte Darstellung des Textes ist diese:

english1 4WERBEH english3 2WERBEH english5 6WERBEH
                 ------->
                    E
         <-----------------------
                    H
------------------------------------------------->
                    E

Um zwei eingebettete Richtungswechsel zu erreichen, müssen wir zusätzliche Informationen verwenden. Das tun wir, indem wir die zweite Einbettung explizit begrenzen. In diesem Beispiel verwenden wir das SPAN-Element und das dir-Attribut, um den Text auszuzeichnen:

english1 <SPAN dir="RTL">HEBREW2 english3 HEBREW4</SPAN> english5 HEBREW6

Autoren können auch spezielle Unicode-Zeichen benutzen, um mehrfach eingebettete Richtungswechsel zu erreichen. Um Links-nach-rechts-Einbettung zu erzielen, schließen Sie den eingebetteten Text in die Zeichen LEFT-TO-RIGHT EMBEDDING (»LRE«, hexadecimal 202A) und POP DIRECTIONAL FORMATTING (»PDF«, hexadecimal 202C) ein. Um Rechts-nach-links-Einbettung zu erzielen, schließen Sie den eingebetteten Text in die Zeichen RIGHT-TO-LEFT EMBEDDING (»RTE«, hexadecimal 202B) und PDF ein.

Verwendung der HTML-Richtungs-Auszeichnung mit Unicode-Zeichen: Autoren und Entwickler von Autoren-Software sollten sich bewußt sein, dass Konflikte auftreten können, wenn das dir-Attribut in Inline-Elementen (einschl. BDO) gleichzeitig mit den entsprechenden [UNICODE]-Formatierungszeichen eingesetzt wird. Vorzugsweise sollte entweder das eine oder das andere exklusiv benutzt werden. Die Auszeichnungsmethode bietet eine bessere Gewähr für die strukturelle Integrität des Dokuments und mindert manche Probleme, wenn bidirektionaler Text mit einem einfachen Text-Editor bearbeitet wird; manche Software könnte jedoch geschickter im Umgang mit [UNICODE]-Zeichen sein. Wenn beide Methoden benutzt werden, sollte große Sorgfalt geübt werden, um eine saubere Verschachtelung von Auszeichnung und Richtungseinbettung und -überschreibung zu sichern. Anderenfalls sind die Darstellungergebnisse undefiniert.

Anmerkung der Übersetzer:

Der oben erwähnte Konflikt besteht in dem Widerspruch, der auftreten kann, wenn auf Zeichenebene die Richtung links-nach-rechts (zum Beispiel mit dem genannten Zeichen an Position 202A) angegeben wird, gleichzeitig das dir-Attribut den Wert »RTL« besitzt.

8.2.4 Überschreiben des Bidirektional-Algorithmus: das BDO-Element

<!ELEMENT BDO - - (%inline;)*          -- I18N BiDi over-ride -->
<!ATTLIST BDO
  %coreattrs;                          -- id, class, style, title --
  lang        %LanguageCode; #IMPLIED  -- language code --
  dir         (ltr|rtl)      #REQUIRED -- directionality --
  >

Start-Tag: erforderlich, End-Tag: erforderlich

Attributdefinitionen

dir = LTR | RTL [CI]
Dieses zwingende Attribut spezifiziert die Basisrichtung für den Text-Inhalt des Elements. Diese Richtung überschreibt die eigene Richtung von Zeichen wie in [UNICODE] definiert. Mögliche Werte:
  • LTR: Text oder Tabelle, von links nach rechts zu lesen
  • RTL: Text oder Tabelle, von rechts nach links zu lesen

An anderer Stelle definierte Attribute

Der Bidirektional-Algorithmus und das dir-Attribut genügen im Allgemeinen, um eingebettete Richtungswechsel zu handhaben. Es könnten jedoch einige Situationen entstehen, in denen der Bidirektional-Algorithmus eine inkorrekte Darstellung bewirkt. Das BDO-Element gestattet Autoren, den Bidirektional-Algorithmus für ausgewählte Textpassagen auszuschalten.

Betrachten wir ein Dokument, das denselben Text enthält wie eben:

english1 HEBREW2 english3 HEBREW4 english5 HEBREW6

nehmen jedoch an, dass dieser Text bereits in visueller Reihenfolge vorliegt. Ein Grund dafür kann sein, dass der MIME-Standard ([RFC2045], [RFC1556]) visuelle Reihenfolge begünstigt, z.B., dass von rechts nach links zu lesende Zeichenfolgen von rechts nach links in den Bytestrom aufgenommen werden. In EMail könnte der obige Text -- Zeilenwechsel einbezogen -- so formatiert werden:

english1 2WERBEH english3
4WERBEH english5 6WERBEH

Das kollidiert mit dem [UNICODE]-Bidirektional-Algorithmus, weil dieser Algorithmus 2WERBEH, 4WERBEH, und 6WERBEH ein zweites Mal umkehren und so die hebräischen Wörter von links nach rechts darstellen würde anstatt von rechts nach links.

Die Lösung in diesem Fall ist, den Bidirektional-Algorithmus dadurch zu überschreiben, dass man den EMail-Auszug in ein PRE-Element setzt (zur Erhaltung der Zeilenumbrüche) und jede Zeile in ein BDO-Element, dessen dir-Attribute auf LTR gesetzt ist:

<PRE>
<BDO dir="LTR">english1 2WERBEH english3</BDO>
<BDO dir="LTR">4WERBEH english5 6WERBEH</BDO>
</PRE>

Das sagt dem Bidirektional-Algorithmus »Lass mich von links nach rechts!« und würde die gewünschte Darstellung erzeugen:

english1 2WERBEH english3
4WERBEH english5 6WERBEH

Das BDO-Element sollte in Szenarien verwendet werden, in denen absolute Kontrolle über die Reihenfolge gefordert ist (z.B. mehrsprachige part numbers). Das dir-Attribut ist zwingend für dieses Element.

Autoren könne auch spezielle Unicode-Zeichen verwenden, um den Bidirektional-Algorithmus zu überschreiben -- LEFT-TO-RIGHT OVERRIDE (202D) oder RIGHT-TO-LEFT OVERRIDE (hexadecimal 202E). In beiden Fällen beendet das Zeichen POP DIRECTIONAL FORMATTING (hexadecimal 202C) das Überschreiben.

Anmerkung: Erinnern Sie sich, dass Konflikte auftreten können, wenn das dir-Attribut in Inline-Elementen (einschl. BDO) gleichzeitig mit den entsprechenden [UNICODE]-Formatierungszeichen eingesetzt wird.

Bidirektionalität und Zeichenkodierung: Gemäß [RFC1555] und [RFC1556] gibt es spezielle Konventionen für die Verwendung von »Zeichensatz«-Parameterwerten, um bidirektionale Behandlung in MIME-Mail zu kennzeichen, insbesondere zur Unterscheidung zwischen visueller, impliziter und expliziter Richtung. Der Parameterwert »ISO-8859-8« (für Hebräisch) heißt visuelle Kodierung, »ISO-8859-8-i« heißt implizite Bidirektionalität und »ISO-8859-8-e« heißt explizite Richtung.

Weil HTML den Unicode-Bidirektional-Algorithmus verwendet, müssen unter Verwendung von ISO 8859-8 kodierte konforme Dokumente als »ISO-8859-8-i« ausgewiesen sein. Explizite Kontrolle der Richtung ist auch mit HTML möglich, kann aber nicht mit ISO 8859-8 ausgedrückt werden, deswegen sollte »ISO-8859-8-e« nicht verwendet werden.

Der Wert »ISO-8859-8« impliziert, dass das Dokument visuell formatiert ist, einige Auszeichnungen dabei missbrauchend (wie TABLE mit Rechtsbündigkeit und ohne Zeilenumbruch), um eine verständliche Darstellung durch ältere Benutzerprogramme, die Bidirektionalität nicht behandeln, zu gewährleisten. Solche Dokumente entsprechen nicht der gegenwärtigen Spezifikation. Wenn erforderlich, können sie zur aktuellen Spezifikation konform gemacht werden (und gleichzeitig werden sie von älteren Benutzerprogrammen korrekt dargestellt werden), indem, wo nötig, BDO-Auszeichnungen hinzugefügt werden.Im Gegensatz zu dem, was in [RFC1555] und [RFC1556] gesagt wird, kommt bei ISO-8859-6 (Arabisch) keine »Visual«-Reihenfolge zum Einsatz.

Anmerkung der Übersetzer:

Die letzte Bemerkung bezüglich arabischer Kodierung wird verständlich, wenn man in den beiden genannten RFCs nachliest: »Visual« wird dort (RFC 1556) definiert als Anzeigemodus, bei dem die primäre Anzeigerichtung (links nach rechts) für die Zeichenreihenfolge und die Darstellung verwendet wird. Der Modus ist unabhängig davon, welche Inhaltsrichtung den Daten zugrundeliegt. Das bedeutet, dass das Benutzerprogramm die Zeichen in der Reihenfolge anzeigen kann, in der die Bytes bei ihm eintreffen. Bei Sprachen, die von rechts nach links schreiben, werden die Texte also »von hinten nach vorne« (links nach rechts) angezeigt. Das Autorenwerkzeug muss sich darum kümmern, die von rechts nach links eingegebenen Zeichen in anderer Reihenfolge abzuspeichern.

8.2.5 Zeichenreferenzen für die Richtung und für die Steuerung von Verbindungen (joining control)

Da manchmal Mehrdeutigkeiten bezüglich der Richtung bestimmter Zeichen enstehen (z.B. Zeichensetzung), enthält die [UNICODE]-Spezifikation Zeichen, die eine korrekte Entscheidung ermöglichen. Unicode enthält auch einige Zeichen, um, wenn erforderlich, das Verhalten in Bezug auf die Verbindung von Zeichen zu steuern (z.B. in einigen Fällen arabischer Buchstaben). HTML 4 beinhaltet Zeichenreferenzen für diese Zeichen.

Der folgende DTD-Auszug zeigt einige der Richtungs-Entities (directional entities):

   <!ENTITY zwnj CDATA "&#8204;"--=zero width non-joiner-->
   <!ENTITY zwj  CDATA "&#8205;"--=zero width joiner-->
   <!ENTITY lrm  CDATA "&#8206;"--=left-to-right mark-->
   <!ENTITY rlm  CDATA "&#8207;"--=right-to-left mark-->

Das zwnj-Entity wird verwendet, um das Verbinden in Umgebungen zu verhindern, in denen es durchgeführt werden würde, jedoch nicht durchgeführt werden soll. Das zwj-Entity bewirkt das Gegenteil; es erzwingt das Verbinden, wenn es nicht durchgeführt werden würde, jedoch durchgeführt werden soll. Zum Beispiel wird der arabische Buchstabe »HEH« als Abkürzung des islamischen Kalendersystems »Hijri« benutzt. Da die alleinstehende Form von »HEH« aussieht wie die Ziffer fünf in arabischer Schrift (basierend auf indischen Ziffern), wird, um Fehldeutungen von »HEH« als letzte Ziffer fünf einer Jahreszahl vorzubeugen, die ursprüngliche Form von »HEH« benutzt. Wie dem auch sei, es gibt keinen folgenden Kontext (z.B. einen vebindenden Buchstaben) mit dem das »HEH« verbunden werden kann. Das zwj-Zeichen liefert diesen Kontext.

Ähnlich gibt es in persischen Texten Fälle, in denen ein Buchstabe, der normalerweise in einer kursiven Verbindung mit einem nachfolgenden stehen würde, dies nicht tun sollte. Das Zeichen zwnj wird verwendet, um das Verbinden in diesen Fällen zu verhindern.

Die anderen Zeichen lrm und rlm werden benutzt, um für richtungsneutrale Zeichen eine Richtung zu erzwingen. Wenn zum Beispiel ein doppeltes Anführungszeichen zwischen einem arabischen (von rechts nach links) und einem lateinischen (von links nach rechts) Buchstaben steht, ist die Richung des Anführungszeichens nicht klar (Bezieht es sich auf den arabischen oder auf den lateinischen Text?). Die Zeichen lrm und rlm haben eine Richtungseigenschaft, jedoch keine Breiten- und Wort- bzw. Zeilenumbrucheigenschaft. Detaillierte Informationen finden Sie unter [UNICODE].

Gespiegelte Zeichenglyphen: Im Allgemeinen spiegelt der Bidirektional-Algorithmus Zeichenglyphen nicht, sondern lässt sie unangetastet. Ausnahmen bilden Zeichen wie runde Klammern (siehe [UNICODE], Tabelle 4-7). Wird eine Spiegelung gewünscht, beispielsweise für ägyptische Hieroglyphen, das griechische Bustrophedon oder spezielle Designeffekte, sollte dies über Stil-Vorgaben (styles) geregelt werden.

8.2.6 Die Wirkung von Stylesheets auf die Bidirektionalität

Im Allgemeinen ist die Verwendung von Stylesheets zur Änderung der visuellen Wiedergabe eines Elements von Block-Level zu Inline oder umgekehrt unkompliziert. Da der Bidirektional-Algorithmus jedoch auf die Unterscheidung zwischen Inline- und Block-Level baut, sollte die Umwandlung mit besonderer Sorgfalt geschehen.

Wenn ein Inline-Element, das kein dir-Attribut besitzt, durch ein Stylesheet in den Stil (style) eines Block-Level-Elements transformiert wird, erbt es das dir-Attribut von seinem nächstliegenden Eltern-Block-Element, um die Basisrichtung des Blocks festzulegen.

Wenn ein Block-Eelement ohne dir-Attribut durch ein Stylesheet in den Stil eines Inline-Elements transformiert wird, sollte die resultierende Darstellung in Bezug auf die bidirektionale Formatierung äquivalent zu der Formatierung sein, die durch explizites Hinzufügen eines dir-Attributs (Zuweisung des ererbten Wertes) zum transformierten Element erzielt wird.