Re: [Frunge] Brechprogramm

[Arno Trautmann]

Martin Roppelt wrote:
> 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.

Ich brauch mit lua auf meinem Core2 Duo @1,6GHz ca. 90sec, um 10MB
Textdaten zeilenweise umzuformatieren. Nur, um auch mal ’ne Zahl in den
Raum geworfen zu haben.

>> 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 ;-).

Naja, der Vergleich mit MikTeX ist schon ein bisschen unfair. Ich
glaube, mit ConTeXt minimals zu vergleichen, wäre passender:

ConTeXt macro files are small (less than 10MB), but the minimals comes
with various free fonts which considerable increase the size of the
distribution to around 200MB).

> 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ß.

Na alſo :)

>> 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.

Da das Programm ja nicht abſolut leiſtungskritiſch iſt, würde ich eher
auf hohe Portabilität ſetzen als Leiſtungsopmitierung.

>>> 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)

Iſt halt leider nicht zuverläſſig, da die Liſte ja beſchränkt iſt. Aber
vermutlich die beſte Möglichkeit.

>> (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?

Was genau meinſt du jetzt? Du willſt mittels TeX die Erſetzungen
durchführen? Würde ich von abraten. TeX ſelbſt kann das ſchonmal nicht,
wegen utf8-Unfähigkeit.
Eine Möglichkeit wäre natürlich, das in lua zu fabrizieren und mittels
LuaTeX den Trennalgorithmus zu verwenden. Davon habe ich allerdings
mangels aktuellem TeXlive ſehr wenig Ahnung. Für realiſierbar halte ich
es aber.

>> 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??

dito.

>> ſ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 ;)

lol … ich merke, daſs ſich hier ein ganz eigener Sprachgebrauch
entwickelt ^^
Wie wäre es denn mit „antiquieren“ und moderniſieren“? ;)

>> 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.

Nebenbei: Macht Kapitälchenſatz da irgendwie Probleme? Oder gibt es
einfach das Mapping s⇒S, ſ⇒S? Was paſſiert dann mit ſs am Wortende als
Ligatur? Da wir die ja unterſcheiden wollten von ß, müſſte das auch im
Verſalſatz als Ligatur gegenüber dem ẞ getrennt ſein?

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

Vielleicht mal für einen erſten Teſt?

>  – immer langes s

Dieſer Kommentar verwirrt ;)

>  – 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!)

Klingt doch recht einfach. Bis auf die Anwendung von kurſiv. Wie bringt
man das einem Programm bei? In LuaTeX widerum könnte das dann ſehr
einfach ſein …

Gruſʒ
Arno

signature.asc
Description: OpenPGP digital signature