Format=flowed

Here are a few things to think about with regard to the format=flowedoption of text/plain.


First of all, some paragraphs are short.

Single line paragraphs are ambiguous as to whether they are fixed orflowed. I think that it is a little startling to have a fixed-width fontline in between two variable-width paragraphs. Granted, it's not acapital crime, but it is less than ideal.

It also seems that your latest code has a bug. It does not show a blankline between two flowed paragraphs.

Here's another issue, reusing the example that Gunnar Hjalmarsson sentin his last message, but with a subtle difference.

But the rows below are converted to be displayed with the defaultfont, even if they also end with [^ ]\r\n:

   for (split (/[&;]/, $in)) {
       ($name, $value) = split(/=/);
       $value =~ s/%(..)/pack("c",hex($1))/ge;
       $in{$name} = $value;
   }

Typically, when you post a code fragment, you want it to be viewedwith a fixed font, don't you?

Because the code is not set off by blank lines, it is interpreted asformat=flowed. I've checked Eudora and the Mozilla MUA and what theydo is preserve spaces that come after a hard return. They don't switchback and forth between fixed and variable width fonts in a singlemessage.


I think this code would do the trick to fix that problem:

 $para =~ s{(\A|[^ \r]\r?\n)([ \t]+)}
           {$1 . &preserve_space($2)}eg;
before line 563:
 $para =~ s/(^|[^ ])(\r?\n|\Z)/$1<br>$2/mg;

I think that the correct solution would be:
 1. A paragraph ends either with a blank line or a hard return at the
    end of a flowed paragraph.
 2. A paragraph of two or more lines with only hard returns is
    considered fixed.
 3. An ambigous paragraph is formatted with the same font as the
    paragraph that precedes it.
 4. Blank lines are preserved but don't count as a fixed paragraph for
    purposes of rule 3.
 5. Leading spaces are preserved via the code above.

My personal preferences would be that instead of rule 2, a heuristicrule would be used to determine when a paragraph would use a fixed-widthfont. The rule I have in mind is that it would be fixed-width if anyline contains three or more internal spaces /\S( |\t)/ or if any linein it is indented more than the preceding line. Maybe that's a littleperfectionist, but I think it would rarely be wrong. Unfortunately, itwould be a somewhat slow, since I think you'd have to process it line byline.

One last unfortunate fact which I learned recently; When Mozillareplies to a format=fixed message which has paragraphs as one long line,it keeps the reply as one long line. My code will then wrap it with a<PRE> tag, leading to unfortunate viewing. I purposely did not use themaxwidth parameter for format=flowed because there are explicitprovisions in RFC2646 for longer lines. But it looks like for replies,at least, some modification may be necessary.


Here is an example from a Mozilla reply:

This is a test.  This is only a test.  For the next sixty seconds, this message 
will be conducting a test of the long paragraph. Lorem ipsum dolor sit amet, 
consetetur sadipscing elitr, sed diam nonumy eirmod tempor invidunt ut labore 
et dolore magna aliquyam erat, sed diam voluptua. At vero eos et accusam et 
justo duo dolores et ea rebum. Stet clita kasd gubergren, no sea takimata 
sanctus est Lorem ipsum dolor sit amet.

By contrast, Eudora does what I think is the right thing, and convertsit to a flowed paragraph:

This is a test. This is only a test. For the next sixty seconds, thismessage will be conducting a test of the long paragraph. Lorem ipsumdolor sit amet, consetetur sadipscing elitr, sed diam nonumy eirmodtempor invidunt ut labore et dolore magna aliquyam erat, sed diamvoluptua. At vero eos et accusam et justo duo dolores et ea rebum. Stetclita kasd gubergren, no sea takimata sanctus est Lorem ipsum dolor sitamet.


---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV