In
<Mailstrom(_dot_)1(_dot_)03(_dot_)19494(_dot_)9528(_dot_)de19(_at_)umail(_dot_)umd(_dot_)edu>,
Dana wrote:
I propose an open extension to the comment facility to provide for such things
as explicit fontnames and font size lists, this would allow senders to imply
suppresion of display of text of significant length. Perhaps:
<Comment-AdobeFont> ITC-MoreThan40Char </Comment-AdobeFont>
<Comment-Bigger>14,18,36,72</Comment-Bigger>
<Comment-foo> ... </Comment-foo>
I think that an extension mechanism which can allow the bracketed
text to be omitted when not understood is clearly desirable. The
idea I had was
<Extension> ... </Extension>
For a text/enriched parser which accepts no extensions,
<Extension> is just like <Comment> (i.e. everything until the
matching </Comment> is ignored). However, a parser which does
provide extensions can look between <Extension>...</Extension>
for extended commands it recognizes. For any it does not
recognize, the bracketed text would still be ignored. (This is,
of course, in marked contrast to the default behavior for
unrecognized and/or extended commands, which is to ignore the
commands but include the bracketed text.)
By way of example,
This is <X-ornatefont>not</X-ornatefont> a test.
<Extension><X-footnote>Or is it?
<X-blurfl>(Maybe?)</X-blurfl></X-footnote></Extension>
would display as
This is not a test.
if no extensions were recognized, and as something like
This is not a test. Or is it?
under a parser/formatter that understood the <X-footnote>
extension (but not the <X-ornatefont or <X-blurfl> extensions).
I haven't checked to see exactly how much this would complicate
the implementation of a minimally-compliant text/enriched parser,
but it shouldn't be much.
Steve Summit
scs(_at_)adam(_dot_)mit(_dot_)edu