"Linux Gazette...making Linux just a little more fun!"
Set your browser as wide as you'd like now.
I've fixed the Muse to expand to fill the aviailable space!
© 1998 by mjh
to the Graphics Muse! Why a "muse"? Well, except for the sisters aspect,
the above definitions are pretty much the way I'd describe my own interest
in computer graphics: it keeps me deep in thought and it is a daily source
v; to become absorbed in thought
n; [ fr. Any of the nine sister goddesses of learning and the arts
in Greek Mythology ]: a source of inspiration
is dedicated to the use, creation, distribution, and discussion of computer
graphics tools for Linux systems.
Not much to say this month. I've been very busy working on some
things for Linux Journal and a few other projects. I did manager
to get the reviews done that I had promised last month. Well, 2 out
of 3 of them. That's better than I usually do.
In this months column I'll be covering
XeoMenu, a Java based menuing program
an update on X server support for 3D cards and the X Input Extension
VRWave, a VRML browser for Linux
Disclaimer: Before I get too far into this
I should note that any of the news items I post in this section are just
that - news. Either I happened to run across them via some mailing list
I was on, via some Usenet newsgroup, or via email from someone. I'm not
necessarily endorsing these products (some of which may be commercial),
I'm just letting you know I'd heard about them in the past month.
Robert Mallozzi announces
a new version (1.3) of his XForms interface to the ray tracer POV-Ray.
If you have ever used POV-Ray from the command line, you might find this
program useful. Check
Source code is available in tgz, bzip2, and rpm formats.
Robert S. Mallozzi
University of Alabama
XMRM 2.0 (Alpha release)
The Institute of Computer Graphics at Vienna University of Technology,
Austria, announce the release of XMRM 2.0alpha
XMRM (multi resolution morphing for X) is an image morphing program
written for XWindows. A special feature of this program, which is not found
in other morphing packages, is the ability to control the morphing speed
of details in relation to the morphing speed of big features.
Check out the XMRM homepage:
For a few animated GIFs visit the Online manual:
For download got to:
Greetings, The XMRM-Team <firstname.lastname@example.org>
FREETYPE 1.0 The FREE TrueType Font Engine
Copyright (C) 1996-1998 The FreeType Development Team
The FreeType engine is a free and portable TrueType font rendering engine,
available in ANSI C and Pascal source code. It has been
developed to provide TrueType support to a great variety
of platforms and environments.
Notice that FreeType is a library. It is not
a font server for your preferred environment, even though it
has been designed to be the basis of many high-level
libraries, tools and font servers.
It's a clean-room implementation that is not
derived from the original TrueType engine developed by
Apple and Microsoft, though it matches it regarding rendering
quality. To our knowledge, it's the only royalty-free complete
TrueType engine available.
For more information, please visit the Freetype web site at:
|That's it. Not much in the way of announcments this month.
I had a few more, but lost them pasting them into my XPostitPlus program.
That's the first time it's crashed in that manner - where I lost the data.
Did You Know?
...there is a OpenGL widget for GTK? Take a look at ftp://ftp.gimp.org/pub/gtk/contrib/glgtk-demo.971104.tgz.
Q and A
Q: How do you use anti-aliasing with POV-Ray?
Do higher values cause more anti-aliasing?
A: Ron Parker responded on the IRTC-L discussion list:
Whenever POV-Ray detects a sufficient change, the threshold, in
colour from one pixel to it's neighbour, it will calculate the in-between
color pixels by shooting multiple rays into the scene, rather than just
one, to determine the colour. The higher the "+A" number is (from
0 to 1), the more rays will be shot into the scene, and the smaller a difference
in colour from one pixel to the next will be needed to cause the anti-aliasing
to be brought into effect. Anti-aliasing is triggered when the threshold
between two pixels is reached. The number of rays is controlled by +R,
and the "spread" is controlled by +J. Setting +A0.1 will trigger
on smaller color differences than +A0.3, so it actually anti-aliases more
than higher values of +A. All this is the description for +AM=1.
Adaptive supersampling (+AM=2) works somewhat differently.
For more information, see section 188.8.131.52 of the POV documentation.
Ron Parker * email@example.com
Q: I took an image to a printer today who requested that I bring
back the image when I have increased the resolution from 72 pixels/inch
to 300 pixels /inch. I cant locate how to do this with the GIMP. Any pointers?
A: You can scale the image, but that will decrease the quality
of the image. The best way to deal with images you plan to print is to
plan to create them using the correct resolution. For example,
if you want an 8.5" by 11" image at 300pixels/inch:
width: 8.5*300 = 2550 pixels
So you need to start with an image window that is 2550x3300 and work from
there. Keep in mind - doing this sort of image manipulation (with
such large image sizes) is better suited to:
height: 11*300 = 3300 pixels
As to "can I convert from 72 to 300 pixels from my original image": yes,
use the scale option (image->scale) and set the correct size. But
remember - scaling up will reduce image quality, especially going from
72dpi to 300dpi.
tons of memory
lots of disk space
An unnamed reader sent the following information:
I've recently written 3 Perl scripts which help to distribute the task
of rendering with povray between several CPU's. One script is for
SMP (multiple processor) machines. It will break an image into halves
and start a separate process for each. This utilizes both CPU's in
a dual processor machine, and nearly halves the rendering time. The
other two scripts work together to utilize multiple machines on a network.
The server script tells each client script how much of an image to render
(also sending the .pov file and any necessary files to each client).
'Muse: I really need to
update the LGH and UGU pages. Anyway, if any of my readers tries
these scripts, let me know what you think of them. I don't have any
multiprocessor boxes, although I do have a network. I just don't
have time right now to experiment with these scripts.
These scripts were created using Perl 5.004, Linux 2.0.32, and POVRay
3.0. I'd be honored if you would like to include a link from your excellent
graphics site to my page at http://www.frozenwave.com/~hixson/projects.html.
Syd Logan, Senior Software Engineer
@ NetManage, Inc., writes:
I was perusing an old copy of The
Linux Journal in preparation to do an article or two for them on the
X Image Extension when I came across your article in the November 1996
issue. This isn't so much about the article, but I just thought I'd drop
you a line to make you aware of my home page which is devoted to XIE at
Feel free to point any queries you may hear about or receive regarding
XIE or XIElib to my home page, or to me directly at firstname.lastname@example.org.
'Muse: Thanks for the
note. While working for Xi Graphics I had read the XIE specification
and wondered why it hadn't been used much. Perhaps it's like X Input
- it just needed a market to drive its use. Well, the exposure Linux
will give X Windows may be that driving force. We'll have to wait
Thomas Vaughan writes:
My work involves writing code in Iris GL and OpenGL. I am particularly
interested in accelerated 3D graphics, as I just bought a ViRGE 3D accelerator
for my home PC which runs linux 24 hours a day. I have played with
Mesa, but there is apparently no real free hardware support yet.
'Muse: No free support,
but Xi Graphics has recently announced
ViRGE 3D support in their commercial Accelerated X server.
The GGI project sounds interesting, but I don't really know whether
it's worth investigating seriously yet.
'Muse: I don't really
like the idea of GGI, partly because I don't think sticking the graphics
driver in the kernel is a good idea but also because I don't want to see
the desktop interface splintered into seperate camps. X is just really
coming into its own on the desktop and I'd like to see it continue.
At work my supervisor has, on my advice, just made a capital request
for a graphics card based on the 3D Labs Permedia chip which comes with
accelerated OpenGL support for Windows NT. In the back of my mind,
I am hoping that I can convince people at work to give linux a serious
look as a low-cost alternative to the SGI platform. After all, even with
GNU/Win32, the NT platform is not nearly as nice as real Linux. Unfortunately,
however, this seems just a little out-of-reach at the moment, because of
the apparent lack of 3D hardware support on Linux. Any news on this
front would be heartily appreciated, and I would love to write bug reports
and use either machine as a test platform.
'Muse: I got a similar
request from Anand Rangarajan:
I noticed that SuSE http://www.suse.de/XSuSE/XSuSE_E.html
has developed a bunch of drivers for the ELSA Gloria family of 3D graphics
cards. Will their drivers accelerate Open GL or Mesa? Also, these drivers
are free and will be integrated into the XFree 4 release.
'Muse: Well, I thought
it was about time I did a little survey of the various graphics card vendors.
See the X Server Update article below.
Marc S. Jensen writes to the
GIMP User mailing list:
When I run xscanimage, it complains about my system not having a /dev/scanner
device. So, here's my question: What do I do to my Red Hat
5.0 system to get a /dev/scanner device installed. I'm using an Adaptec
2940 SCSI adapter, and my kernel is compiled with SCSI support. What's
'Muse: Assuming your scanner
is the only deviced attached to your scsi card:
ln -s /dev/sga /dev/scanner
and you're all set. If you have more than one device connected
to the scsi bus (re: cable) then you'll need to figure out which one of
the /dev/sg[x] devices maps to your scanner. Then link that one to
Joel Becker also wrote
to the GIMP User mailing list:
Just a quick question. What is a reccomened drawing tablet, for
best use and easiest XInput setup? I think I heard the Wacom ArtPad
thrown around here. Also, what is a good scanner to work with SANE?
I mean ease of setup as well as quality of image.
'Muse: Can't answer about
the tablet, but I just happened to install a scanner recently. I
bought a Adaptec 2940 SCSI card and a UMAX 1200S scanner. The Adaptec
dropped right in on my Pentium 200MMX board with no hardware config necessary.
The RH 4.2 distribution I use already had the necessary scsi module prebuilt
in /lib/modules (the module name is aic7xxx.o). I ran insmod
aic7xxx and up it came.
The scanner I chose from the list of scanners I reviewed last year for
my Graphics Muse
column in the Linux Gazette. I first tried a 610s, but it only worked
in greyscale modes. So I exchanged it for the more expensive (about
$250) 1200s. Works quite well with the Umax drivers. Image
quality is excellent. I've been scanning hardware (twisted pair and
thinnet cables), and my hand once, and the scans were quite good although
very dark. I just brightened them up with xv and the GIMP and all
However, I haven't tried the scanner and drivers in conjunction with
Marco Iannacone wrote:
First of all I want to say thanks for all the great stuff you wrote
(and still write) about Linux & Graphics.
'Muse: No problem.
Since a friend of mine uses Photoshop on Mac, I wanted to show how
powerfull is Linux, so I installed RedHat 5.0 on a Pentium 166 with 64Mb
of RAM, with a Matrox Mystique. When I showed him GIMP he was REALLY
impressed but he found it quite slowly compared to Photoshop. I told him
that the reason was probably that XFree86 was using the generic SuperVGA
driver since it doesn't have a native driver for it.
'Muse: Possibly, but that
would only make a difference in screen updates. The majority of the
GIMP's processing is done before it updates the screen.
Is that true or maybe GIMP is only slower that Photoshop?
'Muse: Define "slower"?
Slower loading the same file? Slower in computing a new brightness
or contrast? Slower how?
What he might be talking about is the use of tiles, which may appear
to update slowly, wherease in Photoshop they may all appear almost at once
(I've never used Photoshop, so I don't know if this is true or not).
So before I can answer "is GIMP slower than Photoshop" I need to know by
what means you've been measuring the two.
More than this I was not able to open any GIF, JPG or TIFF coming from
Photoshop... do you know the reason?
'Muse: You may not have
installed the proper image libraries. Download the libgr
package and install it, then try again. You may want to build the
GIMP from the sources, after you install the libraries in the libgr package.
Or, if you installed GIMP from one of the distributions (Red Hat, Debian,
etc) you may want to verify you installed all the graphics libraries that
came with that distribution too.
Tero Auvinen wrote:
In a past Graphics Muse you wrote:
'Muse: If the link from
Larry's page (the
BMRT home page) is not working I'm not certain where this package can
be found. Try the Renderman Repository: http://rmr.spinne.com/.
...from the archive of shaders from Guido Quaroni. This archive includes
shaders from the RenderMan Companion by Steve Upstill, from Texturing and
Modeling by Ebert, Musgrave, et al, Larry Gritz, and various other places.
Where could I get this semi-wonderous package? Found one link from BMRT
homepage, but it was defunct (anonymous ftp access denied). If you'd happen
to have it somewhere, I'd appreciate a copy, otherways I'll just go and
grab everything from the aforementioned fellows homepages etc.
Also hmm, I might've missed it, highly possible, but I remember that
you 'promised' a 3 part BMRT special, seen 2 so far(issues 15&17),
maybe in march issue?
'Muse: No, there wasn't
a third part. I wanted to do one but I'm not that experienced with
it and I had too many other things come up. I've never had a chance
to go back and revisit it.
Re: Modellers: I can't seem to find one GOOD one, if it's nice
to look and use at, then it won't export RIB, or does it in a silly way,
using polygons and whatnot, one'd prefer RMan primitives huh? Sure I can
do the basic primitives in a non-wysiwyg way, the ascii way. But anything
more complex, no thanks.
'Muse: No modellers are
available for Linux which export RIB primitives. All of the ones
I know of export polygons only.
I've been thinking of getting another computer, running only MSWindows,
networked together with Linux, I could edit [3D models] using Rhino or
equivalent free Win95/NT modeler and render in Linux. (oh yeah, now there's
Win32 port of BMRT even...but Linux I will NOT leave, Windows generally
drives me nuts). Only if I had the money.
'Muse: You couldn't pay
me to run MS on anything. But that's just me.
You happen to know what Larry uses for modeling? (besides Alias on
'Muse: I think he's got
some big boxes, SGI's and Sun's probably. I'm sure Pixar feeds him
well. On Linux he may be using AC3D (as do I). It's a pretty
good modeller, but still exports everything as polygons only. It
does import 3DS and Lightwave files, though. That's quite useful for
using the canned models from the various model sites and CDs that are available.
AC3D - http://www.comp.lancs.ac.uk/computing/users/andy/ac3dlinux.html.
Marsel Osipov writes:
I am starting a project called Virtuoso. It's a 3D Modeling/Animation/Rendering
package for Linux. I am sure that I would not be able to create
a high quality package by myself, so if you would like to join, visit my
home page for more info. http://www.geocities.com/SiliconValley/Lakes/7705/
'Muse: We can never have
too many modellers.
One of the problems with pages based around standard HTML constructs is
the inability to easily modify navigation aides. A navigation aid
can be a set of text links, a set of images with individual links or it
can be an image map using hot spots for links. These tools allow
readers of a page to move around a Web site easily. Properly done,
they can remove the linearity (the hierarchical structure) of a Web site
and allow the reader to move freely between pages.
Adding an text links is fairly easy to do and updating them simply requires
editing the HTML. But text links lack pizazz. Images used as
the images are fairly static. They lack the feel of a real user interface.
Image maps are no better and, in fact, don't even allow rollover changes
as easily making them even more static than individual images used as links.
Fortunately, issues such as this is part of why Java exists. Java
allows for more programmatic interfaces. These interfaces can take
on the more familiar menu-based interfaces that readers will be accustomed
to. Although it can be argued that such interfaces are not any better
than static image maps, for the sake of this article we'll assume that
menuing systems are a good thing.
XeoMenu is a simple Java program
from Patrick Chan at Xeo (www.xeo.com)
that overlays a menuing system over an image in a Web page. The program
is run as an applet and is used by embedding it within HTML source code.
Readers can retrieve a copy from http://java.sun.com:81/share/classes/menu/source/source.html.
Java source code is included, along with an example HTML file, sample
images, a users manual (a sort of man page in HTML) and the compiled Java
byte code. There is also a second version of the code, called horizMenu,
that permits menus to be layed out horizontally instead of vertically.
Since I can't seem to get Java working on my Red Hat 4.2 system (neither
through the javac compiler nor through my version of Vibe - something about
my CLASSPATH is not set up right I think), I won't be able to provide information
on compiling the source in this article. If I do get javac and/or
Vibe working, I'll start talking about how to compile Java programs.
If anyone has a write up of what I need to do to get my stock RH 4.2 version
of the Java compilers working, please drop me a line.
To use XeoMenu you need to first create an image that contains two parts:
The menu as it is displayed without the mouse over the image and the image
as it would look if the mouse were over different parts of the original.
For our example, we'll use the following image:
The image is divided into 2 halves. The left half is the image as
it displays without the mouse over it. The image is actually going
to be subdivided into a top (Linux) and bottom (Gazette) section.
The right side, then, shows how each section will be displayed when the
mouse is over that section. For example, if the mouse is over the
word Linux in the image then the blue Linux text will be displayed.
By default, the red colors (the left half of the image) is displayed.
Now, in order not to annoy readers without Java support, you need to
move to the next section of this article, which
will show how the Java application is used and what it looks like when
it runs. You will need a Java compatible browser to view this part
of the article.
This was just a simple example. XeoMenu itself comes with a more
sophisticated example, but there is no real explanation (ie documentation)
of what is going on in the code. Hopefully, between that example,
the user manual, and this article you'll be able to do something useful
with XeoMenu. The main
applet page for Java.sun.com shows an example of the horizontal
version of XeoMenu running and it's quite slick. Although the interface
uses a fairly large number of optional parameters and the format for menu
descriptions is less than ideal, it is still a useful tool that takes only
a little getting used to in order to make a very usable menu-based interface
for your Web pages.
X Server Update
I've been doing this column now for over a year and writing
for Linux Journal on and off for another year. In that time
I haven't really addressed one of the more obvious topics related to doing
graphics on Linux - the X server. Part of the reason for that is
that I don't have the resources to test a bunch of different server configurations.
If I got paid to do this it would be a different story, but this column
is born from whatever time and system resources I can spare each month.
Still, I get requests fairly often asking for information
about what 3D video cards are supported under Linux and which ones support
various hardware extensions such as the X Input Extension. Most of
the questions specifically ask "which are supported under XFree86".
But some readers ask about support in general, either free or commercial.
Well, I thought it was time I sent a query to the various
vendors and find out where things stand. The email I sent was fairly
generic. It read as follows:
Do you have any information which I may use in my column related to your
current or planned support for 3D hardware acceleration (specifically related
to OpenGL/Mesa, but not necessarily so)? What about support for alternative
input devices via the X Input Extension. The GIMP, and its X toolkit
Gtk, both make use of X Input if available and I expect many other tools
will do so as well in the near future.
This query was sent out around the 12th of this month to Xi
Graphics, Metro Link, SuSE,
and the XFree86 project. I received
responses from all 4, however Metro Link did not receive my query immediately
and so their response came in too late for this article. I will cover
Metro Link's response next month. Please note that this article
is intended to list which servers support what features/devices
and is not intended to explain how to use those features.
The responses have been edited to remove what appeared to be editorial
comments, where recognizable. I will refrain from editorializing
on these responses in this article as well.
The first reply was nearly immediate and came from Dirk
H Hohndel at SuSE. He sent two emails, one as the Vice President
of The XFree86 Project, Inc. and one as the Lead Developer, S.u.S.E. GmbH.
Dirk wears both hats, and therefore his comments are considered official
responses, one from each organization. Both responses were direct
and to the point. First his XFree86 response:
Because Dirk's response came quickly, and because responses from the other
vendors provided more detailed information, I thought I should offere XFree86
a chance to expand their reply. When asked to comment on architectural
details and XFree86's relationship to the commercial vendors, Dirk responded:
|Well, XSuSE and XFree86 are mostly identical. As far as legally
possible, all work done on XSuSE is integrated into the next XFree86 version.
XFree86 in itself focuses on the X Window System and 2D support for the
different cards. While they are not actively pursuing 3D support, they
are in contact with several groups working in that area.
I do not speak for Metro Link, but I can tell you that Metro Link and
XFree86 are in very positive cooperation on the 2D side of servers.
Metro Link donated lots of code to XFree86 recently, and Metro Link and
XFree86 are working together on many aspects of the design of our future
He followed up his XFree86 reply with a response from SuSE:
|Why would I bore you or anyone else with architectural details
that no one really cares about.
|SuSE is working on hardware 3D support, but there is no release
date for that, yet.
The 2D drivers from SuSE are intended to be integrated into XFree86-4.0,
but we are currently running into some legal problems with that for one
of them (3DLabs GLINT), as some of the docs are under NDA and we have not
been able to get the permission to release sources, yet. We are working
on it, though. All the other drivers from SuSE have already been
included into XFree86-3.3.2
The other replies came from Xi Graphics. Both Thomas Roell, President
of Xi Graphics and technical architect for their servers, and Jeremy Chatfield
|Our next generation X-Server will support additional new input
devices for the XInputExtension. The extension itself is supported since
Accelerated-X 4.1. Planned devices are mainly CAD oriented input systems,
like Tablets, Touchscreens and Space-Balls. As for Hardware 3D, you
can bet that the next generation will have that.
Jeremy Chatfield followed up with the following (edited partially for
-Top of next column-
|Accelerated-X 4.1 supports the XInputExtension, using a small
and fixed list of devices, with very limited device management. Future
releases will support a wider range of devices.
We've been evolving Accelerated-X ever since 1994, to take advantage
of 3D hardware acceleration. Examples of the technology introductions
and the reason for needing them for 3D support:
Memory allocation and buffer management. 3D uses a lot of memory.
Standard malloc() (as of 1994, when we started this work) did not permit
programs to decrease in size, tended to thrash memory when freeing and
sometimes when allocating, and exhibited other behaviors that were not
suitable to long running processes with a mix of temporary and long term
storage in a wide variety of data sizes. We do things like lazy buffer
allocation, only allocating stencil buffers when needed, and so on.
This improves speed and reduces system impact, seen in total Server size,
and paging demand.
Xi Graphics recently announce support for ViRGE 3D (see the February
1998 Graphics Muse).
Coprocessor locking. When using the host processor, graphics engine
and 3D engine, all writing in the same memory areas, and when using both
system memory (via AGP) and graphics board memory, fast and correct mutex
locking is essential. [Without locking] this will cause problems
when all three processors (or more) attempt to handle the same memory.
We have continued to refine our mutex locking for several years, though
this is not visible in any product other than multihead, at present.
Asynchronous I/O When X Servers with high levels of hardware acceleration
are handling buffered drawing requests, keyboard and mouse input is put
into the end of the queue. This results in sluggish response, and
in mouse and keyboard data being handled in bursts. Mouse acceleration
can be triggered inappropriately, so mouse motion becomes very hard to
control, and sequential single button clicks can be misinterpreted as double
clicks. We introduced the "Velvet Mouse" mechanism to permit input
even while the Server was in heavy rendering, as will be typical of 3D
Overlays. Many 3D applications on workstations rely on the presence
of overlays. [Overlays] also benefit from the memory management and
other architectural changes in Accelerated-X.
Beyond these two vendors, there is also 3D hardware support available
for Mesa for the following video hardware:
3Dfx Voodoo - Cards based on the 3Dfx Voodoo chipset (such as Diamond Monster
3D and Orchid - Righteous 3D) are supported under Linux and Windows 95.
for the latest info. This is the best supported 3-D hardware for Linux
at this time.
3Dfx Voodoo Rush (rendering into window) - Supported under Windows. Linux
support is underway.
GLINT-based boards - Look here
for the latest info.
This information was taken directly from the Mesa
Web pages. I ignored any cards for which Linux was not mentioned
except the Cirrus Mondello. I don't know if it's for Linux or Windows.
Also, I don't know exactly how Mesa makes use of this hardware without
actually being part of the X server. You will have to investigate
the Mesa pages and its links for more information in that area.
Cirrus Mondello - No longer supported- download Mesa 1.2.8 if you're interested
in this driver.
So, now you should know as much as I do with respect to 3D and X Input
support from XFree86/SuSE and Xi Graphics. In summary, most of the
3D work seems to be planned and under development, but no word on when
the support (at least for wide spread 3D support) will be available.
Neither XFree86/SuSE nor Xi specifically mentioned any 3D boards being
supported, although Xi did have the announcement for the ViRGE 3D last
month. Xi stated they support the X Input Extension in their Accelerated-X
4.1 release. Although XFree86 didn't mention it, I know that X Input
is supported in their product as well. Don't forget: I'll be
covering Metro Link's responses to my query next month.
I should mention again that I have worked for Xi Graphics in the past,
and in fact worked with both Thomas and Jeremy at Dell computer and with
Jeremy at Information Foundation (a USL source code licensee back around
1993 or so). I have made every attempt to remove all editorial comments,
both my own and any from the respondents, from this article.
Dirk reports: In both cases we try to keep the web pages up to date
and XFree86 has a FAQ online that contains workarounds for known bugs.
Jeremy added: We keep the web site up to date.
The following links are just starting points for finding more information
about computer graphics and multimedia in general for Linux systems. If
you have some application specific information for me, I'll add them to
my other pages or you can contact the maintainer of some other web site.
I'll consider adding other general references here, but application or
site specific information needs to go into one of the following general
references and not listed here.
Next month: Unknown. I've got some prior obligations
(paying ones, that is) that I absolutely must get done.
Let me know what you'd like to hear
Previous ``Graphics Muse'' Columns
Graphics Muse #1, November 1996
Graphics Muse #2, December 1996
Graphics Muse #3, January 1997
Graphics Muse #4, February 1997
Graphics Muse #5, March 1997
Graphics Muse #6, April 1997
Graphics Muse #7, May 1997
Graphics Muse #8, June 1997
Graphics Muse #9, July 1997
Graphics Muse #10, August 1997
Graphics Muse #11, October 1997
Graphics Muse #12, December 1997
Graphics Muse #13, February 1998
Copyright © 1998, Michael J. Hammel
Published in Issue 26 of Linux Gazette, March 1998