rfc1896.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/4 页

     Smaller
          causes the affected text to be in a smaller font. It is
          recommended that the font size be changed by two points,
          but other amounts may be more appropriate in some
          environments. Nested smaller commands produce ever
          smaller fonts, to the limits of the implementation's
          capacity to reasonably display them, after which further
          smaller commands have no incremental effect.

     Bigger
          causes the affected text to be in a bigger font. It is
          recommended that the font size be changed by two points,
          but other amounts may be more appropriate in some
          environments. Nested bigger commands produce ever bigger
          fonts, to the limits of the implementation's capacity to
          reasonably display them, after which further bigger
          commands have no incremental effect.

   While the "bigger" and "smaller" operators are effectively inverses,
   it is not recommended, for example, that "<smaller>" be used to end
   the effect of "<bigger>". This is properly done with "</bigger>".

   Since the capabilities of implementations will vary, it is to be
   expected that some implementations will not be able to act on some of
   the font-alteration commands. However, an implementation should still
   display the text to the user in a reasonable fashion. In particular,
   the lack of capability to display a particular font family, color, or
   other text attribute does not mean that an implementation should fail
   to display text.

Fill/Justification/Indentation Commands

   Initially, text/enriched text is intended to be displayed fully
   filled (that is, using the rules specified for replacing CRLF pairs
   with spaces or removing them as appropriate) with appropriate kerning
   and letter-tracking, and using the maximum available margins as suits
   the capabilities of the receiving user agent software.





Resnick & Walker             Informational                      [Page 6]

RFC 1896            text/enriched MIME Content-type        February 1996


   The following commands alter that state. Each of these commands force
   a line break before and after the formatting environment if there is
   not otherwise a line break. For example, if one of these commands
   occurs anywhere other than the beginning of a line of text as
   presented, a new line is begun.

     Center
          causes the affected text to be centered.

     FlushLeft
          causes the affected text to be left-justified with a
          ragged right margin.

     FlushRight
          causes the affected text to be right-justified with a
          ragged left margin.

     FlushBoth
          causes the affected text to be filled and padded so as to
          create smooth left and right margins, i.e., to be fully
          justified.

     ParaIndent
          causes the running margins of the affected text to be
          moved in. The recommended indentation change is the width
          of four characters, but this may differ among
          implementations. The "paraindent" command requires a
          parameter that is specified by using the "param" command.
          The parameter data is a comma-seperated list of one or
          more of the following:

          Left
               causes the running left margin to be moved to the
               right.

          Right
               causes the running right margin to be moved to the
               left.

          In
               causes the first line of the affected paragraph to
               be indented in addition to the running margin. The
               remaining lines remain flush to the running margin.

          Out
               causes all lines except for the first line of the
               affected paragraph to be indented in addition to the
               running margin. The first line remains flush to the



Resnick & Walker             Informational                      [Page 7]

RFC 1896            text/enriched MIME Content-type        February 1996


               running margin.

     Nofill
          causes the affected text to be displayed without filling.
          That is, the text is displayed without using the rules
          for replacing CRLF pairs with spaces or removing
          consecutive sequences of CRLF pairs. However, the current
          state of the margins and justification is honored; any
          indentation or justification commands are still applied
          to the text within the scope of the "nofill".

   The "center", "flushleft", "flushright", and "flushboth" commands are
   mutually exclusive, and, when nested, the inner command takes
   precedence.

   The "nofill" command is mutually exclusive with the "in" and "out"
   parameters of the "paraindent" command; when they occur in the same
   scope, their behavior is undefined.

   The parameter data for the "paraindent" command may contain multiple
   occurances of the same parameter (i.e. "left", "right", "in", or
   "out").  Each occurance causes the text to be further indented in the
   manner indicated by that parameter. Nested "paraindent" commands
   cause the affected text to be further indented according to the
   parameters. Note that the "in" and "out" parameters for "paraindent"
   are mutually exclusive; when they appear together or when nested
   "paraindent" commands contain both of them, their behavior is
   undefined.

   For purposes of the "in" and "out" parameters, a paragraph is defined
   as text that is delimited by line breaks after applying the rules for
   replacing CRLF pairs with spaces or removing consecutive sequences of
   CRLF pairs. For example, within the scope of an "out", the line
   following each CRLF is made flush with the running margin, and
   subsequent lines are indented. Within the scope of an "in", the first
   line following each CRLF is indented, and subsequent lines remain
   flush to the running margin.

   Whether or not text is justified by default (that is, whether the
   default environment is "flushleft", "flushright", or "flushboth") is
   unspecified, and depends on the preferences of the user, the
   capabilities of the local software and hardware, and the nature of
   the character set in use. On systems where full justification is
   considered undesirable, the "flushboth" environment may be identical
   to the default environment. Note that full justification should never
   be performed inside of "center", "flushleft", "flushright", or
   "nofill" environments.  Note also that for some non-ASCII character
   sets, full justification may be fundamentally inappropriate.



