On October 29, 2002 at 03:31, Gunnar Hjalmarsson wrote:
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 betw
een two variable-width paragraphs. Granted, it's not a capital crime, but it i
s less than ideal.
As I wrote in my recent CVS commit to mhtxtplain.pl, I think the fixed
font rendering is correct according to RFC 2646. However, I changed
the filter to render in non-fixed.
I do agree that there is some ambiguity, but the conversion table
they provide implies that it should be fixed. Maybe the authors of
RFC 2646 should be notified about this.
I should note that Mozilla renders flowed data all in a fixed font (but
flowed text where required) so it ignores the problem.
It also seems that your latest code has a bug. It does not show a blank line
between two flowed paragraphs.
I agree on both those comments, and have attached some modifications
that resolve the issues. To see the difference, please compare
http://www.gunnar.cc/misc/archive/msg00005.html, converted with revision
2.25 of mhtxtplain.pl, with
http://arc.ringlink.org/ringlink-open/msg02452.html, converted with my
(latest) modified version.
Also, I noticed that v2.25 never converts to more than one blank line. I
think that 2 or 3 blank lines between paragraphs should be recognized,
since the use of additional blank lines may be part of a message's
disposition. The attached code takes care of that as well.
Thanks for the patches, but I hopefully just committed more
optimal fixes to the problems. Also, I had to make some other
changes to get the correct rendering. Take the following example:
>> This is some flowed text
>> that is quoted.
This is not quoted and appears without an extra line break.
Previous to my committed changes, the converted page would have a line
break between the two chunks (including both flowed conversion and
fancyquote conversion), an error. To fix it, I modified the inline
style to blockquote and added one to pre elements to suppress the
automatic line space after the end of blockquote and pre elements.
Therefore, if using the quoteclass option, the user will need to take
this into account to get proper rendering sematics.
I also changed the handling of line breaks to get the correct rendering.
I checked IE 6 and Mozilla with my test page, and the page appears
to be rendered properly in both. I used Mozilla's native rendering
of flowed data to compare that line breaks were handled properly.
Since proper rendering does require a CSS-enabled browser, this
provides a good reason for the existence of the disabledflowed option.
Converted messages may not look that good in non-CSS-enabled browsers
and text browsers, so disabling flowed conversion may be needed for
users that want to cater to this usage base.
To sign-off this list, send email to majordomo(_at_)mhonarc(_dot_)org with the
message text UNSUBSCRIBE MHONARC-DEV