Frank Markopoulos <[EMAIL PROTECTED]> wrote on 22.04.04:

> nachdem ich jetzt einige Wochen mit FreeXP arbeite,

Erstmal 'ne Frage meinerseits:

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]>, wo ich Dir erkl�rt hatte, wie Du
eingegangene Nachrichten aus dem Spool fischen kannst, und so eine
Nachricht, die in XP2 und FreeXP unterschiedlich dargestellt wird, h�tte
ich mal gerne.

> hier ein paar erste Beobachtungen (Bugreports und Vorschl�ge f�r neue
> Features):

Danke f�rs Feedback. :)  Hier meines dazu:

> a) Nachrichten-Extraktion: Erfolgt jetzt pauschal im Windoofs-Zeichen-
>    satz.

Das w�re mir neu.  Die Nachrichten werden in dem Zeichensatz extrahiert,
in dem sie in den MPUFFERn liegen, und daf�r gelten in XP2 wie in FreeXP
schon seit Jahren folgende Regeln:

- Singlepart-Nachrichten werden in den DOS-Zeichensatz CP437
  konvertiert und in den MPUFFERn abgelegt.

- Multipart-Nachrichten werden nicht zeichensatz-konvertiert (weil sie
  mehrere Zeichens�tze gleichzeitig enthalten k�nnen) und 1:1 abgelegt.
  Beim �ffnen eines Nachrichtenteils wird dieser "on the fly" in den
  DOS-Zeichensatz CP437 konvertiert.

Und so, wie sie abgelegt werden, werden sie auch 1:1 extrahiert (ich
rede jetzt �ber Extraktion "als..Puffer").

> Ich kann das "Warum" daf�r nat�rlich bestens nachvollziehen,

Ich nicht (wenn es so w�re).  Denn auch unter Windows arbeitet man mit
XP in exakt demselben Zeichensatz wie unter DOS, diesbzgl. gibt es gar
keinen Unterschied.

> Da sollte es einen Schalter geben, wo man einstellen kann: DOS- oder
> Windows-Zeichensatz (und ggf. gleich noch Zeilenende-Konvention).

Schalter f�r Zeichensatz hat sich dann ja er�brigt, und Zeilenende-
Konventionen sind bei DOS und Win identisch (n�mlich CRLF).  Alle
Nachrichten in den MPUFFERn sind mit CRLFs abgeschlossen (und wenn
nicht, ist das im Einzelfall ein Fehler).

Was anderes ist es, wenn Du eine Multipart als "Text mit Kopf" (nicht
als Puffer) extrahierst - dann hat man dort (aber eben auch nur dort)
das Problem, da� der Zeichensatz nicht nach CP437 konvertiert wird.   
Dasselbe gilt f�rs Drucken, wenn man auf einer Nachricht "r" dr�ckt.

Da ist Handlungsbedarf und der ist bekannt.

> Dann braucht man keine externen Konvertierungstools zur Umlaut- und
> Zeilenendeformatwandlung mehr.

Brauchst Du auch so nicht, es sei denn, Du willst aus irgendeinem Grunde
von CRLF nach LF konvertieren.

> b) Prima ist die M�glichkeit, Bin�ranh�nge in die Mail selber mit
>    einf�gen zu k�nnen. Soweit, sogut. Aber wenn man x KB Mailtext
>    geschrieben und dann ein x MB langes Archiv dranh�ngt, dann bleibt
>    das jetzt im Puffer h�ngen, weil /N/�/T nach Versand nicht geht.

Doch, geht: N/�/Y, dann N/�/T.

>    Kann man hier nicht eine M�glichkeit einbauen, nach Versand die
>    Anlagen wieder zu l�schen, wobei die Nachricht anschlie�end kein
>    Mime-Multipart mehr ist, sondern nur noch Plaintext

Siehe oben.  Da soll es aber irgendwann mal eine komfortablere
M�glichkeit geben, auch f�r eingegangene Nachrichten (z.B. <Del> auf dem
Nachrichtenteil im Multipart-Auswahldialog l�scht den jeweiligen Teil).

> 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, aber alternativ zu obigem
geht auch folgendes (mache ich manchmal bei extrem gro�en Anh�ngen):

