Re: [Frunge] Brechprogramm

[Martin Roppelt]

Dennis Heidsiek ſchrieb:
> Martin Roppelt ſchrieb am 22.09.2009 05:16 Uhr:
> >Aber dann sollte es auch mit einer annehmbaren Geschwindigkeit 
> >brechen. Wenn ich für 1 KB 1 Minute warten müsste, wäre mir das zu 
> >lang … ;)
> 
> Kann ich gut nachvollziehen, das würde mir auch ganz entſchieden auf 
> den Wecker gehen. Aber da bin ich wie geſagt etwas optimiſtiſcher … 
> bſpw. braucht mein Java-Programm eine Sekunde, um die UnicodeData.txt 
> (1.091 KB) einzuleſen und daraus die unicode.module (1.716 KB) zu 
> generieren (1.114.428.719 Nanoſekunden auf einem Intel Celeron 430 
> @1.8 GHz, um ›etwas‹ ;-) genauer zu ſein). Da ſehe ich jetzt nicht 
> wirklich Optimierungsbedarf.

1 s iſt abſolut akzeptabel.

> Man braucht tatſächlich erſt eine Java-Laufzeitumgebung (JRE), um 
> Java-Programme ablaufen zu laſſen. Unter Windows muſs ſich man ſich 
> dafür knapp 16 MB herunterladen, unter Linux (sudo apt-get install 
> openjdk-6-jre bei Debian) ſollte das ähnlich ſein. Ob das jetzt 
> beſonders viel oder beſonders wenig iſt, kommt wohl auf den 
> Vergleichsmaßſtab an … die Komplettinſtallation von MiKTeX belegt 1,33 
> GB auf meiner Feſtplatte, ſo geſehen iſt es alſo geradezu ein 
> ſchlankes Programm ;-).

Ok, hab mal bei Arch geſchaut (download/entpackt): perl 16/50 MB, 
python(3) 16/65 (15/66) MB, openjdk6 43/123 MB; iſt alſo in etwa 
gleich/doppelt ſo groß.

> Anſonſten enthält die GCC (GNU Compiler Collection) tatſächlich auch 
> einen Compiler für Java (gcj); praktiſch geſehen ſind die davon 
> produzierten ausführbaren Programme aber ungefähr gleich ſchnell und 
> gleich groß wie jar-Dateien (ſogar wesentlich größer, wenn es eine GUI 
> enthält und das ganze ›Toolkit‹ eingebettet werden ſoll). Zudem ſind 
> ſie – im Gegenſatz zu jar-Dateien – dann nicht mehr unter Windows oder 
> Apple ausführbar, weshalb in der Praxis eher ſelten auf dieſen Weg 
> zurückgegriffern wird.

Für meinen lokalen Computer aber durchaus eine Option.

> >So viel Programmlogik ist dafür bestimmt nicht nötig, eher eine gute 
> >Datenbank?
> 
> Sehr gute Frage! Das Problem bei einem primär Datenbank-baſiertem 
> Programm wäre wohl, daſs dieſe erſtmal erſtellt bzw. gepfegt werden 
> müſſte … weshalb ich da derzeitig eher zu einer Umſetzung der ſ/s

Stellen wir alſo mal s-Regeln auf:

 – Immer ſ, am Wort(!)ende s
 – vor d/k/m/n/w: s (tolle Regel weil ſie immer gilt) (laut BFDS)
 – Am Teilwortende s
 – vor Nachſilben s: -bar, -chen, -haft, -heit, -lein, -ler, -lich, 
-ling, -keit, -ismus, -tum, -ſchaft, … (Ergänzungsregel, falls das 
vorige nicht greifen ſollte)
 – bei Vorſilben (ſind eigentlich auch nur Teilwörter) s: di/e/ys-, 
trans-
 – es gibt kein ss, sss, ſſſ (dann wiſſen wir, es iſt etwas ſchief 
gelaufen)

Wie ſtellen wir feſt, ob
 – ein Teilwort vorliegt?
 – welches die Vor- und Nachſilben ſind? (OK, das iſt nicht ſo das 
Problem, die können wir zur Not in ein Array packen)

Hier empfiehlt ſich eine Teilwortliſte (der auf -s endenden Teilworte, 
da reduziert ſich das wieder, puh! :))! (Bitte beachten: Teilworte „ſind 
oft umgelautet oder verkürzt“, d.h. hier müſſen wir eine variable 
Notation (o.w.a.i.) finden: b{ö,o}ſ[e] (böſe, boshaft)

> (und Ligatur-Regeln) in Programmlogik tendiere. So gibt es bereits 
> eine freie Umſetzung des TeX-Silbentrennungsalgorithmus in Java; wenn

Hm, wir haben alſo als Einſatzgebiete:

 – Befehlsorientiert
 – Browſer/Mailer/alle anderen Programme
 – Textverarbeitung

Wie wärs auch mit TeX? Das können wir gleich wieder mit 
rückverbauen/eigenes Paket machen. Allerdings fühle ich abſolut nicht 
fähig dazu, TeX-Programmierung zu machen. Wie geht es euch?

> man den mit den überarbeiteten (freien) Trennmuſtern füttert, ſollte 
> man eigentlich ſchon eine recht gute Baſis haben (Schlussstrich -> 
> Schluss-strich → Schluſsſtrich bzw. Sluſsſtri). Wenn man dann noch 
> eine Ausnahmebehandlung für ſſ (aſ-ſe, iſ-ſe, üſ-ſe, aſ-ſt, uſ-ſt, 
> eſ-ſor, …) hinzufügt,

Kannſt du mir bitte erklären, wofür wir eine Ausnahmebehandlung für ſ-ſ 
brauchen??

> ſollte das eigentlich ſchon recht brauchbare Ergebniſſe liefern.
> 
> Obwohl … noch viel beſſer wäre es wohl, erſtmal den TeX-Algorihmus um 
> Hauptwort-Trennſtellen zu erweitern.
> 
> Aber wo wir grade dabei ſind: Gibt es irgendwo einen längeren, 
> einigermaßen aktuellen Text in garantiert korrekter 
> Frakturſchreibweiſe (etwa das Grundgeſetz)? Das wäre ein recht guter 
> Teſtfall – ›antiquieren‹

Warum nicht glätten? ;) Paſſt beſſer zu brechen. Und wenns glatt iſt, 
kann man das Fähnchen auch beſſer in den Wind hängen ;)

> und anſchließendes Brechen ſollte wieder den Originaltext ergeben.

Ich empfehle erſtmal unſer Pangramm (als Härteteſt). Einen garantiert 
regelgerecht geſetzten gebrochenen Text kann ich dir gerne ſchreiben.

Gruß,
 Martin

PS: Ich empfehle auch eine Umſetzung für das Engliſche, aber die iſt ja 
einfach:

 – immer langes s
 – am Wortende, vor Apoſtroph, vor und nach f: s
 – Bei Zeilentrennung immer ſ-
 – 17. Jahrhundert: s + k/b, 18. Jahrhundert: ſ + k/b
 – In kurſivem Text: ſſ → ſs (immer!)