allegro news Nr.48

wünscht die news-Redaktion allen Lesern, die bis zu dieser Nummer durchgehalten haben. Vermutlich würden einige AnwenderInnen lieber auf einer brandneuen CD-ROM die "news"-los funktionierende Windows-Version auf dem Gabentisch vorfinden - leider zu früh gefreut. Wir beschreiben aber in dieser Ausgabe verschiedene Entwicklungen, aus denen schon im ersten Halbjahr 1998 eine neue CD-Lieferung hervorgehen wird. Dazu wird auch ein weiter ausgebautes PRESTO für Win’95 und NT gehören. Diese Nummer wird hoffentlich dennoch eine willkommene Festtagsgabe sein, weil sie eine umfassende Zusammenstellung der verschiedensten Eingabe-Erleichterungen enthält. Ein namhafter allegrologe, Herr Berger aus Bonn, hatte kürzlich auf einer Tagung konstatiert, daß "allegro über so viele Eingabe-Erleichterungen verfügt, daß niemand sie alle anwendet; hingegen gibt es Anwender, die keine einzige davon kennen!" Nun denn, diesem Mißstand gebührt Abhilfe, welche auf den Seiten 2-6 geleistet wird. Das zweite größere, aber leidige Thema dieser Nummer sind die Zeichensätze.

Wenn nach der allegro-Bilanz 1997 gefragt wird, sind die folgenden Punkte zu nennen:

Der "Reifungsprozeß" der V15 hat inzwischen zu einigen kleineren Verbesserungen und zur Behebung von Randproblemen geführt. In dieser Nummer werden alle diese Korrekturen beschrieben. Im ersten Halbjahr 1998 wird eine neue CD-ROM erscheinen, auf der dann die gereifte V15 mit weiter verbesserten Standardparametern enthalten sein wird, dazu aber auch die ersten Windows-Programme, die nicht mehr als "Beta-Version" bezeichnet werden müssen.

Immer mehr greift die Erwartung um sich, daß benutzerfreundliche Software "intuitiv" gestaltet sein sollte. Das bedeutet, alle Funktionen, Optionen und Aktionen sollen auf direkt verständliche, plausible Weise realisiert und möglichst mit Mausklick auszulösen sein. Jeder weiß, daß dies mit allegro noch nicht so ist. (Nicht jeder weiß, daß es auch z.B. mit Microsoft-Produkten nicht so ist - man braucht sich nur den Umfang der gedruckten Literatur dazu anzuschauen.)

Deshalb wird hier der Versuch gemacht, einmal alles zusammenzustellen, was es an Möglichkeiten gibt, sich die Eingabe und Bearbeitung von Daten zu erleichtern. Diese Übersicht können Sie als Ergänzung und teilweise auch Hinführung zum Handbuch und zur Ouvertüre betrachten. Alles wird zwar in jenen Büchern in geeigneten Zusammenhängen behandelt, und wir weisen auf die Stellen auch hin, aber diese Stellen sind verstreut und nicht immer leicht zu finden.

Es ist klar: sobald ein Windows-Ersatz für PRESTO kommt, wird vieles anders aussehen und es wird auch noch andere Erleichterungen geben, die man unter DOS nicht programmieren konnte. In der Nummer 47 hatten wir schon die Wünsche genau beschrieben, die in einem Windows-Editor (EBOX) realisiert werden sollten. In der Nummer 49 werden wir sehr wahrscheinlich erste einsatzfähige Module vorstellen können. Weil jedoch nicht jeder unmittelbar auf Windows ’95 oder NT umsteigen kann (für Windows 3 wird es die neuen Programme nicht geben!), bleiben die nachfolgenden Darstellungen für viele Anwender noch auf absehbare Zeit wichtig.

Die für Handbuch und Ouverüre angegebenen Seitenzahlen beziehen sich auf V15, die Kapitelnummern stimmen auch für ältere Ausgaben. Die Darstellung ist hier ganz knapp gehalten, es werden aber vorzugsweise Fakten genannt und Tips gegeben, die nicht so allgemein bekannt sind.

