Hallo/2,

zum offline-Lesen eines aktuellen Wikidumps hat sich hier das Programm
WikiTaxi (http://www.wikitaxi.org) mittels Odin bewährt. Eine aktuelle
Datenbank gibt es bei
http://download.wikimedia.org/dewiki...urrent.xml.bz2


Die fertig entpackte Datenbank braucht etwa 2,2 GB (ohne Bilder) und muß
deshalb auf JFS. Das Programm kann auch auf ein anderes Dateisystem.

Folgende Einschränkung bleibt: Sonderzeichen aus dem UTF-Repertoire
werden nicht richtig dargestellt. Die gewählte Schrift (hier Workplace
Sans) an sich ist schon o.K. Hat da jemand eine Idee ???

--
Mit freundlichen Grüßen

Ralph
Dieses OS/2-System läuft seit 83 Tagen und 04:50 Stunden (en).

On Mon, 19 Jan 2009 12:33:10 UTC, "R. Hannes" wrote:

> Folgende Einschränkung bleibt: Sonderzeichen aus dem UTF-Repertoire
> werden nicht richtig dargestellt.

Einige oder alles oberhalb von ASCII bzw. außerhalb der System-Codepage?

> Die gewählte Schrift (hier Workplace
> Sans) an sich ist schon o.K. Hat da jemand eine Idee ???

Jeder Unicode Font hat nur ein beschränktes Subset alle Unicode Zeichen,
also wirst Du mir der Auswahlmöglichkeit nur eines Fonts niemals alle
darstellen können. Aber etwa die DejaVu Fonts (http://dejavu-fonts.org/)
können deutlich mehr Zeichen als Workplace Sans.
--
Grüße von
Peter.

Peter Weilbacher schrieb:

>> Folgende Einschränkung bleibt: Sonderzeichen aus dem UTF-Repertoire
>> werden nicht richtig dargestellt.
>
> Einige oder alles oberhalb von ASCII bzw. außerhalb der System-Codepage?

Hallo/2,
danke für die Antwort. Die 850 kommt korrekt. Dazu dann noch die dt.
„Gänsefüßchen“ und auch einiges Nordisches(Bokmål oder
Skopunarfjørður). Griechische, Russische oder Hebräische Zeichen sind
dagegen nur Fragezeichen.

>> Die gewählte Schrift (hier Workplace Sans

> Jeder Unicode Font hat nur ein beschränktes Subset alle Unicode Zeichen,
> also wirst Du mir der Auswahlmöglichkeit nur eines Fonts niemals alle
> darstellen können. Aber etwa die DejaVu Fonts (http://dejavu-fonts.org/)
> können deutlich mehr Zeichen als Workplace Sans.

Mit der ganz frisch gezogenen Dejavu Sans ist es aber auch nicht besser.
Umgekehrt werden diese Zeichen unter XP mit Workplace Sans korrekt
angezeigt. Dabei ist zu beachten, daß dieses XP in einer vBox stecktund
mittels Freigaben genau die gleiche *.ttf wie mein OS/2 nutzt. Braucht
Odin da noch irgendwelche Einstellungen?

--
Mit freundlichen Grüßen

Ralph
Dieses OS/2-System läuft seit 84 Tagen und 06:31 Stunden (en).

R. Hannes wrote:
> Mit der ganz frisch gezogenen Dejavu Sans ist es aber auch nicht besser.
> Umgekehrt werden diese Zeichen unter XP mit Workplace Sans korrekt
> angezeigt. Dabei ist zu beachten, daß dieses XP in einer vBox steckt und
> mittels Freigaben genau die gleiche *.ttf wie mein OS/2 nutzt. Braucht
> Odin da noch irgendwelche Einstellungen?

Ich glaube nicht. Nur werden die Zeichen vermutlich irgendwo einmal in
die OS/2 codepage konvertiert. Alles, was da nicht durch passt, ist dann
Essig.


Marcel

Marcel Müller schrieb:
> R. Hannes wrote:

>> Mit der ganz frisch gezogenen Dejavu Sans ist es aber auch nicht
>> besser. Umgekehrt werden diese Zeichen unter XP mit Workplace Sans
>> korrekt angezeigt. Dabei ist zu beachten, daß dieses XP in einer vBox
>> steckt und mittels Freigaben genau die gleiche *.ttf wie mein OS/2
>> nutzt. Braucht Odin da noch irgendwelche Einstellungen?
>
> Ich glaube nicht. Nur werden die Zeichen vermutlich irgendwo einmal in
> die OS/2 codepage konvertiert. Alles, was da nicht durch passt, ist dann
> Essig.

Ich habe keine Probleme damit, bei mir werden auch Unicose-Zeichen
korrekt dargestellt.

Allerdings, das muß ich dazusagen, habe ich mein OS/2 *nicht* unter den
alten DOS-Codepages 437 bzw. 850 am laufen, sondern unter der 1004, die
identisch ist mit Windows-1252 und mit ISO-8859-1 kompatibel ist.

| Doch er es mir nachmachen will, und sei es nur probeweise,
| der sei gewarnt!

Bevor man in der CONFIG.SYS die Codepage umstellt, müssen vorher aufden
Festplatten *ALLE* Datei- und Verzeichnisnamen geändert werden, die
einen Umlaut enthalten. Das fängt schon mit der »Arbeitsoberfläche« an
(in einer englischen Installation heißt die »Desktop«), die nach einem
Start mit der CP1004 nämlich *nicht* gefunden wird, und auch danach nie
wieder. Als ich das zum erstenmal versuchte, mußte ich anschließend mein
OS/2 komplett neu installieren.



Glückauf!
Erika Ciesla (Mannheim/Deutschland)

--
Fährst Du Fahrrad?
Mußt Du gucken: http://www.erika-ciesla.de

Hallo,

Erika Ciesla wrote:
> Bevor man in der CONFIG.SYS die Codepage umstellt, müssen vorher auf den
> Festplatten *ALLE* Datei- und Verzeichnisnamen geändert werden, die
> einen Umlaut enthalten. Das fängt schon mit der »Arbeitsoberfläche« an
> (in einer englischen Installation heißt die »Desktop«), die nach einem
> Start mit der CP1004 nämlich *nicht* gefunden wird, und auch danach nie
> wieder.

ganz so schlimm ist es nicht. Wenn man die ursprüngliche Codepage noch
als zweite in der Config.sys angegeben hat, geht folgendes:

chcp 437
rename Arbeitsoberfläche xxx
chcp 1004
rename xxx Arbeitsoberfläche

Analog kann man sich per Skript auch durch alle Dateien und
Verzeichnisse mit Sonderzeichen durchfressen, dann passt alles wieder.


Marcel

Marcel Müller schrieb:
> Erika Ciesla wrote:

>> Bevor man in der CONFIG.SYS die Codepage umstellt, müssen vorher auf
>> den Festplatten *ALLE* Datei- und Verzeichnisnamen geändert werden,
>> die einen Umlaut enthalten. Das fängt schon mit der
>> »Arbeitsoberfläche« an (in einer englischen Installation heißt die
>> »Desktop«), die nach einem Start mit der CP1004 nämlich*nicht*
>> gefunden wird, und auch danach nie wieder.
>
> ganz so schlimm ist es nicht. Wenn man die ursprüngliche Codepage noch
> als zweite in der Config.sys angegeben hat, geht folgendes:

Hatte ich ja, hat nix genutzt.

Was ich allerdings nicht verstehe.

Anders als ich liest Der Rechner nicht die Buchstaben, sondern Einsen
und Nullen. Er soll darauf programmiert sein mir auf dem Bildschirm ein
»ä« zu zeigen wenn im Speicher das Byte »54« gespeichert ist, selbst
wissen, daß das ein »ä« ist, muß er nicht.

Nun ändere ich die Codepage, nehme die 1004 statt der 437. Gemäß der
neuen Übersetzungstabelle muß er mir statt der »Arbeitsoberfläche« nun
die »Arbeitsoberfl„che« anzeigen, aber die Bitfolge istdoch noch immer
dieselbe!?

Warum das System mit der CP1004 die »Arbeitsoberfl„che«nicht findet,
kann ich also nicht erklären, noch kann ich es verstehen (das Bytemuster
ist ja dasselbe, nur die Anzeige auf dem Bildschirm ist eine andere),
kann nur aus Erfahrung sagen: es tut nicht.

Aber so richtig geärgert habe ich mich erst, als ich die CONFIG.SYS
wieder in den ursprünglichen Zustand versetzte. Ich habe erwartet, daß
er nun das Verzeichnis wieder findet, aber auch das tut nicht. Einmal
nicht gefunden ist immer nicht gefunden. :-(

Und das gilt leider für *ALLE* Datei- und Verzeichnisnamen.

> chcp 437
> rename Arbeitsoberfläche xxx
> chcp 1004
> rename xxx Arbeitsoberfläche

Nenne es um in »Desktop«, wie es in der englischen Version genannt ist,
und das Problem ist ein für allemal behoben.

Und tu das mit *allem* was Du auf der Platte hast, sonst kriegst Du
»Zombies«, die zwar im Direktory noch erscheinen, auf die Du aber
niemals wieder zugreifen kannst. Auch löschen kannst Du sie nicht.

Jetzt darf man mich natürlich fragen, warum tu ich das überhaupt? Tut
das Not, OS/2 mit der CP1004 laufen zu lassen? Normalerweise nicht, also
kann man die 437 bzw. die 850 auch stehen lassen.

Erklärung: Ich hatte ein Problem.

Ich wollte mal einen Text verfassen der in einem andren Alphabet als dem
lateinischen geschrieben werden sollte. Einen geeigneten Fond hatte ich,
aber der lief nur auf ISO-8859-1. Ärgerlich dabei war, daß der
CHCP-Befehl das Problem nicht löste. Aus einem mir nicht bekannten Grund
wurde das Alphabet nur unvollständig integriert. So kam ich auf die
Idee, es doch mal damit zu versuchen, den Rechner gleich mit der CP1004
booten zu lassen, und dann passierte das was ich beschrieben habe: ich
habe mein OS/2 komplett neu installiert. :-(

Bei einem zweiten Versuch, nämlich als ich wußte was vorher zu tun ist,
gings dann, der exotische Zeichensatz lief.

Das sind Erfahrungen die ich gemacht habe. Ich kann sie beschreiben, die
Probleme, aber nicht erklären.


Glückauf!
Erika Ciesla (Mannheim/Deutschland)

--
Fährst Du Fahrrad?
Mußt Du gucken: http://www.erika-ciesla.de

Hallo,

Erika Ciesla wrote:
>> ganz so schlimm ist es nicht. Wenn man die ursprüngliche Codepage noch
>> als zweite in der Config.sys angegeben hat, geht folgendes:
>
> Hatte ich ja, hat nix genutzt.
>
> Was ich allerdings nicht verstehe.
>
> Anders als ich liest Der Rechner nicht die Buchstaben, sondern Einsen
> und Nullen. Er soll darauf programmiert sein mir auf dem Bildschirm ein
> »ä« zu zeigen wenn im Speicher das Byte »54« gespeichert ist, selbst
> wissen, daß das ein »ä« ist, muß er nicht.
>
> Nun ändere ich die Codepage, nehme die 1004 statt der 437. Gemäß der
> neuen Übersetzungstabelle muß er mir statt der »Arbeitsoberfläche« nun
> die »Arbeitsoberfl„che« anzeigen, aber die Bitfolge ist doch noch immer
> dieselbe!?

Nein, so tickt das Dateisystem nicht. Es ist schlau genug, mit dem
Dateinamen die Codepage, unter der selbiger erzeugt wurde, mit abzulegen.
Allerdings ist es damit nicht getan. Beim lookup nach der Datei müsste
er den angegebenen Namen theoretisch in alle in Frage kommenden
Codepages konvertieren und dann die Datei suchen, bis ein passender
Eintrag gefunden wird. Da endet die Unterstützung von Codepages allerdings.


> Aber so richtig geärgert habe ich mich erst, als ich die CONFIG.SYS
> wieder in den ursprünglichen Zustand versetzte. Ich habe erwartet, daß
> er nun das Verzeichnis wieder findet, aber auch das tut nicht. Einmal
> nicht gefunden ist immer nicht gefunden. :-(

Nein, beim Start ohne Arbeistoberfläche hat es WP_DESKTOP zerlegt. Das
wurde vmtl. in die OS2.INI zurückgeschrieben. Man hätte also auch diese
Datei (und vmtl. OS2SYS.INI) wiederherstellen müssen.


> Nenne es um in »Desktop«, wie es in der englischen Version genannt ist,
> und das Problem ist ein für allemal behoben.

Für /diesen/ Ordner.


Marcel

Marcel Müller schrieb:
> Erika Ciesla wrote:


>> Anders als ich liest Der Rechner nicht die Buchstaben, sondern Einsen
>> und Nullen. Er soll darauf programmiert sein mir auf dem Bildschirm
>> ein »ä« zu zeigen wenn im Speicher das Byte »54« gespeichert ist,
>> selbst wissen, daß das ein »ä« ist, muß er nicht.

Bäh, ich habe Mist getippt. =-O

Das »ä« ist: x84 (CP437) oder xE4 (ISO), wie komme ich auf54?

>> Nun ändere ich die Codepage, nehme die 1004 statt der 437. Gemäß der
>> neuen Übersetzungstabelle muß er mir statt der »Arbeitsoberfläche« nun
>> die »Arbeitsoberfl„che« anzeigen, aber die Bitfolge ist doch noch
>> immer dieselbe!?
>
> Nein, so tickt das Dateisystem nicht.

Was mir schmerzlich aufgefallen ist.

> Es ist schlau genug, ...

Du meinst also, er sucht auch mit der neuen Codepage noch immer nach der
Arbeitsoberfläche mit ä, nur daß er das ä nun tatsächlich auf xE4 finden
möchte, und nicht länger auf x84?

Die »Arbeitsoberfläche« auf Computerisch:

41 72 62 65 69 74 73 6F 62 65 72 66 6C *84* 63 68 65 (CP437/CP850)
41 72 62 65 69 74 73 6F 62 65 72 66 6C *E4* 63 68 65 (ISO)

Und das funzt nicht nur nicht, das ist geradezu tödlich!

>> Aber so richtig geärgert habe ich mich erst, als ich die CONFIG.SYS
>> wieder in den ursprünglichen Zustand versetzte. Ich habe erwartet, daß
>> er nun das Verzeichnis wieder findet, aber auch das tut nicht. Einmal
>> nicht gefunden ist immer nicht gefunden. :-(
>
> Nein, beim Start ohne Arbeistoberfläche hat es WP_DESKTOP zerlegt.Das
> wurde vmtl. in die OS2.INI zurückgeschrieben.

So wird es sein!

> Man hätte also auch diese Datei (und vmtl. OS2SYS.INI) wiederherstellen
> müssen.

Das ist wohl richtig, aber dazu war ich in der Aufregunt temporär zu
dumm für. Daran habe ich erst hinterher gedacht, als ich mit der
Neuinstallation von OS/2 schon fertig war.

Aber wer kein Idiot ist, der lernst aus seinen Fehlern. Habe gestern zum
Beispiel so lange an der OS.INI und anderen systemrelevanten Dateien
herumgebastelt, bis ich es endlich geschafft habe, daß mein OS/2 nicht
nur nicht mehr geht, sondern nicht einmal mehr hochfährt. Das ist
normalerweise die finale Katastrophe.

Aber *DIESMAL* war ich schlauer. Habe nämlich vorher das komplette LW-C:
in ein ZIP-Archiv gepackt und auf einen USB-Steckling kopiert. Nachdem
dann gar nichts mehr ging, habe ich von der ECS-CD die Wartungsplatform
gestartet, die Platte formatiert und das ZIP-Archiv wieder ausgepackt.
Das geht erstens viel schneller als den ganzen Driß wieder neu zu
installieren, und vor allem, auch die gewohnte Möblierung der WPS ist
wieder da.

>> Nenne es um in »Desktop«, wie es in der englischen Version genannt
>> ist, und das Problem ist ein für allemal behoben.
>
> Für /diesen/ Ordner.

Richtig, das war die Kurzfassung. Konkret muß man *ALLE* Verzeichnisse
vorher gründlich durchsuchen und umbenennen, wenn man ein bestehendes
OS/2 auf eine ISO-Codepage umstellen will. Aber wäre dieses Problem
nicht lösbar?

Schon als wir uns alle noch im Fido-Netz tummelten tobten die Kämpfe,
weil der Amiga einen anderen Zeichensatz hatte also der PC, und dieser
wiederum einen anderen als der Apple, der Atari, oder der was auch
immer. Was wir also brauchen ist ein »Esperanto« für den Computer, also
*EINEN* Zeichensatz für alle. Und nein, das ist *nicht* ASCII, das ist
nur der kleinste gemeinsame Nenner.

Es gibt doch seit einiger Zeit ein Zeichensatz der für *alle* nationalen
Belage ausgelegt ist und folglich die Lizens hat, ausnahmslos alle
bisher bestehende Codepages zu ersetzen: Unicode.

Mein Wunsch für die Zukunft wäre darum, daß im Filesystem ausschließlich
in UNICODE gespeichert wird und die nationale Codepage nur noch in der
Schnittstelle zum jeweiligen benutzer Anwendung findet.

Leider verhält sich OS/2 alias eCS in dieser Hinsicht noch etwas
störrisch. Die echte Codepage für ISO-8859-1 wäre IBM-819,aber die will
OS/2 nicht. Komisch! Aber damit kann man leben, die IBM-1004 (das ist
die Windows-1252) ist kompatibel (die enthält eine komplette ISO-8859-1
als Teilmenge), und die geht. Aber wir wollen ja Unicode.

IBM-1200 = UCS-2 bzw. UNICODE
IBM-1208 = UTF8

Und auch die frißt OS/2 nicht. Ich will hoffen, *noch* nicht.

Aber ich habe da was beobachtet, bin mir nur noch nicht sicher was ich
da gesehen habe. Denn als ich mir mit Ubuntu meine OS/2-Laufwerke ansah,
wurden die dort gespeicherten Umlaute korrekt angezeigt. Ubuntu
behauptet, daß es bereits unter UNICODE liefe. Woher zum Teufel weiß der
Pinguin, wie die Umlaute auf meinen OS/2-Laufwerken auszusehen haben?
Hat das was mit dem neuen Filesystem JFS zu tun? Wird darin die Codepage
notiert? Oder läuft JFS gar schon auf Unicode?

Letzteres wäre schön, und ist ja auch gar nicht auszuschließen. Denn in
meiner CONFIG.SYS ist folgender Eintrag zu finden, der lt. Lehrbuch der
erste Eintrag überhaupt sein soll:

DEVICE=C:\OS2\BOOT\UNICODE.SYS

Ich weiß es nicht, ich probiere es mal aus. Ich habe vorgestern meinen
einen USB-Steckling auf JFS formatiert. Darauf werde ich demnächst ein
paar Dateien mit reichlich Umlauten im Namen ablegen. Danach ändere ich
meine lokale Codepage und gucke mir den Steckling nochmal an. Ich werde
dann sehen, ob die Umlaute unverletzt sind, oder ob ich Mist sehe.

Und wenn was schiefgeht, den USB-Stecklin neu zu formatieren tut mir
nicht weh.



Glückauf!
Erika Ciesla (Mannheim/Deutschland)

--
Fährst Du Fahrrad?
Mußt Du gucken: http://www.erika-ciesla.de

Hallo,

Erika Ciesla wrote:
> immer. Was wir also brauchen ist ein »Esperanto« für den Computer, also
> *EINEN* Zeichensatz für alle. Und nein, das ist *nicht* ASCII, das ist
> nur der kleinste gemeinsame Nenner.
>
> Es gibt doch seit einiger Zeit ein Zeichensatz der für *alle* nationalen
> Belage ausgelegt ist und folglich die Lizens hat, ausnahmslos alle
> bisher bestehende Codepages zu ersetzen: Unicode.
>
> Mein Wunsch für die Zukunft wäre darum, daß im Filesystem ausschließlich
> in UNICODE gespeichert wird und die nationale Codepage nur noch in der
> Schnittstelle zum jeweiligen benutzer Anwendung findet.

So schlau waren MS und IBM auch, als sie NTFS für ursprünglich OS/2 3.x
(nicht Warp 3) entwickelt haben. Naja, es ist dann halt nach einigen
Verwerfungen NT 3.1 geworden.

> Leider verhält sich OS/2 alias eCS in dieser Hinsicht noch etwas
> störrisch. Die echte Codepage für ISO-8859-1 wäre IBM-819, aber die will
> OS/2 nicht. Komisch! Aber damit kann man leben, die IBM-1004 (das ist
> die Windows-1252) ist kompatibel (die enthält eine komplette ISO-8859-1
> als Teilmenge), und die geht. Aber wir wollen ja Unicode.
>
> IBM-1200 = UCS-2 bzw. UNICODE
> IBM-1208 = UTF8
>
> Und auch die frißt OS/2 nicht. Ich will hoffen, *noch* nicht.

Die Hoffnung ist unbegründet. Der ganze Kernel ist 8-Bit. Der DBCS-Kram
ist nur in der Shell halbherzig für die Asiaten drangeflickt.


> Aber ich habe da was beobachtet, bin mir nur noch nicht sicher was ich
> da gesehen habe. Denn als ich mir mit Ubuntu meine OS/2-Laufwerke ansah,
> wurden die dort gespeicherten Umlaute korrekt angezeigt. Ubuntu
> behauptet, daß es bereits unter UNICODE liefe. Woher zum Teufel weiß der
> Pinguin, wie die Umlaute auf meinen OS/2-Laufwerken auszusehen haben?
> Hat das was mit dem neuen Filesystem JFS zu tun? Wird darin die Codepage
> notiert? Oder läuft JFS gar schon auf Unicode?

JFS ist Unicode. Bringt aber nix, weil der Kernel es nicht kann.
Die Codepage wird selbst unter HPFS bereits gespeichert, und zwar pro
Datei. Das war vmtl. nötig, um LAN-Server in heterogenen Landschaften zu
betreiben. Das heißt aber nicht unbedingt, dass jene mit anderen
Codepages die Files hätten nutzen können.


> Letzteres wäre schön, und ist ja auch gar nicht auszuschließen. Denn in
> meiner CONFIG.SYS ist folgender Eintrag zu finden, der lt. Lehrbuch der
> erste Eintrag überhaupt sein soll:
>
> DEVICE=C:\OS2\BOOT\UNICODE.SYS

JFS braucht ihn unter anderem, aber auch etliche andere Programme.
Selbst PM123 seit 1.32 oder 1.33 (weiß nicht mehr).


> Ich weiß es nicht, ich probiere es mal aus. Ich habe vorgestern meinen
> einen USB-Steckling auf JFS formatiert. Darauf werde ich demnächst ein
> paar Dateien mit reichlich Umlauten im Namen ablegen. Danach ändere ich
> meine lokale Codepage und gucke mir den Steckling nochmal an. Ich werde
> dann sehen, ob die Umlaute unverletzt sind, oder ob ich Mist sehe.
>
> Und wenn was schiefgeht, den USB-Stecklin neu zu formatieren tut mir
> nicht weh.

Geht auch einfacher, gerade getestet:

chcp 850
md "säöü"
chcp 1004
dir
dir "sõ÷³"

Gibt Hackfleisch, aber die Dateien sind ansprechbar. Sowohl mit HPFS als
auch mit JFS.
Es sieht wohl so aus als wäre an dem Verhalten nochmal irgendwas
gepatcht worden, seit ich das letzte mal getestet habe. Jetzt versucht
OS/2 wohl nicht mehr die Coderpage beim Directory-Listing richtig zu
stellen. Konsequenterweise wird alles falsch angezeigt. Unter dem
falschen Namen ist der Zugriff allerdings möglich.
Früher wurden die Umlaute bei dir korrekt angezeigt, der Zugriff aber
mißlang. Ich nehme an, dass die Filesystem-Treiber einfach immer die
primäre Codepage nehmen, unabhängig davon, was die aktuelle Anwendung
für eine Codepage hat.


Marcel