Hallo Liste. Ich bin zwar ein newbie, habe aber bisher stückweise mein Suse in den Griff bekommen und dabei schon einiges gelernt.... Aber an der Umstellung von Outlook zu evolution verzweifle ich noch! Ich habe mir evolution 1.4.4 aufgespielt. Danach bekam ich zwar den Palm in den Griff aber hatte immer noch Probs mit dem Import meiner Adressen. Mit Outport habe ich die Datensätze unter Win erstellt und hinein kopiert. Bisher hatte ich immer eine Reihe von nicht lesbaren Datensätzen. Diese entstanden durch nicht zuweisbare Adressen. Behoben! Jetzt habe ich aber etwas neues. Ich weiß einfach nicht an welchem Rad ich drehen muss: Alle Einträge mit Umlauten enden an diesen. In der addressbook.db stehen die Datensätze mit Umlauten und allem drin. Daran liegt es also nicht (hatte vorher ja funktioniert). PS: Ich habe eine ganze Reihe von TTF in der Systemsteuerung hinzugefügt und mit den versch. Einstellungen für Schriften experimentiert. Leider weiß ich nicht wie ich dem Fehler jetzt auf die Spur kommen soll. In anderen Programmen habe ich keine Probleme mit Umlauten. In den Einstellungen von evolution gibt es nur einen von mir gefundenen Eintrag mit dem Schriften def. werden können: email-Einstellungen/allgemein/'selben Schriften verwenden' Wenn ich hier eine für emails eigene Schrift def. passiert aber nicht um das Importproblem für Adressen zu beheben. Vage Hinweise würden mir schon helfen. Ich fummel mich dann durch. Danke. Kai.
Moin, Am Fr, 2003-09-19 um 23.12 schrieb Kai Krämer:
PS: Ich habe eine ganze Reihe von TTF in der Systemsteuerung hinzugefügt und mit den versch. Einstellungen für Schriften experimentiert.
Leider weiß ich nicht wie ich dem Fehler jetzt auf die Spur kommen soll. In anderen Programmen habe ich keine Probleme mit Umlauten. In den Einstellungen von evolution gibt es nur einen von mir gefundenen Eintrag mit dem Schriften def. werden können: email-Einstellungen/allgemein/'selben Schriften verwenden' Wenn ich hier eine für emails eigene Schrift def. passiert aber nicht um das Importproblem für Adressen zu beheben.
Bei deinem Problem kann ich dir leider nicht helfen, ich kann dir aber sagen, daß du mit den Fonts auf dem Holzweg bist - daran liegt es nicht. Das Problem mit den Umlauten klingt eher nach Codepage oder $LANG Einstellung, evtl. ein Konflikt mit UTF8 oder dergleichen... Sprich: Dein Evolution hat beschlossen, daß am "ä" Schluß ist, das ändert sich nicht dadurch, daß du den Buchstaben eine andere Gestalt gibst. Schau doch erstmal bei ximian.com nach, die haben eine Knowledgebase für evolution. Wenn da nix ist, gibt es ebd. eine Mailingliste, in der man Bugs melden kann. GRuß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Am Sam, 2003-09-20 um 00.05 schrieb Joerg Rossdeutscher:
Bei deinem Problem kann ich dir leider nicht helfen, ich kann dir aber sagen, daß du mit den Fonts auf dem Holzweg bist - daran liegt es nicht.
Dann kann ich das schon mal ausschließen. Habe da schon zu lange rumgesucht. Danke.
Das Problem mit den Umlauten klingt eher nach Codepage oder $LANG Einstellung, Ich habe zwischenzeitlich von ISO8859-1 auf ISO8859-15 umgestellt. Meinst Du das?
evtl. ein Konflikt mit UTF8 oder dergleichen... Sprich: Dein Evolution hat beschlossen, daß am "ä" Schluß ist, das ändert sich nicht dadurch, daß du den Buchstaben eine andere Gestalt gibst. ÄHM? Was ist UTF8?
Schau doch erstmal bei ximian.com nach, die haben eine Knowledgebase für evolution. Wenn da nix ist, gibt es ebd. eine Mailingliste, in der man Bugs melden kann.
GRuß, Ratti
Mach ich. Wenn ich was finde, sage ich Bescheid. Gruß, Kai.
Moin, Am Sa, 2003-09-20 um 00.19 schrieb Kai Krämer:
Am Sam, 2003-09-20 um 00.05 schrieb Joerg Rossdeutscher:
Das Problem mit den Umlauten klingt eher nach Codepage oder $LANG Einstellung, Ich habe zwischenzeitlich von ISO8859-1 auf ISO8859-15 umgestellt. Meinst Du das?
Vom Prinzip her - ja. Allerdings ist der Unterschied zwischen -1 und -15 nur ein einziges Zeichen. -15 enthält den Euro. Es gibt aber noch viel mehr Codierungen als nur die beiden. Solltest du zufällig "recode" installiert haben, tipp mal "recode - l", dann bekommst du eine seeeehr lange Liste, welche Codierungen der kennt und verarbeiten kann. Irgendwo da drin sind auch 8859-1 und -15.
evtl. ein Konflikt mit UTF8 oder dergleichen... Sprich: Dein Evolution hat beschlossen, daß am "ä" Schluß ist, das ändert sich nicht dadurch, daß du den Buchstaben eine andere Gestalt gibst. ÄHM? Was ist UTF8?
Ich kenne mich da nicht so richtig gut aus, aber ich probiere es mal: UTF8 ist ebenso wie 8859-15 eine bestimmte Codierung. Das ist der kommende Standard für Linux. Der Umstieg ist ein ziemlicher Brocken, denn Codierungen wie 8859 "können" nur 255 Zeichen, während solche wie UTF auch Chinesisch und englisch in einer Datei erfassen. Die Methode ist relativ komplex, das lasse ich jetzt mal außen vor, jedenfalls: Evolution ist eines der relativ neuen Programme, die schon schön mit UTF hantieren können. Gelegentlich kommt es zu Problemen, wenn angeflanschte Programme noch mit alten (oder einfach mit anderen) Codepages arbeiten. Falls du ein Windows-Umsteiger bist, kennst du vielleicht den Effekt, daß du alte DOS-Dateien mit dem Windows Texteditor aufmachst, und statt der Umlaute hast du kryptische Zeichen. Oder du bekommst einen Datei von einem Mac-User und hast das gleiche Problem. Da ich zwar evolution benutze, nicht aber die anderen von dir aufgelisteten Tools kann ich dir nicht konkret helfen. Es könnte sein, daß da zwei Tools aneinander vorbeireden, was die Codierung angeht. Daß nicht einfach "falsche" Zeichen auftreten, z.B. { statt ä könnte bedeuten, daß sich da eine 8-bit-codierung wie 8859-15 und eine 16-Bit-Codierung wie UTf ins Gehege kommen. Falls du testweise ein Programm in einer anderen Umgebung starten willst, geht sowas durch setzen von LANG & Co. Kleines Beispiel. Den freien Plattenplatz kannst du mit df -h überprüfen. Wenn du eintippst: LANG="de_DE.UTF-8" df -h erhältst du die Angabe Dateisystem Größe Benut Verf Ben% Eingehängt auf Das gleiche Programm sagt bei LANG="C" df -h Filesystem Size Used Avail Use% Mounted on Beachten, daß das nicht bloß die Sprache betrifft, auch die Codierung ist angegeben. Ich benutze kein Suse-System, sondern Debian unstable, und wie in der oberen Zeile angegeben bereits UTF als Standard.
Schau doch erstmal bei ximian.com nach, die haben eine Knowledgebase für evolution. Wenn da nix ist, gibt es ebd. eine Mailingliste, in der man Bugs melden kann.
Mach ich. Wenn ich was finde, sage ich Bescheid.
Das ist schön, so soll's sein. Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Hallo, Am Sat, 20 Sep 2003, Joerg Rossdeutscher schrieb:
Vom Prinzip her - ja. Allerdings ist der Unterschied zwischen -1 und -15 nur ein einziges Zeichen. -15 enthält den Euro.
Es sind noch ein paar mehr. z.B. 0xA8, 0xB4, 0xB8, 0xBC, 0xBD, 0xBE...
Es gibt aber noch viel mehr Codierungen als nur die beiden. Solltest du zufällig "recode" installiert haben, tipp mal "recode - l", dann bekommst du eine seeeehr lange Liste, welche Codierungen der kennt und verarbeiten kann. Irgendwo da drin sind auch 8859-1 und -15.
'man grep' ist da sehr hilfreich...
evtl. ein Konflikt mit UTF8 oder dergleichen... Sprich: Dein Evolution hat beschlossen, daß am "ä" Schluß ist, das ändert sich nicht dadurch, daß du den Buchstaben eine andere Gestalt gibst. ÄHM? Was ist UTF8?
Ich kenne mich da nicht so richtig gut aus, aber ich probiere es mal:
UTF8 ist ebenso wie 8859-15 eine bestimmte Codierung. Das ist der kommende Standard für Linux. Der Umstieg ist ein ziemlicher Brocken, denn Codierungen wie 8859 "können" nur 255 Zeichen, während solche wie UTF auch Chinesisch und englisch in einer Datei erfassen.
*moep* UTF-8 ist eine bestimmte Variante die 32bit Unicode Zeichen zu kodieren, bei der "zufaelligerweise" die ersten 7bit US-ASCII entsprechen. UTF-8 hat den Vorteil, dass fuer US-ASCII Zeichen auch jew. nur ein Byte benotigt wird. Gehen die Zeichen ueber 7bit/US-ASCII hinaus, so kodiert UTF-8 zuerst mit 2 Bytes, dann mit 3, dann mit 4 und (AFAIK) schliesslich mit 5 Bytes. Ist das Bit 8 == 1, dann heisst das nix anderes, als dass das UTF-8 Zeichen unvollstaendig ist, und dass das naechste Byte herangezogen werden soll -- ebenso bei Bit 15, 23 und 31. Die Details weiss ich jetzt allerdings auch nicht. Da gibt es aber genug Doku zu.
Die Methode ist relativ komplex, das lasse ich jetzt mal außen vor,
Ja. -dnh -- :Mamma, kuck ma, ich bin in der Sicknatur! [Dieter Bruegmann in dag°]
Moin, Am Sa, 2003-09-20 um 02.37 schrieb David Haller:
Am Sat, 20 Sep 2003, Joerg Rossdeutscher schrieb:
UTF8 ist ebenso wie 8859-15 eine bestimmte Codierung. Das ist der kommende Standard für Linux. Der Umstieg ist ein ziemlicher Brocken, denn Codierungen wie 8859 "können" nur 255 Zeichen, während solche wie UTF auch Chinesisch und englisch in einer Datei erfassen.
*moep*
Punktabzug wegen moep'ens! :-) Siehst du in der obigen Oberflächlichen Erklärung einen Fehler, verglichen zu deiner=
UTF-8 ist eine bestimmte Variante die 32bit Unicode Zeichen zu kodieren, bei der "zufaelligerweise" die ersten 7bit US-ASCII entsprechen.
UTF-8 hat den Vorteil, dass fuer US-ASCII Zeichen auch jew. nur ein Byte benotigt wird.
Gehen die Zeichen ueber 7bit/US-ASCII hinaus, so kodiert UTF-8 zuerst mit 2 Bytes, dann mit 3, dann mit 4 und (AFAIK) schliesslich mit 5 Bytes. Ist das Bit 8 == 1, dann heisst das nix anderes, als dass das UTF-8 Zeichen unvollstaendig ist, und dass das naechste Byte herangezogen werden soll -- ebenso bei Bit 15, 23 und 31.
Die Details weiss ich jetzt allerdings auch nicht. Da gibt es aber genug Doku zu.
Der Vorteil von UTF ist, daß es keine "wirren Steuerzeichen" (TM) produziert. Wenn man alles straight in 2-Byte-Codierung durchziehen würde, gäbe es Zeichen, die z.B. den Code 410D hätten. Für ein 2-Byte-fähiges Programm wäre das dann korrekt das Isländische Zeichen für "Damentoilette", aber ein altes 1-Byte-Programm würde hier stolpern: Es würe 410D interpretieren als zwei Zeichen: 41 und 0D. Für 41 würde es ein "A" nehmen, aber "0D" ist ein Zeilenumbruch, und -rumms- würden z.B. die ganzen schönen Kommandozeilentools nicht mehr laufen. Dank der UTF-Codierung gibt es solche Stolperfallen nicht. Ein UTF-Code enthält niemals einen Umbruch, ein Null-Byte oder solche "Specials". Ein altes Programm vielleicht aus "ä}" statt "Damentoilette", aber die Funktionalität bleibt gewährleistet. Außer für Isländerinnen, die ein Klo suchen. Sorry. Gruß, Ratti
Hallo Liste, hallo Ratti Am Sam, 2003-09-20 um 00.54 schrieb Joerg Rossdeutscher:
Das Problem mit den Umlauten klingt eher nach Codepage oder $LANG Einstellung, Ich habe zwischenzeitlich von ISO8859-1 auf ISO8859-15 umgestellt. Meinst Du das?
Schau doch erstmal bei ximian.com nach, die haben eine Knowledgebase für evolution. Wenn da nix ist, gibt es ebd. eine Mailingliste, in der man Bugs melden kann.
Mach ich. Wenn ich was finde, sage ich Bescheid.
Das ist schön, so soll's sein.
Gruß, Ratti
Das Problem ist gelöst: Die Idee mit den verschiedenen Kodierungen war der richtige Hinweis. Ich habe von http://outport.sourceforge.net/ die alte Version 1.1.22 geladen. Es klappt wieder. Der Fehler war also nicht in Evolution 1.4.4 sondern in Outport 1.1.24 zu suchen. Gruß, Kai. PS: Stürzt eigentlich noch jemandem immer wieder der Rechner ab, wenn er seinen Palm mit Evolution (gnome-pilot.d ) synchronisiert? Wie kann das eigentlich unter Linux passieren? Ich dachte immer jeder Prozess sei allein stehend. Dann dürfte sich doch nur der Pilotdeamon aufhängen. Bei mir ist aber alles totenstill!!! Noch mal Grüße. Das habe ich installiert: Suse 8.2 Standardkernel (Suse-CD) evolution 1.4.4.ximian.7.2 evolution-devel 1.4.4.ximian.7.2 evolution-pilot 1.4.4.ximian.7.2 gnome-pilot 2.0.10-0.ximian.7.1 gnome-pilot-devel 2.0.10-0.ximian.7.1 gnome-pilot-applet 2.0.10-0.ximian.7.1 gnome-pilot-conduits 2.0.10-0.ximian.7.1 [Outport 1.1.22 bzw. 1.1.24] was ich sonst noch gefunden habe: perl-PDA-Pilot 0.11.7-24 (Suse-CD) pilot-link 0.11.7-24 (Suse-CD) pilot-link-devel 0.11.7-24 (Suse-CD) control-center 1.4.0.4-525 (Suse-CD) Brauch ich das wirklich alles um zu synchronisieren?
Moin, Am Sa, 2003-09-20 um 20.01 schrieb Kai Krämer:
Am Sam, 2003-09-20 um 00.54 schrieb Joerg Rossdeutscher:
Vorab: Bring mal bitte dein Quoting in Ordnung. Wie schaffst du das überhaupt mit evolution? Der "kämmt" doch sonst nicht... Ich lass dir mal was stehen, damit du weisst, was ich meine:
Das Problem mit den Umlauten klingt eher nach Codepage oder $LANG Einstellung, Ich habe zwischenzeitlich von ISO8859-1 auf ISO8859-15 umgestellt. Meinst Du das?
Schau doch erstmal bei ximian.com nach, die haben eine Knowledgebase für evolution. Wenn da nix ist, gibt es ebd. eine Mailingliste, in der man Bugs melden kann.
PS: Stürzt eigentlich noch jemandem immer wieder der Rechner ab, wenn er seinen Palm mit Evolution (gnome-pilot.d ) synchronisiert? Wie kann das eigentlich unter Linux passieren? Ich dachte immer jeder Prozess sei allein stehend. Dann dürfte sich doch nur der Pilotdeamon aufhängen. Bei mir ist aber alles totenstill!!!
Der Begriff "Absturz" ist relativ weit gefasst. Nein, Linux stützt normalerweise nicht ab. Außerhalb von Betatests seh ich vielleicht zweimal im Jahr 'ne Kiste von unten, und eigentlich immer mit Ursache (Hardwaredefekt, z.B. unsauberes Update wichtiger Komponenten im laufenden System und so). Meistens ist eher die Hardware defekt als Linux buggy. Aber "nicht abgestürzt" kann auch heissen: Die grafische Benutzeroberfläche ist tot, die Tastatur ist tot, die Maus ist tot, aber du kannst dich von außen über eine serielle Konsole noch in den Rechner einloggen und die entsprechenden Dienste zurücksetzen. Das ist dann der Punkt, wo Kollege Homeuser jetzt einfach mal Reset drückt. Logisch. Das sollte aber SEHR selten sein. Sehr, sehr selten. Sonst ist was im argen. Es gibt eine Sache, bei der das System wirklich richtig hängen bleibt, und das sind Hänger im Systemkern selbst, und dazu gehören auch diverse Gerätetreiber, also die paar Progrämmchen, die direkt am Herzen operieren. Es kann sein, daß eine deiner Pilot-Komponenten dazugehört. Weiss ich aber nicht. Die Firma will mir immer so'n Ding andrehen, ich will aber keinen Notizblock mit Strom drin. :-) Gruß, Ratti -- -o) fontlinge | Font management for Linux | Schriftenverwaltung in Linux /\\ http://freshmeat.net/projects/fontlinge/ _\_V http://www.gesindel.de https://sourceforge.net/projects/fontlinge/
Nachtrag:
Das Problem ist gelöst: Die Idee mit den verschiedenen Kodierungen war der richtige Hinweis. Ich habe von http://outport.sourceforge.net/ die alte Version 1.1.22 geladen. Es klappt wieder. Der Fehler war also nicht in Evolution 1.4.4 sondern in Outport 1.1.24 zu suchen.
Gruß, Kai.
Ich habe zur Sicherheit auf einer anderen Partition ein jungfräuliches SUSE 8.2 mit evolution von CD aufgespielt. Bei der Nachinstallation von 1.4.4 sind mir zu viele Bibliotheken mit erneuert worden. Sowohl outport 1.1.23, als auch 1.1.24 verursachen einen Abbruch des Eintrags mit Einsetzen eines Umlauts. Vieleicht kann jemand mit besseren Fach- und Englischkenntnissen bei Outport oder ximian den Fehler melden. Ach ja, in Version outport 1.1.22 werden nicht immer die Notizen exportiert. Wann und wann nicht habe ich mir noch nicht die Mühe gemacht zu prüfen. Aber das Problem ist als Bekannt auf der homepage http://outport.sourceforge.net/ aufgeführt. Auf der hompage wird auch von UTF-8 gesprochen. Ich habe daraufhin mit der SUSE-Hilfe den Eintrag RC_LC_ALL in /etc/sysconfig/language auf RC_LC_ALL="de_DE@euro.UTF-8" gesetzt. Hat sich aber nichts geändert!!! Habe ich die news von outport falsch "übersetzt"? Oder bringt mir der Eintrag da nichts? Die SUSE-Hilfe hat zu UTF noch folgenden Vorschlag: kai@tower:~> localedef -i de_DE@euro -f UTF-8 de_DE@euro.UTF-8 Und das kommt bei mir als Antwort: Das Verzeichnis »/usr/share/i18n/charmaps« der Zeichensatz-Definitionen kann nicht gelesen werden: Datei oder Verzeichnis nicht gefunden Muß ich mir darüber Gedanken machen? Ich habe doch RC_LC_ALL gesetzt? Gruß, Kai -- Kai Krämer Reduitstr. 19 76829 Landau +49 6341 348753
participants (3)
-
David Haller -
Joerg Rossdeutscher -
Kai Krämer