RFC 1003

Network Working Group RFC 1003 🎀

• Request for Comments: 1003, the number of this RFC 💖
• Title: Issues in Defining an Equations Representation Standard ✨
• Author: Alan Katz, USC/ISI 🧚
• Date: March 1987 📅
• Category: not listed in the title block
• Obsoletes / Updates: the title block doesn't list anything this RFC obsoletes or updates 🦋

Status of This Memo 💌

okay so this memo is meant to identify and explore issues in defining a standard for swapping mathematical equations 🧮 it's NOT a complete definition, and honestly there are way more questions than answers rn 🙈 questions about the user interface only get addressed to the extent that they affect interchange 💅 comments are totally welcome, and distribution of this memo is unlimited 🫶

---

I. Introduction 🌸

ever since the early days of the Arpanet, electronic mail has been in wide use, and a lot of people see it as an essential tool 💌 mailing lists and newsgroups have popped up over the years, so huge numbers of people all over the world can join discussions on all kinds of topics remotely 🌍 more recently, multimedia mail systems have been developed that let users send and receive not just text, but messages with voice, bitmaps, graphics, and other electronic media too 🎶

most of us in the Internet community take email for granted, but for the rest of the world it's a brand new capability 🤯 a lot of people aren't convinced email will be useful for them, and they may also feel it's just an infinite time sink (as we all know, this is actually true 💀). especially, most scientists (apart from computer scientists) don't use email yet, or are only just beginning to 🔬

the current NSF supercomputer initiative may change this ✨ its main purpose is to give remote supercomputer access to a way bigger number of scientists across the country 🖥️ but doing that means interconnecting lots of university-wide networks to NSF supercomputer sites, and therefore to the NSF backbone network 🛣️ so in the very near future, we'll have a big number of scientists in the country suddenly able to communicate via email 📬 main character moment for them!

text-only mail has been enough up until now 📝 one can dream of the day (not so far away) when everyone has bitmapped display workstations with multimedia mail systems, but we can get by without it for now 🌈 the author does believe, though, that the new NSF user community will find one other capability almost essential for making email useful to them, and that's the ability to include equations in messages 🧠

a glance through any scientific journal shows how important equations are in scientific communication 📖 honestly, papers in some fields seem to contain more math than English 😭 it's hard to imagine that people in these fields, once they're connected into an email community, will be happy with a mail system that doesn't allow equations 🙅‍♀️ plus, with the NSF's Experimental Research in Electronic Submission (EXPRESS) project, scientists will start submitting manuscripts and project proposals directly through email, so handling equations will be essential 🔥

rn there's no standard for representing equations 🥺 there isn't even agreement on what ought to be represented! users of particular equation systems (such as LaTex or EQN) sometimes push for just including source files of that system in messages, but that may not be a good long-term solution 🙃 with the new NSF community coming online in the near future, the author feels the time is right to try defining a standard that meets the present and future needs of the user community 🎀

such a standard should allow equations to be swapped via electronic mail, and be compatible with as many existing systems as possible 🫶 it should be as general as possible, but still efficiently represent the aspects of equations that are most commonly used ⭐ one thing to keep in mind: most equation typesetting is currently done by secretaries and professional typesetters who don't know what the equations mean, only what they look like 👀 even though this is mainly a user interface consideration, any proposed standard must not require the user to understand an equation in order to type it in 💖 and to be clear, we're not interested here in representing mathematics, only displayed equations 🦋

in this memo, the author will try to raise issues that need to be considered when defining such a standard, and get a handle on what it is that needs to be represented 🧩 hopefully this will form the basis of a discussion that eventually leads to a definition 💜 before looking at what could or should be represented, we'll first review the characteristics of some existing systems 🔍

---

2. Existing Systems 💅

there are currently many incompatible systems that can handle equations to a certain extent 🌷 most of these are extensions to text formatting systems that allow equations to be included 📄 since that's the case, general representation and standards considerations weren't a major concern when these systems were first designed 🙈 we'll look at the three main types: Directive systems, Symbolic Language systems, and Full Display systems 🎀

some text editing facilities just allow an expanded font set that includes the symbols typically used in mathematics 🔤 the author doesn't consider these systems truly able to handle equations, since much of mathematics can't be represented with them 😬 it takes more than the Greek alphabet and an integral and square root symbol to make an equations system, babe 🧠

Directive systems are the ones that represent equations and formatting information in terms of directives embedded in the text ✍️ LaTex and EQN are two examples 🌸 LaTex is a friendlier version of Knuth's Tex system, while EQN is a preprocessor for Troff, a document preparation system available under Unix 🐣

with Directive systems, you usually have to actually print out the document to see what the equations and formatted text will look like, although there are on-screen previewers that run on workstations such as the Sun 🖨️ the big win is that the source files are just text, so they can be edited with standard text editors (such as Emacs) and transferred as text in standard electronic messages, which is a huge advantage given how the various user communities are already mail-connected 📬 it's also relatively easy to make global changes with your favorite text editor, like changing all Greek letter alpha's to beta's, or all integrals to summation signs in a document 🪄 this is generally impossible with the other types of systems described below 🙌

