[Top] [All Lists]

Re: text/enriched comments

1993-06-29 08:17:17
Nathaniel Borenstein <nsb(_at_)thumper(_dot_)bellcore(_dot_)com> writes:
The fact that the "verbatim" turns off interpretation of embedded
formatting commands significantly increases the complexity of parsers.
[...] I can
see of no benefit of the turn-off-interpretation directive, what was
the reason for it?

To make it easier to generate text/enriched data that includes things,
e.g. C programs with lots of "<" characters.

If you wan't to include something that isn't text/enriched, don't use
text/enriched.  Use multipart/mixed, with the surrounding text in
text/enriched and included thing in an apropriate content-type.

Compare the respective size and complexity of the minimal
text/richtext and text/enriched parsers.  The text/enriched parser has
at least 50% more code, most of which is for handling verbatim.

Making a composer quote "<" characters and deal with the CRLF
conventions should take 10 lines of code at most.  It's certainly no
more complex than having to deal with quoting "</verbatim>".
The negligible savings you get in the composer are completely
outweighed by the increased complexity of the parser.

If verbatim stays as is, the claim in Appendix B that text/enriched is
a "simplification" of text/richtext should be removed.

Are you claiming here that "\n" is converted to local conventions by all
the world's C compilers?

That's what the C language specification requires.

putc('\n', stdout);

No, it corresponds to a general desire to have the final line of output
show up on line-buffered terminals.

Sample code in specifications should follow the specification to the
letter.  Anything else is likely to mislead implementors.  At least in
RFC 1341, that line was commented...

...slightly challenging to include the literal string "</
verbatim>" inside of a verbatim environment...

Well, I'll admit that I haven't read the spec in detail since I wrote
the last draft nearly half a year ago, but I can't find anything that
says you can split it there.   This may be an ambiguity in the spec; did
you simply assume it was OK to break lines at tokens, even without white
space, or did I actually say that somewhere?

The instant you leave verbatim, there is no longer any directive
against filling.  Since there is no whitespace outside a verbatim,
folding the line there is certainly doing so "intelligently to the
best of its ability."

In short, I think verbatim should just turn off filling and
justification.  Readers can then treat it as any other command.
Composers can easily deal with having to double < and CRLF's.

Well, I've gone back and forth on this quite a few times.  I guess I
would certainly concede that if verbatim's going to stay as it is, there
should also be a "nofill" environment.  My gut feeling is that the
current version is a lot easier on composing software, though.  Other
opinions?  -- NB


<Prev in Thread] Current Thread [Next in Thread>