After many hundreds of kilobytes of e-mail with those involved in the metamail
richtext project, I have some proposals which I can post here now, can send to
those who request it individually, or we can leave it for the next round.
Please send them to me. If the slightly extended way seems reasonable,
why not? But wouldn't you need multibyte recognition for *all* richtext
readers then, even those only supporting us-ascii?
I was under the impression that the next round has already started,
since Nathaniel replied to me earlier:
# Thanks for the comments. It turns out they are VERY well timed -- I'm
# just about to get serious about the next version of the MIME spec, for
# advancement to Draft Standard status.
There are a few oversights in the minimal compliance requirements
Could you forward them to me, or post them in the mailing list? Since I'm
the primary richtext implementor for metamail, I'll be very interested in it.
Well, I listed them but here they are again, culled from my earlier mail
to Nathaniel:
CONCEPTUAL: The `Richtext Conformance' statement does not require
treatment of </paragraph>, while this is almost required for
interoperability (otherwise </paragraph> is useless because it has to be
embellished with <nl> commands). The minimal program from app D does this
nevertheless; I think it should be added to the minimal conformance
requirements.
CONCEPTUAL: Running the program on the examples also clearly shows the
desirability of white space compression at some points; maybe we should
add this as a minimal requirement? It is trivial to implement.
app D, page 54, translator: this program is still too long (an equivalent
program can be shorter by eliminating code duplication) and does not
satisfy the minimal richtext conformance requirements: it does not
convert CRLFs (newline) to SPACE (as required in sec 7.1 under `Richtext
conformance').
The following 42-line revised version conforms to the minimal
requirements (the only non-minimal thing is the </paragraph>
interpretation, which was already present in the previous version).
#include <stdio.h>
#include <ctype.h>
main() {
int c, i, commct;
char token[42], *p;
commct=0;
while ((c=getc(stdin)) != EOF) {
if (c == '<') {
for (i=0, p=token; (c=getc(stdin)) != EOF && c != '>'; i++)
{
if (i < 41)
*p++ = isupper(c) ? tolower(c) : c;
}
*p = '\0';
if (c == EOF)
break;
if (strcmp(token, "comment") == 0)
commct++;
else if (strcmp(token, "/comment") == 0)
commct--;
else if (commct > 0)
; /* ignore comments */
else if (strcmp(token, "lt") == 0)
putc('<', stdout);
else if (strcmp(token, "nl") == 0)
putc('\n', stdout);
else if (strcmp(token, "/paragraph") == 0)
fputs("\n\n", stdout);
/* ignore others */
} else {
if (commct > 0)
; /* ignore comments */
else if (c == '\n')
putc(' ', stdout);
else
putc(c, stdout);
}
}
putc('\n', stdout);
exit(0);
}
You write:
The example program wasn't meant to be a richtext formatter - it was meant
to demonstrate the minimum amount of work necessary to convert richtext into
something more or less readable by humans.
You missed my point. If the example of a simple richtext parser
does not satisfy the MINIMAL CONFORMANCE requirements for richtext
(because it doesn't convert newline to space, even though this is REQUIRED),
then what good is it to include in the RFC? Besides, the compliant version is
shorter and cleaner :-)
I agree with you on the space compression, though; although it is very
nice to have and doesn't cost much code, it need not be required.
--
Luc Rooijakkers Internet:
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271