AW: AW: Unicode Methode 2: UTF-8 intern

[Thomas Berger]

Lieber Herr Habisch,

> Die 'Jahresberichte für deutsche Geschichte' stellen den Titel
> 
> "Klaipÿedos kra·sto mokykl¸u draugijos istorija ... Kult¯uros zurnalo
> "Santara"..."
> 
> so dar:
> 
> "Klaipedos kra¹to mokyklu draugijos istorija ... Kulturos ¾urn. "Santara..."
> 
> Die Buchstaben '¹' und '¾' sind als Einzelzeichen im Ostwest-Font enthalten,
> nicht aber 'ì' und 'ù'. Man lässt also bei den Jahresberichten einfach die
> diakritischen Zeichen weg, wenn die entsprechenden Buchstaben nicht als
> Einzelzeichen im Ostwest-Zeichensatz vorkommen.

Das ist vermutlich eine Erfassungsangelegenheit der Jahresberichte.

Gegenbeispiel: Wenn Sie eine Stichwortsuche nach "latv*" machen,
so zeigt die Kurzliste die Verfasser "Berzins, Valdis" und
"Kazocns, Indulis" mit "n mit Punkt untergesetzt" (definitiv nicht
kombiniert in Ostwest enthalten), die Vollanzeige jedoch zeigt
ein Kloetzchen vor dem "n".

Der Grund ist, dass fuer die Darstellung der Kurzanzeige ein
Unterprogramm im CGI-Skript dafuer sorgt, Ostwest (-Windows,
wie es avanti liefert) nach UTF-8 oder HTML umzusetzen, fuer die 
Vollanzeige jedoch eine Allegro-Parameterdatei dafuer zustaendig 
ist, ostwest (-DOS) nach HTML umsetzt. Hier muss dann derzeit
eigentlich fuer jede in Ostwest denkbare Kombination eine globale 
Ersetzung die Zusammenfassung von Diakritikum und Grundbuchstaben 
uebernehmen, der OPAC der Jahresberichte hat dies derzeit noch
nicht.

Mit der Unicode-Methode 1 aus Verlautbarung 164 erhebt allegro
folgenden Anspruch auf Verbesserung:

- Die Parametrierbare Ausgabebearbeitung fuer "write" sollte
  sich (nicht getestet) auch auf die Kurzliste auswirken,
  d.h. das CGI-Skript kann hier schon - wie bei Vollanzeigen -
  korrekt (d.h. 1:1 an den Browser durchzureichende HTML-)
  formatierte Ausgben erwarten

- die neuen Befehle "set U" geben die Moeglichkeit, den Rueckweg,
  also die Umwandlung von UTF-8 (wie der Browser es bei geeigneter
  Einstellung Ihrer Seiten zurueckschickt) nach Ostwest(-Windows)
  von Eingaben vom CGI-Skript an avanti zu verlagern. [Zusammengenommen
  ist das also eine Situation, die es der CGI-Anwendung *erlaubt*,
  ignorant gegenueber Zeichencodierungsfragen zu sein, weil avanti
  und Webbrowser dasselbe sprechen]

- "dow accent" bzw. #dA vertauschen die Diakritika auf "unicode-
  gerechte" Positionen, das ist notwendig fuer die Kombinationen,
  die durch globale Ersetzungen *nicht* erwischt werden.

Fuer die erforderlichen Globalen Ersetzungen in der Parameterdatei,
die Ostwest-Mehrzeichenkombinationen auf Unicode/HTML4/XML-
Einzelzeichen umsetzen, gibt es bei Methode 1 keine Abkuerzung,
hier ist immer noch angesagt, sorgfaeltig eine moeglichst vollstaendige
Umsetzungstabelle herzustellen (von Ostwest nach UTF-8 bzw.
HTML4, die koennte fuer alle Allegro-Anwendungen genutzt werden,
die Ostwest als Grundlage haben, irgendwo habe ich das auch
rumliegen).

- Mit den VS-Sequenzen, ebenfalls aus Verlautbarung 164, koennten
  Sie theoretisch ueberlegen, ob Sie die interne Datenhaltung bei
  Zeichen, die Ostwest nur als Kombination kennt, auf HTML-
  Entitaeten umstellen: Ihre interne Anwendung wird bei Eingabe
  und Darstellung darunter leiden, Ihre WWW-Anwendung gewinnen.

- Die VS-Sequenzen koennen Sie auch benutzen, um definitiv ausserhalb
  der Darstellbarkeit von OSTWEST liegende Zeichen (etwa einzelne
  kyrillische Worte) zu erfassen, dies halte ich aber fuer
ausserordentlich
  muehsahm (ausser man kann sie aus externer Quelle als UTF-8 
  importieren und die Umwandlung in HTML-Entitaeten den neuen
  Funktionalitaeten der allegro-Module ueberlassen)


 
> Wir möchten aber die gleiche Anzeige bekommen, wie die litauische
> Nationalbibliothek, nämlich:
> 
> "Klaipìdos kra¹to mokyklù draugijos istorija"
> 
> Die Lösung dafür gibt es leider bei den Jahresberichten nicht. Bleibt also
> die Frage: Ist es möglich mit "P-Ersetzungen" mit Methode 1 zu diesem
> Ergebnis zu kommen?

P-Ersetzungen, wie jetzt als Methode 2 vorgeschlagen, gibt es fuer
Methode 1 selbstredend nicht. Die P-Ersetzungen wuerden ermoeglichen,
die Datenbank *intern* komplett auf UTF-8 umzustellen, das ist 
gewiss attraktiver als eine Osteuropa-spezfische Bastelei, etwa
die Umsetellung auf CP850 und dgl.

viele Gruesse
Thomas Berger