[Trennmuster] Callbacks

[Stephan Hennig]

Am 15.10.20 um 20:35 schrieb Keno Wehr:
> Am 15.10.20 um 00:58 schrieb Stephan Hennig:
>> Am 12.10.20 um 22:10 schrieb Keno Wehr:
>>> Am 01.10.20 um 02:38 schrieb Stephan Hennig:
>>>> Ich dachte, luatexbase bzw. ltluatex würde die Callbacks exklusiv
>>>> reservieren (solange niemand dazuwischenfunkt) und dann verschiedenen
>>>> Interessenten geordneten Zugriff darauf gestattet.  Ist das nicht so?
>>>> Ich habe das nicht mehr parat.
>>> Im Prinzip ja, aber bei exklusiven Callbacks wie „hyphenate“ und
>>> „ligaturing“ kann nur eine Funktion angewandt werden.
>> Das würde den Zweck der Callback-Behandlung in ltluatex aber ad absurdum
>> führen.  Ein Vorteil gegenüber LuaTeX wäre dann ja nicht erkennbar.
> 
> Ja, du hast Recht. Ich habe jetzt den passenden Abschnitt in der 
> ltluatex-Anleitung gefunden:
> 5.18 Lua callback management
> 
> Dort wird allen Callbacks einer der Typen „list“, „data“, „exclusive“, 
> „simple“, „reverselist“ zugeordnet. Was diese Typen genau bedeuten, wird 
> leider nicht erklärt, auch in der LuaTeX-Anleitung nicht.

Da klingelt bei mir leider auch nichts.


> „hyphenate“ und „ligaturing“ sind „simple“ (was auch immer das genau 
> bedeutet). Jedenfalls war es eine Fehleinschätzung von mir, dass sie 
> exklusiv sind.
>
> [...]
> 
> Ich habe jetzt eine andere Kombination ans Laufen gekriegt: 
> „pdnm_hyph-mark-by-color.sty“ (farbliche Markierung der Buchstaben um 
> gewöhnliche Trennstellen, geändert von Latein auf Deutsch) und 
> „pdnm_non-std-hyph-de-1901.sty“ (Spezialtrennungen für die AR).
> Diese Kombination funktioniert in beliebiger Ladereihenfolge.

Schön zu hören, dass das funktioniert.


> Dass der Standardtrennalgorithmus dabei zweimal aufgerufen wird,
> scheint kein Problem zu sein.

Ich meine, mich daran zu erinnern, dass das irgendwo – vermutlich im
LuaTeX-Handbuch – auch erwähnt wird.  Kann aber auch ein Vortrag von Has
gewesen sein.


> „pdnm_hyph-mark-by-color.sty“ und „pdnm_hyph-mark-by-glyph.sty“ 
> manipulieren die Knotenliste offenbar in einer Weise, dass das jeweils 
> andere Paket nicht mehr damit klarkommt.
> Dass das Einfügen der Mittepunkte an den Trennstellen einen folgenden 
> Algorithmus zur farblichen Markierung von Trennstellen zerschießt, 
> leuchtet mir ein, da die Zeichenfolge im Wort verändert wird; bei 
> umgekehrter Reihenfolge ist mir aber unklar, wo das Problem liegt.

Das dürften Whatsit-Knoten sein.  Und die Worterkennung behandelt diese
derzeit vermutlich als Wortgrenze, so dass für den zweiten
Node-List-Scanner jede Silbe ein eigenes Wort bildet.



> Das konkrete Problem ist aber auch nicht so wichtig, da es zur 
> Markierung von Trennstellen bereits das Paket „showhyphens“ gibt, das 
> den Callback „post_linebreak_filter“ nutzt, wobei es sich zunutze macht, 
> dass die potentiellen Trennstellen (discretionary nodes) beim Umbruch 
> nicht entfernt werden.
> Wird „pdnm_non-std-hyph-de-1901.sty“ geladen, zeigt showhyphens auch die 
> Spezialtrennstellen an.
> 
> Kandidaten zur Veröffentlichung sehe ich in jenen Paketen also nicht.

Keno, das sind alles wirklich nur Beispiele zur Anwendung von
pdnm_nl_manipulation.lua bzw. padrinoma.sty, die nie zur
Veröffentlichung gedacht waren und eher den Charakter von Dokumention haben.



