Flowed text is a form of text in which spaces play the role of continuation
of paragraphs. Technically it was first defined in
RFC 2646, later extended
in RFC 3676.
The main point of flowed text is to display text correctly despite of the
screen width of the recipient of the message. Depending on the size of the
screen of the recipient of the message, the displayed text may contain
text wrapped in undesirable ways. This is a more delicate point in small
screens (like a PDA, cell phone, etc). Normally when a text written in a
80 columns terminal is displayed in a 30 columns screen, lines are cut in
the middle and the formatting of the message is destroyed. Vice versa,
when a message was written in a 30 columns screen and it is displayed in a
80 column screen, the message feels like it was wrapped too early. The
purpose of flowed text is to be able to send and receive text that will
adapt to the screen width of the display device, no matter what device
that is, so the same text will look well formatted in
a 30 or 80 columns screen.
Pine started supporting flowed text in version 4.60. It can send a display
flowed text correctly.
In every message there are three types of lines, signature separator lines,
flowed lines and fixed lines. There can be any number of these lines.
A signature separator line is a line whose only
content in two dashes followed by a space. This is an old convention in
USENET which got propagated to e-mail.
A flowed line is a line which is not a signature
separator line whose last character is a space. The idea is that the next
line to a flowed line is a line in the same paragraph as that line. In
other words, you are signaling with this space a continuation of
paragraph.
A fixed line is a line that does not end in a space.
A fixed line is the last line of a paragraph.
In other words, in flowed text, a paragraph is composed of several
flowed lines ended by a fixed line.
If you can resize the screen of your web browser to widen or shorten the
columns, you will see the text of this page adapting to the screen width.
This is exactly what is supposed to happen with flowed text in e-mail, and
the interplay between fixed and flowed lines is used to accomplish this.
Of course, you could have a paragraph of only fixed lines, but it will
fail the test described above, which is undesirable since we want text to
adapt to any screen size.
The above plan is a good idea, but there is a problem when you try to
resize quoted text, this is because a 74 characters quoted line, when
resized to a screen of 30 columns a web brower produces, several lines one
of which is quoted, the others are not. There is an intent in this format
to make quoted flowed lines look quoted (in an e-mail program!!) no matter
how small the screen be. Since it is very difficult to guess quotes
strings, in this format there is a simplification, where the only quote
allowed is ">", but not "> " (a bigger than sign followed by a
space). In this way, you only need to count how many consecutive ">"
characters are in a line in order to know what is the quote string of a
paragraph. Pine deviates a little bit of this convention and it accepts
"> " as a quote string too.
Accepting only one type of quote string makes this format simple.
However, there is a tradition of adding a quote to any line that begins
with the string "From ", which adds one level of
quoting to a paragraph containing such line. Due to this problem, the
format destroys this quote by "stuffing a space" to its left. When
processing a message leading spaces from lines must be removed, which
means that if you want to have a space at the beginning of the line you
must add two spaces.
There are more technical details which have been omitted from this
presentation, which you read directly in the RFC that defines flowed text.
This is just a quick summary so that you can get the basic ideas of what
this format is.
[ ] quell-flowed-text: If this option
is enabled, Pine will not send messages that are marked
as flowed text, but still display it.
[ ] strip-white-space-before-send:
There have been wars over this configuration option. In versions previous
to 4.60, Pine used to strip white spaces at the end of a line when it sent
the message. However, some Linux developers complained that this broke
some patches they were submitting, so RedHat decided to patch their
distribution of Pine to not to strip white spaces before the message was
sent. This patch made it into SuSe, as far as I know, and I think even to
Gentoo. RedHat would submit this patch periodically to the Pine Team
without success. Eventually RedHat pulled out Pine from its distribution,
and now Pine includes this feature.
In any case, the point of this feature is that you can have the old
behavior if you want to (by enabling this feature), and in case you do so,
Pine will not tag any messages as flowed text (this
implies that Pine will assume that quell-flowed-text is enabled).
viewer-margin-left: this feature has nothing to do
with flowed text, but it is the symmetrical option to the next one, which
does have to do with flowed text. In any case the number specified here is
the number of spaces added at the beginning of each line when Pine
displays text, be it flowed or not.
viewer-margin-right: One of the problems of the
display of flowed text is that it will be displayed up to right most
column of the screen. This configuration variable tells Pine how many
characters it should leave empty up to the right margin. Normally this
makes reading flowed text nicer. However, if your screen is too wide this
may have the undesirable effect of having too much text in each line of
the screen. In Pine4.61 you can use this feature to specify in which
column you want Pine to wrap flowed text in the screen, this is done by
entering the column number followed by the lowercase letter c, so for example 72c means to wrap text at the 72 column
of the screen.
In Pine4.60 there was a restriction that either this configuration option,
or its symmetrical could not take more than 25% of the screen width. In
Pine4.61 the amount of space left for text displayed in the screen between
these two configuration options must be at least 8 characters. In case
this limit is passed, this variable goes back to its default value of 4
characters.
quote-replace-string (available in version 4.63).
This configuration option has to do with the display of a flowed
message when you read it, this does not apply to what you see
when you reply or forward a message.
This is a configuration option which allows you to replace the quote string
when a flowed text is being displayed. For example one could replace the
quote string to be | instead of >.
This is useful because the default is that different levels of quoting
are displayed separated by spaces, and you can use this option to override
this behavior.
If you use this option you could define this variable to be
">", which has the effect of leaving no
space between quote strings, so more quoted text per line is displayed. The
problem of defining this variable like that, is that your displayed text
will appear merged with the quote string, which may be undesirable. One way
to create such space is to add it to the quote string, as in
"> ". This defeats the purpose of this
variable, since it makes the quote string much longer than needed.
The way to avoid this problem is to define the quote string replace with
no space at the end, to save space and to tell Pine to add a space at the
end, between the full quote string and the displayed text. This is done by
defining this field as ">" " "
(a bigger than sign enclosed in double quotes, separated by a space
of a space enclosed in double quotes). The last space enclosed in quotes is
the text that Pine adds between the full quote string and the text of the
body and can be replaced by anything (yes, even anoter quote string with a
space at the end!)
[X] quote-replace-nonflowed is a feature
which enables Pine to use the quote-replace-string for every message,
not only those that are flowed text.
There are several situations under which Pine will send flowed text.
When composing a new message, or continuing a message that is already
flowed.
When replying to a message, and your quote string is either ">" or
"> ". Observe that if you correspond with someone who uses a
different quote string than the above mentioned strings and has an e-mail
program that is aware of flowed text, then when you quote quoted text in
their messages using either ">" or "> ", there's a very good
chance that the message will look corrupted in the screen of the
recipient, in the sense than the second level of quoting will look
mangled. If your recipient reads the message using Pine, there is a patch which will fix this for you when
you read that message, but if you do not, text may look garbled.
When forwarding a message.
Of course, none of these applies if you have already turned off sending
of flowed text.
In Pine4.61 Pine started offering an option to not to send flowed text
even if you have not enabled any of the features that would permanently
disable sending of flowed text. This can be done when you are in the
editor and press ^X to send a message. In the menu of the bottom of the
screen there is a configuration option ^V, which is active only when the
message that you are going to send will be tagged format=flowed. When you
press ^V Pine will not tag that message as format=flowed.
If you are sending flowed text, and you don't know if your text is
already flowed, you can force it to flow by justifying it. In Pico this is
done by pressing ^J. This only justifies one paragraph at the time. In
Pine 4.60 you can justify the full message by pressing ^W^J, but in
Pine4.61 you can do the same with the command ^W^U (the reason why it was
redefined was because it is possible to press ^W^J without intending to do
so, but not ^W^U). Pine (actually Pico) does a good job of reflowing text
when justifying it (modulo a few disagreements I have with the way some
text is flowed), especially when the only quote string is either ">" or
"> ". If there are other quote strings in the message that you are
trying to flow, you will need a patch
to do this more reliably.