As per Relevance of the word position, we have this rfc below:
Network Working Group Alan
Request for Comments: 1003 USC/
March 1987
Issues in Defining an Equations Representation
Status of This
This memo is intended to identify and explore issues in defining
standard for the exchange of mathematical equations. No attempt
made at a complete definition and more questions are asked than
answered. Questions about the user interface are only addressed
the extent that they affect interchange issues. Comments
welcome. Distribution of this memo is unlimited
I.
Since the early days of the Arpanet, electronic mail has been
wide use and many regard it as an essential tool. Numerous
lists and newsgroups have sprung up over the years, allowing
numbers of people all over the world to participate remotely
discussions on a variety of topics. More recently, multimedia
systems have been developed which allow users to not only send
receive text messages, but also those containing voice, bitmaps
graphics, and other electronic media
Most of us in the Internet community take electronic mail
granted, but for the rest of the world, it is a brand
capability. Many are not convinced that electronic mail will
useful for them and may also feel it is just an infinite time
(as we all know, this is actually true). In particular,
scientists (apart from computer scientists) do not yet use, or
just beginning to use, electronic mail
The current NSF supercomputer initiative may change this.
primary purpose is to provide remote supercomputer access to a
greater number of scientists across the country. However,
this will involve the interconnection of many university-
networks to NSF supercomputer sites and therefore to the
backbone network. Thus, in the very near future we will have
large number of scientists in the country suddenly able
communicate via electronic mail
Generally, text-only mail has sufficed up until now. One can
of the day (not so far in the future) when everyone will
bitmapped display workstations with multimedia mail systems, but
can get by without it for now. I believe, however, that the new
user community will find one other capability almost essential
making electronic mail useful to them, and that is the ability
Katz [Page 1]
RFC 1003 March 1987
include equations in messages
A glance through any scientific journal will demonstrate
importance of equations in scientific communication. Indeed,
in some fields seem to contain more mathematics than English. It
hard to imagine that when people in these fields are connected
an electronic mail community they will be satisfied with a
system which doesn't allow equations. Indeed, with the advent
the NSF's Experimental Research in Electronic Submission (EXPRESS
project, scientists will begin submitting manuscripts and
proposals directly through electronic mail and the ability to
equations will be essential
Currently, there exists no standard for the representation
equations. In fact, there is not even agreement on what it is
ought to be represented. Users of particular equation systems (
as LaTex or EQN) sometimes advocate just including source files
that system in messages, but this may not be a good long-
solution. With the new NSF community coming on line in the
future, I feel the time is now right to try to define a
which will meet the present and future needs of the user community
Such a standard should allow the interchange of equations
electronic mail as well as be compatible with as many
systems as possible. It should be as general as possible, but
efficiently represent those aspects of equations which are
commonly used. One point to be kept in mind is that most
typesetting is currently being done by secretaries and
typesetters who do not know what the equations mean, only what
look like. Although this is mainly a user interface consideration
any proposed standard must not require the user to understand
equation in order to type it in. We are not interested here
representing mathematics, only displayed equations
In this memo, I will try to raise issues that will need to
considered in defining such a standard and to get a handle on
it is that needs to be represented. Hopefully, this will form
basis of a discussion leading eventually to a definition.
examining what it is that could be or should be represented in
standard, we will first review the characteristics of some
systems
2. Existing
There currently exist many incompatible systems which can
equations to a certain extent. Most of these are extensions to
formatting systems to allow the inclusion of equations. As such
general representation and standards considerations were not a
concern when these systems were initially designed. We will
the three main types of systems: Directive systems,
Language systems, and Full Display systems
Katz [Page 2]
RFC 1003 March 1987
Some text editing facilities simply allow an expanded font set
includes those symbols typically used in mathematics. I do
consider these systems as truly able to handle equations since
of mathematics cannot be represented. It takes more than the
alphabet and an integral and square root symbol to make an
system
Directive systems are those which represent equations and
information in terms of directives embedded in the text. LaTex
EQN are two examples. LaTex is a more friendly version of Knuth'
Tex system, while EQN is a preprocessor for Troff, a
preparation system available under Unix
With these Directive systems, it is usually necessary to
print out the document to see what the equations and formatted
will look like, although there are on-screen previewers which run
workstations such as the Sun. Directive systems have the
that the source files are just text and can be edited with
text editors (such as Emacs) and transferred as text in
electronic messages (a big advantage considering existing
interconnectivity of the various user communities). Also, it
relatively easy to make global changes with the help of
favorite text editor (for example, to change all Greek
alpha's to beta's or all integrals to summation signs in a document
This is generally impossible with the other types of
described below).
The primary disadvantage of these systems is that writing
equation corresponds to writing a portion of a computer program
The equations are sometimes hard to read, generally hard to edit
and one may make syntax errors which are hard to identify. Also
people who are not used to programming, and typesetters who do
actually know what an equation means, only what it should look like
find specifying an equation in this language very difficult and
not be willing to put up with it
Full Display Systems are those such as Xerox STAR and VIEWPOINT
The user enters an equation using the keyboard and sees exactly
equation displayed as it is typed. At all times, what is
is exactly how things will look when it is printed out
Unfortunately, VIEWPOINT does not allow the user to place any
anywhere on the page. There are many things (such as putting
on indices) which are not possible. For those things which
implemented, it works rather nicely
Hockney's Egg is a display system which was developed at the
Physics Department and runs on the IBM PC. It has the advantage
being able to put any character of any font anywhere on the screen
thus allowing not only equations, but things like chemical diagrams
Katz [Page 3]
RFC 1003 March 1987
Interleaf's Workstation Publishing Software system is not
speaking an equations system, but equations may be entered via a
and paste method. At all times, what one sees is what will
printed out and one may put any symbol anywhere on the page.
problem with this system is that one HAS TO put everything in
certain place. It sometimes takes an enormous amount of work to
things to be positioned correctly and to look nice
Generally, Full Display Systems are specific to a particular
of hardware and the internal representation of the equations is
only hidden from the user, but is in many cases proprietary
Symbolic Language systems, such as Macsyma and Reduce, also
the entry of equations. These are in the form of program
calls. These are systems that actually know some mathematics.
can only enter the particular type of mathematics that the
knows
We next will look at what should be represented in an
system. We will want a representation standard general enough
allow (almost) anything which comes up to be represented, but
not require vast amounts of storage
3. What Could be Represented
We will first examine what it is that could be represented. At
most primative level, one could simply store a bitmap of
printed equation (expensive in terms of storage). At the other
of the spectrum, one could represent the actual
information that the equation itself represents (as in the input
Macsyma). In between, one could represent the mathematical
and where they are, or represent a standard set of
notation, as in EQN
It is useful to think of an analogy with printed text. Suppose
have text printed in a certain font. How could it be represented
Well, we could store a bitmap of the printed text, store
and fonts, store words, or at the most abstract, we could store
meaning behind the words
What we actually do, of course, is store characters (in
text) and sometimes fonts (in text intended to be printed). We
not attempt to represent the meaning of words, or even represent
notion of a word. We generally only have characters, separated
spaces or carriage returns (which are also characters). Even
we specify fonts, if a slightly different one happened to be
out it would not matter greatly
Equations may be considered an extension of ordinary text,
with particular fonts. However, the choice of font may be
important. If the wrong font happens to be printed out, the
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
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
the equation. Thus, we will not further consider the types
representations made in the Symbolic Language systems. We
have Directive systems and the Full Display systems. We
assume that both of these will continue to exist and that
defined standard should be able to deal with existing systems
either type
Assuming we do not want to just store a bitmap of the
(which would not allow any easy editing or interfacing with
systems), we are now left with the following possibilities
1. Store characters, fonts and positions only.
anything to be anywhere (this is what Interleaf does).
2. Store characters, fonts, and positions, but only
discrete positions. This makes it easier to
subscripts and superscripts correctly (this is
Hockney's Egg does).
3. Use a language similar to EQN or LaTex, which has
such as subscripts, superscripts, fractions, and
parentheses. Generally positioning is done
when the typesetting occurs, but it is possible to do
sort of relative positioning of symbols with some work
4. Use a language such as Troff or Tex, which is what EQN
Latex is translated into
5. Some combination of the above
In the next section, I will argue for a particular combination
the above as a tentative choice. It may turn out, with
information and experience, that this choice should be modified
4. What I Think Should be
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
compatible with all of the existing systems described previously
If the standard becomes widely accepted, it should be general
not to constrain severely the design of new user interfaces. Thus
while we should provide for efficiently representing those
of equations which are commonly used (subscripts, parentheses, etc.)
we would like extensions to be possible which enable
representation of any symbol anywhere
Katz [Page 5]
RFC 1003 March 1987
We would like standard mathematical symbols, as well as all
and Latin letters to be available. We would also like any
typesetting knowledge to be in programs and not required of
user
I feel that the exact position of a subscript or superscript
not have to be specified by the user or be represented (unless
user specifically wants it to be). It is nice to be able to
any symbol anywhere (and indeed the standard ought to allow
this), but having to do this for everything is not good.
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
extensions to allow positioning of symbols in some kind of
coordinates as well as relative positioning (EQN does allow
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
directly into it, and it should allow representation for
Display systems. The ideas of subscript and superscripts (
having to specify a position), growing parentheses, fractions,
matrices, and special fonts are already there
Most equations can be specified very compactly within EQN, and
positioning is provided as an extension, exceptions can be handled
(The same could be said for LaTex, however, I consider the
there to be somewhat unreadable and prefer EQN. Essentially,
will do).
User interfaces should be able to be easily constructed which
allow one to type in an EQN style specification and have
equation appear immediately on the screen. For non-specialists,
may be better to use existing Full Display systems which are
translated in this EQN like standard (perhaps using a lot of
absolute positioning facility).
5.
In summary
1. A standard for the efficient representation of
equations should be defined as soon as possible in order
allow the interchange of equations in documents and
messages and the transfer of equations between
existing internal representations
2. Most equations entry is currently done by people who do
know what the equations mean, and are not programmers.
may be that the optimal user interface for these people
Katz [Page 6]
RFC 1003 March 1987
different than for those who do know mathematics and/or
programmers. An equations standard should not
this
3. The standard should easily handle those aspects of
which are common, such as the set of things provided in EQN
4. It should also be possible, however, to place any
symbol anywhere and the standard should allow this type
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
interface such that the user must have much
knowledge. This knowledge should be in the user
or printing routines
7. Full Display systems may be best for non-specialists and
non-programmers. Directive systems, perhaps with
ability to preview the final equation on one's screen,
be best for the rest
8. A distinction should be made between the representation
an equation (which we are dealing with here) and
mathematical knowledge it represents
I suggest something like EQN as a standard with extensions to
positioning of symbols in some kind of absolute coordinates as
as relative positioning. This has the advantage that
representation is in ordinary text, which can be sent in messages
the Directive systems can map almost directly into it, and it
allow representation for Full Display systems. The ideas
subscript and superscripts (without having to specify a position),
growing parentheses, fractions, and matrices, and special fonts
already there
Katz [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
