Re: The extent of <nofill> and other text/enriched nitpicks

[Pete Resnick <[e-mail]>]

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:[e-mail]>
QUALCOMM Incorporated
Home: [phone] / Fax: [phone]