[Trennmuster] Entscheidungsmuster für Binnen- und Schluss-S in Frakturschriften
Guenter Milde
milde at users.sf.net
Mo Feb 6 22:55:57 CET 2012
On 6.02.12, Stephan Hennig wrote:
> Am 05.02.2012 20:31, schrieb Guenter Milde:
> > On 3.02.12, Stephan Hennig wrote:
> >
> >> Ich vermute, eine Verquickung von Substitution (Lang-s) und Trennung
> >> wären nicht die Art von Regeln, die Taco bisher im Blick hat.
> >
> > Eine Verquickung ist auch nicht nötig. Nötig ist, daß der Trennalgorithmus
> >
> > * für jedes Wort "angeschmissen" werden kann (ohne daß es dazu über die
> > Zeile hinausragen muß). Für einen in Lua implementierten Trennalgorithmus
> > bedeutet dies, daß er mit einer Lua-Funktion aufzurufen sein sollte. Da
> > sehe ich kein Problem.
> >
> > [...]
> Das geht in die Richtung eines speziell auf die deutsche Sprache
> abgestimmten Pakets.
Eine *Schnittstelle* zum Trennalgorithmus, welche für ein übergebenes
Wort die Trennstellen berechnet und zurückgibt ist zunächst
sprachunabhängig.
(Da die *Trennregeln* sprachabhängig sind, muß der Trennalgorithmus die
Sprache des Wortes kennen. Vorschlag für die Grundeinstellung:
die aktuelle Spracheinstellung zum Zeitpunkt des Aufrufs.)
> Ich weiß nicht, ob das Trennen beliebiger Wörter
> in LuaTeX heute schon möglich ist. Falls das so wäre, ...
> > * Alle Trennstellen des übergebenen Wortes zurückliefert und dabei nach
> > Haupt- und Nebentrennstellen unterscheidet.
> ... könnte man dies durch mehrfaches Trennen mittels verschiedener
> Trennmuster erreichen, die jeweils eine bestimmte Klasse von Trennungen
> repräsentieren.
... zum Beispiel.
Wie der Trennalgorithmus intern arbeitet, ist für die Lang-ſ-Schreibung
egal.
Eine Trennung mit Beachtung der Haupt- und Nebentrennstellen scheint
Taco durchaus im Blick zu haben:
OpenTaal (https://en.wikipedia.org/wiki/OpenTaal) has started an
initiative with several other groups and individuals such as Taco
Hoekwater and László Németh to support hyphenation patterns for
compounds (as used in German, Dutch, Afrikaans, Greek, Russion and more
languages) and to fix some other bugs.
-- [tex-hyphen] Improving hyphenation support for compounds
> Ich denke allerdings, dass Hans und Taco, wenn sie schon etwas einbauen,
> an einer allgemeinen Lösung interessiert sind, die auf Seiten der
> Sprachanpassung möglichst wenig Aufwand erfordert (sprich, im
> entsprechenden Paket sollte möglichst wenig Lua-Kode nötig sein) und von
> der verschiedene Sprachen gleichermaßen profitieren.
Denkst Du hier an internationale automatische Lang-ſ-Schreibung?
Wie groß ist der Bedarf außerhalb der deutschen Sprache?
Ich denke wir müssen ganz klar zwischen der automatischen Silbentrennung
und der s-ſ-Wandlung unterscheiden.
Silbentrennung:
* ein Muß in allen europäischen Sprachen,
* bereits implementiert als Teil des Umbruchs,
* Angewendet nur auf Wörter, die über den Textbereich ragen,
* verbesserungsbedürftig (Haupt- Nebentrennstellen, Wichtung,
zusammengesetzte Wörter)
Automatische s-ſ-Wandlung:
* ein Muß, wenn ein Dokument wahlweise in Antiqua oder Fraktur gesetzt
werden soll,
* wünschenswert für einfache Eingabe und vertrautes Aussehen des
Quelldokuments wenn nur in Fraktur gesetzt werden soll.
* Angewendet auf alle Wörter.
* Kann als pre-processing der Quelldatei (über eine Funktion des
Text-Editors oder über einen Wrapper um den latex-Aufruf) erfolgen.
* In LuaTeX wäre auch eine Wandlung im Rahmen eines Text-Input-"hooks"
denkbar.
Ein wesentlicher Vorteil des integrierten "trennmusterbasierten
ſ-Algorithmus" wäre, daß nach Definition zusätzlicher Trennmuster im
Vorspann (\hyphenation{Vos=berg Mess=sig-nal Dreh=impuls=erhal-tung%
Gleich=gewichts=pro-zes-se In-duk-ti-ons=ter-me}) diese auch für die
s-ſ-Wandlung verwendet werden können.
> Explizite ſ-s-Muster scheinen mir hier ein bewährtes Konzept
> aufzugreifen.
Für eine "deutsch-lang-s" Rechtschreibprüfung oder für die automatische
Ersetzung in einem "s2lang-s" Präprozessor sind aus einer Wortliſte
generierte s-ſ-Muster sicherlich gut geeignet.
Aber ich wünsche mir diese Wortliſte auf der Basis einer guten
Trennmusterliste, keine separat zu pflegenden ſ-s-Muster.
> Eine Einzellösung in Lua hätte zunächst allerdings den Vorteil, dass wir
> bei der Einarbeitung des langen/runden S zeitlich unabhängig von der
> LuaTeX-Entwicklung wären. Ich möchte dich da von nichts abhalten. Im
> Gegenteil.
Wenn unabhängig von LuaTeX, kann die Entwicklung des ſ-Algorithmus auch
weiter in Python erfolgen. Das ist (zumindest für mich) deutlich
einfacher und sollte auch ohne spezielle Python Kenntnisse gut lesbaren
Code ergeben.
Eine Umsetzung in Lua wäre sinnvoll, falls sich dann mehr Mitstreiter
fänden.
> Deshalb hier einige kurze Worte zum Duden Korrektor (DK)
...
> DK6 Duden (1996)
> In-dus-trie In-dust-rie
Duden 24. Aufl. (2006): In|dus|t|rie
> Zum interessanten Stil 'ästhetisch': Dieser scheint zusammengesetzte
> Wörter an Wortgrenzen zu trennen
> Tank-stellen-besitzer
> Es werden jedoch auch Prä- und Suffixe in einer Art und Weise getrennt,
> die ich nicht durchschaue
> Kinder-geburts-tag
> Ge-burts-tag
> un-ent-schieden
> un-befleckt
> Ich hänge am Ende eine kurze Liste an, die ich mit LibreOffice 3.5 RC3
> und DK6 über die Basic-API erstellt habe. Könnt ihr da ein System
> erkennen? (Die Zeichenkette ---- steht für Wörter, die nicht getrennt
> werden konnten.)
Mir erscheint der Stil "ästhetisch" genau das zu machen, was Werner mit der
Idee der "guten" Trennstellen angestrebt hat.
Ein Blick auf die angehängte Liste läßt mich vermuten, daß dies für meine
Suche nach "morphologischen" Trennstellen nicht die Lösung ist.
Man könnte natürlich spaßeshalber den Algorithmus über die Liste der
16 0000 "ungewichteten" und "offenen" Wörter laufen lassen, die wegen
fehlender Markierung von Vorsilben und Zusammensetzungen nicht automatisch
in die Lang-ſ-Schreibung gewandelt werden können. Kannst Du diese Listen mit
dem letztens geschickten Algorithmus selbst generieren oder soll ich sie
schicken?
> > Für die Bestimmung optimaler Trennstellen kann ein rückgewandeltes
> > Wort an den Trennalgorithmus übergeben werden, so daß keine
> > zusätzlichen Lang-ſ-Trennmuster erforderlich sind.
> Trennmuster mit langem S wären aber sinnvoll. Es gibt nämlich auch den
> Fall, dass Texte schon mit langem S geschrieben werden. Man könnte ſ
> natürlich auch dort zunächst in s umwandeln und das Wort so mit den
> bisherigen Mustern trennen. Der Rechenaufwand pro Zeichen im
> Eingabestrom wäre mit ſ-Mustern jedoch geringer. Da langes und rundes S
> ja gut mit den Trennregeln korrespondieren, sollte sich die Menge
> zusätzlicher Muster in Grenzen halten.
> Oder kann man bei der Trennung s irgendwie als LC-Kode für ſ deklarieren?
Da bin ich überfragt.
Vielen Dank,
Günter
Mehr Informationen über die Mailingliste Trennmuster