rfc1003.txt

RFC 的详细文档！

    of the spectrum, one could represent the actual mathematical
    information that the equation itself represents (as in the input to
    Macsyma).  In between, one could represent the mathematical symbols
    and where they are, or represent a standard set of mathematical
    notation, as in EQN.

    It is useful to think of an analogy with printed text.  Suppose we
    have text printed in a certain font.  How could it be represented?
    Well, we could store a bitmap of the printed text, store characters
    and fonts, store words, or at the most abstract, we could store the
    meaning behind the words.

    What we actually do, of course, is store characters (in ordinary
    text) and sometimes fonts (in text intended to be printed).  We do
    not attempt to represent the meaning of words, or even represent the
    notion of a word.  We generally only have characters, separated by
    spaces or carriage returns (which are also characters).  Even when
    we specify fonts, if a slightly different one happened to be printed
    out it would not matter greatly.

    Equations may be considered an extension of ordinary text, together
    with particular fonts.  However, the choice of font may be extremely
    important.  If the wrong font happens to be printed out, the meaning



Katz                                                            [Page 4]

RFC 1003                                                      March 1987


    of the equation may be completely changed.  There are also items,
    such as growing parentheses, fractions, and matrices, which are
    particular to equations.

    We are not interested in representing the meaning of an equation,
    even if we knew how to in general, but in representing a picture of
    the equation.  Thus, we will not further consider the types of
    representations made in the Symbolic Language systems.  We still
    have Directive systems and the Full Display systems.  We shall
    assume that both of these will continue to exist and that the
    defined standard should be able to deal with existing systems of
    either type.

    Assuming we do not want to just store a bitmap of the equation
    (which would not allow any easy editing or interfacing with existing
    systems), we are now left with the following possibilities:

         1.   Store characters, fonts and positions only.  Allow
              anything to be anywhere (this is what Interleaf does).

         2.   Store characters, fonts, and positions, but only allow
              discrete positions.  This makes it easier to place
              subscripts and superscripts correctly (this is what
              Hockney's Egg does).

         3.   Use a language similar to EQN or LaTex, which has ideas
              such as subscripts, superscripts, fractions, and growing
              parentheses.  Generally positioning is done automatically
              when the typesetting occurs, but it is possible to do a
              sort of relative positioning of symbols with some work.

         4.   Use a language such as Troff or Tex, which is what EQN and
              Latex is translated into.

         5.   Some combination of the above.

    In the next section, I will argue for a particular combination of
    the above as a tentative choice.  It may turn out, with more
    information and experience, that this choice should be modified.

4.  What I Think Should be Represented

    Let us now take a stab at what sort of standard we should have.
    First of all, we would like our standard if at all possible to be
    compatible with all of the existing systems described previously.
    If the standard becomes widely accepted, it should be general enough
    not to constrain severely the design of new user interfaces.  Thus,
    while we should provide for efficiently representing those aspects
    of equations which are commonly used (subscripts, parentheses, etc.)
    we would like extensions to be possible which enable the
    representation of any symbol anywhere.



Katz                                                            [Page 5]

RFC 1003                                                      March 1987


    We would like standard mathematical symbols, as well as all Greek
    and Latin letters to be available.  We would also like any required
    typesetting knowledge to be in programs and not required of the
    user.

    I feel that the exact position of a subscript or superscript should
    not have to be specified by the user or be represented (unless the
    user specifically wants it to be).  It is nice to be able to place
    any symbol anywhere (and indeed the standard ought to allow for
    this), but having to do this for everything is not good.  The
    standard should be able to represent the idea of a subscript,
    superscript, or growing fraction with no more specification.

    My suggestion, therefore, is for something like EQN, but with
    extensions to allow positioning of symbols in some kind of absolute
    coordinates as well as relative positioning (EQN does allow some
    positioning relative to where the next symbol would normally go).
    This has the advantage that the representation is in ordinary text,
    which can be sent in messages, the Directive systems can map almost
    directly into it, and it should allow representation for Full
    Display systems.  The ideas of subscript and superscripts (without
    having to specify a position), growing parentheses, fractions, and
    matrices, and special fonts are already there.

    Most equations can be specified very compactly within EQN, and if
    positioning is provided as an extension, exceptions can be handled.
    (The same could be said for LaTex, however, I consider the syntax
    there to be somewhat unreadable and prefer EQN.  Essentially, either
    will do).

    User interfaces should be able to be easily constructed which would
    allow one to type in an EQN style specification and have the
    equation appear immediately on the screen.  For non-specialists, it
    may be better to use existing Full Display systems which are then
    translated in this EQN like standard (perhaps using a lot of the
    absolute positioning facility).

5.  Conclusions

    In summary:


       1.   A standard for the efficient representation of mathematical
            equations should be defined as soon as possible in order to
            allow the interchange of equations in documents and mail
            messages and the transfer of equations between various
            existing internal representations.

       2.   Most equations entry is currently done by people who do not
            know what the equations mean, and are not programmers.  It
            may be that the optimal user interface for these people is



Katz                                                            [Page 6]

RFC 1003                                                      March 1987


            different than for those who do know mathematics and/or are
            programmers.  An equations standard should not preclude
            this.

       3.   The standard should easily handle those aspects of equations
            which are common, such as the set of things provided in EQN.

       4.   It should also be possible, however, to place any defined
            symbol anywhere and the standard should allow this type of
            specification when needed.

       5.   As many of the existing systems (all of them if possible)
            should be able to be translated into the standard.

       6.   The standard should not make requirements on the user
            interface such that the user must have much typesetting
            knowledge.  This knowledge should be in the user interface
            or printing routines.

       7.   Full Display systems may be best for non-specialists and for
            non-programmers.  Directive systems, perhaps with the
            ability to preview the final equation on one's screen, may
            be best for the rest.

       8.   A distinction should be made between the representation of
            an equation (which we are dealing with here) and the
            mathematical knowledge it represents.

    I suggest something like EQN as a standard with extensions to allow
    positioning of symbols in some kind of absolute coordinates as well
    as relative positioning.  This has the advantage that the
    representation is in ordinary text, which can be sent in messages,
    the Directive systems can map almost directly into it, and it should
    allow representation for Full Display systems.  The ideas of
    subscript and superscripts (without having to specify a position),
    growing parentheses, fractions, and matrices, and special fonts are
    already there.

















Katz                                                            [Page 7]