In <p04320402b58c00185384(_at_)[129(_dot_)46(_dot_)242(_dot_)106]> Randall
Gellens <randy(_at_)qualcomm(_dot_)com> writes:
At 10:41 AM +0000 6/12/00, Charles Lindsey wrote:
If you are considering updates to this spec, then could you please also
put in a feature to retain whatever indentation existed in the original. I
explained to you before the present proposal was adopted that it could
easily be done within the spirit of the present system, but I had come
onto the scene too late in the process to influence what was being done at
that time.
I'd like to keep changes to a minimum, if possible. There is a
demonstrated problem with languages and character sets which do not
necessarily use spaces. This needs to be fixed.
Any changes to F=F should be done in such a way as to maximize
interoperability with existing F=F code.
OK, let me propose an extension, and then let us see how well it
interoperates.
Currently, the receiving agent keeps a 'quote-count'. Let it now also keep
a 'space-count'.
On reception:
1. remove leading '>'s, and set quote-count accordingly.
2. remove 1st leading SP and discard.
3. remove further leading SPs, and set quote-count accordingly.
4. If we are in a flowed paragraph, decide at what point to wrap this
line (or decide to join it with next line).
5. When you are ready to display reformatted line
(a) display quote-count '>' characters
(b) display space-count SP characters
(c) display rest of line
6. Within a paragraph, quote-count and space-count SHOULD be the same
for every line. If they are not, then 'quote-depth-wins'. I.e. treat
the line as fixed (whether it was the quote-count or the space-count
or both that was mismatched).
On generation:
1. space-stuff any line beginning with SP (in addition to
space-stuffing lines beginning with not-for-quoting '>'s).
Example (SPs represented as '_' for visibility):
On reception:
____1._remove_leading_'>'s,_and_set_quote-count_
____accordingly.
____2._remove_1st_leading_SP_and_discard.
____3._remove_further_leading_SPs,_and_
____set_quote-count_accordingly.
____4._If_we_are_in_a_flowed_paragraph,_decide_
____at_what_point_to_wrap_this_line_(or_decide_to_
____join_it_with_next_line)._ <-----deliberate mistake
_______(a)_display_quote-count_'>'_characters
_______(b)_display_space-count_SP_characters
_______(c)_display_rest_of_lineof_line
____6._Within_a_paragraph,_quote-count_and_space-count_
____SHOULD_be_the_same_for_every_line._If_they_are_not,_
____then_'quote-depth-wins'._I.e._treat_the_line_as_
____fixed_(whether_it_was_the_quote-count_or_the_
____space-count_or_both_that_was_mismatched).
When that is received on a system that likes to wrap to 72 cols, it will
recover the version exhibited earlier on.
When received on a system that does not implement the new 'space-count'
feature, it will give:
On reception:
1. remove leading '>'s, and set quote-count accordingly.
2. remove 1st leading SP and discard.
3. remove further leading SPs, and set quote-count accordingly.
4. If we are in a flowed paragraph, decide at what point to wrap_
this line (or decide to join it with next line). (a) display_
quote-count '>' characters
(b) display space-count SP characters
(c) display rest of lineof line
6. Within a paragraph, quote-count and space-count SHOULD be the_
same for every line. If they are not, then 'quote-depth-wins'. I.e._
treat the line as fixed (whether it was the quote-count or the _
space-count or both that was mismatched).
Observe 3 effects:
1. The start of each indented region gets indented correctly, but
subsequent lines are not indented. That is acceptable, I think.
2. There are lots of spurious spaces in the middle of the text. That
is unfortunate.
3. The "deliberate mistake" has produced a horrible effect. But in a
properly generated text it would not have been there in the first place.
So the real question is whether those "spurious spaces" in the short
term are worth the added benefits in the longer term, if we were to put
this additional feature into the revision.
Note that this example was made worse because I had generated the text
using short lines, and read it back on a system with longer lines. More
usually, the reverse would be the case, so fewer spurious spaces would
have been produced.
Note also that if I had taken the original indented text, and generated
it on an older system, it would have come out with spurious spaces in
much the same way. I.e., it does not really make sense to try and use
format=flowed with indented text under the present specification.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Email: chl(_at_)clw(_dot_)cs(_dot_)man(_dot_)ac(_dot_)uk Web:
http://www.cs.man.ac.uk/~chl
Voice/Fax: +44 161 437 4506 Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5