Nachricht als Puffer extrahieren, in einen Editor laden, 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.

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.

> Dabei fiel mir ein �bler Bug auf: Wird der Text im Windoofs-
> Zeichensatz (also so wie unter "/N/X/N" extrahiert) unter DOS
> importiert, wird das "�" falsch dargestellt (als "langer Binde-
> strich", also offenbar gar keine Zeichensatz-Konvertierung).

Das ist kein Bug, sondern eine Fehlbedienung. :)

Du hast vermutlich die MIME-Boundaries samt MIME-Header entfernt, 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.

Es gab allerdings einen Bug in diesem Bereich, der auch in Deiner
Version noch drin ist, aber der verhielt sich IIRC genau andersherum:
Nicht-Multiparts wurden f�r Multiparts gehalten und daher im Lister
konvertiert.

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.

> d) Soeben beobachtet: Versand von ca. 20 News. Ein Artikel von
>    "mittendrin" aus dem Paket hat lokal durchaus einen (v�llig
>    unverd�chtigen) Betreff - aber beim Versand-Versuch via UKA_PPP
>    �ber T-Online meldete der Newsserver: "Betreff fehlt" und der
>    Artikel wurde nicht versandt. Ich probiere es jetzt nochmal. Wenn
>    das weiter-hin so ist, melde ich mich nochmal und lege den Puffer
>    hier bei...

Dazu hattest Du ja bereits was geschrieben und festgestellt, da� der
Betreff doch da ist.  Kann h�chstens ein Bug in UKA_PPP sein, denn ab
dem Zeitpunkt, wo der UUZ die Nachricht konvertiert hat, ist XP raus.

Eine Frage stellt sich mir zu Deinem anderen Posting - Du schreibst:

----------8<----------
> Komisch ist: Ich habe im Spoolverzeichnis von T-Online "N0000.OUT" mit
> "Unerase" wiederhergestellt und das mit dem Ergebnis verglichen, was
> "UUZ -zu <o.g. Puffer> <Ziel>" liefert - ist (bis auf den Zeitstempel)
> identisch und _enth�lt_ den Betreff; hier der Anfang des Headers:

> --------------------------
> Path: t-online.de!fm666
> Date: 22 Apr 2004 19:57:00 +0200
> From: Frank Markopoulos <[EMAIL PROTECTED]>
> Newsgroups: de.soc.weltanschauung.christentum
> Message-ID: <[EMAIL PROTECTED]>
> References: <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> <[EMAIL PROTECTED]>
> Subject: Re: Ich bereue zutiefst ...
> X-Newsreader: CrossPoint/FreeXP v3.40 RC3 (EMS) @ 3108030130 R/A994
> X-No-Archive: yes

> [... usw. ...]
> --------------------------
----------8<----------

Ich nehme mal an, da� die direkt *untereinander* stehenden MsgIDs aus
dem References:-Header nicht dem Originalzustand entsprechen und das
irgendwie durchs Einf�gen in das Posting entstanden ist, richtig?

Die m�ssen n�mlich unbedingt *nebeneinander* in einer Zeile stehen, und
das tun sie hier auch.  So wie oben k�nntest Du das Posting in der Tat
nicht verschicken, es m��te sich wenigstens ein Leerzeichen vor den
MsgIDs befinden, wenn sie schon nicht in einer Zeile stehen.

> e) Beim *Erstanlegen* der Clipboard-Datei unter plain DOS kommt eine
>    unsinnige Fehlermeldung "Schreibschutzverletzung" oder so - aber
>    dann ist CLIP.TXT da und kann benutzt werden. ;-)

Huch?  Wir hatten da mal einen Bug, der unter Linux/Dosemu sogar zu
einem Absturz f�hrte und unter Win2K dazu, da� der Inhalt der Datei
gel�scht wurde (unter DOS hingegen war alles OK).

Mu� man sich mal ansehen, danke f�r den Hinweis.


        Michael
------------------------------------------------------------------------
FreeXP Support-Mailingliste
[EMAIL PROTECTED]
http://www.freexp.de/cgi-bin/mailman/listinfo/support-list

Antwort per Email an