Chris Newman wrote:
It turns out that *every* client which generates text/enriched or
text/html results in largely unreadable output, and that includes the
vendors who gave us assurances about how it would be readable.
This much is true (though I wonder who those assurances came from.)
It may be possible to make this stuff readable, but it requires very
careful engineering -- doing things like merging adjacent style runs,
keeping careful track of the plain-text output column, pushing paragraph
markers to the right edge, making sure spurious plain-text newlines aren't
inserted, not generating boilerplate at the beginning and so forth.
Yes, it requires some care. It's not what I'd consider rocket science,
however.
The fact nobody has done this is adequate evidence that it's too hard
to be practical.
No, it is evidence of no such thing!
If there had seemed to be any *attempt* to do this, and it had just not
worked, then that might be the case. But the reality is that nobody has
even *tried*. Presumably because none of the implementors have seen it
as being important enough to spend time on, for whatever reason.
The kinds of things you're talking about are easy to do as a
post-process, I think (it's really just a peephole optimizer, mostly);
perhaps someone who cared deeply about this (pause for dramatic effect)
should code something up and give it away, so that all the horrible
vendors who couldn't be bothered to invent their own solutions to this
problem could instead just drop in this filter and make everyone happy.
I think I understand why most vendors have not found the time to work on
this. A vendor ships a tool that can display more high-tech messages,
as well as low-tech messages. What is their incentive to work on making
those high-tech messages readable to people using low-tech mail readers?
Those low-tech users are, by definition, not the customers of the
vendor! Yes, the vendor's direct customers need to interact with them,
but see, that's an additional level of indirection.
I think that this is bad, and that backward compatibility is very
important, but it's also easy for me to understand how we got into the
situation we're in today.
In hindsight, we should have developed a markup language using tricks like
_italics_, *bold* and >excerpt for email, so that the markup language
itself would be plain text. Even that would require style-run merging,
but it probably would have worked. Unfortunately, it's too late to
introduce something like that now.
Brad Templeton (I think) proposed something like that years and years
ago, and came to the conclusion that it didn't really work. Then later
he came up with ProleText (http://www.clari.net/prole/prolespec.html)
which ClariNet has been using for a couple of years. (For those who
haven't seen it, it's a way of encoding HTML markup using only
end-of-line whitespace.)
--
Jamie Zawinski http://www.jwz.org/ about:jwz