Zeichenumwandlung [LANG!]

Mo Nov 19 17:42:48 CET 2001

Lieber Herr Allers, liebe Liste,

Als Nachtrag zur Diskussion von voriger Woche habe ich
einige Experimente unternommen. Meine Behauptung war
ja, dass "ich niemanden kenne, der weiss, wie man einen
beliebigen (etwa Allegro-Zeichensatz) sauber unter Windows
einbinden kann". Ich kann diese Behauptung inzwischen
nur bekraeftigen (es mag sein, dass es jemanden gibt,
der es kann, ich habe aber trotz extensiver Recherchen
niemanden gefunden, der das auch nur behaupten wuerde
und ich habe viele Indizien gefunden, dass es nicht 
geht). Aber der Reihe nach:

[Alles folgende fuer Windows NT, Service Pack 6a, 
Internet Explorer 5.0, Pan-European Support installiert,
Tastaturschema fuer Deutsch und Griechisch]

Ich habe mich nicht darum gekuemmert, mein System 
komplett zu "allegro(in)fizieren", d.h. mein Ziel
war es nicht, OSTWEST zur Standard-Codepage zu machen
oder alle Windows-Zeichensaetze auf Allegro umzubiegen:

- Es ist mir gelungen, eine Codepage (444) fuer den
  OSTWEST-Zeichensatz zu erzeugen, die (nach eingabe
  von "chcp 444" in DOS-Boxen mit Cmd.exe die entsprechenden 
  Zeichen des OSTWEST-Zeichensatzes zeigt (sofern man eine 
  multilinguale Schrift, wie etwa Lucida Console, eingestellt
  hat, sonst sieht man nur die (passenden!) Grundbuchstaben.
  Im Vollbildmodus tut sich mangels einer entsprechenden
  Unterstuetzung in fixedsys.fon natuerlich nichts.
  Nachteil: startet man den x-editor, so sieht man doch
  nur die dos-Zeichen (hat der wirklich eine eigene
  Zeichentabelle?), startet man allegro, kann man auch
  normale Buchstaben nur mit Alt-nn eingeben (unter
  cmd am Prompt gilt keine dieser Einschraenkungen).

- Es ist mir gelungen, eine Codepage (1234) fuer den
  Windows-Zeichensatz zu erzeugen. Eine Testdatei
  liess sich mithilfe dieser Codepage in UnicEdit
  (eine Art Unicode-Notepad mit Konvertierungsfunktionen
  anhand vorhandener Systemressourcen) oeffnen und
  wurde korrekt angezeigt.

- Mein Hauptinteresse galt natuerlich den TTF-Fonts.
  Es gibt wohl zwei Wege, jeweils mit Vor- und Nachteilen:

1. Die Windows 3.1-Methode: Es wird ein Font gebaut, bestehend
  aus 256 Zeichen (genauer: 232), dieser Font ist von
  seinen Eigenschaften her ein Symbol-Font, die Zeichen
  werden dem privaten Unicodebereich U+F000 - U+F07F zugeordnet.
  Mein Font a-cour-s.ttf (Allegro Courier) ist nach dieser
  Methode erzeugt, ich habe der Reihe nach einfach die
  gewuenschten Zeichen aus cour.ttf (Courier New) in der
  Reihenfolge fuer allegro.ttf dort hineinkopiert. Diese
  Methode ist in dem Sinne "sauber", dass sie nichts falsches
  behauptet und in dem Sinne unbefriedigend, dass zu allen
  benutzten Zeichen natuerlich die Unicode-Mappings (d.h.
  die "Bedeutungen" bekannt sind, aber nicht beruecksichtigt
  werden koennen). Dieser Font ist sehr blaesslich, der
  Standard-Font cour.ttf besitzt wohl entweder Hinting-Tabellen
  oder fuer niedrige Aufloesungen auch noch Bitmaps, die beim
  Kopieren der Zeichen verlorengegangen sind: Als Effekt wird
  in kleineren und mittleren Aufloesungen eine optische
  Glaettung der Zeichen mittels Graustufen vorgenommen.

2. Die TU-BS-Methode: Man nehme sich einen vorhandenen Font
  und sortiere die Zeichen so um, dass es passt. Mein Font
  a-cour-t.ttf (Courier Allegro) ist so erzeugt: Man muss
  hierzu wissen, welche Unicode-Zeichen unter CP1252 den
  einzelnen Positionen von 32 bis 255 zugeordnet werden und
  weist dann den Glyphen, die man auf der entsprechenden Position
  sehen will, den entsprechenden Unicode zu (es ist also etwas
  indirekter als bei Methode 1). Diese Methode operiert also
  mit "Luegen", denn das grosse Z mit Hacek (Unicode 017D) etwa
  liegt in CP1252 auf Position 142 und in den allegro.ttf
  auf Position 219, wo in CP1252 das "ganz normale" ISO-Zeichen
  U mit Circonflex liegt. Damit der Font funktioniert, muss
  man nun einerseits behaupten, dass es ein Z mit Hacek nicht
  gibt, und von dem Zeichen, das so aussieht, muss man behaupten,
  dass es ein U mit Circonflex ist. Bei Cut und Paste sind
  natuerlich diese Behauptungen und nicht das Aussehen massgeblich.
  Der Effekt dieser Verbiegungen ist natuerlich nicht schlimmer
  als mit dem Symbol-Zeichensatz: Auch hier wird vom System
  stillschweigend CP1252 (hier jedoch, weil Grundeinstellung
  des Testsystems?) unterstellt, Kommunikation mit anderen
  Anwendungen ist nicht moeglich.

  Uebrigens muss man durchaus doppelt luegen: Microsoft hat die 
  Codepage 1252 im Laufe der Jahre des oefteren erweitert, etwa 
  um das Euro-Zeichen. Man muss dem entsprechenden Glyphen (der
  sowohl in Ostwest als in CP1252 auf Position 128 kommt) daher
  einerseits (fuer alte Windows-Systeme) sagen, dass er U+0080 
  ist, andererseits (fuer neue Systeme) sagen, dass er U+20AC
  ist (was er auch wirklich ist, weil allegro.ttf da nicht
  abweicht).

3. Meine behauptete Methode, dass es eventuell "sauber" ginge,
  funktioniert nicht. Meine Ueberlegung war, dass man mit
  einer geeigneten Codepage (daher die oben erwaehnte Codepage
  1234) und Unicode-Zuordnungen des Allegro-Fonts (schon laengst
  vorhanden) einfach dafuer sorgen kann, dass einer der 
  Systemfonts, die alle viele hundert Zeichen (WGL4: Westlich,
  Oestlich, Grieschisch und kyrillisch) enthalten, in neueren
  Versionen auch noch Hebraeisch und Arabisch nicht im Ausschnitt
  CP1252 sondern im neu erfundenen Ausschnitt CP1234 angezeigt
  wird. Meine Recherchen haben jedoch ergeben, dass hierfuer
  nicht die Codepage massgeblich ist, sondern ein undokumentiertes
  Feature von Microsoft (LanguageID?), das festverdrahtete,
  urspruenglich mnemnoische) Zuordnungen enthaelt. Bekannt sind 
  die Zuordnungen
  00       <=> CP 1252
     (161) <=> CP 1253 (griechisch)
  BA (186) <=> CP 1257 (BAltisch)
  CE (204) <=> CP 1251 (Cyrillic Europe)
  EE (238) <=> CP 1250 (Eastern Europe)
     (162) <=> CP 1254 (Tuerkisch)
     (177) <=> CP 1255 (Hebraeisch)
  und noch einige wenige andere (Koreanisch, Arabisch, Chinesisch)
  D.h. man kann sich einen Font nicht beliebig (mittels Codepage)
  aus dem Unicode-Repertoire zusammenstellen, sondern ist an
  die oben angegebene Liste von vorgegebenen Codepages gebunden.
  (Unter WordPad bekommt man ja auch die Systemschriften in den
  Geschmacksrichtungen "Griechisch, Baltisch, Kyrillisch,
  Mitteleuropaeisch, und Tuerkisch" angeboten: Dies entspricht
  also nicht den im System verfuegbaren Codepages, sondern 
  den Codepages, denen von Microsoft eine Funktion fuer die
  Sprachauswahl zugeordnet ist)

  Im kyrillischen Raum gibt es etwa gleich verbreitet 4 verschiedene
  kyrillische Codepages: neben CP 1251 noch das DOS-Pendant von
  Microsoft sowie die KOI-8R-Codierung, die sich im Osten lokal
  entwickelt hat, diese unter zwei verschiedenen Codepage-Nummern
  und m.W. noch als Windows-Pendant (oder ISO-Kyrillisch mit leichten
  Abweichungen von CP 1251 ist verbreitet). In diese Bereich
  gibt es diverse vorgehensweisen, ein Windows-System zu
  "russifizieren": Sei es, dass man mit KOI-8R weiter arbeiten
  moechte und nicht mit CP 1251, oder dass man mit ukrainischen
  oder altslavischen Schriften arbeiten moechte: Der beste bekannte
  Weg unter Windows NT ist es, die entsprechende Codepage auf
  die "eigentliche" Codepage C_1251 zu kopieren: dann wird der
  erwartete Font angeboten und funktioniert. Analog koennte
  man also eine Allegro-Codepage als CP1253 ausgeben (d.h. C_1234.nls
  auf C_1254.nls kopieren) und haette dann den OSTWEST-Font
  immer dann angeboten, wenn man auf "Tuerkisch" umschaltet
  (man koennte sie auch auch C_1252.nls kopieren und haette dann
  ein vollstaendig "allegrofiziertes" System). Das alles scheint
  mir allerdings sehr drastisch...
  In Windows'9x sieht die Sache noch etwas duesterer aus, hier
  sind die entsprechenden Zuordnungen von Sprach-Codierung zu
  Codepage in der Datei GDI.EXE verborgen, fuer die KOI-8R-Fans
  gibt es im Internet downloadbar gepatchte Versionen des GDI.EXE
  (fuer jedes der verschiedenen Win'9x natuerlich ein anderes),
  die CP1251 durch KOI-8r ersetzen.

  Wenn man nun also - wie ich mittlerweile - akzeptiert, dass
  der TU-BS-Weg der einzig gangbare ist, um sichtbare und
  allegro-Artige Fonts zu erzeugen, tun sich noch weitere
  Moeglichkeiten auf: Der zugrundeligende, pervertierte
  courier-font enthaelt ja z.B. noch alle griechischen Zeichen,
  und man kann mit den "Virtuellen Fonts" von Microsoft etwa
  auch noch einen Zeichensatz "Courier allegreek" in der
  Registry (oder win.ini) eintragen, der dieselbe .ttf-Datei
  benutzt, aber CP1253 als Codepage (indirekt via Einstellung
  "161" aus obiger Liste): Damit hat man dann im Bereich der
  Zeichen 160-255 die bekannten, unverfremdeten griechischen
  Zeichen und im Bereich 128-159 (der ja sowieso nie benutzt
  werden sollte) sind die Zeichen belegt, die ueber die
  Bastelei mit Codepage 1252 dort explizit hingelegt wurden.
  Es sind aber noch diverse Zeichenpositionen absolut unbelegt:
  136, 138, 140-143, 152, 154, 156 und 159. Die von Herrn 
  Allers so oft benoetigten 7 deutschen Sonderzeichen im
  ansonsten Griechischen Zeichensatz sollten sich hier also
  unterbringen lassen. Natuerlich ist das dann eine voellig
  neue Codetabelle, die aus allegro-Sicht einen komplett
  anderen Satz von Umcodierungstabellen benoetigt (und
  nicht-kompatible Datenbanken), jedenfalls aber braucht
  man nicht noch einen zweiten Satz von "Luegen-.ttfs"
  zu basteln, sondern haelt die Verheerung in kleinstmoeglichen
  Grenzen (problematisch allerdings, dass im Bereich von 128-159
  ausgerechnet "u" und "o" mit Doppelakut sind, die werden dann
  natuerlich leicht mit "u" und "o" mit Diaerese verwechselt...)

****
Informationen, denen ich nicht nachgegangen bin:

- Auf Systemen (Auch Win'95!!!) mit Internet Explorer 5.0 und
  neuer kann ein Programm auf die sogenannten UNISCRIBE .API-
  Funktionen zurueckgreifen, die sehr weitgehende Unicode-
  Unterstuetzung zulassen. Wenn ich es recht verstanden habe,
  koennte ein Programm seine private Zeichentabelle weiterhin
  benutzen, aber mit dem Betriebssytem nur ueber Unicode-
  Funktionen kommunizieren. Damit waeren so ziemlich alle
  Probleme mit a99 und Zeichensaetzen neu zu betrachten und
  vermutlich geloest.

- OTF-Fonts (Win 2000 und XP) haben auch noch Encoding-
  Tabellen vom Typ 4, die anscheinend beliebige Codepages 
  mappen koennen. Ich habe aber weder die Betriebssysteme
  hier zur Verfuegung noch Werkzeuge fuer die Bearbeitung
  dieser Fonts gefunden.

- Windows XP besitzt angeblich ein Unicode-Faehiges RichEdit
  control und insgesamt eine wesentlich verbesserte Unicode-
  Unterstuetzung, angeblich gehoeren Codepages jetzt der 
  Vergangenheit an (es gibt in den Executables des Systems
  wohl keine nationalen Varianten mehr).

viele Gruesse
Thomas Berger

P.S.: Die von mir beschriebenen Codepages und Fonts liegen
auf dem Braunschweiger ftp-Server als a-cour.zip im Upload-
Verzeichnis.

> > > (In einer heftigen Diskussion mit Windows-Aposteln, die meinten, unter
> > > W-2000 sei das Zeichensatzproblem ein für allemal gelöst, ergab sich hier
> > > neulich als Ergebnis das glatte Gegenteil).
> 
> und B. Eversberg hakte nach:
> 
> > Ist das irgendwo protokolliert und nachlesbar?
> 
> Nein. Es war eine sich über Monate hinziehende
> Auseinandersetzung informellen Charakters mit zum Teil
> wechselnder Besetzung.
> 
> > Solche Erkenntnisse koennen vielerorts von Nutzen sein, wo solche
> > Apostel ihr Wesen treiben,
> 
> In der Tat. Hätten solche Erkenntnisse vor einem Jahr hier
> vorgelegen, wäre die Allegro-Entwicklung in Athens und
> Thessalonikis Goethe-Instituten nicht um Monate zurückgeworfen
> worden.
> 
> > deshalb waere es gut, damit nicht
> > hinter dem Berge zu halten.
> 
> Ich hatte mich auf die Endphase besagter Auseinandersetzung
> präpariert, indem ich bei der hiesigen Microsoft-Niederlassung
> anrief und nach einem von Microsoft angebotenen Font frug, der die
> Zeichen des Neugriechischen zusammen mit den deutschen
> Umlauten und dem scharfen s enthielte. Nein, hieß es, da solle ich
> mich an die Firma soundso wenden. Als ich die anrief, fiel mein
> Partner dort aus allen Wolken, daß Microsoft ihn in dieser
> Angelegenheit empfiehlt, und verwies mich an eine andere Firma in
> Berlin. Aber auch diese Firma paßte bei meiner Frage nach dem
> genannten speziellen Font.
> 
> ###
> 
> Das einzig Neue, was ich an Windows 2000 bisher gegenüber NT
> hinsichtlich der internationalen Zeichensätze gezeigt bekam, war,
> daß man im DOS-Fenster tatsächlich mit dem Zeichensatz schreiben
> kann, auf den man die Tastatur umgestellt hat.
> 
> Mit besten Grüßen:
> 
> Heinrich Allers
> 
> allers at t-online.de * http://home.t-online.de/home/allers
> Gegen unseren Krieg / Contra nuestra guerra:
> http://www.9-11peace.org/index.php3