Um noch einmal auf den Vorwurf der mangelnden Intuitivität zurückzukommen: man versuche einmal, die nachfolgend beschriebenen Dinge jeweils in wenigen Worten klar, unmißverständlich und für jedermann sofort verstehbar zu formulieren und/oder sich ein graphisches Symbol dafür auszudenken. In einigen Dingen wird das gehen und wird auch kommen. Wo das aber nicht gelingt, sind Zweifel angebracht, ob denn eine intuitive Programmgestaltung überhaupt zu machen ist. Und führt nicht Intuition ohne Sachkenntnis so leicht in den Irrtum wie Glaube ohne Skepsis in den Aberglauben?

Die Symbole J K L haben naheliegende Bedeutungen:

J : dieser Punkt ist für jede Datenbank sofort und von jedem leicht einsetzbar

K : geringe, einfache Vorbereitungen sind evtl. nötig

L : Parametrierkenntnisse werden gebraucht.

Diese Einteilung bezieht sich aber nur auf das Einrichten solcher Mittel und Maßnahmen! Ist das einmal geleistet, ist die praktische Anwendung in jedem Fall sehr leicht. Eigentlich heißt L , daß die Methode besonders viel bringt, dafür muß man oder jemand aber auch zuerst etwas tun.

Wenn Sie diese Auflistung als zu abstrakt empfinden, ziehen Sie den Abschnitt 0.9.1 im Handbuch mit heran! Unter der Überschrift "Schnelle Antworten auf häufige Fragen" finden Sie vielleicht einen besseren Einstieg.

Nicht alles kann durch künstliche Intelligenz vereinfacht werden. Für gewisse Dinge ist der bibliothekarische Fachverstand des Anwenders gefordert. Die Katalogisierungsregeln sind z.B. nicht gezielt für Online-Kataloge, sondern mehr für Zettelkataloge entwickelt worden. Vielleicht werden deshalb, aber auch aus anderen Gründen, unnötige Einzelheiten erfaßt - deren Abschaffung spart mehr Zeit als jede denkbare Erleichterung ihrer Eingabe. Das sind Dinge, die außerhalb der Kompetenz eines Computers liegen! Entscheidungen darüber müssen im Vor- und Umfeld fallen.

Fremddaten sind ein großes Thema für sich. Enorme Ersparnisse können erzielt werden, wenn man möglichst viele Dokumente gar nicht selber erfassen muß, sondern Titelaufnahmen komplett aus anderen Quellen übernehmen kann. Es sind Beispiele bekannt, wo eine Person hunderte von Datensätzen pro Tag erfaßt, weil 80 oder 90% aus geeigneten Fremdquellen kopiert werden können. Das Schnellste ist das Übernehmen durch Kopieren aus einer parallelen allegro-Datenbank (die ihrerseits durch Import aus verschiedensten Quellen gespeist werden kann). Dann kommt das Übernehmen aus Verbund-, Internet- oder CD-ROM-Quellen (s. Kap.5). In diesen Fällen muß immer außerhalb des allegro-Systems eine Recherche mit "Download" an einer anderen Datenbank stattfinden, dann eine Umwandlung (Programm IMPORT) und das Einmischen (Programm UPDATE) in die eigene Datenbank, bevor man Signaturen und andere lokale Angaben hinzufügen kann. Bei geschickter Organisation reduziert sich das alles auf wenige Tastendrücke gegenüber der Schreibarbeit einer vollständigen Eigenerfassung. Außerdem erhält man oftmals geprüfte und zuverlässige Daten (z.B. aus der Deutschen Bibliothek oder Library of Congress), deren Qualität man bei Eigenerfassung ohnehin nicht erreichen könnte.

In Netzwerken ist es in der Regel so, daß der Systemverwalter periodisch alle Platten auf Bandkassetten sichert. Dann ist eine eigene Sicherung für die allegro-Datenbanken nicht notwendig. Sinnvoll und zu empfehlen ist aber, die .LOG-Dateien jeweils in Verbindung mit der Sicherung zu löschen, denn sie sollen ja nur dazu dienen, die Veränderungen zwischen einer Sicherung und der nächsten festzuhalten.

#hi +#

