For information on graphics file formats (like JPG, GIF, and others),
see my notes on graphics file formats.
Computer graphics can mean lots of different things to different people,
and rightly so. What I am interested in talking about are ways to generate
2D computer graphics from a conventional computer language like C.
Long ago, in the days of punch cards, calcomp plotters, and tektronix storage tube
terminals, I was able to do things with computer graphics that I am no longer able
to do. In those days our goal was ultimately to put black lines on paper, and I
could draw a line scaled in inches via:
CALL PLOT ( 1.0, 1.0, 3 )
CALL PLOT ( 2.0, 2.0, 2 )
(For full details, see the 1968 book
Programming Calcomp Pen Plotters).
In those days I could generate a device independent file (with coordinates in inches),
preview it on a Tektronix 4006 or 4010 terminal, then send it to be plotted on paper.
I am itching to be able to do the same thing in this modern age, but don't have the
same tools. Ideally what I want to be able to do from the same piece of software is:
All the pieces to do this exist, but not in one happy collection.
Let's look at some of the options.
- Display lines on my computer screen.
- Save lines to a file that can be displayed on the web (.gif or .jpg)
- Save lines to a file that can be printed (probably .ps)
Since I work on linux systems and use X windows via the Gnome desktop, maybe this
will lead me where I want. I have written Gtk programs in C and there is something
called the canvas that I can draw on. It is not clear how to generate screen output
one time and file output another. And I would like to work in inches, anticipating
final postscript output on paper.
OpenGL seems like using a sledge hammer to pound a nail given all of its 3D ability,
but if it allows me to get the job done, I really don't mind using a subset of its
capabilities. (Another writer says this is like using a jackhammer to dig up a weed).
This is worth further investigation given that whatever I learn about it will serve
me well for possible 3D escapades down the road.
I simply refuse to program in Tcl, but Tk is another way to get to a canvas in an
X windows environment. Perl/Tk offers a much more sane (insofar as anything involving
perl can be called sane) approach to Tk programming. Ultimately though, this is not
what I want - I want to do graphics programming from C.
This is a nice way to produce x/y plots of data without doing any programming at all,
but it is not C programming. Worth mentioning, even though it does not solve the
What a person could do (and this does tempt me) is to write a library of C routines
that would generate postscript. A program could then be run to produce a postscript
file. This file could be printed on paper, and it could be examined on a screen using
a postscript viewer. This is probably to closest thing I can imagine to the way I
used to do things back in the Calcomp days. Postscript itself is "zany". It is a
forth-like RPN programming languages with bizarre loop constructs and a long list
of idiosyncrasies. It is kind of fun though, because you can compose postscript using
a text editor, then either view or print the source file itself.
The graphical kernel system. This may still be living and breathing somewhere.
It is pretty much like a graphics package produced by a federal beaureaucracy.
It very much did some things right (like abstracting viewports), but in general
was a pain in the neck (or maybe somewhere else), and I would prefer to just
forget about it.
Do PLOT-10 in an xterm
The "standard" xterm emulates the Tektronix 4010 command set, just like the good
old days, but even this would require me to write my own C library to exploit, and
I am not sure I want to recreate plot-10 in the twentyfirst century.
Qt and C++
Qt is a graphics library that gets lots of attention in the linux community.
It is my understanding though that it requires you to be programming in C++
not just C, which is a bridge I do not intend to cross.
In the X windows environment, it would not be possible to dig any deeper than this.
Doing things at this low a level would certainly be flexible and efficient, at least
as far as getting output on the screen (you would be generating your own custom
canvas widget), but I am not sure how easy it would be to flip a switch and get
Simple DirectMedia Layer - libsdl in the linux world. It is written in C, but
has bindings to many languages. It utilizes OpenGL, and people say it
facilitates game programming.
yum install SDL
yum install SDL-devel
These were both already installed on my Fedora 14 system in December of 2010.
A quick look shows that this is strongly C++ oriented and 3D game oriented.
It is not clear why one would do this instead of directly using OpenGL.
Have any comments? Questions?
Drop me a line!
Adventures in Computing / email@example.com