ietf-822
[Top] [All Lists]

Re: text/enriched draft critique

1993-03-21 18:35:55
3)  Smaller & Bigger.  I dont like the recomendation of a constant 2 pt
differential.  It is awkward for both directions.  Neither do I like a 
formulaic
(ie, 10% change) solution, as it promotes difficulties for non-PS based
displays.  The RichText table recomendation is the only plausible approach I 
can
foresee, and I would suggest that a sample table be cited.  Even better would 
be
provision for specification of the table, with the understanding that some
receivers would have to interpolate or otherwise fudge things.

Also, It is still unclear to me if <Bigger> = </Smaller> (in effect).  

I would like to see seperate "Big" and "Small" states recomended, so that
<Bigger> and <Smaller> index into seperate tables.  This will allow a slightly
more compact  description, especially if a document employs both a Small and a
Big size alternatly:

Dana and I have chatted (and disagreed :-) in private mail about this in
recent weeks.  For the record, here are some arguments for the more intuitive
approach to using <bigger> and <smaller>.

Dana's method proposes that <bigger> and <smaller> be made independent.  This
produces more compact representations when you have small text with some
"really big" text embedded in the middle.  However, I don't feel that the
amount of "really big" text that is embedded in small text is sufficiently
large to warrant diverging from the more intuitive semantics whereby the point
size is increased or decreased based on the current point size, rather than
some point size that is a long way back in the document.

Here's a scenario: suppose that a user wishes to excerpt some enriched text
from some other user's message and render it in a smaller font.  Let's say the
original text was:

        The quick brown fox jumps over the <bigger>lazy</bigger> dog.

The intuitive "smaller excerpting" algorithm would suggest the following:

        <smaller>
        The quick brown fox jumps over the <bigger>lazy</bigger> dog.
        </smaller>

So, comparing the two semantics we have: under my scheme, "lazy" will appear
slightly bigger than the surrounding text, just as it was in the original.
Under Dana's scheme, "lazy" will appear in a point size proportially bigger
than the normal font, rather than the smaller font, making it appear _much_
bigger in respect to the surrounding text than it was in the original.

Dana's scheme using intuitive excerpting gets progressively worse the more
levels of excerpting are done.  Consider:

        <smaller>
        <smaller>
        <smaller>
        The quick brown fox jumps over the <bigger>lazy</bigger> dog.
        </smaller>
        </smaller>
        </smaller>

Now, the word "lazy" would really stick out, since its size would bear
little relationship to the size of the surrounding text.

For the excerpting user to get something similar to his original intentions
in Dana's scheme, he'd have to re-write the sentence as:

        <smaller>
        The quick brown fox jumps over the </smaller>lazy<smaller> dog.
        </smaller>

This has a number of problems: (a) some people on the net could get quite
shirty if their original message was modified during quoting, (b) this returns
back to the "normal" font, which won't look right on a GUI system that say
does 10% size increases instead of 2-point size increases, and (c) in more
complex permutations of <smaller> and <bigger>, it may be very difficult for
the excerpting user (or more likely, the UA) to rearrange the commands to
produce the desired effect, especially when embedded in multiple levels of
excerpting.

       <Smaller>
       ...are described in the following sections.
       <Bigger><Bold>Formatting Commands</Bold></b>

       The text/enriched formatting commands...according to type.

       <Bigger><Bold>Font-Changing Commands</Bold></Bigger>

       The following formatting commands are intended to alter...
       </Smaller>

Dana does have a point here to some extent in that if the user intends to
use a small font for most of the text, with some bigger parts, then his
scheme is more compact.  However, I contend that this would look quite
natural in the intuitive manner as well, where the section headings still
appear larger than the surrounding text.

It needs to be kept in mind that until real enriched text editors become
available, most users will probably avoid trying to be too smart with smaller
and bigger fonts, and when the editors do become available, the compactness
will not be an issue since it will be machine, rather than human generated.

would suffice, instead of the lengthier:

       <Smaller>
       ...are described in the following sections.
       </Smaller><Bigger><Bold>Formatting Commands</Bold></b>

OK, so if it really was your intention to produce something "bigger than the
normal font", wouldn't the following be just as natural:

        <Smaller>
        ...are described in the following sections.
        <Bigger><Bigger><Bold>Formatting Commands</Bold></Bigger></Bigger>
        ...
        </Smaller>

I admit, this is not a common usage, but it is very cheap to support, and
brevity for the transport is desirable.  The only down side I can see is that
one might be tempted to code <Bigger> and </Smaller> as synonyms, but that 
seems
unclean to me.

I don't think it is very cheap to support, based on my richtext implementation
experience, compared to the intuitive scheme.

and also the following layout (common to TOC/indexes)

       <L> Status of this Memo</L><R>i</R>

       <L> Abstract</L><R>i</R>

       <L> The Text/enriched MIME type</L><R>1</R>

This would be overdoing it with text/enriched I feel.  Tables of contents,
indexes etc display page numbers in one of the columns, and since page numbers
are meaningless to text/enriched, such things should probably be left to more
complex formatting languages.  While something like the above would be useful
sometimes, we shouldn't make the semantics so complex that implementing
enriched text formatters is a non-trivial exercise.  UA programmers don't want
to have to re-implement TeX. :-)

8)  "Comment"

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>

I both like and dislike this one.  I like it because it provides a nice way
to declare implementation-specific information that won't affect other
enriched text processors.  But I also dislike it for the same reason, because
we should avoid allowing people to get too implementation-specific.  The
<Comment-Bigger> command also takes control away from the reader as to what
size of fonts they wish to view things.  Where point sizes are important, use
something like Postscript.

The conclusion I have formed is that, charsets comprising multi-byte streams 
are
subject to misinterpretation when parsed for Text/enriched constructs, and that
we propose to transmit "<<" for apparently literal "<" irregardless of the
actual semantics of the original "<".

The difficulty I see here (poorly expresed by the present text) is that a
non-MIME complient reader will be fed garbage as a result.

Just some background:

I did some prototyping of ISO-2022-JP in richtext last year, and finally came
to the conclusion that there is no portable way to handle '<' in such a way
that non-MIME readers won't get garbage if '<' is special to the character
encoding.  This is one of the reasons I posted the ISO-10646/FSS-UTF proposal
a week or so ago: FSS-UTF only uses '<' for '<', and never as part of a
multi-octet character encoding.

In closing, Kudos are due to the authors for this version, I think It will be
implementable, where its predecessor was not.

Well, to be fair, the previous version could be implemented to an extent.
In fact, the implementation extent corresponds pretty closely to what the
cut-down text/enriched type now has, given fairly intuitive interpretations
of the richtext commands.

Cheers,

Rhys.

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