am Beginn der Kategorieliste kann man es zwar verhindern, aber dann funktioniert die Normalanzeige auch nicht mehr, denn dabei müssen die Untersätze ja ausgegeben werden. Der Punkt ist aber, daß der Ausgabespeicher dann wieder ab der ersten Zeile überschrieben wird mit dem, was dann für die Untersätze herauskommt. Und wenn man verhindert, daß etwas herauskommt, entsteht kein Flip. Wenn man es nicht verhindert, entsteht ein falscher. (Wenn die Abarbeitung fertig ist, steht also im Ausgabespeicher obenan das Ergebnis des letzten Untersatzes Und wenn das nichts Sinnvolles ist, flippt das Programm aus, d.h. es flippt, aber nicht zur gewünschten Stelle.)

Abhilfe: Im Flip-Abschnitt sorgt man dafür, daß in jedem Flip-Fall am Ende noch diese drei Zeilen erreicht werden:

#+#

Wer auf den Geschmack gekommen ist, kann auf harte Grenzen stoßen: nicht jedes Zeichen kann zum Flippen benutzt werden. Nur diejenigen gehen, die im Anzeigebildschirm (noch) keine andere Funktion haben, und auch nur Buchstaben und Ziffern! Das sind insgesamt folgende Zeichen:

Leider kann man auch aus diesem Grund nicht immer einen schön mnemonischen Buchstaben nehmen und auch keine plausible Folge a,b,c,d,.. machen. Was tun die anderen Buchstaben? Das steht in Kap. 1.5.

Bis zum letzten ausgereizt haben wir dieses Repertoire in der Datenbank UNIC, die wir vor kurzem bereitgestellt haben. Mehr dazu weiter unten unter "Zeichensatzfragen".

In die Abfrageliste können Vorgaben eingebaut sein. Das kann z.B. so aussehen:

123 " Dokumenttyp: "Buch<

123 t" Dokumenttyp: "<

Eine Vorgabe nämlich, die vor den Anführungszeichen steht, wird ebenfalls übernommen.

Das Fenster, in dem man beim Befehl #b arbeitet, hat eine Menge Tastenfunktionen, die sehr wenig bekannt sind. Oben wurde schon im Kapitel "Eingabe-Erleichterungen" darauf hingewiesen, daß man mit F1 alles darüber erfahren kann. Eine dieser Funktionen ist jedoch unnötig und hat einen störenden Nebeneffekt: Mit [Strg]+[Rücktaste] wird das gesamte Fenster leer gemacht. Wenn man das wirklich jemals will, kann man es auch mit [Pos1] [Strg]+[Entf] machen. Der Nebeneffekt ist, daß bei der OSTWEST-Tastatureinstellung (in OSTWEST.BAT versteckt) der Code 127 (für das ‘e’ mit Hacek) auf die Kombination [Strg]+[Rücktaste] gelegt wird. Das geht dann in dem Fenster nicht. In der aktuellen, nachgebesserten PRESTO-Version haben wir diese Kleinigkeit beseitigt.

Das auf der CD ausgelieferte V15-Programm INDEX hat Probleme damit, Globale Ersetzungsbefehle in den Indexparametern abzuarbeiten. Es kann zum Absturz kommen. Einerseits wird ohnehin empfohlen, auf solche Befehle in den Indexparametern zu verzichten (sie kosten viel Zeit), andererseits sind Ausweichlösungen (z.B. mit lokalen Ersetzungen) nicht immer elegant. Außerdem klappt es in PRESTO problemlos. Daher wurde INDEX nachgebessert (20.10.97).

Es gibt nicht nur reservierte (Handbuch S. 204), es gibt auch ungünstige Sprungmarken. Und zwar sind dies das Apostroph und das Anführungszeichen. Diese haben ja die Sonderfunktion, druckbare Texte einzuschließen, wobei dann Mehrfach-Leerzeichen zulässig sind. Deshalb entsteht ein Konflikt, wenn man die Sprungbefehle +’ oder +" schreibt. Der Sprung oder aber der Rest der Befehlszeile funktioniert dann in der Regel nicht. Man muß also auf diese Zeichen als Sprungmarken verzichten.

