I took some time last week to research prior art relating to the undergraduate research project. A few minutes of searches on (which I love O so much) led me to several papers that appeared promising. I was dismayed but not surprised to find a handful of very smart people had already explored many of the ideas , , and I had brainstormed. In a way it is reassuring that our ideas were useful and practical enough to warrant study.
The first paper almost exactly echoes the basic idea of a programmatic vector language. Van Wyk's language, called IDEAL, is certainly far more elegant than three undergrads could have devised in a semester.
A programming language that includes special constructs for drawing pictures is discussed. The language has been designed so that programs to draw pictures can reflect the structure of those pictures.
...
A variety of graphics languages is available. Some are simply standard notations for basic graphical operations like point placement and line and circle drawing. Others include operations like translation, rotation, and scaling, which can be applied to sets of primitive objects. All of these systems rely heavily on the use of explicitly computed coordinates. They also lack a procedure mechanism, that is, there is no way to group several graphical operations together and refer to the whole by a single name. Another approach to graphics languages has been to allow access to graphics commands from a high-level language such as FORTRAN...
This second article defines both a constraint-based (i.e. programmatic) graphics language as well as a WYSIWYG editor that one can and use. I wish Adobe Illustrator had some of this type of functionality.
Juno is a system that harmoniously integrates a language for describing pictures with a what-you-see-is-what-you-get image editor. Two of Juno's novelties are that geometric constraints are used to specify locations, and that the text of a Juno program is modified in response to the interactive editing of the displayed image that the program produces.
...
Several years ago I used METAFONT and Draw to produce figures for my thesis.... The contrasting virtues of these two programs inspired me to design Juno, a system that integrates a programming language like METAFONT with a WYSIWYG image editor like Draw.
Chris had the idea to design our language as a based on . We had not gotten beyond just the idea, but Finne and Jones did in the context of , another functional language.
We present in this paper a simple, device-independent model for describing two-dimensional graphics using a functional language. Graphical scenes, or pictures, are represented as values that functions can manipulate and inspect to create new values. Complete pictures are constructed by repeatedly composing such picture values together using picture combinators. A novel aspect of the model presented is its use of structured translation to abstractly express the geometric composition of arbitrary pictures.
The structured graphics model presented has been implemented in Haskell, and we also give an overview of a general rendering framework for traversing a picture value. Applications of this renderer include both output to various graphical systems, testing for picking or selection of a picture and the computation of the bounding box of an arbitrary picture. The graphics model forms the basis for all graphical output in a user interface framework being developed in Haskell.
My teammates, Professor J., and I met on Monday to discuss these papers and what direction we wanted to pursue in light of the ideas they contained. Did we want to extend the work already done or did we want to brainstorm some more and try to come up with something completely different?
We chose the former. We still plan to work on a programmatic graphics language, but that will not be the focus of the project. Instead, we will use our language to explore some of the aspects involved in "compiling" such a language. We see our compiler having several possible forms of output: a simple raster image, a normal vector language, a programmatic vector language such as those detailed in the papers, or even a general-purpose language utilizing a graphics library. Other programmatic graphics languages can only output a simple raster or vector image that discards any of the logic or constraints present in the original language. What if our "compiler" retained as much of that as it could? It would be interesting to, say, design a picture programmatically, then output a .gif, a Postscript diagram, and even Java code that one could stick in an interactive applet.
A programmatic graphics language compiler with multiple output formats seems like an ideal computer science research project. It lends itself well to questions like: "What kind of programmatic functionality does it make sense to have the output contain?" "How does one convert one form of programmatic flow to another, possibly completely different, form?" "What possible optimizations can one make to a picture based on the target format?" "What problems does a graphical focus present?"
I am excited to see where the project goes from here.