Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comp.text.misc > #51

text/plain; format=flowed (was: Thunderbird und "format=flowed")

Cross-posted to 2 groups.

Followups directed to: de.comp.text.misc

Show all headers | View raw

 ram@zedat.fu-berlin.de (Stefan Ram):
> =?UTF-8?Q?J=c3=b6rg_Knobloch?= <jorgk@jorgk.com> writes:

 Vorbemerkung:  Diesen Beitrag habe ich im Fließformat verfasst, mit 
 konsequentem space‐stuffing.  Das bedeutet, dass Leser mit 
 Newsreadern, die das Fließformat nicht unterstützen, in ausnahmslos 
 jeder Zeile außer den ganz leeren Zeilen und den Zeilen, die nur 
 Zitatzeichen enthalten, am Zeilenanfang bzw. nach den Zitatzeichen 
 genau ein Leerzeichen zu viel vorfinden werden, während Leser mit 
 Newsreadern, die das Fließformat verstehen, die zusätzlichen 
 Leerzeichen nicht zu Gesicht bekommen.  Damit sollte der Inhalt 
 auch für Leser von nicht‐fließformat‐fähigen Newsreadern 
 einigermaßen nachvollziehbar sein.

>> Genau, das heißt "space stuffing" (und wird hier auch getestet:
>
>  Dieses "space-stuffing" (nicht "space stuffing")
>  wird mit zwei Zielen begründet: 1.) Es sollten Zeilen möglich
>  sein, die mit ">" beginnen, aber keine Zitate sind. 2.) Es soll
>  verhindert werden, daß Systeme, die Nachrichen weiterleiten,
>  "From" am Anfang einer Zeile mit ">From" ersetzen.

 Es gibt noch einen dritten Grund, und der ist eigentlich der 
 nullte:  Das space‐stuffing ermöglicht es dem Absender, den 
 Newsreader des Lesers ausdrücklich das Neuumbrechen des Textes nach 
 Wunsch des Lesers zu empfehlen, und zwar so, dass Zweideutigkeiten 
 vermieden werden.

>
> |In order to allow for unquoted lines which start with ">", and to
> |protect against systems which "From-munge" in-transit messages
> |(modifying any line which starts with "From " to ">From "),
> |Format=Flowed provides for space-stuffing.
> RFC 2046

 Den Text gibt es dort nicht. 


>
>  Beide Probleme habe ich noch nie gesehen.

 Ich habe sie schon gesehen – und die Autoren von RFC 3676 auch.  
 Sonst hätten sie ihn nicht verfasst.  Und den nullten, von dir 
 nicht erwähnten Grund, habe ich auch schon oft in freier Wildbahn 
 gesehen.

>  Daher erscheint mir die "Lösung" hier als schlimmer als die
>  Probleme, welche sie angeblich lösen soll.

 Nimm im folgenden Beispiel einer Nachricht an, die Nachricht soll 
 auf einem Smartphone angezeigt werden, und der Leser hat nicht mehr 
 sehr gute Augen, braucht also große Schrift.  Deshalb hat er nur 
 Platz für 45 Zeichen je Zeile.

 Nimm weiter an, dass er beispielsweise den folgenden Satz angezeigt 
 bekommen soll:

 «An arithmetischen Vergleichsoperatoren gibt es in 
 Programmiersprachen oft die folgenden: =, <>, <, >, <= und >=.»

 Wenn der Absender nicht das Fließformat benutzt, der Leser aber 
 seinen Newsreader anweist, den Text auf 45 Zeichen je Zeile neu zu 
 umbrechen, kann es – je nachdem, wo beim Neuumbrechen ein 
 Zeilenwechsel passiert – durchaus sein, dass er das 
 Größer‐als‐Zeichen als Zitatzeichen präsentiert bekommt, 
 beispielsweise als farbigen senkrechten Balken.  Je nach 
 Anwendungsfall kann das dazu führen, dass der präsentierte Text 
 unverständlich oder missverständlich wird.

 Sein Newsreader kann da ohne Nutzung des Fließformats nur raten – 
 und es kann sein, dass er in diesem Fall falsch rät.


 Hätte der Absender der Nachricht dagegen das Fließformat benutzt, 
 gäbe es keine Zweideutigkeiten, und die Rohform des Textes sähe 
 dann beispielsweise so aus:

 | An arithmetischen Vergleichsoperatoren gibt es in |
 | Programmiersprachen oft die folgenden: =, <>, <, >, <= und >=.|

 Die senkrechten Striche markieren die Zeilenanfänge und ‐enden.  
 Man sieht das space‐stuffing am Zeilenanfang und das Leerzeichen am 
 Ende der ersten Zeile, das anzeigt, dass der Absatz in der nächsten 
 Zeile fortgesetzt wird.


 Der Newsreader des Lesers würde dann beispielsweise folgendes 
 anzeigen.  Vom space‐stuffing ist nichts mehr zu sehen:

 +---------------------------------------------+
 |An arithmetischen Vergleichsoperatoren gibt  |
 |es in Programmiersprachen oft die folgenden: |
 |=, <>, <, >, <= und >=.                      |
 +---------------------------------------------+

 Die senkrechten Striche zeigen den Fensterrand an. 




 Hätte der Absender das Größer‐als‐Zeichen als Zitatkennzeichen 
 verstanden haben wollen, müsste die Rohform des Textes 
 beispielsweise so aussehen:

 | An arithmetischen Vergleichsoperatoren gibt es in |
 | Programmiersprachen oft die folgenden: =, <>, <,|
 |> , <= und >=.|

 Das Größer‐als‐Zeichen muss als Zitatzeichen am Zeilenanfang noch 
 vor dem space‐stuffing sein.  Das space‐stuffing folgt unmittelbar 
 danach vor dem Komma.  Dass die mittlere Zeile am Ende kein 
 Leerzeichen hat, zeigt an, dass dort der Absatz endet.


 Der Newsreader des Lesers würde dann beispielsweise folgendes 
 anzeigen.  Das «#»‐Zeichen steht für den farbigen senkrechten 
 Balken als Zitatmarkierung.  Vom space‐stuffing ist nichts mehr zu 
 sehen:

 +---------------------------------------------+
 |An arithmetischen Vergleichsoperatoren gibt  |
 |es in Programmiersprachen oft die folgenden: |
 |=, <>, <,                                    |
 |#, <= und >=.                                |
 +---------------------------------------------+

 => Der Newsreader auf dem Smartphone ist beim Neuumbrechen des 
 Textes in der Lage, das arithmetische Zeichen vom Zitatzeichen zu 
 unterscheiden, denn das space‐stuffing lässt keinen 
 Interpretationsspielraum.

