Here are a few things to think about with regard to the format=flowed
option of text/plain.
First of all, some paragraphs are short.
Single line paragraphs are ambiguous as to whether they are fixed or
flowed. I think that it is a little startling to have a fixed-width font
line in between two variable-width paragraphs. Granted, it's not a
capital crime, but it is less than ideal.
It also seems that your latest code has a bug. It does not show a blank
line between two flowed paragraphs.
Here's another issue, reusing the example that Gunnar Hjalmarsson sent
in his last message, but with a subtle difference.
But the rows below are converted to be displayed with the default
font, 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 viewed
with a fixed font, don't you?
Because the code is not set off by blank lines, it is interpreted as
format=flowed. I've checked Eudora and the Mozilla MUA and what they
do is preserve spaces that come after a hard return. They don't switch
back and forth between fixed and variable width fonts in a single
message.
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 heuristic
rule would be used to determine when a paragraph would use a fixed-width
font. The rule I have in mind is that it would be fixed-width if any
line contains three or more internal spaces /\S( |\t)/ or if any line
in it is indented more than the preceding line. Maybe that's a little
perfectionist, but I think it would rarely be wrong. Unfortunately, it
would be a somewhat slow, since I think you'd have to process it line by
line.
One last unfortunate fact which I learned recently; When Mozilla
replies 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 the
maxwidth parameter for format=flowed because there are explicit
provisions 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 converts
it to a flowed paragraph:
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.
---------------------------------------------------------------------
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV