Konfiguration: Silbentrennung und Sprache

#Silbentrennung

Ist die Textausrichtung auf 'justify' gesetzt, verhindert die Silbentrennung übermäßige Wortabstände, indem sie lange Wörter an Silbengrenzen trennt. Die Engine findet natürliche Trennstellen an Silbengrenzen mit Mustern nach TeX/Liang. Eine ausführliche Erklärung finden Sie unter Silbentrennung und Blocksatz. Flattersatz wird nur getrennt, wenn Sie es verlangen: siehe Flattersatz weiter unten.

Unterstützte Sprachen: 'en-us' (Englisch), 'es' (Spanisch), 'fr' (Französisch), 'de' (Deutsch), 'it' (Italienisch), 'pt' (Portugiesisch), 'ca' (Katalanisch), 'nl' (Niederländisch).

Region-, Schrift- und Varianten-Subtags werden bei der Wahl der Muster ignoriert, ebenso Groß- und Kleinschreibung und Trenner _: 'es-ES', 'es-MX' und 'es_419' trennen mit 'es', 'pt-BR' mit 'pt' und jedes englische Tag ('en', 'en-GB') mit 'en-us' – den einzigen mitgelieferten englischen Mustern, britischer Text erhält also amerikanische Trennungen. Eine Sprache ohne mitgelieferte Muster ('sv', 'pl', 'fi' …) wird mit den Mustern von 'en-us' getrennt, was falsche Trennungen statt gar keiner ergibt; die Engine meldet das einmal pro Tag mit einem console.warn, und die Sandbox führt es in ihrem Bedienfeld „Prüfungen“ auf. Setzen Sie für ein solches Dokument enabled: false; das bringt auch die Warnung zum Schweigen. Chinesisch, Japanisch und Koreanisch (zh, ja, ko, gleich mit welcher Region oder Schrift) brauchen keine Muster und geben keine Warnung aus: Ein Dokument in einer dieser Sprachen wird ohne Silbentrennung gesetzt. Um die darin zitierten lateinischen Wörter zu trennen, setzen Sie enabled: true und nennen deren Sprache in locale ('en-us' für Englisch). enabled: true ohne locale oder mit einer chinesischen, japanischen oder koreanischen lässt die Silbentrennung aus und meldet das einmal auf der Konsole. matchHyphenationLocale(tag) gibt die mitgelieferte Sprache zurück, der ein Tag zugeordnet wird (undefined, wenn es keine gibt), und HYPHENATION_LOCALES listet die mitgelieferten auf. Die aufgelöste Konfiguration (doc.config.bodyText.hyphenation) nennt in locale die tatsächlich verwendeten Muster und behält in tag das von Ihnen angegebene Tag, wenn es abweicht. Das PDF-Backend deklariert die Dokumentsprache aus dem locale der obersten Ebene und nur dann aus diesem Tag, wenn locale nicht gesetzt ist (siehe Dokumentsprache).

import { matchHyphenationLocale } from 'postext';
 
matchHyphenationLocale('es-MX'); // 'es'
matchHyphenationLocale('en-GB'); // 'en-us'
matchHyphenationLocale('sv');    // undefined: hyphenated with 'en-us', with a console warning

Wörter mit weniger als 5 Zeichen werden nie getrennt. Die Engine verlangt mindestens 2 Zeichen vor und 3 Zeichen nach einer Trennstelle.

#Ungetrennte Wörter

Ein Wörterbuch trennt einen Namen wie jedes andere Wort: Al-ice, Áms-ter-dam, You-Tu-be. Drei Einstellungen halten Wörter ganz, und alle drei folgen standardmäßig dem Wörterbuch.

hyphenation.exceptions ist eine Liste von Wörtern wie \hyphenation{…} in TeX. Ein ohne Bindestrich geschriebener Eintrag wird nie getrennt; ein mit Bindestrichen geschriebener wird nur dort getrennt, sodass 'You-Tube' You- · Tube ergibt und sonst nichts. Ein Eintrag passt auf eine Folge von Buchstaben, gleich was darum steht: 'Alice' deckt (Alice, und Alice’s ab, und ein Kompositum wird Teil für Teil abgeglichen (Blender-based passt auf 'Blender'). Eine flektierte Form ist ein anderes Wort und braucht einen eigenen Eintrag. Ein kleingeschriebener Eintrag passt auf das Wort in jeder Schreibung ('blender' deckt Blender und BLENDER ab); ein Eintrag mit großem Anfangsbuchstaben passt nur auf die Vorkommen, die mit einem Großbuchstaben beginnen, sodass 'Rose' den Namen ganz hält und rose dem Wörterbuch überlässt. Einträge enthalten nur Buchstaben und Bindestriche; alles andere wird verworfen.

hyphenation.capitalized: false hält jedes Wort ganz, das mit einem Großbuchstaben beginnt: Namen, Akronyme und auch das erste Wort jedes Satzes. Es entspricht dem ausgeschalteten Schalter „Großgeschriebene Wörter trennen“ von InDesign und \uchyph=0 in TeX. Ein Eintrag in exceptions mit Bindestrichen trennt sein Wort weiterhin dort. Im Deutschen wird jedes Substantiv großgeschrieben, sodass der Schalter einem deutschen Text kaum ein trennbares Wort ließe: Nennen Sie dort die Wörter in exceptions oder verwenden Sie citations.hyphenateNames.

citations.hyphenateNames: false hält die Familiennamen der vom Dokument zitierten Autorinnen und Autoren ganz, wo immer sie stehen: in einem Zitat, im laufenden Text und im Literaturverzeichnis. Siehe Zitationen.

const config: PostextConfig = {
  locale: 'es',
  bodyText: {
    hyphenation: { exceptions: ['Ámsterdam', 'Blender', 'You-Tube'] },
  },
};

Die drei erreichen jeden Text, den das Wörterbuch trennt: Fließtext, Überschriften, Listen, Kästen, Legenden, Tabellenzellen, Anmerkungen, lebende Kolumnentitel und die übrigen Gestaltungstexte. Das ist mehr als bei compounds, das Legenden, Anmerkungen, Zellen und Inhaltsverzeichnis ignorieren. Zwei Dinge bleiben, wie sie sind. Ein in einem Vorkommen eines Worts getipptes weiches Trennzeichen entscheidet weiterhin über dieses Vorkommen, und ein weiches Trennzeichen vor dem ersten Buchstaben hält ein Vorkommen ohne Liste ganz (siehe Wo eine Zeile nie umbricht). Und ein Wort, das breiter als seine ganze Satzbreite ist, wird weiterhin getrennt: an den Stellen seines Eintrags, wenn es welche hat, sonst an den Silben des Wörterbuchs. Weniger getrennte Wörter lassen einer schmalen Blocksatzspalte weniger Möglichkeiten, ihre Zeilen zu füllen; prüfen Sie daher die Wortabstände, nachdem Sie capitalized auf einer dreispaltigen Seite ausgeschaltet haben. Das umfließende EPUB überlässt die Silbentrennung dem Lesesystem, das von diesen Regeln nichts weiß.

#Flattersatz

Standardmäßig wird nur Blocksatz getrennt: Mit textAlign: 'left' und in links, zentriert oder rechts gesetzten Absatzformaten bleibt jedes Wort ganz, wie stark die Kante auch flattert, außer an einem im Text getippten weichen Trennzeichen (U+00AD). Setzen Sie hyphenation.ragged: true, um auch Flattersatz zu trennen.

Eine Flattersatzzeile wird nie gedehnt, deshalb würde das Trennen jedes Worts, das nicht passt, die Kante mit Trennstrichen säumen. Die Trennzone begrenzt das, so wie es der Einzeilen-Setzer eines DTP-Programms tut. Passt ein Wort am Ende einer Zeile nicht, betrachtet die Engine die Lücke, die das ganze Wort auf der nächsten Zeile hinterließe. Ist diese Lücke breiter als zone, wird das Wort an der letzten passenden Silbe getrennt; sonst rückt es ganz hinunter. Eine Zone in em bezieht sich auf die eigene Schriftgröße des Texts. Der Standard 3em trennt nur die Wörter, die eine merklich kurze Zeile hinterließen. Eine breitere Zone ergibt weniger Trennstriche und eine stärker flatternde Kante; 0 trennt jedes Wort, das nicht passt. Beim zeilenweisen Setzen enden höchstens zwei Zeilen in Folge auf einer Silbe. Harte Bindestriche (enseñanza-aprendizaje), URL-Fugen, im Text getippte weiche Trennzeichen und Wörter, die breiter als die ganze Zeile sind, brechen wie immer um: Die Zone und die Grenze von zwei Zeilen gelten nur für die Silben des Wörterbuchs.

Die Einstellung gilt für das ganze Dokument. Sie wirkt auf Fließtext und Zitate, wenn sie im Flattersatz stehen, und auf jedes Absatzformat im Flattersatz und jeden Kastentext, deren eigenes hyphenation an ist (Standard ist hyphenation.enabled des Fließtexts); hyphenation: false hält also die Wörter eines Formats ganz. Überschriften, Legenden, Anmerkungen, Tabellenzellen und das Inhaltsverzeichnis werden nicht getrennt; dort wird, wie überall, nur ein Wort getrennt, das breiter als die ganze Satzbreite ist. Gestaltungstexte – lebende Kolumnentitel, Kapitelauftakte, Teiltitelseiten – folgen dem eigenen Schalter hyphenate jedes Textelements, den die eingebauten ganzseitigen Kapitelauftakte und Teiltitelseiten setzen, und verwenden ebenfalls das Wörterbuch des Dokuments. Blocksatz ignoriert ragged und zone.

const config: PostextConfig = {
  locale: 'es',
  bodyText: {
    textAlign: 'left',
    // A little more hyphenation than the 3 em default.
    hyphenation: { ragged: true, zone: { value: 2, unit: 'em' } },
  },
};

Mit optimalRagged (Standard) wird laufender Text im Flattersatz mit Knuth-Plass umbrochen, und die Zone behält dort ihre Bedeutung: Ein Wort wird nur getrennt, wenn es nicht in den Rest der Zeile passt und es ganz hinunterzuschicken mehr als die Zone leer ließe. Zwei Silben in Folge werden nicht verweigert, kosten aber so viel wie zwei Trennstriche in Folge im Blocksatz, sodass eine dritte selten ist. Mit optimalRagged: false oder optimalLineBreaking: false wird jede Zeile gefüllt, bevor die nächste beginnt, wie bis postext 1.4.

Die Silbentrennung im Flattersatz setzt Absätze mit dem Umbruchverfahren, das Absätze mit Inline-Formatierung (fett, kursiv, Links, Mathematik) immer verwenden; sie einzuschalten kann daher auch einige Umbrüche verschieben, die keine Trennungen sind. In einer Flattersatzzeile bricht dieses Verfahren neben Leerzeichen und den Silben des Wörterbuchs nach einem harten Bindestrich oder einem Strich zwischen zwei Wörtern um (largas—separadas; mit breakAfterDashes nach jedem Strich, der ohne Abstand zwischen Wörtern steht, auch riddles.—I und riddles—*and*), an URL-Fugen und zwischen Ideogrammen, und es hält ein in mehreren Abschnitten gesetztes Wort zusammen (**Nota**:, (*véase*). Ohne Silbentrennung im Flattersatz wird ein Flattersatzabsatz ohne Formatierung mit Knuth-Plass umbrochen, wenn optimalRagged an ist (Standard): an Wortzwischenräumen, nach einem harten Bindestrich zwischen zwei Buchstaben (meta- · analyses), wie es das andere Verfahren tut, und mit breakAfterDashes nach Strichen ohne Abstand. Zeile für Zeile gesetzt, durchläuft er das Umbruchverfahren von Pretext, das sich in drei Punkten unterscheidet: Es darf auch vor einem Strich umbrechen, der einen Einschub schließt, oder nach einem, der ihn eröffnet (él · — y), beim Trennen nach einem Schrägstrich (km/ · h), und es schneidet ein Wort, das breiter als die Zeile ist, an einem beliebigen Zeichen ohne Trennstrich, wo das andere Verfahren es zuerst an einer Silbe trennt.

In der Sandbox heißt der Schalter Flattersatz trennen; er steht unter der Absatzausrichtung im Abschnitt „Grundtext“, mit der Zone darunter. Bei Fließtext im Blocksatz steht derselbe Schalter bei den Blocksatzeinstellungen, für die Absatzformate und Kästen im Flattersatz.

#Dokumentsprache

Das locale der obersten Ebene ist die Sprache des Dokuments als Ganzes. Es nimmt dieselben Werte wie hyphenation.locale an und dient als Ersatz, wenn dieses Feld nicht gesetzt ist; ein spanisches Buch braucht also nur locale: 'es', um spanisch zu trennen. Es wählt auch die Sprache der eingebauten Fortsetzungstexte von Tabellen und geteilten Kästen ((cont.) / Continued gegenüber Continúa, siehe Tabellen, die höher als die Seite sind und Hinweise an einem geteilten Kasten) und der ausgeschriebenen Überschriftennummern (Chapter One gegenüber Capítulo uno, siehe Ausgeschriebene Zahlen) und ist die Sprache, die in ein barrierefreies PDF getaggt wird. Ohne Wert nimmt die Engine 'en-us' an; die Sandbox fällt auf die Sprache der Oberfläche zurück und setzt das Feld unter Gestaltung › Schriftsystem.

Es wählt auch die eingebauten Ressourcentypen. Ist resourceTypes nicht gesetzt, nummeriert und beschriftet buildDocument mit defaultResourceTypes(locale), sodass locale: 'de' allein Abbildung 1.1 und Tabelle 1.1 ergibt. Ist locale nicht gesetzt, vertritt es die Sprache der Silbentrennung, für die Ressourcentypen wie für die Tabellentexte. Eine ausdrückliche Liste resourceTypes hat immer Vorrang. Frühere Versionen verwendeten die englischen Typen, gleich welches locale galt, es sei denn, Sie übergaben selbst defaultResourceTypes(locale); ein Dokument, das locale setzt und die englischen Bezeichnungen behalten will, übergibt resourceTypes: defaultResourceTypes('en'). Bücher und Pakete der Sandbox bringen ihre eigene Liste mit und sind daher nicht betroffen.

Jedes BCP-47-Tag funktioniert hier wie in hyphenation.locale: 'de-AT' erhält die deutschen Texte. Die eingebauten Texte gibt es in den acht Sprachen, die die Silbentrennung unterstützt, in Chinesisch (in vereinfachten und in traditionellen Schriftzeichen), in Japanisch und in Arabisch; jede andere Sprache erhält die englischen.

Chinesisch nimmt zh, zh-Hans, zh-Hant, zh-CN, zh-SG, zh-TW, zh-HK, zh-MO und die langen Formen (zh-Hant-TW) an, in jeder Schreibung und mit - oder _. Die Texte folgen der Schrift, gelesen mit Intl.Locale(tag).maximize(): zh, zh-CN und zh-SG sind vereinfacht, zh-TW, zh-HK und zh-MO traditionell. Die typografischen Standardwerte, die von der Sprache abhängen, folgen dagegen der Region, wie es clreq §1.2 empfiehlt: CN, SG und MY zählen als Festland, TW als Taiwan, HK und MO als Hongkong, und ein Tag ohne Region richtet sich nach seiner Schrift (zh-Hant ist Taiwan, zh und zh-Hans das Festland). Japanisch nimmt ja, ja-JP, ja-Jpan und jedes andere Tag ja an (isJapaneseLanguage(tag)); seit postext 1.16 hat es eigene Texte und eine eigene Region, japan, deren typografische Standardwerte JLReq folgen (siehe Japanischer Satz). Eine Tabelle von Texten ohne japanischen Eintrag liefert Englisch, nie Chinesisch. localeScript(tag), cjkRegionOf(tag), stringsKeyOf(tag) und sameContentLocale(a, b) liefern diese Lesarten, und DOCUMENT_LANGUAGES listet die Sprachen mit eingebauten Texten, jede in ihrer eigenen Sprache benannt (日本語 zwischen den chinesischen Einträgen und العربية), so wie die Auswahl „Dokumentsprache“ der Sandbox sie zeigt.

Das Präfix der Legende ist der Name des Typs (Abbildung 1.1.). Die chinesischen Typen nummerieren innerhalb des Kapitels mit einem Bindestrich, {h1}-{n} (图 1-1); mit den Legendeneinstellungen labelNumberGap: '' und labelSeparator: '　' lautet die Legende 图1-1　标题 (siehe Legendenstil). Auch das Register folgt der Sprache: 见 und 另见 vor einem Querverweis, 符号 und 数字 über den Symbolen und den Zahlen in vereinfachten Schriftzeichen; 見, 另見, 符號 und 數字 in traditionellen. Japanisch nummeriert seine Typen ebenso und setzt seine Legenden ohne die beiden Einstellungen als 図1-1　題, schreibt Querverweise als 第3章, 2.3節 und 12ページ, betitelt das Literaturverzeichnis mit 参考文献, und sein Register druckt 記号 und 数字 über Symbole und Zahlen und schreibt seine Querverweise mit einem Pfeil, →夏目漱石 für siehe und →夏目漱石、森鷗外も見よ nach den Seitenzahlen für siehe auch, die Bezeichnungen aufrecht. Arabisch nummeriert seine Typen ebenso, {h1}-{n} (شكل 2-3), schreibt Querverweise als الفصل 3, القسم 2-1 und ص 12, betitelt das Literaturverzeichnis mit المراجع, und sein Register druckt انظر / انظر أيضًا, رموز und أرقام, mit dem arabischen Komma und Semikolon (، ؛).

Ein chinesisches, japanisches oder koreanisches Dokument deklariert seine Sprache in der HTML-Ausgabe (lang auf der Wurzel .pt-doc, zh-Hant-TW ungekürzt) und auf dem Canvas, den es malt (ctx.lang, in Chrome 136 und neuer), sodass der Browser die Glyphenformen der Region zeichnet: Unicode vereinheitlicht die Han-Zeichen, und ein Codepoint sieht in einer taiwanischen und in einer japanischen Schrift verschieden aus. Seit postext 1.30 tut das auch jedes andere Dokument, in der Sprache, in der sein Text geformt wird (bodyText.shapingLanguage: 'document', der Standard); mit 'host' tragen die übrigen Dokumente kein lang, und jeder Canvas malt in der Sprache der Seite, die ihn einbettet. Das PDF deklariert für jedes Dokument, getaggt oder nicht, /Lang aus locale, mit Schrift und Region. Ein Dokument in einer Sprache, die von rechts nach links geschrieben wird (Arabisch, Persisch, Urdu, Hebräisch …), deklariert seine Sprache ebenfalls: Die Sprachformen der Schrift (locl) und die Ersatzschrift folgen ihr.

const config: PostextConfig = {
  locale: 'es',
  bodyText: { textAlign: 'justify', hyphenation: { enabled: true } }, // hyphenates in Spanish
};

#Ziffern des Dokuments

numerals auf oberster Ebene legt die Ziffern jeder Zahl fest, die die Engine schreibt: Seitenzahlen und die Seitenangaben von Inhaltsverzeichnis, Register und Seitenverweisen; Nummern geordneter Listen und Fußnoten; Zähler von Überschriften und Kapiteln, {chapterNumber}; {h1} und {n} einer Abbildungsnummer und eines Verweises darauf; {totalPages}, {bookTotalPages} und {numberDecimal}. 'latn' schreibt 0–9, 'arab' die arabisch-indischen Ziffern ٠–٩ und 'arabext' die persischen Ziffern ۰–۹. Nur das Dezimalformat ändert sich – decimal, arabic der Listen oder eine auf dem Standard belassene Einstellung –, sodass ein vom Autor genanntes Format wie genannt gedruckt wird: lower-roman bleibt i, ii, iii, und arabic-indic schreibt auch in einem lateinischen Dokument ١, ٢, ٣. Der Text des Dokuments wird nie umgeschrieben.

Der Standard 'auto' nimmt die Ziffern von locale (defaultNumeralsFor(tag)): 'arab' für Arabisch ohne Region oder mit einer Region außerhalb des Maghreb (ar, ar-EG, ar-SA, ar-AE …), 'latn' für ar-MA, ar-DZ, ar-TN, ar-LY, ar-MR und ar-EH, 'arabext' für Persisch (fa), Paschtu (ps) und das Urdu Indiens (ur-IN) und 'latn' für alles andere, das Urdu Pakistans eingeschlossen. CLDR gibt latn für ein bloßes ar und für ar-AE an; arabische Bücher des Maschrek und der Golfstaaten drucken ٠–٩, und dem folgt Postext. Ein Tag, das seine Ziffern nennt, behält sie: ar-MA-u-nu-arab. Eine in den Ziffern des Dokuments nummerierte Seite speichert arabic-indic oder persian als ihr pageNumberFormat, sodass die Seitenbezeichnungen des PDFs dieselben Ziffern zeigen. Ein unbekannter Wert folgt der Sprache und wird als unknownNumerals gemeldet.

Zahlen, die der Autor tippt, werden in jedem der drei Systeme gelesen: Ein Listenpunkt ٣. beginnt bei 3, und {startAt=٥}, :::numbering{startAt=٥}, :::space{lines=٢} und :::part{number="٣"} (für {numberDecimal}) lesen den Wert.

const config: PostextConfig = { locale: 'ar' };                     // ١، ٢، ٣
const maghreb: PostextConfig = { locale: 'ar-MA' };                 // 1, 2, 3
const forced: PostextConfig = { locale: 'ar', numerals: 'latn' };   // 1, 2, 3

#Schreibrichtung

direction auf oberster Ebene legt die Grundrichtung des Dokuments fest: 'ltr', 'rtl' oder 'auto' (Standard), das 'rtl' ist, wenn die Schrift von locale von rechts nach links geschrieben wird (Arabisch, Persisch, Urdu, Hebräisch, Syrisch, Thaana, N’Ko, Adlam …, gelesen mit directionOf(tag)), und sonst 'ltr'. Ein Dokument von rechts nach links wird in einem gespiegelten Rahmen gesetzt: Seine Zeilen beginnen rechts, seine erste Spalte ist die rechte, seine Einzüge, Listenmarken, Gleitobjekte, Fußnoten und Kästen stehen rechts, und page.binding: 'auto' bindet es rechts. Die aufgelöste Konfiguration trägt direction: 'rtl' nur für ein solches Dokument, sodass ein Dokument von links nach rechts wie bisher aufgelöst wird. Ein unbekannter Wert wird als 'auto' gelesen und als unknownConfigValue gemeldet. Der Unicode-Bidi-Algorithmus (UAX #9) ordnet die Abschnitte jeder Zeile in beiden Richtungen: Ein arabisches Zitat in einem englischen Buch liest sich an Ort und Stelle von rechts nach links.

Innerhalb des Dokuments nimmt eine Überschrift oder ein Container ::: {dir=ltr} oder {dir=rtl} an, und die Inline-Auszeichnungen :ltr[…] und :rtl[…] isolieren einen Textabschnitt (siehe Schreibrichtung in der Auszeichnung); eine Tabellenressource nimmt table.direction an. Ein Block, der gegen die Richtung des Dokuments gesetzt ist, behält seine eigene Anfangsseite: Sein Einzug, seine Listenmarken und das bündige Ende seiner letzten Zeile wechseln auf die Seite, an der sein Text beginnt.

Eine Einstellung, die eine Seite nennt, meint eine Seite des Texts oder des Textflusses, nie des Bogens, sodass eine für ein englisches Buch gemachte Gestaltung funktioniert, wenn das Buch auf Arabisch umgestellt wird. 'start' und 'end' werden als ausdrückliche Namen angenommen:

placement.rotate behält auf einer gespiegelten Seite seine physische Bedeutung: Eine im Uhrzeigersinn gedrehte Abbildung ist auf dem Bogen im Uhrzeigersinn gedreht. Ein Host, der das Layout liest, findet auf jeder Seite den gespiegelten Rahmen (VDTPage.flow mit direction: 'rtl', pageIsMirrored(page)) und die visuelle Reihenfolge der Segmente jeder Zeile in VDTLine.order; flowToPage und pageToFlow rechnen zwischen Textfluss und Bogen um. Siehe Arabischer Satz.

const arabic: PostextConfig = { locale: 'ar' };                        // right to left, bound on the right
const english: PostextConfig = { locale: 'en', direction: 'rtl' };     // forced; rarely what you want

#Sprachen und Schriftsysteme

Postext setzt alphabetische Schriften, die von links nach rechts geschrieben werden, sowie Chinesisch und Japanisch quer über die Seite und von oben nach unten. Chinesischer Satz und Japanischer Satz erklären, wie sie gesetzt werden und welche Einstellungen sie steuern; die Schlüssel stehen unter Ostasiatische Typografie, Vertikale Schrift und Bindung. Was jedes Schriftsystem erhält:

• Chinesisch wird vom CJK-Setzer gesetzt, wenn ein Absatz mehr CJK-Zeichen als Wortzwischenräume enthält: Seine Zeilen brechen zwischen Zeichen um, nach den Regeln für Zeilenanfang und -ende von cjk.lineBreak (keine Zeile beginnt mit 。、」 oder ー, keine endet mit 「 oder （), halten —— und …… sowie eine Zahl mit ihren Zeichen und ein lateinisches Wort ganz, und eine Blocksatzzeile wird zwischen ihren Zeichen auf die Satzbreite verteilt. Breiten der Satzzeichen, hängende Satzzeichen, der Abstand zwischen Han und Latein, das Zeichenraster, Betonungspunkte, die Markierungen für Eigennamen und Buchtitel, Ruby und Warichu-Anmerkungen folgen der Region von locale, quer über die Zeile oder an ihr hinab (layout.writingMode: 'vertical-rl'). Ein lateinischer Absatz, der ein paar CJK-Wörter zitiert, behält den optimalen Zeilenumbruch und darf neben ihnen umbrechen; eine CJK-Klammer, der Mittelpunkt oder ein Vollbreitenzeichen in lateinischem Text (〈h〉, ％) ändert nichts.
• Japanisch durchläuft seit postext 1.16 denselben Setzer mit eigenen Regeln, denen der W3C-Requirements for Japanese Text Layout (JLReq) und von JIS X 4051: Ein ja-Locale ergibt die Region japan, deren automatische Werte die Kinsoku-Stufen von JLReq setzen (kleine Kana und ー eröffnen nie eine Zeile), Satzzeichen in voller Breite mit Paarstauchung, ein Geviert nach ？！, die Klammer, die einen Absatz eröffnet, in der zweiten Hälfte des Einzugs, Sesam-Betonungszeichen über dem Text, Buchtitel in 『』, Furigana im Verhältnis 1:2:1, japanische Zählwörter, Anmerkungen und ein nach Lesung sortiertes Register. Frühere Versionen setzten Japanisch mit den Standardwerten für das chinesische Festland.
• Koreanisch durchläuft denselben Setzer und wird ohne Silbentrennung gesetzt, aber mit den Standardwerten für das chinesische Festland: Seine eigenen Regeln (KLREQ) sind nicht umgesetzt. Koreanischer Text bricht zwischen Silben wie auch an seinen Leerzeichen um.
• Arabisch und andere Schriften von rechts nach links (Persisch, Urdu, Hebräisch …) werden von rechts nach links gesetzt: Arabischer Satz erklärt, wie. Die direction des Dokuments ergibt sich aus der Schrift von locale, der Unicode-Bidi-Algorithmus ordnet die lateinischen Wörter und Zahlen in jeder Zeile, das Buch wird rechts gebunden, mit seiner ersten Spalte rechts, und jede Zahl, die die Engine schreibt, nimmt die Ziffern der Region an. Ein Wort mit einem Buchstaben in arabischer Schrift wird nie getrennt, gesperrt oder geschnitten, und eine arabische Blocksatzzeile wird an ihren Leerzeichen und mit Kaschidas gedehnt. Vokalzeichen, Hervorhebung, Fußnoten und die Texte des Arabischen stehen unter Arabischer Text. Persisch, Urdu und Hebräisch erhalten die Richtung, die Ziffern und die Regeln für ganze Wörter, aber keine eigenen eingebauten Texte.

Trennmuster werden für acht Sprachen mitgeliefert (en-us, es, fr, de, it, pt, ca, nl); die eingebauten Ressourcentypen und Fortsetzungstexte gibt es in diesen acht, in Chinesisch, in Japanisch und in Arabisch. Chinesisch, Japanisch, Koreanisch und die Sprachen, die von rechts nach links geschrieben werden, werden ohne Silbentrennung gesetzt. Jede andere Sprache wird mit den Mustern für US-Englisch getrennt, mit einer Warnung auf der Konsole, und erhält die englischen Texte. Setzen Sie für ein solches Dokument hyphenation.enabled: false und übergeben Sie resourceTypes und die Fortsetzungstexte von tableStyle in seiner Sprache.

#Arabischer Text

Diese Einstellungen dienen Text in arabischer Schrift; keine ändert ein Dokument in einer anderen Schrift. Arabischer Satz erklärt sie zusammen mit dem Rest eines arabischen Buchs: Richtung, Bindung, Ziffern, Vers, Inhaltsverzeichnis und Register.

• Vokalzeichen und Zeilenabstand. Die Vokalzeichen eines vokalisierten Texts (Fatha, Kasra, Schadda, Tanwīn, das hochgestellte Alif, die koranischen Zeichen) stapeln sich über und unter den Buchstaben, im Zeilenabstand, der für sie nie wächst. Jede Zeile mit Zeichen speichert, wie weit deren Farbe reicht (VDTLine.markInk), und der Spaltenzuschnitt der Renderer schließt die Zeichen der ersten und letzten Zeile einer Spalte ein. Trifft ein Zeichen über einem Wort auf die Buchstaben oder Zeichen, die unter dem Wort darüber hängen, meldet der Build den Absatz (arabicMarksExceedLeading, im Bedienfeld „Prüfungen“ der Sandbox). Nur übereinanderstehende Wörter werden verglichen. Teilweise vokalisierter Text braucht etwa 1,7–1,85 em lineHeight, voll vokalisierte Verse 1,9–2,1 em.
• Hervorhebung. Arabische Schrift kennt keine Kursive, daher wird *…* in einem Dokument, dessen locale in arabischer Schrift geschrieben wird, standardmäßig fett gesetzt (bodyText.emphasis: 'auto'). 'color' setzt es aufrecht in italicColor, und 'overline' zieht eine Linie über die Wörter, das khaṭṭ fawqī arabischer Bücher. Die Einstellung erreicht jeden Text, der in den Schriften des Fließtexts gesetzt wird: Absätze, Listen, Zitate, Absatzformate, Kastentexte, Anmerkungen und Überschriften. Legenden, Tabellenzellen, Inhaltsverzeichnis und Register behalten ihre eigenen Kursiveinstellungen. Was auch gewählt ist, die Engine neigt nie arabische Buchstaben: Die arabischen Wörter eines kursiv gesetzten Abschnitts stehen aufrecht, seine lateinischen Wörter behalten ihre Kursive. Ein Zitat ist in einem solchen Dokument standardmäßig aufrecht.
• Taschkīl. bodyText.tashkil: 'strip' entfernt die Vokal- und koranischen Zeichen aus dem Text, den das Layout setzt, für eine unvokalisierte Ausgabe aus einer vokalisierten Quelle: Fatha, Damma, Kasra und ihr Tanwīn, Sukūn, Schadda, das hochgestellte Alif (هٰذا wird zu هذا) und die Zeichen U+0656–U+065F und U+06D6–U+06ED. 'strip-vowels' behält die Schadda, wie die meisten modernen Bücher sie drucken. Hamza und Madda bleiben (أ إ آ sind Buchstaben, auch wenn sie mit kombinierenden Zeichen getippt werden). Die Quelle behält ihre Zeichen; die Zeilen, die Überschriften und das Inhaltsverzeichnis werden ohne sie gesetzt, und jedes gesetzte Zeichen verweist weiterhin auf seine Stelle in der Quelle.
• Fußnoten. footnotes.markerTemplate: '({n})' schreibt die Marken «(١)» in den Ziffern des Dokuments, numbering: 'page' beginnt sie auf jeder Seite neu, und noteNumberPosition: 'inline' setzt die eigene Nummer der Anmerkung auf die Zeile. Die Trennlinie und die Anmerkungsnummern stehen am Anfang der Spalte, in einem Buch von rechts nach links also rechts.
• Ganze Wörter. Ein Wort mit einem Buchstaben in arabischer Schrift wird nie getrennt, geschnitten oder gesperrt, weder in einem arabischen Buch noch als Zitat in einem anderen. Ein Format, das letterSpacing auf arabischen Text setzt, wird gemeldet (joiningScriptLetterSpacing), und ein Wort, das breiter als seine Zeile ist, läuft über sie hinaus und wird gemeldet (unbreakableWordOverflow). Siehe Arabischer Satz.
• Kaschida und Vers. Eine arabische Blocksatzzeile wird mit Kaschidas wie auch an ihren Leerzeichen gedehnt (bodyText.kashida, siehe Kaschida in arabischem Text), und ein klassisches Gedicht wird mit :::verse ein Bayt pro Zeile in zwei gleich breiten Halbversen gesetzt (siehe :::verse).
• Register. Ein Register auf Arabisch sortiert alphabetisch und ignoriert den Artikel ال (index.ignoreArticle), die Vokalzeichen und die Träger der Hamza; siehe Register.