the primary downside is that writing an equation is basically like writing part of a computer program 💻 equations can be hard to read, generally hard to edit, and you can make syntax errors that are hard to spot 😵 also, people who aren't used to programming, and typesetters who don't actually know what an equation means (only what it should look like), find specifying an equation in this language really difficult, and they may not be willing to put up with it 🥲

Full Display Systems are things like Xerox STAR and VIEWPOINT 🖥️ the user enters an equation with the keyboard and sees exactly that equation displayed as it's being typed ✨ at all times, what's displayed is exactly how things will look when printed 🖨️ unfortunately, VIEWPOINT doesn't let the user place any symbol anywhere on the page, so there are a lot of things (like putting dots on indices) that aren't possible 😩 for the things that are implemented, it works rather nicely 💅

Hockney's Egg is a display system developed at the UCLA Physics Department that runs on the IBM PC 🥚 its big advantage is that it can put any character of any font anywhere on the screen, which means it can handle not only equations but things like chemical diagrams too 🧪 iconic, honestly 👑

Interleaf's Workstation Publishing Software isn't strictly speaking an equations system, but equations can be entered with a cut and paste method 📋 at all times, what you see is what gets printed, and you can put any symbol anywhere on the page 🗺️ the problem is that one HAS TO put everything in a certain place, and it sometimes takes an enormous amount of work to get things positioned correctly and looking nice 😭

generally, Full Display Systems are specific to a particular piece of hardware, and their internal representation of equations is not only hidden from the user, but in many cases proprietary 🔒 not very shareable, bestie 🙃

Symbolic Language systems, such as Macsyma and Reduce, also allow the entry of equations 🧮 these are in the form of program function calls, and they're the systems that actually know some mathematics 🤓 the catch is that you can only enter the particular type of mathematics the system knows 🧠

next up, we'll look at what should be represented in an equations system 💖 we want a representation standard that's general enough to allow (almost) anything that comes up to be represented, but that doesn't require vast amounts of storage 🦋

3. What Could be Represented? ✨

okay so first we need to figure out what it even is that we could represent 🤔 at the most primitive level, you could just store a bitmap of every printed equation (ngl that's expensive storage-wise 💀). at the other end of the spectrum, you could represent the actual math information the equation is about, like what you'd feed into Macsyma 🧠. in between, you could represent the math symbols and where they sit, or a standard set of math notation, like EQN 🎀.

it helps to think about printed text 📝 say you have text printed in a certain font. how could it be represented? we could store a bitmap of the printed text 🖼️, store characters and fonts, store words, or, at the most abstract, store the meaning behind the words 🌈.

what we actually do is store characters (in ordinary text) and sometimes fonts (in text meant to be printed) 🫶. we don't try to represent the meaning of words, or even the notion of a word 🙈. we generally just have characters, separated by spaces or carriage returns (which are also characters) ✨. even when we specify fonts, if a slightly different one got printed out it wouldn't matter greatly 💅.

equations kinda count as an extension of ordinary text, plus particular fonts 🧚. BUT the choice of font can be super important 😭. if the wrong font gets printed out, the meaning of the equation could be completely changed 💀. there are also things that are particular to equations, like growing parentheses, fractions, and matrices 🦋.

we are not interested in representing the meaning of an equation, even if we knew how to in general 🙅. we want to represent a picture of the equation 📸. so we won't go further into the types of representations made in the Symbolic Language systems. we still have Directive systems and Full Display systems 💖. we'll assume both of these keep existing, and that the defined standard should be able to deal with existing systems of either type 👑.

assuming we don't want to just store a bitmap of the equation (which wouldn't allow any easy editing or interfacing with existing systems) 🙃, we're left with these 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

okay, let's take a stab at what sort of standard we should have 🎯. first of all, we'd 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 severely constrain the design of new user interfaces 🌸. so while we should provide for efficiently representing the aspects of equations that are commonly used (subscripts, parentheses, etc.), we'd like extensions to be possible that enable the representation of any symbol anywhere 🌟.

we'd like standard mathematical symbols, as well as all Greek and Latin letters, to be available 🔤. we'd also like any required typesetting knowledge to live in programs and not be 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's nice to be able to place any symbol anywhere (and the standard ought to allow for this), but having to do that 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 than that 💕.

so my suggestion 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 too 🦄. the ideas of subscript and superscripts (without 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 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 easy to construct that would allow someone 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 into this EQN-like standard (perhaps using a lot of the absolute positioning facility) 🫧.

---

5. Conclusions

okay, 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 equation entry is currently done by people who don't know what the equations mean, and who aren't programmers 🙋‍♀️. it may be that the optimal user interface for these people is different from the one 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 that are common, such as the set of things provided in EQN 🍰.
4. It should also be possible 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 non-programmers. Directive systems, perhaps with the ability to preview the final equation on one's screen, may be best for everyone else 👀.
8. A distinction should be made between the representation of an equation (which is what we're 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 🎉🦋💖