A bunch of responses in one message:
On 8/15/03 at 1:49 PM -0400, Keith Moore wrote:
OK, then let's do a small thought experiment: Why would you need
long lines in English (of course, that are not otherwise addressed
by format=flowed)?
wide tables or "ASCII art", lots of columns of data, data files that
are in character format but not really intended for human
consumption.
And which of those would you ever send in a format=flowed message?
(Remember, the original issue I was answering was why you should
never send QP with Japanese in format=flowed.)
On 8/15/03 at 8:40 PM +0200, Marc Mutz wrote:
As I see it (and Pete has just reinforced my view on this by sharing
it), format=flowed's main feature is to define paragraphs (in
unquoted, but more importantly also in quoted text) and an algorithm
for preserving that information on replies.
Not quite. The main features of format=flowed are:
1. To give *plain text* clients the ability to re-wrap paragraphs
(especially in quoted text) for display. (Of course, this is most
important for clients with smaller screens.)
2. To give clients the ability to reformat reply messages so that
quoted sections (even if they are excerpted from the middle of a
line) are reasonably wrapped and displayed upon receipt.
There are two important things to note about these features: They are
about *display* and they are about *plain text*. Whatever gets to the
other side has to be easily and reasonably displayed by any plain
text reader. The least common denominator you are shooting for is
that someone who ignores that "format=flowed" parameter will do OK.
The best you want is that someone who honors the parameter will be
able to do fancier things. Reliable semantic transmission is not the
primary goal. If you really want to preserve the semantics of
paragraph and quoting reliably, you should be using HTML or XML or
some other markup.
However, that requires trailing whitespace to be preserved, since
line-coupling to paragraphs is lost if TWS is. In my experience,
"preserve TWS" evaluates to "apply QP". Now, that is not suggested
(not to say forbidden) for readability reasons with legacy
(non-QP-aware) MUAs.
If your primary purpose was to preserve semantics, preserving TWS
would be required. Since that's not the primary purpose, it is not
necessary, and more importantly not desirable.
IMO, priority should be on preserving the information for "modern"
MUAs, not on enhancing readability for legacy MUAs[1].
That's why you have HTML.
On 8/16/03 at 4:45 PM -0400, Nathaniel Borenstein wrote:
On Friday, August 15, 2003, at 12:03 PM, Pete Resnick wrote:
When you put it back together, what you get is a single long line
that (for example) should be displayed with a horizontal scrollbar.
It is a representation of a single line, not a wrapped paragraph.
The latter sentence is true, but I have a quibble with your use of
the word "should" in the previous sentence. The fact that the data
object being displayed is properly understood as a single long line
of text does not mandate the choice of one display mechanism over
another. In this case, I would contend that inserting soft line
breaks and avoiding a horizontal scrollbar is more often than not
the more user-friendly thing to do.
If you had said "might" instead of "should" I would have kept my
mouth shut. -- Nathaniel
On one hand, you're correct: The reality of the world is that clients
do dumb things, including marking things as quoted-printable long
lines even though they really don't intend to convey that this line
really *should* be displayed as a single line with a horizontal
scroll bar. On the other hand, a client with a 30 column display
which chooses to display:
Stupid Smart
Pete Resnick Nathaniel =
Borenstein
as:
Stupid Smart
Pete Resnick
Nathaniel Borenstein
instead of using a scrollbar and showing:
Stupid Smart
Pete Resnick Nathaniel Borenstein
is doing their user a disservice. If we are strictly talking about
preserving semantics, you *should* use the horizontal scrollbar. If
we are accounting for what sending clients incorrectly transmit in
the semantics, you are of course correct that we might want to do
something different.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102