Re: Line Wrapping Question

["Barton E. Schaefer" <[e-mail]>]

On Feb 7, 11:51pm, Jamie Zawinski wrote:
} Subject: Re: Line Wrapping Question
}
} Hi.  I'm responsible for the MIME support in the Netscape 2.0 mail and news
} readers.

And I'm probably the single largest contributor to the same support in
Z-Mail, though with greatest emphasis on the UNIX side of the UI.

} Microsoft is generating messages with single-line-paragraphs with
} content-type: text/plain and content-transfer-encoding: quoted-printable,
} such that the on-the-wire (encoded) message doesn't have long lines (thus
} not technically violating any RFCs) but which, when decoded, would become 
} unreadable on a system which didn't wrap lines.
} 
} Netscape 2.0 is such a system: when confronted with long lines, Netscape
} puts up a horizontal scrollbar.

Z-Mail makes this optional whenever possible; the character-terminal
version (Lite) can toggle between line wrapping or horizontal scrolling
at display time; the Motif version has an X resource for same (and allows
stretching the window as well, of course).  The Mac and Windows versions
always wrap, but allow streching the window.

(This is on message receipt, of course; the following discusses
composition/sending.)

} I believe that we've got a good, interoperable approach in Netscape 2.0,
} so I'll describe that.  I'd be interested in any comments/criticisms of
} it.

It's remarkably similar to the approach that has been working well in
Z-Mail for years.  However, Z-Mail is a bit less consistent accross
platforms about the details than is Netscape.

} So, the Netscape composition window takes the following approach: let the
} platform-specific text editor do display-time word-wrapping.  If a paragraph
} is typed, and then a word is inserted in the middle of that paragraph, the
} rest of the paragraph should re-wrap.  Hitting return is a "hard" line break
} that will never be auto-filled.

Z-Mail provides a run-time toggle to switch between this behavior and
explicit carriage returns after each line.  In the UNIX versions, the
UI actually changes behavior to reflect this switch; on Mac and Windows
the toggle has an affect only at send time.

} However, when the time comes to deliver the message, Netscape takes all of
} the "implicit" line breaks (where words have wrapped because they reached the
} right edge of the window) and turns them into "explicit" line breaks.

This is what Z-Mail does when automatic word-wrapping is selected.
When automatic wrapping is not selected, it does no extra processing.

} There are several problems with this.
} 
} The first is that, when quoting messages using the conventional USENET style
} (to set off each quoted line by preceeding it with "> ") the line lengths
} tend to get longer with each subsequent quote.
} 
}   > All work and no play makes Jack a dull boy.  All work and no play makes
}   Jack a
} 
} It would be horrible were Netscape to send out messages that looked like
} this.  Therefore, there is an additional hack in the formatting code which
} is that we never wrap lines which have ">" as their first character.

I'm curious how you accomplished this in the Motif text widget.  Or
do you apply this only after the fact?

Z-Mail does occasionally send out messages that look bad in the way
you describe.  Netscape won't do very well with this message, for
example, because I don't use ">" to indent quotations.  (I found a
long time ago that I got mis-attributed less this way.)  Z-Mail does
provide an explicit edit-time formatting operation that identifies
and strips off leading indentation, re-fills the text at a narrower
margin, and then puts back the indentation.

} Now, the next problem with this is that we wrap lines based on where the
} system's built-in text editor has chosen to do display-time word-wrapping.
} This, in turn, is based on the size of the window.

An additional complication with this for Z-Mail is that the user may
select a proportional font for the editor.  At send time, howver, we
do all line wrapping based character counts, not extents.  This means
that the editor is not quite WYSIWYG.

This sort of thing gets even worse when you get into Asian languages
like Chinese or Japanese.

} We create all composition windows 72 characters wide, on all platforms.
} [...] The problem is this: if the user drags the window wider, we will
} then wrap at the current width of the window [...]
} One solution to this, which we rejected, would be to disallow the window from
} being made wider than 79 columns.  That would be bad, because there are
} situations when it is necessary and appropriate to send messages with long
} lines: when formatting a table, for example.

Z-Mail gives the user an option for the character position at which
wrapping should take place; this determines how wide the window should
be.  UNIX and Windows versions then fix the window at that size; the
Mac version permits the window to be wider or narrower, but always
re-fills to the preset wrap position at send.

Long lines can be entered by toggling off word wrapping; we provide an
edit-time fill-paragraph action that inserts hard breaks at the wrap
position, in case you want to mix filled text and long lines.

} Another attractive and often-suggested solution is to cause the editor to
} always do word-wrapping somewhere before 79 columns, regardless of the width
} of the window.

Our users ask for this all the time, too; we haven't done it yet mostly
for the same reasons you listed.

} A simpler version of this hypothetical "more sophisticated" editor would be
} one which inserted "hard" newlines when the user typed a word which passed
} the right edge.  In this editor, typing a paragraph and then inserting a word
} in the middle of it would leave the paragraph with ragged margins.  It would
} then need to provide a "refill paragraph" command to discard and recompute
} the line breaks of that paragraph.

We also rejected this solution, though we went ahead and provided the
"refill paragraph" action.

} Note also, that all of these problems/solutions apply only to the case
} of generating messages of type text/plain, which is all that the Netscape
} mail composition window can directly do at this time.

One additional problem that we frequently encounter is that people
sending messages to recipients who have older mail clients tend to
do things like load uuencoded text directly into the text/plain
message body.  Then they send it without turning off word wrap, and
if there happen to be any space characters in the uuencoded block
(Sun's uuencode is notorious this way) ... well, you get the idea.

-- 
Bart Schaefer                     Vice President, Technology, Z-Code Software
[e-mail]                  Division of NCD Software Corporation
http://www.well.com/www/barts