Die m-Befehle in der CFG müssen oberhalb der Kategorieliste stehen, d.h. vor der ersten Zeile, die mit einem ‘#’ beginnt. Wenn die Kategorieliste nämlich kommt, muß das Programm bereits wissen, mit welchen Speichergrenzen es arbeiten soll. Es nimmt sonst erst einmal die Standardwerte. Kommen aber dann später noch die m-Befehle, kann hinterher beim Programmlauf plötzlich und undurchschaubar etwas schiefgehen, weil das Programm u.U. nicht merkt, daß es eine kritische Grenze überschreitet. In den gelieferten CFG-Dateien kommt dieses Problem zum Glück nicht vor. Im Handbuch allerdings, in der abgedruckten Version der $A.CFG (S.290+292) ist es genau falsch!

Die Entwicklung der Z39.50 Schnittstelle war im letzten Monaten etwas in den Hintergrund getreten. Da der avanti-Datenbankserver sich auch schon ohne diese Schnittstelle im Kreis der allegro-Anwender und auf diversen Plattformen sehr rasch verbreitet hat, kamen zahlreiche Fehlermeldungen und Erweiterungswünsche für WWW-Kataloge auf die Entwicklungsabteilung zu, die vordringlich bearbeitet werden mußten. Jetzt, da der Avanti-Server die Kinderkrankheiten überwunden hat und für alle wichtigen Betriebssysteme zur Verfügung steht, wird wieder verstärkt an der Z39.50 Schnittstelle weitergearbeitet. (Ein ausführlicher Bericht über die Arbeiten seit Juli 1996 liegt auf dem WWW-Server.)

Grundlegende Entscheidungen sind gefallen. Die allegro-Schnittstelle wird auf der Z39.50 Funktionsbibliothek des DBV-OSI II Projektes aufbauen. Diese Software ist in der UNIX-Version (bisher) frei verfügbar. Da alle großen Bibliotheksverbünde in Deutschland Projektpartner von DBV-OSI II sind, ist zu erwarten, daß auch in Zukunft die Pflege der Z39.50 Funktionsbibliothek sichergestellt bleibt. Kommende Änderungen des Protokollstandards können mit wenig Aufwand in die allegro-Schnittstelle übernommen werden.

Die allegro-Z39.50 Schnittstelle wird für UNIX und Windows NT entwickelt. Dabei zeichnet sich ab, daß die UNIX Version zeitlich vorauseilt, weil die Portierungsarbeiten entfallen. Für beide Plattformen wird ein modulares Konzept verfolgt. Der Avanti-Server erledigt die Datenbankzugriffe über die lokale Serversprache "Avanti". Seine Aufträge kann der Avanti-Server sowohl direkt als auch über das Z39.50 Interface erhalten (vgl. nebenstehende Abbildung). Die Z39.50 Schnittstelle wirkt in diesem Konzept als schlichter Client. Parallel können Anfragen beantwortet werden, die nicht diesem Protokoll folgen (z.B. die Perl-Scripte der WWW-Schnittstelle). Zusätzlich erhoffen wir uns eine unkomplizierte Pflege der Programmteile. Zur Jahresmitte 98 erwarten wir, Ihnen einen ersten Prototypen präsentieren zu können. (ve)

avanti heißt der vor einem Jahr (vgl. allegro-news Nr. 43) erstmals vorgestellte allegro-Datenbankserver, der zur Zeit überwiegend im Zusammenhang mit der WWW-Schnittstelle eingesetzt wird. Für das kommende Jahr kündigen sich neue Client-Programme an, die die Attraktivität des Avanti-Servers weiter erhöhen werden. Wie erhofft beteiligen sich auch engagierte Anwender an dieser Entwicklung. Selbstverständlich wird das neue Programm PRESTO-W mit dem Avanti-Server Daten austauschen können.

Da die in den letzten Monaten entwickelten bzw. verbesserten Versionen des Avanti-Servers nur den Teilnehmern der E-Mail-Liste bekannt sind, sollen diese noch einmal im Überblick dargestellt werden.

Zwei Entwicklungslinien sind zu unterscheiden:

• Zweitens die Entwicklungen für die Microsoft Betriebssysteme Windows ’95 / ‘NT 4.0 ("AVANTI-W"). Hier wurden in jüngster Zeit inhaltliche und gestalterische Detailverbesserungen vorgenommen. Besondere Aufmerksamkeit kam dabei den gemeldeten Schwächen im Stabilitätsverhalten zu. Aktuell ist die Version 1.3. Falls Sie mit einem älteren Programm arbeiten, sollten Sie sich die neue Version von unserem FTP-Server abholen (AC15/WINDOWS). Als Beta-Version ("AVNTSERV.EXE") liegt dort auch die Systemdienst-Version für Win’NT zum Test bereit. Sie erlaubt den Avanti-Betrieb auch ohne einen im System angemeldeten Benutzer. Da ein Systemdienst normalerweise über keine Benutzerschnittstelle verfügt, muß man Programmeinstellungen (zunächst noch) mit Hilfe von "Avanti-W" vornehmen. Alle Meldungen werden wie bisher in eine täglich wechselnde Log-Datei protokolliert.

	Kommunikation	Systemdienst	Benutzer-schnittstelle	Konfiguration	incl. WWW-Schnittstelle	incl. Client-Programm
AVANTI-X (UNIX)	Sockets			INI-Datei		Perl-Scripte
AVANTI-W (Win’95/NT)	ZAD, DDE, Named-Pipes, Sockets			Dialoge
AVNTSERV(Win’NT)	ZAD, Named-Pipes, Sockets			® Avanti-W	® Avanti-W	® Avanti-W

Mit dem Befehl qrix - stellt man ein, daß der nächste qrix vom Suchbegriff aus nach oben sucht, d.h. die gewünschte Anzahl davor statt dahinter liegenden Einträge aufblättert.

Der Server kann zwar Sätze, die bearbeitet werden sollen, sperren und nach Abspeicherung wieder freigeben. In einem Client/Server-Betrieb ist das aber nicht unbedingt eine gute Lösung. Es ist ja ganz ungewiß, ob ein Satz, der einem Client zum Ändern übergeben wurde, überhaupt jemals zurück kommt! (Unter PRESTO ist das kein Problem, denn der Editor ist ja ins Programm eingebaut, so daß es immer genau weiß, wann der Satz wieder freigegeben werden kann.) Deshalb wurde für den Server noch eine andere Arbeitsweise realisiert. Diese beruht auf dem Änderungs-Zeitstempel, der mit dem Befehl ce in der CFG definiert wird. Die Sache ist ganz einfach:

Sonderkategorien, z.B. #nr und #dt, können mit dem write-Befehl ebenfalls ausgegeben werden.

Suche nach Variablen ist möglich: dem find-Befehl kann man als Suchbegriff eine #u-Variable geben.

Zwischen DOS und Windows klafft leider, was die Zeichensätze angeht, ein Abgrund der Inkompatibilität. Die ANSI- Zeichensätze der Windows-Welt sind erweiterte ISO-8859-Sätze, wie sie UNIX verwendet. Der Bereich 128-159 ist bei ISO unbelegt, bei Windows teilweise belegt. Daß die PC-Sätze nicht diesen Normen gefolgt waren, ist IBM anzulasten. Schuldzuweisungen nützen aber gar nichts, denn nun haben wir den Zeichensalat. Die Codes des OSTWEST-Satzes, den die UB Braunschweig vor Zeiten als Erweiterung der PC-Tabelle 437 und kompatibel zur Norm DIN 31628/2 erstellt hat (siehe Handbuch Anhang E) finden zu einem großen Teil keine Entsprechung in der hierzulande normalerweise verwendeten Windows-ANSI-Tabelle. Weil man aber mindestens eine vorläufige Lösung braucht, bei der nichts verloren geht, wurde eine Liste der in ANSI nicht vorhandenen Zeichen aufgestellt und diese dann in einer Weise auf ANSI-Zeichen abgebildet, daß insgesamt eine ein-eindeutige Abbildung (eins-zu-eins) zwischen OSTWEST und ANSI entsteht. Damit wird wenigstens folgendes erreicht: wenn man mit Windows oder UNIX auf eine unveränderte PC-Datenbank mit OSTWEST-Codes zugreift und Datensätze bearbeitet, bekommt man zwar etliche Zeichen nicht korrekt zu sehen, sondern es erscheinen teilweise ganz andere (die es in OSTWEST nicht gibt), aber diese Zeichen werden beim Abspeichern wieder in die korrekten PC-Zeichen zurückverwandelt. Solange wir keinen vollständigen Windows-Ersatz mindestens für PRESTO haben, müssen die Daten noch im PC-Code verbleiben, denn in die DOS-Programme ist keine solche eins-zu-eins Hin-und-Her-Konvertierung eingebaut. Unter Windows und UNIX sorgt dafür eine Tabelle namens o.apt, welche in die Index-Parameter mit dem Befehl to eingebunden wird. Für die Bildschirmanzeige gibt es eine andere Tabelle namens d.apt, die man mit td in d-1.apr einbindet. Diese wichtigen Tabellen sind unabhängig von der Konfiguration, man kann also Kopien machen für andere CFGs, z.B. o.bpt und d.bpt für B.CFG. Die aktuellen Dateien o.apt und d.apt liegen auf dem Verzeichnis PARAM des FTP-Servers.