Resnick & Walker             Informational                      [Page 8]

RFC 1896            text/enriched MIME Content-type        February 1996


   Note that [RFC-1563] defined two additional indentation commands,
   "Indent" and "IndentRight". These commands did not force a line
   break, and therefore their behavior was unpredictable since they
   depended on the margins and character sizes that a particular
   implementation used.  Therefore, their use is deprecated and they
   should be ignored just as other unrecognized commands.

Markup Commands

   Commands in this section, unlike the other text/enriched commands are
   declarative markup commands. Text/enriched is not intended as a full
   markup language, but instead as a simple way to represent common
   formatting commands. Therefore, markup commands are purposely kept to
   a minimum. It is only because each was deemed so prevalent or
   necessary in an e-mail environment that these particular commands
   have been included at all.

     Excerpt
          causes the affected text to be interpreted as a textual
          excerpt from another source, probably a message being
          responded to. Typically this will be displayed using
          indentation and an alternate font, or by indenting lines
          and preceding them with "> ", but such decisions are up
          to the implementation. Note that as with the
          justification commands, the excerpt command implicitly
          begins and ends with a line break if one is not already
          there. Nested "excerpt" commands are acceptable and
          should be interpreted as meaning that the excerpted text
          was excerpted from yet another source. Again, this can be
          displayed using additional indentation, different colors,
          etc.

          Optionally, the "excerpt" command can take a parameter by
          using the "param" command. The format of the data is
          unspecified, but it is intended to uniquely identify the
          text from which the excerpt is taken. With this
          information, an implementation should be able to uniquely
          identify the source of any particular excerpt, especially
          if two or more excerpts in the message are from the same
          source, and display it in some way that makes this
          apparent to the user.

     Lang
          causes the affected text to be interpreted as belonging
          to a particular language. This is most useful when two
          different languages use the same character set, but may
          require a different font or formatting depending on the
          language. For instance, Chinese and Japanese share



Resnick & Walker             Informational                      [Page 9]

RFC 1896            text/enriched MIME Content-type        February 1996


          similar character glyphs, and in some character sets like
          UNICODE share common code points, but it is considered
          very important that different fonts be used for the two
          languages, especially if they appear together, so that
          meaning is not lost. Also, language information can be
          used to allow for fancier text handling, like spell
          checking or hyphenation.

          The "lang" command requires a parameter using the "param"
          command. The parameter data can be any of the language
          tags specified in [RFC-1766], "Tags for the
          Identification of Languages". These tags are the two
          letter language codes taken from [ISO-639] or can be
          other language codes that are registered according to the
          instructions in the Langauge Tags RFC. Consult that memo
          for further information.

Balancing and Nesting of Formatting Commands

   Pairs of formatting commands must be properly balanced and nested.
   Thus, a proper way to describe text in bold italics is:

     <bold><italic>the-text</italic></bold>

   or, alternately,

     <italic><bold>the-text</bold></italic>

   but, in particular, the following is illegal text/enriched:

     <bold><italic>the-text</bold></italic>

   The nesting requirement for formatting commands imposes a slightly
   higher burden upon the composers of text/enriched bodies, but
   potentially simplifies text/enriched displayers by allowing them to
   be stack-based. The main goal of text/enriched is to be simple enough
   to make multifont, formatted email widely readable, so that those
   with the capability of sending it will be able to do so with
   confidence. Thus slightly increased complexity in the composing
   software was deemed a reasonable tradeoff for simplified reading
   software. Nonetheless, implementors of text/enriched readers are
   encouraged to follow the general Internet guidelines of being
   conservative in what you send and liberal in what you accept. Those
   implementations that can do so are encouraged to deal reasonably with
   improperly nested text/enriched data.






Resnick & Walker             Informational                     [Page 10]

RFC 1896            text/enriched MIME Content-type        February 1996


Unrecognized formatting commands

   Implementations must regard any unrecognized formatting command as
   "no-op" commands, that is, as commands having no effect, thus
   facilitating future extensions to "text/enriched". Private extensions
   may be defined using formatting commands that begin with "X-", by
   analogy to Internet mail header field names.

   In order to formally define extended commands, a new Internet
   document should be published.

White Space in Text/enriched Data

   No special behavior is required for the SPACE or TAB (HT) character.
   It is recommended, however, that, at least when fixed-width fonts are
   in use, the common semantics of the TAB (HT) character should be
   observed, namely that it moves to the next column position that is a
   multiple of 8. (In other words, if a TAB (HT) occurs in column n,
   where the leftmost column is column 0, then that TAB (HT) should be
   replaced by 8-(n mod 8) SPACE characters.) It should also be noted
   that some mail gateways are notorious for losing (or, less commonly,
   adding) white space at the end of lines, so reliance on SPACE or TAB
   characters at the end of a line is not recommended.