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. --ewh --------------------------------------------------------------------- To sign-off this list, send email to [EMAIL PROTECTED] with the message text UNSUBSCRIBE MHONARC-DEV