On 2012-11-24, Derek Martin <inva...@pizzashack.org> wrote: > > It's not a straw man, because format=3Dflowed is functionally > identical to what you're suggesting in every way, except that you > are imposing an ADDITIONAL constraint that a specified number of > line feeds MEANS something. THIS CAN NOT WORK. I've already > explained why.
Your explanation was based in a false ambiguity, so it fails. As I said, there are a distinct number of EOLs unique to each scenario. >> Saying that people will violate a standard of any kind isn't good >> enough because any standard can be abused. > > The difference here is that the violation will be NECESSARILY > commonplace, rendering your standard useless. That's a user problem, one that a good tool cannot solve. Unless you're talking about rendering old text prior to the standard and erroneously detecting that it is conformant to the standard. In this case, you simply have paragraphs rendering as monospaced which should be variable width -- but that's no worse than it was before, and in fact potentially preferrable because it was written with that kind of presentation in mind anyway. > There are many reasons to want extra blank lines in formatted text. And what I described accommodates that by way of a whitespace character followed by an EOL. > There are people who don't want blank lines in their e-mail. Of the two options I described for variable width text following monospaced text, one of them could even accommodate this odd and unimportant need (that is, using the whitespace char, where the absence thereof would be an immediate transition to the other style). > You CAN NOT distinguish between the four possible cases, and you > therefore CAN NOT define a format based on that information. Of course I can, because I've described a unique syntax for each case. That's all that's needed - unlike the ambiguities inherent in the traditional approach.