Es folgt hier als Auszug aus o.apt die Liste derjenigen OSTWEST-Codes, die in ANSI keine Entsprechung haben und die deshalb, nur zum Zeitpunkt des Editierens, durch andere Zeichen provisorisch ersetzt werden. Zum Drucken kann man immerhin eine p-*.apt machen, die alle Zeichen des Druckers ausnutzt, z.B. kann man weiterhin die vorhandene p-dskjet.apt auch für HP-kompatible Laserdrucker nehmen und ebenfalls für andere CFGs kopieren.

176 185 Έ tuerk. i ohne Punkt Ή 1 49 0131 i

182 145 á gravis ‘ 3 0 0300 `

183 136 ã circumflex ˆ 94 5E ^

190 178 æ Halbkr.ueberg/breve ² 3 6 0306 ---

198 227 · Doppelakut ã 3 11 030B ---

199 179 é Hacek/Caron ³ 3 12 030C ---

207 186 ê Ringel Ί 3 10 030A °

209 215 ù Halbkr.unter (breve) Χ 3 46 032E ---

210 171 ø Ogonek « 3 40 0328 ---

212 191 ò untergesetzter Punkt Ώ 3 35 0323 .

213 146 ° Ain ’ 6 57 0639 ??

219 161 / diakrit / ‘ 3 56 0338 /

242 217 ‘ L m.Schrägstrich Ù 1 65 0141 L

243 218 ± l m.Schrägstrich Ú 1 66 0142 l

Das eigentliche Problem ist hiermit natürlich nur aufgeschoben, nicht aufgehoben. Wenn dereinst die vollständige Umstellung auf Windows oder UNIX und damit die ANSI-Codes ansteht, was soll dann wirklich mit den OSTWEST-Sonderzeichen werden? Vielleicht sollte man aber abwarten und es kommt alles noch ganz anders:

 

UNICODE?

Rechts sind die UNICODE-Codes angegeben. Der UNICODE-Standard beginnt sich langsam durchzusetzen - zumindest gibt es keine Alternative dazu, wenn man einen wirklich umfassenden Zeichensatz will. Noch gibt es allerdings wenig Anwendungssoftware, und es ist schwierig, solche zu machen, die mit diesem Standard arbeitet, und auch für allegro dürfte das noch eine Weile dauern. Das Thema UNICODE ist zu umfangreich, um es in diesen Blättern abzuhandeln. Es gibt jedoch, wie könnte es anders sein, eine Homepage: WWW.UNICODE.ORG, wo man alles erfahren und sich die Zeichentabellen sogar im Großformat anschauen kann. Wir haben als kleine Vorarbeit eine Datenbank erstellt, in der zu allen bekannten PC-, Windows- und UNIX-Standards sowie zu den Pica, MAB1, MAB2, und USMARC-Codes, außerdem SGML/HTML, die UNICODES zugeordnet sind. Hier ein Blick in diese Datenbank, angezeigt wird der Datensatz zum Buchstaben LATIN SMALL LETTER R WITH CARON (r mit Hacek, Code 168 in OSTWEST).

 

 

 

Das Interessante passiert, wenn man auf die ‘4’ drückt. Dann wird ein Hilfsdatensatz geladen, der im Register 10 versteckt ist, und der produziert den folgenden Bildschirm, der fast nur aus Flips besteht. Das sieht dann so aus:

 

 

Danach kann man zwei beliebige der roten Zeichen eingeben, kann noch zwischen dezimal und hexadezimal entscheiden, und es entsteht die Konvertierungsliste zwischen den beiden betreffenden Codelisten.

Der Flip [4] ermöglicht so die Erstellung jeder beliebigen Konkordanzliste, z.B. zwischen OSTWEST und PC-852 oder Pica oder auch SGML/HTML. Die Liste kommt, wie gesagt, wahlweise in hexadezimal oder dezimal heraus, letztere dann sofort brauchbar für Listen, die man in Export- oder Importparameter einbauen kann. Die Datenbank liegt auf dem FTP-Server als UNIC.EXE auf dem Verzeichnis FORMATE. Sie wird auch auf der nächsten CD mitgeliefert werden.

Experten können die Wirkungsweise in den Parametern D-1.YPR und in UNI.BAT studieren. Aber wohlgemerkt: die Datenbank dokumentiert die Zeichensätze rein verbal, sie kann nicht die Zeichen irgendwie wirklich anzeigen. Dafür ist die Original-UNICODE-Dokumentation heranzuziehen.

Zu den größeren Problemen mit UNICODE gehören diese:

• Man braucht zwei Byte je Zeichen statt nur einem, d.h. jede Datei oder Datenbank wird doppelt so groß, wenn sie auf UNICODE umgestellt wird.
• Speziell für allegro wird es mit den Tabellen für die Umcodierung etwas schwierig. Akzentbuchstaben wird man nach wie vor in Grundbuchstaben umcodieren müssen, weil sonst die Ordnung nicht funktioniert. Bisher haben diese Tabellen 256 Byte, das reicht dann nicht mehr. Wenn man die Sprachen mit nicht-lateinischen Buchstaben außen vor läßt, also nur einige ausgewählte Seiten des UNICODE-Standards einsetzt, wird es wohl einfacher sein als wenn man den kompletten Standard realisieren will. (Welche Bibliothek würde das schon brauchen?)

Es gibt übrigens einen Windows-Font für die USMARC-Zeichen, doch damit können wir auch nichts anfangen: es gibt keine präkombinierten Akzentbuchstaben, sondern sogar unsere Umlaute werden darin durch Kombination realisiert. Dieser Zeichensatz ist weitgehend, aber natürlich nicht ganz, mit dem von Pica identisch.

 

Druckfehler im Handbuch

19. 204 Bei der reservierten Sprungmarke #-# : [Strg]+F10 statt F10

Termine

stehen für 1998 noch keine fest! Wir wollen zu der Gepflogenheit zurückkehren, unterbrochen durch die Bauperiode, ein Expertentreffen im Herbst zu veranstalten. Sicher ist zur Stunde nur, daß es im Oktober sein wird.

Diejenigen Abonnenten, die ihre Rechnung erst im Januar wünschten, erhalten diese innerhalb der ersten drei Wochen, zusammen mit etwa bestellten Büchern. Mit der Rechnung kommt dann auch das Blatt mit dem neuen FTP-Passwort!

 

Diskussionsliste: Schicken Sie die Message subscribe allegro Vorname Nachname an die Adresse maiser@buch.biblio.etc.tu-bs.de. (Und zum Abmelden: unsubscribe allegro .)

FTP-Adresse: 134.169.20.1 , E-mail: allegro@tu-bs.de, WWW: www.biblio.tu-bs.de/allegro

---

© 22.07.1997 UB Braunschweig, Bernhard Eversberg (b.eversberg@tu-bs.de)

Fragen bitte an:

ub@tu-bs.de