Hans-Juergen Taenzer <[EMAIL PROTECTED]> wrote on 04.03.04:
> Michael Heydekamp ([EMAIL PROTECTED]) wrote
>> Wobei noch zu pr�fen w�re, was man zur�ckbekommt, wenn DISPLAY.SYS
>> nicht installiert und bei COUNTRY gar keine Codepage angegeben
>> ist...
>> Wer CP437 benutzt, hat DISPLAY.SYS i.d.R. nicht installiert.
> Wenn dem tats�chlich so ist, w�re das vermutlich ein KO-Kriterium,
Jeder, der sich halbwegs mit der Materie auskennt und nicht auf
st�ndiges Codepage-Switching angewiesen ist, schmei�t diesen
�berfl�ssigen Speicherfresser raus.
>> Wobei "verh�lt sich entsprechend" im gegenw�rtigen Zustand nur
>> bedeuten kann: Es finden andere Konvertiertabellen Anwendung. Ist
>> CP437 aktiv, wird von/nach CP437 konvertiert, entsprechend wird im
>> Falle CP850 oder anderer Codepages verfahren.
>> Abgesehen davon, da� das die inzwischen ohnehin schon sehr hohe
>> Anzahl an Konvertiertabellen - je nachdem, wieviele und welche
>> Codepages man unterst�tzen will - um ein Vielfaches erh�hen w�rde,
>> scheitert diese Idee IMO schon an folgenden Umst�nden (Aufz�hlung
>> unvollst�ndig):
> Danke erstmal f�r Deine ausf�hrliche Kommentierung.
> Aber du gehst von einer falschen Vermutung bez�glich meiner
> Vorstellungen aus.
> Ich war bei meinen Gedankenspielen nie davon ausgegangen, die Ablage
> der Nachrichten codepageabh�ngig zu machen, die soll wie bisher bei
> CP437 bleiben.
Hmm, aber dann bringt's doch gar nix, andere Codepages zu unterst�tzen.
Bzw. es ist gar nicht m�glich.
> Was ich mir vielmehr vorgestellt habe, war, da� die Anzeige
> abgestellt wird auf die jeweilig aktive Codepage,
Die Anzeige von *was*? Der XP-Oberfl�che oder der Nachrichten?
> und nat�rlich beim Schreiben die aktive Codepage zur Kenntnis genommen
> wird.
> Das bedeutet dann nat�rlich, da� bei der Anzeige und beim Speichern
> von Nachrichten on the fly beim Anzeigen von cp437 in die aktuelle
> Codpage, und beim Speichern von der aktuellen Codepage nach CP437
> konvertiert werden muss.
Letzteres mag ja noch halbwegs gehen (in einem Sonderfall macht FreeXP
das sogar jetzt schon, und zwar bei "�", das, auf einem CP850-System mit
FreeXP erzeugt, korrekt ankommen wird, mit XP2 aber z.B. nicht), aber
ersteres ist nicht machbar.
Ein Zeichen z.B. aus ISO-8859-1, das bei der Konvertierung
transliteriert werden mu�te, weil es in CP437 nicht existiert (z.B. ein
skandinavisches durchgestrichenes "o" nach "�"), kann bei der Anzeige
auf einem CP850-System nicht wieder in eben dieses durchgestrichene "o"
konvertiert werden, weil die Information, da� es sich um dieses Zeichen
gehandelt hat, schlicht nicht vorhanden ist.
IOW: Bringt nix, au�er bei den wenigen Zeichen, die sowohl in CP437 als
auch in CP850 existieren, dort aber jeweils auf unterschiedlichen
Positionen liegen. Das sind nicht mal eine Handvoll, IIRC.
Die meisten Zeichen, in denen sich CP437 und CP850 unterscheiden,
existieren *entweder* in CP437 *oder* in CP850.
> Da� auch diese simplere Vorgehensweise an vielen Stellen Arbeit
> bedeutet, ist mir schon klar.
Ich kann mir aber nicht vorstellen, da� dieser marginale Vorteil das
ist, worum es Dir wirklich gegangen sein sollte.
Da ist das Umstellen der Codepage sicher sinnvoller und einfacher.
> ZB. m�ssen beim Suchen die eingegebenen Suchkriterien von der
> aktuellen CP nach 437 gewandelt werden. Dann gibts bei Kl�tzchen-
> Grafik Probleme, mit Zeichen, die nicht in zB. CP 850 enthalten sind.
> Ausserdem m�sste es auf die jeweilige Codepage abgestellte
> Schriftarten geben (wobei vermutlich neben 437 nur 850 von Bedeutung
> sind), usw...
Das kommt alles noch dazu, richtig. Und macht es doch recht
unwahrscheinlich, da� sich jemand wegen des wirklich geringstf�gigen
Nutzens dieses Monsterumbaus annimmt.
Zumal das Problem mit der Oberfl�che selbst dann immer noch nicht gel�st
w�re.
Michael
------------------------------------------------------------------------
FreeXP Entwickler-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/dev-list