>> Keno, könntest du Probleme mit dem Callback-Management auf der
>> entsprechenden Liste (lualatex) zur Sprache bringen?
> 
> Die Problematik scheint sich erst mal geklärt zu haben.

Was nicht als "wegschicken" gemeint war, ich lese deine Funde sehr
interessiert.


> Für einen ersten CTAN-Upload würde ich ein Bündel namens padrinoma o. ä. 
> vorschlagen, das vier LaTeX-Pakete für die konkreten Anwendungen 
> bereitstellt, evtl. noch ein weiteres für die Bindestrichproblematik.

Mein Plan sieht etwas anders aus.  Ich habe hier lokal verbesserte Tests
für die Lua-Klassen geschrieben, die mir etwas Sicherheit geben, dass
eine Veröffentlichung auf CTAN nicht zu sofortigen Nachfragen/Bugreports
führt.  Vor einem Upload möchte ich aber noch die API-Dokumentation in
Ordnung bringen, das heißt von LuaDoc auf ldoc umstellen.  Das sollte
nicht allzu lange dauern.

Die Pakete, die du vorschlägst, würde ich weiterhin gern unabhängig von
padrinoma verteilt sehen.  Ich schlage deshalb vor, dass du dafür ein
neues Repositorium anlegst, welches nach und nach mit tatsächlichen
Anwendungen gefüllt wird.  Als Namen hätte ich autotype anzubieten
(automatic typography).


> Auf lange Sicht wäre eine Regelung über Optionen von babel und 
> polyglossia vorzuziehen.
> Die Muster sollten dagegen von dehyph bereitgestellt werden.

Bezüglich der Verteilung der Muster bin ich weiterhin ohne feste
Meinung.  Arthur hat dazu ja auch bereits etwas gesagt.  BTW, Arthur et
al., feel invited switching to English language anytime.


>>> Gewichtete Trennungen auf der Grundlage gewöhnlicher Trennmuster und
>>> Spezialtrennungen konkurrieren insofern nicht, als sie sich auf
>>> unterschiedliche Stellen im Wort beziehen; doch ist sicherzustellen,
>>> dass die durch den einen Algorithmus eingefügten Trennstellen das
>>> Einfügen durch den anderen Algorithmus nicht behindert. (Man beachte
>>> beispielsweise, dass „Abbauergebnis“ mit unseren Mustern
>>> „Ab-bau-ergeb-nis“ getrennt wird, „Abbau"-ergebnis“ mit expliziter
>>> Trennstelle hingegen das unerwünschte „Ab-bau-er-geb-nis“ ergibt).
>> Bei der Trennung von Wörtern mit Bindestrich sollten sowieso größere
>> hyphenmin-Werte verwendet werden.
> 
> Du hast mein Beispiel missverstanden. "- ist kein Bindestrich, sondern 
> eine explizite Trennstelle, die andere nicht ausschließt.

Ja, das habe ich übersehen.  Innerhalb autotype.sty sollte "- dann also
wirkungslos gemacht werden.


>> Eine andere Idee, nur weil sie mir einfällt:  Man könnte auch
>> verschiedene morphologische Trennmuster erstellen und dann mit dieser
>> Information die Entscheidung, ob eine Ligatur aufgebrochen werden muss
>> oder eine Lang-s-Ersetzung stattfinden muss, Lua-seitig vornehmen.  Von
>> der Laufzeit her wäre vermutlich kein Gewinn zu erwarten ...
> 
> Ich weiß nicht, was du hier sagen willst. Ist das nicht genau das, was 
> wir ohnehin vorhaben?

Ich meinte Muster, die nur die Information über die Art einer
Trennstelle tragen (-, <, >, = usw.), aus der dann erst innerhalb LuaTeX
regelbasiert abgeleitet wird, ob ein langes S zu setzen ist o. ä.  Für
die Dokumentation hätte das den Vorteil, dass die Regeln im Paketcode
formuliert wären.  Beim bisherigen Plan, fertige Muster für die stumpfe
Lang-S-Ersetzung zu erzeugen, sind diese Regeln nicht sichtbar, da nur
extern vorhanden/dokumentiert.

Nicht, dass ich das unbedingt so haben möchte.  Aber die Überlegung
führt mich dahin, dass wir Mustern für eine stumpfe Ersetzung die
Regeln, denen sie folgen, zur Dokumentation beilegen sollten.

Viele Grüße
Stephan Hennig