[Allegro] Änderungen im OSTWEST-Zeichensatz?

Di Apr 20 17:43:58 CEST 2010

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Lieber Herr Eversberg,

Der Zeichensatz wurde zwar nicht geaendert, es gab aber Ende
Februar Aenderungen an den u-Tabellen in cat.api und ucodes.apt
(die ich leider jetzt erst bemerke).

Tendenziell bedeutet so etwas eine Aenderung der Semantik der
Ostwest-Zeichen, denn die Unicode-Zeichen haben eine feste
Semantik, und durch das Mapping in der u-Tabelle wird diese
den allegro-Zeichen aufgedrueckt.

Im Einzelnen:

1. ueber den "Combining Grapheme Joiner" haben wir uns hier bereits
 ausgetauscht, Sie scheinen Ihn so sehr zu verabscheuen, dass er
 in cat.api (nicht: ucodes.apt) direkt doppelt vernichtet wird?

2. Die fragwuerdige Umsetzung als ASCII-Art des Registered-Signs
 auf "(R" (wo ist ")"?) ist zusaetzlich noch einmal mit der
 Bemerkung "Right-Zeichen" als Kommentar angelegt

3. Der "russische Apostroph" ist das transliterierte Weichheitszeichen...
 Weiter unten ebenfalls neu aber auskommentiert dasselbe Mapping

4. U02BA wird als MODIFIER LLETTER DOUBLE PRIME (tranlit. Haertezeichen)
  unten auf das Doppelanfuehrungszeichen gemappt '"', oben jedoch als
  "Anfuehrungsstriche oben" vernichtet

5a. Der MODIFIER LETTER RIGHT HALF RING (transl. arab. ain) wird unten auf
  Akut umgesetzt, oben als "Apostroph gekruemmt" vernichtet
5b. Das Zielzeichen 181 in allegro OSTWEST ist ein "combining"-Zeichen,
  das also mit dem vorangehenden zusammenmontiert wird. Ein "Modifier
  letter" ist aber ein fuer sich stehendes Zeichen, diese Zuordnung geht
  also wirklich nicht.
5c. Fuer eine Anwendung im Bibliothekswesen ist es m.E. legitim,
  U02BC (Vorzugszeichen), U02BE und U02C0 zusammenzufassen (alles nach
  links offene Haekchen) und symmetrisch dazu U02BB (Vorzugszeichen), U02BD,
  U02BF und U02C1 (alles nach rechts offene Haekchen).
5d. Fuer das nach rechts offene Haekchen gibt es das OSTWEST-Zeichen 213
5e. Fuer das nach links offene Haekchen gibt es kein OSTWEST-Zeichen,
  die "Prime" U02B9 ist aehnlich und bei 3. auf den regulaeren Apostroph
  "'" gemappt worden, wenn man gewaltsam abbilden will, also ebenfalls
  auf den Apostroph

6. Umgekehrt kann das COMBININC COMMA ABOVE (Psili) *nicht* auf den
  Apostraph als Spacing Zeichen umgesetzt werden (auch dieses Zeichen
  wird parallel weiter oben als "Apostroph" vernichtet)

7. COMBINING LEFT HALF RING BELOW ist ein nach rechts offenes, untergesetztes
  Haekchen, lt. Unicodedatenbank kommt es nur in der IPA-Lautschrift vor.
  In Bibliothekarischen Zeichensaetzen ist es allerdings als "Rechtscedille"
  verbreitet, http://www.loc.gov/marc/marbi/1996/96-10.html erlaeutert, wo
  es her kommt (irgendeine vergessene Transkription von Thai hat das
  eingefuehrt), aber nicht, wieso es in "unseren" Daten haeufig vorkommt
  Das Mapping auf die untergesetzte Breve ist jedoch nicht angebracht.

8. COMBINING MACRON BELOW sowie die diversen "small letter ... WITH LINE BELOW":
  Einverstanden, wobei ich nicht verstehe, warum ausgerechnet diese
  Zeichen nun in ucodes.apt erwaehnt werden, tausende andere aber nicht...

9. COMBINING COMMA ABOVE RIGHT: Das Mapping geht auf eine AE-Ligatur mit
  MODIFIER LETTER LEFT HALF RING???
  Auch das ist ein wohl eher mythisches Zeichen, denn es kommt i.A. nur
  als *typographische* Loesung fuer etwa t mit Hacek vor. Weil der Apostroph
  dem Zeichen deutlich nachgesetzt ist, kann Akut auch optisch nicht
  infrage Kommen

10. COMBINING DIAERESIS BELOW  Mapping auf Anfuehrungszeichen ueber
  Graphiksymbol? Zwei Puenktchen durch einen auszutauschen halte ich
  per se einmal fuer problematisch: Ausser IPA und latinisiertem
  Taiwanesisch finde ich keine Hinweise darauf, wo solche Zeichen
  vorkommen koennten, und wenn ausgerechnet dort der einzelne
  Untergesetzte Punkt ebenfalls vorkommt, ist nichts gewonnen und
  viel verloren (der Benutzer muss /alles/ nachkontrollieren, nicht
  nur die augenfaellig nicht umsetzbar gewesenen Zeichen!). Leider
  kenne ich die Zeichensysteme nicht gut genug, um dem weiter
  nachgehen zu koennen.

11. COMBINING COMMA BELOW umgesetzt auf Komma gefolgt von Ogonek?
  Scheint in manchen slawischen Sprachen der *Cedille* gegenueber
  bevorzugt zu werden (beides nach links offene Haekchen), ist
  also vergleichbar der Apostroph-Loesung fuer den Hacek.
  Siehe auch das in ucodes.apt bereits existierende Mapping
u 200 155 234        LATIN SMALL LETTER T WITH COMMA BELOW (see u 197 163)
  (auf t-Cedille)

Ich weiss natuerlich, dass es in den MAB und MARC-Zeichensaetzen Zeichen
gibt, die der OSTWEST-Zeichensatz nicht hat (der hat sich gegen den
bibliothekarischen Mainstream und fuer DIN 31628-2 entschieden und
die uebriggebliebenen Zeichenpositionen wurden aus heutiger Sicht etwas
zu leichtherzig verbraten), aber es kann keine Loesung sein, diese
Zeichen mit Gewalt auf anderes abzubilden, im Fall heute war es oft
sachlich katastrophal falsch und spaetestens bei einem Export nach
Unicode oder in die Bibliothekarischen Zeichensaetze faellt es als
falsch auf. Gegenueber dem Standardverhalten der u-Tabelle (Entitaet
so lassen) bzw. dem offenen Weglassen dessen, was man nicht kann,
scheinen mir die Brutalo-Mappings normalerweise nur die drittbeste
Loesung, von den Einzelfaellen 8, 9, 11 einmal abgesehen.

viele Gruesse
Thomas Berger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iJwEAQECAAYFAkvNy74ACgkQYhMlmJ6W47M0nAP/Shs6BdlkAZPIjwVhK2dQpD+E
WOBcfdo4/pfUQSwJT0PK4cR/3XRhS2wa7VcmDDd1NmId8NQpu/glfoL7x1hmCEyK
kXz112cVrsJqnO30rYD7+RA/MlpQaD4RkNw7zMIjc1UzcZAkq5AdW6IeD0aX2N+3
PXVAXs3fblIpGg5fwqw=
=7WFp
-----END PGP SIGNATURE-----