Frank Markopoulos <[EMAIL PROTECTED]> wrote on 25.04.04:
> [EMAIL PROTECTED] (Michael Heydekamp) teilte uns am 23.04.04 mit:
>> Du hattest mal von einer unterschiedlichen Darstellung in XP2 und
>> FreeXP in Bezug auf Zeilenumbr�che gesprochen und die Ursache ist
>> bisher offengeblieben. Mir fehlt da noch die Antwort auf
>> <[EMAIL PROTECTED]>,
> Der Artikel, an dem ich das _ganz_ deutlich in Erinnerung hatte, war
> bereits nicht mehr auf dem Newsserver.
Hast Du die MsgID noch?
> Ich habe keine Lust, hier bannig viel rumzuinstallieren, nur um
> nochmal ein XP� aufzusetzen, und dann einen anderen Artikel zu finden,
> wo man das derart deutlich merkte...
Nein, an Installieren dachte ich nicht. Ich brauche nur mal die
Nachricht (und am besten im Originalformat).
> Hast Du nicht selber eine XP�-Installation am Laufen?
Ich hab hier st�ndig alle m�glichen XP-Derivate zum Test installiert,
aber ohne entsprechende Nachricht hilft mir das auch nix.
> Es betrifft _nur_ Artikel, die OjE-Junkies (ohne Morver und �hnliche
> Tools) "verbrochen" haben, und zwar die Behandlung des "Kammquoting"
> beim Anzeigen im Lister und dann auch beim Zitieren. Das sah bei XP�
> einfach besser aus bzw. es war bei Antworten darauf weniger Nacharbeit
> im Editor erforderlich.
Was IMO wie gesagt nur zuf�llige Folge eines Bugs sein kann (oder des
Unverm�gens, lange Zeilen im Body auch als lange Zeilen zu belassen).
Eine automatische Kammquoting-Korrektur hat �berhaupt noch kein XP,
FreeXP wird sie beizeiten haben (aber erstmal nur beim Beantworten eines
Postings).
[Multiparts]
>> Beim �ffnen eines Nachrichtenteils wird dieser "on the fly" in den
>> DOS-Zeichensatz CP437 konvertiert.
> Und _da_ steckt der Fehler! Dazu gleich.
Nope, das Problem liegt woanders. Dazu gleich. :)
>>> c) Wegen des Problems bei b) mu�te ich eine solche Mail extrahieren
>>> und neu importieren (mit "E" f�r den User eine neue Mail
>>> kreieren, und dann nicht absenden; Bezugsverkettung geht
>>> nat�rlich fl�ten...).
>> Das Procedere hab' ich nicht ganz verstanden
> Na, einfach ("quick'n'dirty") den "Puffer" (ca. 7 MB lang) auf die
> RAM- Disk (mein Extract-Dir) gelegt und daraus mit "E" f�r den
> Empf�nger eine neue Mail aufgemacht. Dabei wird nat�rlich nicht der
> ganze Mist in den Editor geladen ("Wowereit!" :-), anschlie�end hab
> ich mit ^KB, ^QC, ^KK, ^KY (merkst Du, da� ich seit Mitte der 80er[!
> -damals noch auf dem Z80] die Original-Wordstar-Kommandos gew�hnt
> bin?! ;-) den MIME-Dreck am Ende weggemacht, und die nun nur noch 12
> KB lange "Mail" erstmal zum Versenden vorbereitet, dann /N/U/L
> gemacht und anschlie�end wieder auf "Halten" gesetzt. So liegt sie
> jetzt noch im Userbrett... :-)
Urghs.
>> Nachricht als Puffer extrahieren, in einen Editor laden
> Der M$-Editior f�r DOS (den hab' ich nat�rlich trotzdem installiert)
> ist mir viel zu verworren zu bedienen. Und der QEdit kann lange Texte
> unter DOS auch nur nicht. Dann doch gleich das XP-Bordwerkzeug. :-)
>> base64-codierten Teil l�schen (dabei aber die MIME-Boundaries
>> belassen), einen Dummy-Text (z.B. "Dateianhang wurde entfernt")
>> stattdessen einsetzen, die Nachrichtenl�nge im LEN-Header auf 0
>> setzen und anschlie�end mit ZPR reparieren lassen; urspr�ngliche
>> Nachricht l�schen und Puffer neu einlesen.
> Geht's noch komplizierter? ;-)
Ist nicht kompliziert und allemal "richtiger" alsd Dein Vorgehen da
oben. Aber jeder, wie er will. ;)
>> Das ist dann nach wie vor eine Multipart, aber mit entferntem
>> Anhang. Das ist ungef�hr das, was auch FreeXP machen m��te, wenn man
>> eine solche Funktion sp�er mal implementiert.
> Haaaben will! :-)))
Schon klar.
>> Du hast vermutlich die MIME-Boundaries samt MIME-Header entfernt,
> Bei dem Bin�rkram: ja. Ansonsten steht der Original-Header noch am
> Anfang des Textes der Mail, inklusive der ersten MIME-Part-Begrenzung
> vor dem ASCII-Teil (aber die zweite vor dem 5-MB-Archiv hab' ich dann
> schon gel�scht). Die Mail selber ist nat�rlich _kein_ MIME-Multipart
> mehr (das war ja der Sinn der ganzen Aktion).
Dann handelst Du Dir damit aber eben die Konvertierprobleme ein.
>> daher ist es f�r XP keine Multipart mehr, also geht XP davon aus,
>> da� es die Nachricht nicht mehr konvertieren mu�, weil Singleparts -
>> siehe oben - per Definition bereits vom UUZ konvertiert werden.
> N����, n����, da _ist_ noch ein Bug. Nur(!) das gr��e "�" wird _im_
> _Lister_ NICHT konvertiert angezeigt. Die anderen Umlaute sehe ich
> korrekt.
Ich darf einfach mal vermuten? Die Konvertierung, die bei Dir
stattfindet, ist *nicht* die Konvertierung, wie sie gew�hnlich bei
Multiparts stattfindet (und bei der nat�rlich der deklarierte
Zeichensatz des jeweiligen Nachrichtenteils korrekt ausgewertet wird),
sondern es ist die "stumpfe" ISO=>IBM-Konvertierung, die nur deshalb bei
Dir stattfindet, weil Du den Schalter "ISO-Umlaute konvertieren" unter
C/O/L aktiviert hast.
Abgesehen davon, da� diese Konvertierung ohnehin nicht den Regeln der
Kunst entspricht, nur ein Workaround f�r defekte Nachrichten ist und
eigentlich nicht aktiviert werden sollte (denn damit w�rdest Du auch
einen in UTF-8 vorliegenden Nachrichtenteil als ISO-8859-1 behandeln,
was mal gar nix bringt), steht in der Hilfe zu diesem Schalter:
----------8<----------
Wenn Sie hier [x] einstellen, konvertiert XP diese
Zeichen im Lister und bei Quotes in ein lesbares
Format. Ausgenommen ist das gro�e � - es entspricht
dem IBM-Grafikzeichen "-" und w�rde in Rahmengrafiken
sehr merkw�rdig aussehen.
----------8<----------
Und - richtig geraten?
Normalerweise d�rfte bei dem von Dir beschriebenen Szenario - Nachricht
ist keine Multipart mehr - n�mlich gar keine Konvertierung mehr
stattfinden. Da� sie �berhaupt stattfindet, ist ein klarer Hinweis
darauf, da� Du diesen Schalter aktiviert hast.
Deaktiviere den Schalter, mache den Test mit einer echten Multipart, und
Du wirst sehen, da� das "�" wie alle anderen Umlaute korrekt dargestellt
wird.
Wenn Du aus einer Multipart eine Singlepart machst, ohne dabei auch die
zwingend erforderliche Konvertierung selbst vorzunehmen, sondern
stattdessen den ISO-Hack von XP benutzt, dann verh�lt sich das nat�rlich
auch so wie dokumentiert.
>> Wenn Du die Eigenschaften der Nachricht in so einer Form ver�nderst,
>> dann mu�t Du auch daf�r sorgen, da� der Body in dem Zeichensatz
>> vorliegt, wie es die obigen Regeln vorsehen.
> Body ist Win-Zeichensatz.
Dann mu�t *Du* ihn nach DOS konvertieren. Jedenfalls, wenn XP sich
verhalten soll wie erwartet. Oder so vorgehen wie ich beschrieben
hatte.
[UKA_PPP]
>> Dazu hattest Du ja bereits was geschrieben und festgestellt, da� der
>> Betreff doch da ist. Kann h�chstens ein Bug in UKA_PPP sein
> Wollte ich ja nur mal gemeldet haben. Irgendwie stolpert UKA_PPP �ber
> irgendwas in den References...
Offenbar, obwohl FreeXP den Header nicht einmal foldet. Vielleicht ist
die Zeile f�r UKA_PPP zu lang und es schneidet irgendwas ab (�hnlich wie
XP3P). Auff�llig ist jedenfalls, da� der angeblich fehlende Subject-
Header unmittelbar auf den References-Header folgt.
Man k�nnte als Workaround f�r solche F�lle die Reihenfolge der Header
umstellen, aber dann ist vermutlich der andere auf den References-Header
folgende Header (oder der Body) teilweise geschrottet.
> UKA_PPP ist eben recht buggy. :-(
Interessant w�re mal zu wissen, wieviel Zeichen UKA_PPP bei References
verkraftet.
Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list
