[Allegro] d-wrtf

[Thomas Berger]

Lieber Herr Osterhus, liebe Liste,

> ich habe mir die aktuelle d-wrtf.apr aus dem svn-Verzeichnis geholt. Früher

[ist identisch mit der aus dem Gesamtpaket: 17.2.2012]


> (bis Jan. 2011 ?) war es so, dass man mit F5 das interne Format in CPI-Schrift
> (Allegro Lucida Console) angezeigt bekam. Jetzt nicht mehr. Ohne

In der Demodatenbank ist das ebenfalls so. Herr Lehmann hat vorhin ja
schon die Stelle identifiziert. Dokumentiert ist dies in vb233, die
Frage ist, ob die Oktober 2010 eingefuehrte Variable #uFS nun in neueren a99
beim Start nicht mehr automatisch initialisiert wird, ob sich irgendeiner
der Start-Flexe geaendert hat, der sonst fuer die Voreinstellung
gesorgt hat, oder ob die d-wrtf.apr erst deutlich nach 2010 auf
diese Aenderung angepasst wurde und das Manko daher erst jetzt auffaellt.


> Allegro-Schriften gab es Courier New. Bei den Exemplarsätzen gab es
> spaltengerechte Einträge. Das ist auch nicht mehr der Fall. Ich habe schon alle

Stimmt. Bei etwa v29.8 war es noch eine Festpunktschrift (klein und fett)


> möglichen Varianten der Bearbeitung der XXXHEAD-Dateien ausprobiert. Hilft
> nichts. Spaltenungerechte Einträge sind für den Pragmatiker OK (Hauptsache die
> Infos stimmen), lassen sich aber an eine an iPhone und iPad geschärfte Ästhetik
> nicht gut verkaufen. Wie sind spaltengerechte Einträge in Exemplarsätzen möglich
> ? Das ist fast schon eine kantische Fragestellung. Nicht ganz, denn eine
> notwendige Bedingung gibt es hier ja nicht. Ich kann auch (noch) ganz gut mit
> der älteren d-wrtf leben.

Geaendert hat sich in der d-wrtf.apr irgendwann in den letzten Jahren die
explizite Einstellung der Festpunktschrift fuer gewisse (an dieser Stelle
uebriggebliebene) Satzarten:

    Satztypen differenziert behandeln: (Sprungverteiler)
#t{ "{ \f1 \fs18 " C }  Schrift allegro Letter Gothic


(d-wrtf.apr, ab ca. Zeile 100): Ueber \f1 wird die Schrift geaendert, mit
\fs18 eine bestimmte Groesse eingestellt. Ich erinnere mich an Ueberarbeitungen
in den letzten Jahren, die alle diese Groesseneinstellungen aus den Anzeige-
parametern herausgenommen haben: Der Anwender soll ja ueber das Menue
mit "Anzeigeschrift +" bzw. "Anzeigeschrift -" das selber beeinflussen koennen.
D.h. fuer das entfallene \fs18 gibt es eine starke Motivation, fuer das
gleich mit entfallene \f1 erst mal keine Motivation.

Allerdings sollte man natuerlich vorzugsweise mit Tabulatoren arbeiten,
wenn man Buendigkeit erreichen will und nicht mit Festpunkt-Schriftarten.
Die Behandlung der tabellenartigen Aufbereitung von Exemplardaten ist
also durchaus verbesserungswuerdig.

[Das "Zoom" ueber Veraenderung der Schriftgroesse ist allerdings im
Anzeigefeld insgesamt problematisch: Denn gerade wenn man mit Tabs
statt mit Auffuellung von Leerzeichen arbeitet, muessten die proportional
mitwandern, denn sonst kickt irgendwann das zu breit gewordene Label
den Text auf die naechste Tab-Position. Tab-Positionen sind aber
traditionell invariant unter Schriftgradveraenderungen, d.h. Zoom geht
anders und der derzeitige Weg taugt nur fuer eher kleine Aenderungen]


> Es stellt sich auch die Frage, ob man nicht mal mit einer Allegroversion
> arbeiten kann, die 6 oder 12 Monate alt ist. Und hinterm Horizont, wo es gemäß
> alten Bardengesängen bekanntermaßen immer weiter geht, lauert schon OpenSource.
> Wer weiß, was das alles kostet. Der öffentliche Dienst ist da ja stets etwas
> harthörig. Schaumermal !

Ich habe mit Anwendern zu tun gehabt, die 18 Jahre mit derselben Allegro-Version
gearbeitet haben (dann schlug ein bislang unentdeckter Bug der eingesetzten
Version 12.1 zu). Das Problem ist allerdings, dass viele Anwender nicht nur
gerne Fehlerkorrekturen haetten, sondern auch echte Verbesserungen und
Funktionalitaetserweiterungen erwarten, bis hin zu (behutsamen) Erweiterungen
im Datenformat (aufgrund ausserallegrotischer Umstaende stagniert da seit
mehreren Jahren allerdings alles auch anderswo).

Folge sind allerdings oft Veraenderungen des Bestehenden, selbst wenn es
"eigentlich nur" Folgen von Fehlerkorrekturen an anderer Stelle sind. Manche
Veraenderungen fallen gar nicht auf, andere waeren vermeidbar gewesen
(es stellt sich dann die Frage, ob sie korrigierenswert sind), fuer dritte
gibt es verborgene Notwendigkeiten und manchmal wird auch ohne Not ein
Bereich aufgeraeumt oder ueberarbeitet und die Optik veraendert sich.

Es ist erwuenscht, dass Anwender Irritationen und Fehler (scheinbare oder
empfundene - alles egal, alles verdient Beachtung) melden, aber einen
Bestandsschutz, also das Recht, von allen Veraenderungen verschont zu werden
*und* gleichzeitig in den Genuss aller wichtigen(?) Fehlerkorrekturen
zu kommen, gibt es beim Allegro-Abo-Modell nicht. Anderswo hingegen ist
das Geschaeftsmodell natuerlich genau so: Sie "kaufen" eine Version und
bekommen fuer Ihre Wartungsgebuehren nur die essentiellsten Fehlerkorrekturen
eingebaut. Die naechste Version duerfen Sie dann (mit Rabatt, als "Upgrade")
ebenfalls kaufen. Wenn Ihnen die Veraenderungen da nicht gefallen, duerfen
Sie auf die vorige Version downgraden oder - gegen Geld - die aktuelle
Version speziell nach Ihren Beduerfnissen "zurueck" anpassen. Wenn Sie das
erste zu oft machen, haben Sie verloren, weil die alte Version irgendwann
nicht mehr supportet wird. Wenn Sie das zweite zu oft machen, sind Sie
schnell pleite. Und selbst wenn nicht, wird sich irgendwann die Frage
stellen, ob die Energie, die Sie ins beharren stecken, nicht anderswo
besser einzusetzen waere.

*Mit* allegro OpenSource laesst sich auch dieses Geschaeftsmodell
implementieren, die simultane (Minimal-)Pflege auch aelterer Versionen
ist allerdings ein gewisser Aufwand, der ueber das derzeit geleistete
(immer nur vorwaerts: die aktuelle Version ist die einzige) hinaus
geht. Einen Markt fuer "erwiesen stabile allegro-Versionen" duerfte
es durchaus geben, aber eigentlich gehen ja viele Anwender (vermutlich
auch Sie?) durchaus zweigleisig vor: Executables regelmaessig
aktualisieren, Parameterdateien eher nicht. Bei allegro-HANS ist es
witzigerweise genau umgekehrt: Anwender aktualisieren haeufig die
Parameterdateien, verharren hingegen gerne lange bei Executables,
die sich als "macht keinen Aerger" erwiesen haben.

viele Gruesse
Thomas Berger