1 of 20 BGRAPH Bertan Aygun ([email protected]) Fall 2004 – Spring 2005 University of Pennsylvania Computer Science and Engineering Senior Design Final Revision April 11, 2005 Advisor: Christopher E. Lewis2 of 20 Abstract: An essential part of representing an idea is to show how it compares with the systems that we use today and best way to visualize these comparisons is by data graphs. Today most papers in Computer Science field use some form of graph to compare the idea presented with the current implementations. For example, a paper on hardware enhancements would try to visualize difference in speed between the proposed enhancement and old techniques. Sometimes these data graphs can be quite complex, especially if they are trying to show several points of views. My aim in this project was to create a system that would generate data graphs in PostScript format. Such a system could be widely used by anyone writing a paper if it is designed to meet today’s requirements. The system itself consists of three main parts: a language to represent graphs and data, a compiler and a part to actually generate PostScript files. PostScript is chosen because it is a common format among all papers written in the community. Key components of the system are the language it uses to represent graphs, it is designed in such a way that data part and style part is represented independent of each other. So, it is be possible to do things like creating templates, reading data from outside sources and etc. Related Work in PostScript Graphs: Today, there are actually some systems to generate PostScript graphs that are widely used on papers. It is also possible to use other software packages, which are written for graph generation but does not support PostScript format, and convert their output to PostScript later on. One such solution is to use printer drivers that output PostScript files. So some advanced programs such as Microsoft Excel can be used to produce graphs and then it can be printed to those drivers to generate PostScript representation of the graph. Even though this solution looks perfect, it has one very important drawback: Data is not independent from definition of graph. Even though most of those programs allow you to import data, it must still be present in the program. For example, to prepare a graph where data for each group of bars come from different sources, a custom automation script must be written in order to create the spreadsheet in Microsoft Excel. This automation script can be either unique to each graph or it can be a whole new front-end for data entrance in to Microsoft Excel which is basically same as creating a compiler. So this solution lacks ease of use and data independency. There are two current systems to generate graphs in PostScript language. One of them is called PostScript::Graph by Christopher Willmot. It is a Perl module that allows you specify the style of the graph you want to generate and source of the data by creating graph objects in Perl. A method on the objects, once setup, can be called to generate PostScript file. Although data and style is independent in the representation of the graph as we wanted, PostScript::Graph module only supports single or grouped bar graphs and data point graphs. As it will be discussed later, stacked bar graphs also make a majority of graphs used on papers which can not be presented using PostScript::Graph module.3 of 20 Another such system is called JGraph written by James S. Plank at University of Tennessee. Unlike PostScript::Graph, JGraph is a completely self sufficient system. It has its own language and a compiler to generate PostScript files. It supports bar graphs, line graphs and data point graphs initially. But it also supports drawing arbitrary curves or lines to any location in the graph so it can be used to generate other types of graphs also. For example a stacked bar graph can be generated using several bar graphs on top of each other to make stacked bar graph. JGraph system is much more flexible than PostScript::Graph, but this flexibility comes with a heavy price. Its language is very close to naïve form where you would be specifying where to draw each line. Especially if you are creating stacked bar graphs or any other form of complex graphs, you can end up specifying where to draw each line to the screen which is not convenient. Another disadvantage is in data independency. Although JGraph is able to read input from outside sources, it only works for graph types supported naively by JGraph. So it would not be possible to draw a stacked bar graph using raw values from a data source, since those values should be arranged to create the effect of stacked bar graph by using only simple bar graphs. So data and style definitions of graphs are dependent to each other in JGraph. This is due to fact that JGraph actually uses a macro like system where shell commands are replaced with their output in the code and then JGraph processes the resultant code. As seen above, both current available systems lack some features that are requirements for the system I am proposing. So they can not be used directly to generate a new enhanced way to generate graphs in PostScript form. Proposed System - BGraph: I have implemented a new language to create graphs which utilizes JGraph to create PostScript output; though the code is extensible enough to allow other type of outputs as well as it will be described later. We can examine BGraph under several parts. I will start discussing implementation and typing system of BGraph. Then since my main focus is on data entry, I will explain how data is represented. Second important part is the actual representation of this data or the style of bars. Once these points are explained, I will be able to provide a general overview of the new language to be used and provide examples of BGraph code and output. Implementation: BGraph is actually a compiler that translates BGraph code to JGraph code, and then the user can execute JGraph to produce postscript output. I have chosen to translate to JGraph code instead of directly to PostScript since JGraph was providing a layer of abstraction over PostScript code. Unlike PostScript::Graph, JGraph’s language allow for arbitrary graphs or shapes to be represented in one way or another and its syntax is very close to actually specifying location of each line one by one so that it has a very flexible