Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!lll-winken!tekbspa!optilink!cramer From: cramer@optilink.UUCP (Clayton Cramer) Newsgroups: comp.lang.postscript Subject: Building A PostScript Toolset Message-ID: <2251@optilink.UUCP> Date: 29 Aug 89 22:29:13 GMT Organization: Optilink Corporation, Petaluma, CA Lines: 79 There was some discussion a few months back about building libraries of PostScript functions, but very little seems to have come of it. I have decided to bring the subject back up again, along with some examples. Reasons For A Toolset 1. The obvious one -- to avoid reinventing the wheel. 2. To build on other people's knowledge. 3. To provide some simple examples for those still learning PostScript. (That includes me -- and I've been writing PostScript, intermittently, since 1984). Ways To Build Such A Toolset 1. Write single, simple functions. As an example, the PostScript function at the end of this posting does pie chart slices -- just pie chart slices. I originally intended it to compute where to put legends, and invoke a function passed in to it to display legends next to the appropriate slices, but both because I don't have time to debug, and because someone can then build such a layer around my pie slice function, all it does it produce pie slices. 2. Make minimal use of global variables. As nice as it is to "setgray" and have that in effect until changed, it also makes it hard to distinguish where or how something was set. (All the same arguments that apply to programming languages apply to page description languages as well). This means that these functions will be passed parameters that the same, much of the time. The decision whether to include all possible variations or not is one of those unpleasant trade-offs. 3. To prevent creating write-only code, set variable names to stack items at the start of the function, and reference those variable names thereafter whenever possible, rather than using lots of dups, exchs, and rolls. It's less efficient, certainly, but the goal here is reusable code that can be easily changed to do something else, if needed. 4. A standard (or at least understandable) convention for showing the number of parameters and what they do. 5. A %%DEMO section at the end of each tool, so you can see how it's called, and have one clear example, if the parameter description isn't. By using %%DEMO before the demonstration invocation, you make it easier to automate the process of extracting just the executable code from each tool. I'm hoping that everyone will contribute general purpose tools that they need to create, so that over time, we will have most of the essential components -- triangles, parallelograms, log-log graphs, bar charts, and so on -- needed to write complex applications. %! /PieSlice {% draw a pie slice % (pie point x, pie point y, start angle, size, radius, gray, width) gsave /Width exch def /Gray exch def /Radius exch def /Size exch def /Angle exch def /Y exch def /X exch def newpath X Y moveto X Y Radius Angle Angle Size add arc closepath Width setlinewidth Gray setgray fill grestore} bind def %%DEMO % Draw a complete pie, with different slices in different gray scales. 300 300 45 75 200 0.00 2 PieSlice 300 300 120 45 200 0.15 2 PieSlice 300 300 165 90 200 0.30 2 PieSlice 300 300 255 105 200 0.45 2 PieSlice 300 300 0 45 200 0.60 2 PieSlice showpage -- Clayton E. Cramer {pyramid,pixar,tekbspa}!optilink!cramer "No man is an island" is the beginning of the end of personal freedom. ---------------------------------------------------------------------------- Disclaimer? You must be kidding! No company would hold opinions like mine!