>
>  Wenn ich Zeilen haben will, die mit ">" beginnen, schütze
>  ich alles mit "|", das ich sowieso aus einem anderen Grund
>  einsetze, nämlich um ein Zitat zu kennzeichnen. Beispiel:

 Und du vergisst dabei, dass es Fälle gibt, die weder Zitate sind 
 noch ASCII‐Grafik einsetzen (s. o.).

 Und vor allem übersiehst du, dass «|» noch weniger als «>» unter 
 Newsreadern allgemein als Zitatzeichen, das beim Neuumbrechen 
 sonderbehandelt werden müsste, anerkannt ist.  Stell dir 
 beispielsweise vor, der anzuzeigende Text will nichts über 
 Arithmetik in Programmiersprachen sondern über Ein‐ und 
 Ausgabeumlenkungsoperatoren im POSIX‐Shell erzählen:  Bei denen 
 gibt es die Operatoren «<», «>», «>>», «>|» und «|».

 => Das Problem des Größer‐als‐Zeichens wird nur verlagert auf ein 
 anderes Zeichen, für das nicht einmal das Fließformat mehr eine 
 Lösung hat:  «|» kann im Fließformat kein Zitatzeichen sein.

>
>  . Ein "From" am Anfang einer Zeile ist in Usenet-Nachrichten
>  ohne weiteres erlaubt. Es gibt keine Grund, es beim Transport
>  irgendwie zu schützen. Hier mal ein Test: Eine Zeile, die nur
>  "From" enthält:
>
> From
>

 Ich habe schon eine Nachricht (aus einer Mailingliste) erhalten, 
 die genau das Problem hatte:  Da begann der erste Satz eines 
 Absatzes mit dem Wort «From» – ich erhielt «>From».

 Vielleicht weißt du das nicht:  Es gibt 
 E‐Mail‐to‐News‐Zweirichtungs‐Gateways, bei denen 
 Mailinglistenbetreiber ihre Liste anmelden können, damit ihre 
 Listenteilnehmer mit dem Newsreader kommunizieren können.

>  . Die Idee, dies mit "space-stuffing" lösen zu wollen, heißt:
>  "Fehlerhafte Systeme fügen Zeichen ein, die der Absender nicht
>  in seine Nachricht geschrieben hat. Deshalb laßt uns jetzt noch
>  mehr Zeichen einfügen!".

 Du hast RFC 3676 nicht vollständig verstanden.  Ehe du das nicht 
 nachholst, kommen wir nicht weiter.

 Mein Vorschlag dafür wäre die Gruppe «de.comp.text.misc», denn die 
 Diskussion des Textformats «text/plain; format=flowed» hat weder 
 mit dem Thunderbird noch direkt mit den Protokollen Netnews oder 
 E‐Mail zu tun.

 Crosspost & Followup-To: de.comp.text.misc 

Back to de.comp.text.misc | Previous | Next | Find similar

Thread

text/plain; format=flowed (was: Thunderbird und "format=flowed") Helmut Waitzmann <nn.throttle@xoxy.net> - 2022-08-26 18:17 +0200

csiph-web