On 2/13/96 at 4:38 AM, Lennart Lovstrand wrote:
Amen. I had exactly the same reflection when writing the text/richtext and
text/enriched converters for NeXT's (RTF-based) mail UA. The updated
text/enriched spec is much clearer and one thing I'm particularly happy to
see explicitly stated is the implied line breaks around paragraph formatting
commands like <center>.
Thanks. Our main purpose was to clarify some of the things that were simply
underspecified. I'm glad you like it.
<nofill> still seems a bit loose, though. In particular, it's not clear to
me exactly what the extent of the affected text really is supposed to be.
From the draft-03 spec, it sounds like it will begin immediately after the
right bracket in "<nofill>" and continue to immediately before the left
bracket in "</nofill>".
That is exactly correct.
However, this means that an example like this:
[...]
since each nofill block will include the CRLF just after <nofill>, the one
just before </nofill>, and the double CRLF between the two blocks will
generate an extra CRLF too.
Yes, it does. However, I don't think we want to play around with this too
much. First, there are a good deal of parsers out there that do this now,
and it's probably not nice to legislate them into illegitimacy. Second, and
more importantly, the idea is that this is supposed to be a simple little
formatting language. The more exceptions we put in, the higher the
complexity. It's probably not optimal, but then again, it's not so bad.
HTML's <pre> command has a special rule for this. It dictates that any
directly adjoining newline to the <pre> command is to be excluded from the
affected text.
Yes, that would be nice. But there are lots of those kinds of things that I
would not necessarily want to impose on someone writing a text/enriched
parser. Remember, it would be nice if this thing went away eventually.
For example, if you have:
--------------------------------
<center>
aaa
bbb
</center>
<center>
xxx
yyy
</center>
--------------------------------
you currently get:
--------------------------------
aaa bbb
xxx yyy
--------------------------------
if I read the spec right.
Actually, as you have written it, you should get an extra space before the
first a and x, as well as extra spaces after the final b and y. This is
because the CRLF after and before each formatting command "counts".
On a related topic, the rule that makes a single CRLFs turn into a space
seems a bit simplistic. For example, this:
--------------------------------
first
<flushleft>
<bold>
second
</bold>
</flushleft>
third
--------------------------------
will generate this:
--------------------------------
first
second
third
--------------------------------
That is, there will be an extra space before both "second" and "third" and
maybe one after "first" and "second" too.
Actually, I count two spaces after "second".
It would probably be better to
borrow an idea from the paragraph commands and say something like "a single
CRLF will cause a space to be produced unless it would mean that it would be
generated immediately next to another space or newline".
Again, we're increasing complexity. It's not that I don't think that these
would be nice ideas; it's just that we were looking to change as little as
possible and effect installed base as little as possible too.
pr
--
Pete Resnick <mailto:presnick(_at_)qualcomm(_dot_)com>
QUALCOMM Incorporated
Home: (217)337-1905 / Fax: (217)337-1980