ietf-822
[Top] [All Lists]

Re: text/enriched comments

1993-06-29 06:46:34
Excerpts from mail: 28-Jun-93 text/enriched comments John Gardiner
Myers(_at_)cmu(_dot_) (1061)

The document does not explictly state that formatting commands are
case-insensitive.

Good point.  It should.

The fact that the "verbatim" turns off interpretation of embedded
formatting commands significantly increases the complexity of parsers.
While text/richtext has one special state (comment), text/enriched has
two, with the param state having to watch out for <verbatim>.  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.

The statement about the UNIX newline convention assumption is
nonsensical--it is up to the C language's stdio library to deal with
newline conventions.

Are you claiming here that "\n" is converted to local conventions by all
the world's C compilers?  That was not my understanding, but I'm
delighted to hear it if I'm wrong.

The sample parser botches the following stream:

<param><<</param>

Eek, I'll check it out.

What is the purpose of the line of code:

putc('\n', stdout);

at the end of the sample parser?  It does not appear to correspond to
any part of the text/enriched specification.

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

Excerpts from mail: 28-Jun-93 more text/enriched comments John Gardiner
Myers(_at_)cmu(_dot_) (771)

The specification states that including the literal string
"</verbatim>" inside of a verbatim environment may be done by breaking
up the verbatim segment into two verbatim segments.  This is not
true--a reader is allowed to split the line as follows:

...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?

It is not possible with the supplied command set to turn off
filling, yet still retain interpretation of formatting commands.

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>