Automatic creation of an Impress presentation from a series of images

By Karl-Heinz Herrmann

Why would I want to use a command line tool to generate a WYSIWYG/GUI Document?

Well, I don't know about you, but I am not very keen on extremely boring and repetitive clicking through some GUI if the task at hand doesn't need individual care for every page done. Specifically, I had a presentation created with LaTeX/beamer in PDF format and "boss" wanted to have a PowerPoint file. Or you have your paper accepted at this great/important conference and you find out they will only accept PPT files for a talk: no PDF, no Impress, no own laptop.

So, I found myself importing a series of identically-sized images into a PowerPoint presentation once too often (i.e. once) and got extremely bored. So bored that I started investigating if I could do it any other way, even if it took me a week to write the program. For me, the "perfect" solution would be to have a list of image files (e.g., created by 'ls *png > file'), run a script and --voila -- get a PPT file, each slide containing exactly one of the images filling the whole slide.

Finding the tools

A Google (re)search showed nothing on automatic generation of PPT files, since their internal structure is too obscure to reverse-engineer. However, I did find information on the inner structure of OpenOffice files. These are simply compressed XML files and the DTD of the XML structure is published. After fast-forwarding through the 571 pages I was seriously hoping somebody else might have done some work on this already. Indeed, adding my favorite programming language Perl to the Google search words produced some interesting links:

• The ooolib
• The OpenOffice::OODoc perl Module

I decided to give the OpenOffice::OODoc module a try. To get the modules installed on my system I went to CPAN (the Comprehensive Perl Archive Network) by typing as root ([...] signifies unimportant left-out parts):

# perl -MCPAN -e shell 

cpan shell -- CPAN exploration and modules installation (v1.7601)
cpan> install OpenOffice::OODoc
CPAN: Storable loaded ok
[...]
Running install for module OpenOffice::OODoc
Running make for J/JM/JMGDOC/OpenOffice-OODoc-1.309.tar.gz
Fetching with LWP:
  ftp://ftp.perl.org/pub/CPAN/authors/id/J/JM/JMGDOC/OpenOffice-OODoc-1.309.tar.gz
[...]
OpenOffice-OODoc-1.309/
OpenOffice-OODoc-1.309/OODoc/
[...]
Checking if your kit is complete...
Looks good
Warning: prerequisite XML::Twig 3.15 not found.
---- Unsatisfied dependencies detected during [J/JM/JMGDOC/OpenOffice-OODoc-1.309.tar.gz] -----
    XML::Twig
Shall I follow them and prepend them to the queue
of modules we are processing right now? [yes] <Enter> 
[...]
Writing /usr/lib/perl5/site_perl/5.8.3/x86_64-linux-thread-multi/auto/OpenOffice/OODoc/.packlist
Appending installation info to /usr/lib/perl5/5.8.3/x86_64-linux-thread-multi/perllocal.pod
  /usr/bin/make install  -- OK
cpan> quit 

The cpan shell realized that a prerequisite, the module XML::Twig, was missing for OpenOffice::OODoc. It offered to fetch it automatically, which I asked it to do. Both Twig and OODoc asked some questions during the install, and I selected the defaults every time. After that, I had OpenOffice::OODoc and all the prerequisites on my system and could start reading the documentation.

The code

After glancing at the Introduction and some man pages, I started checking out the examples that came with the module. I found it interesting to find a solution for the reverse of my problem -- extracting all images from an OpenOffice Document -- since there is another simple method to get the images out: Just run 'unzip' on the *.swi, *.sxw or any other OpenOffice document. They are nothing but a zip-file containing the content, meta files and (in the Pictures subdirectory) all images of the document.

unzip -t img2ooImpressExport.swi
Archive:  img2ooImpressExport.swi
    testing: mimetype                 OK
    testing: content.xml              OK
    testing: meta.xml                 OK
    testing: styles.xml               OK
    testing: settings.xml             OK
    testing: META-INF/manifest.xml    OK
    testing: Pictures/Seite_1.jpg     OK
    testing: Pictures/Seite_2.jpg     OK
No errors detected in compressed data of img2ooImpressExport.swi.

After some digging around in the documentation I came up with the following Perl code:

use OpenOffice::OODoc;

# start a new document
my $document = ooDocument
  (
   file            => 'outputfile.swi',
   create          => 'presentation'
  );

$document->createImageStyle("slide");

# loop over image file names (open is outside of this snippet)
my $i=1;
while (my $imgfile=<IN>){
  chomp($imgfile);


# start a new page/slide
  my $page = $document->appendElement
    ('//office:body',0,'draw:page');

# include the image at full size
my $image=  $document->createImageElement
    (
     "Slide".$i,
     description     => "image ".$i." filename:".$imgfile,
     page            => $page,
     position        => "0,0",
     import          => $imgfile,
     size            => "28cm, 21cm",
     style           => "slide"
    );

$i++;

}

$document->save;

The complete script includes some file-handling and reads the image list. The hardest part was figuring out how to add a new page in an Impress presentation, since I could only find examples which modified a document (inserting an image after some text, etc.) but none that created new pages. Some digging in the other man-pages and the doc-folder (if you have 'locate' installed and ran 'updatedb' after the OODoc installation, 'locate OODoc' will find all of them) started me in the right direction.

In the created *swi file, the very first slide is left blank (named "First Page") and every other page contains one image, named consecutively "Slide N". I didn't bother figuring out how to drop that first page. Also OpenOffice seems to have changed the file extensions between versions: Impress files could be *.swi or *.sxi. The script takes either one or two arguments: The necessary file with the list of images (one filename each line) and an optional output filename (default img2ooImpressExport.swi). The images are automatically aligned, so animations in the PDF (each animation step is a new page) will play out smoothly in Impress/PowerPoint. That was one of the most annoying things with manually importing single images into PPT -- realigning and rescaling so the images won't jump from slide to slide.

If you would like to add a title or other text to the slides you could just modify the position and size specification in the createImageElement block. The page specification adds the image anchored to the page. The Info page gives an example where an image is anchored to a new paragraph. The Intro page is also accessible by:

man OpenOffice::OODoc::Intro

Other examples that came with the Perl module create spreadsheets from *.csv files ('oobuild') or create swriter files from text source ('text2ooo').

So what about PPT?

Impress is quite capable of opening and then exporting the created file to PPT-format, and PowerPoint will not even be able to turn Vector arrows into letters, much less mess about with text colors and other annoyances I see regularly at conferences.

How to convert from LaTeX/PDF files

A cheap way of converting a LaTeX-created PDF presentation (e.g., beamer, prosper or (limited in animation capabilities) TeXPower) is to convert every PDF page into an image and run the images through img2ooImpress.pl. The PDF-to-image conversion can be handled by ghostscript (gs). 'gs -h' will show some useful options and a list of formats it can export to. Look for pngalpha, png16m, and jpeg as useful image formats. If pngalpha (PNG with antialias rendering) is available, you can run something similar to:

gs -dNOPAUSE -g1024x768 -r205 -sDEVICE=pngalpha \
 -sOutputFile=Talkimg_%d.png  -dBATCH Talk.pdf

which creates 1024x768-sized, antialiased PNG images, consecutively numbered Talkimg_1.png to however many pages were in the PDF. The -r205 specifies the resolution which fits PDF files produced with 'pdflatex' and the beamer class. For other PDF files you will want to change the resolution so you fill the 1024x768 pixels as close as possible. 'gs' either pads with white or just clips your pages if the '-r' does not match the '-g' option. With pages rendered exactly at destination resolution no additional scaling will occur and the images should look good on the screen. Alternatively, you can generate the images too large and let Impress do the scaling (image size is set to full page in the script) so they will fit on the slide, e.g.:

gs -dNOPAUSE -r300 -sDEVICE=pngalpha \
 -sOutputFile=Talkimg_%d.png  -dBATCH Talk.pdf

which again is OK for a beamer-class PDF file as the slides are rather small. For a PDF document in A4 landscape, 300 dpi is way too high (-r specifies the dpi resolution for which 'gs' should render the image). Switching from page to page will get really slow if the images are much larger then the actual resolution.

ls -rt *_1024.jpg > imglist
img2ooImpress.pl imglist MyTalk.swi

then converts the images into an Impress file. Since the 'gs' image is generated without padding zeros, i.e. 1, 2, ..., 10, 11, ..., the "ls -rt *png" reverse sorts by file modification time and gets the page sequence right. For some reason, this doesn't work right on all systems and the file list is still not sorted properly. There are several methods to create the filenames with enough left hand zeros so they can be used in "alphabetic" order. If you have "mmv" installed, and you used a file name structure like File_[num].png, you could use:

mmv "*_?.png" "#1_0#2.png"

Here "mmv" will replace #1 with whatever the first wildcard matches and will add one zero left of every single digit number. #2 will become the number before the change. It's straightforward to extend this to more padding zeros. Another option is a Perl-based renaming script as in the perl cookbook or a slightly modified version which lets you test a regular expression until you tell it to actually do the rename by adding as first option "-x", i.e.:

rename.pl -x 's/(\d+)/sprintf "%03d", $1/e' Talkimg*png

which pads left-hand zeros so all images have three digits. A simple 'ls "Talkimg*png" > list' will now create the properly sorted list for 'img2ooImpress.pl'.

Drawbacks

The one major drawback is that any navigational link in the PDF ('beamer' can add a full clickable table of contents in a sidebar) is lost. Text changes can only be added in the Impress/PPT file by overlaying boxes to hide the original text and adding new text on top of that. However, with the suggested small modification in the size and position specification, you could still create preformatted pages which only need the additional title and/or text; then, you could easily choose Insert-NewSlide, insert-Graphics-fromFile, align and resize to fit, etc.

Other uses?

With the rise of digital cameras and the disappearance of color slides (do you still have some?), why not create an Impress or PowerPoint presentation from your latest holiday photos? (assuming Bash usage):

cd your/image/dir
for i in *jpg; do
convert -geometry 1024x768 $i `basename $i .jpg`_1024.jpg
done
ls *_1024.jpg > list
img2ooImpress.pl list img2ooImpressExport.swi

You could then run 'soffice img2ooImpressExport.swi' to see the resulting presentation.

The 'for' loop and 'convert' (from ImageMagick) scale the images down to 1024x768 (most beamers won't use anything larger) and you could throw in a gamma correction (-gamma x), watermark, added text, rotation, sharpening or whatever (see "man convert" for details).

Karl-Heinz is a member of The Answer Gang.

---

I'm a physicist working on magnetic resonance at the university hospital in Jena, Germany. I started out with Linux as it made the leap to 2.0.0 and have been running my home PC under Linux since then. The Laptop and an AMD64 box also run under Linux. With computers, I started out in school when they got Commodore PET 4040 boxes and later the very first PCs. Around that time I picked up a Ti99/4a and did some assembler progamming (nice 16bit command set and relocateable registers) on that one since it was so damn slow in BASIC. At the university I finally got my fingers on a SUN ELC worksation and have tried to stay with Unix systems afterwards.

Booting Knoppix from a USB Pendrive via Floppy

By Ben Okopnik

There's a certain theme that runs through the Linux community, a sense of invulnerability with which we endow our perception of our systems. Terms like "bullet-proof" and "rock-solid", and phrases like "you could run it on a toaster" abound - silly if considered in the bright light of day, and dangerous when looked at from a certain perspective. What if someone called you on it? Would you actually be able to set up a PC with Linux, fire a 44-Magnum round at it, and expect it to bounce off? Would you expect a PC to break in two along a cleavage line if you struck it with a geological hammer? Do you really think that plugging a CD into the bread slot of a toaster will make it pop up a cool GUI a few seconds later? Of course not...

...but, well, still. There's so much that Linux does so well, so many avenues that it opens that looked to be permanently shut, that even in the hopeless cases we still harbor a bit of hope. Just a touch of a sense that maybe, just maybe, just possibly there's some magic extra, some little advantage that will let us overcome broken hardware, missing cables, outdated equipment... hey, don't some of those Linux floppy firewall distros run without a monitor or even a hard drive? If they can do it, why not us?

The thing that keeps it going is that on a few occasions - not all, but a few - there are those little successes that set us up for the next time. Whether this is a good thing or a bad thing, I refuse to judge; I'm as much of a success junkie as most other geeks, and am unrepentant about it - am, in fact, always happy to boast about the fact (although, as they say, "it ain't boasting if you can do it".) All the more so if recounting the experience can help others learn a fun new method, or a cool way to accomplish something useful. Hence, this article.

The Challenge

My fiancée was interested in trying Linux - her opinion regarding OSes being that Micr0s0ft should have stopped when the going was good (that being defined as some time around the release of DOS 5.0.) Since they hadn't, and since neither Micr0s0ft Bob nor the dancing paperclips had lived up to their promise - which she hadn't believed anyway - she was quite happy to try an OS that was bullet-proof and solid as a rock... erm. Well, you know what I mean, anyway.

However, there was A Problem. To be more precise, a long series of problems, compounded by the circumstances. For one thing, her laptop - an aging Sony VAIO F590K - did not have a working CD-ROM drive (goodbye, quick and easy chance of booting Knoppix - or most of the other LiveCD distros...) For another, she is the editor of a monthly newsletter for space activists, and must have uninterrupted access to a powerful graphic program as well as a DTP (desktop publisher program) - having her computer out of service for any length of time was not an option. What she really wanted was a chance to play with Linux on her machine, where the feel of the keyboard and all the controls was familiar and comfortable for her (and I heartily agreed, on the principle that, in a properly-designed experiment, only the factor under test should change while all else is held equal.) To complicate things a bit further, we live on a sailboat at anchor, and our Net access is therefore less than stellar - and is quite slow. Things were looking pretty grim.

By this point, I had considered a number of options, and had rejected almost as many as I'd considered. What remained were some dim possibilities - perhaps booting a minimal floppy-based Linux environment with a VNC client while I ran a VNC server elsewhere on our LAN (clunky and restricted by the artifacts of VNC itself), or maybe setting up the Cygwin X server on Wind0ws (Terra Incognita to me since I'd never done anything with Cygwin, along with a good bit of apprehension related to how it would work and what kind of problems it would introduce into the process - on top of those created by KDE's cluelessness with regard to the X networking paradigm), or... or... wait, how about booting Knoppix from a flash drive? I seemed to recall that I had read something about this, somewhere - perhaps even a success story? - and I was perfectly willing and able to search the Net for an answer. The details of the necessary process were a bit of a muddle in my head, but given time and resources, that would shake out.

The Approach

Googling around the Web refined my list of remaining ideas even further, knocking out several of the possibilities - as an example, several of the live distros failed to include either the GIMP or OOffice, both of which had been decided on as necessities - and focusing the choice down to Knoppix and a few similar distros. Knoppix, as the most-commonly used example of the genre, seemed to be the final answer - but how was I to get it to the VAIO? The flash drive that I had, a 1GB Geek Squad pendrive, would hold the image with room left over, but the machine had no option for booting from flash - and a quick scan of Sony's site showed that there were no BIOS updates to fix this.

About that time, I recalled that someone in the Answer Gang had mentioned Puppy Linux in the recent past - and that the site had a discussion on how to make it boot from flash by using a floppy. Hurrah!... well, Puppy doesn't contain GIMP or OOffice (although it does have Scribus), but the fact that people are booting USB-based Linux images via floppy was encouraging; this is what I was looking for.

FLASH! Uh-huh...

I read the FAQ very carefully, and got a very definite... headache. For whatever reason, right at that moment my brain simply refused to accomodate the necessary information - I'm sure that it had nothing to do with the way it was presented, just that I didn't quite get it. More searching produced the Boot KNOPPIX from an USB Memory Stick FAQ - which helped a bit but still didn't get me where I wanted to go. More research, including posting to The Answer Gang (thanks, guys!)... and then I ran across Fabian Franz' script for booting Knoppix 3.4. It didn't work, of course - I didn't expect it to, since Knoppix has changed quite a bit since those days - but by this point, I understood the process and the structure of the Knoppix image well enough that I could follow the logic all the way through.

Combining the information from the above FAQ and the script finally made it all click. The Knoppix CD consists of a number of files, of which only one really mattered to what I needed: the "miniroot". To be exact, the miniroot is a compressed bootable image within the Knoppix image - it is, in fact, the part that makes the Knoppix CD bootable - so tweaking the files inside it consisted of the following steps:

1. Mount the Knoppix image
2. Decompress the miniroot into a temporary file
3. Mount the miniroot
4. Modify the files in it
5. Recompress it
6. Create a loop-mounted file
7. Copy the miniroot into it
8. Make it bootable
9. Write it to a floppy

Since the miniroot was larger than 1.44MB, the size it needed to be in order to fit on a floppy, the easiest "diet" for it consisted of mercilessly ripping out all the modules that were not needed for booting. The SCSI modules could go... so could the CD-related ones... the important thing to remember was that the miniroot's job is to simply boot a very basic Linux environment and immediately turn control over to Knoppix - which still had every bell and whistle it came with (the Knoppix image itself remained untouched; the miniroot being tweaked was only a copy.) If it became necessary, I'd get a crowbar and start ripping out other bits... fortunately, this was not required, since removing all modules other than the "usb"- and "hci"-related ones left the miniroot below critical mass.

At this point, I ran into another problem... but this one was small enough to be laughable. My laptop has no floppy drive, and the VAIO had nothing resembling '/bin/dd' - and I couldn't think of anything other than DOS's "debug.exe" that would write a raw image to a floppy. Yikes! Would I actually have to remember that ancient command set to do this simple job?... oh, right - the Debian project has "rawrite.exe" in its "tools/" subdirectory. Whew. A few seconds to burn the floppy, and... that familiar Knoppix logo glowed on the VAIO screen. [1]

No Wasted Effort

After going through all this - it was an on-again, off-again project that stretched over a number of weeks - I decided that there were other Linux folks out there who would like to do this (NO, not the struggle and the headache - the floppy/USB boot, of course!) The traditional *nix method to propagate knowledge - notice that it worked well in my case - is a script; the one presented below is a heavily-modified version of the one by Fabian Franz. It allows you to specify a directory containing the Knoppix image(s) as a command-line argument, or in the user configuration section in the script itself, and creates a file called "boot.img" that can be burned to a floppy to make a bootable environment that passes control to a USB device. NOTE: I've tested it as thoroughly as I could on my own machine, but make no guarantees in regard to anything else. If it breaks, you get to keep both pieces. Yes, you are welcome to contact me with suggestions or bug reports; no, I don't know how to fix [pick issue of the day here] in Knoppix. I'm just a guy whose fiancée wants to play with the stuff.

A downloadable file version of this script can be found here. Enjoy, and happy Linuxing!

#!/bin/bash
# Created by Ben Okopnik on Thu Mar 17 23:56:31 EST 2005
#
# Many thanks to Fabian Franz, whose original script gave me the idea of
# how it's all supposed to work.
#
# This script creates a boot floppy that passes control to a USB PenDrive
# containing a Knoppix CD image. No CDROM, no problem!
#

############## User configuration section ###############################

# Set this to the directory where the Knoppix image lives, or specify the
# directory as a command-line argument.
KNOPPIX_DIR=${1:-/home/ben/tmp2}

############## End of user config section ###############################

abort()
{
  printf "$@\n"
  exit 1
}

clean_exit()
{
  [ -d "$TMPDIR" ] && rm -rf $TMPDIR
}

# Validation tests
[ $UID -ne 0 ] && abort "Root privileges are required to run this script."
[ -d "$KNOPPIX_DIR" ] || abort "$KNOPPIX_DIR is not a directory."
[ -z "`ls $KNOPPIX_DIR|grep -i 'knoppix.*iso'`" ] && 
	abort "Knoppix image not found in $KNOPPIX_DIR."

# Create temp dir, get rid of it on exit
TMPDIR=`mktemp -dp /tmp/ make_floppy.XXXXXX`
trap "clean_exit" EXIT

# Jump into TMPDIR and prepare it for the coming ops
ORIG_DIR=$(pwd)
cd $TMPDIR
mkdir knoppix floppy miniroot old_miniroot

# Choose and mount the Knoppix image
printf "Please choose one of the following images:\n"
select choice in $KNOPPIX_DIR/K*.iso; do break; done
mount $choice knoppix -o loop

# Decompress the miniroot from the mounted image's boot dir
gunzip -c knoppix/boot/isolinux/minirt24.gz > minirt24

# "Back up" and mount the miniroot
mv minirt24 minirt24.old
mount -o loop minirt24.old old_miniroot

# Create the file which will contain the new miniroot; format it as a DOS
# FS and mount it
dd if=/dev/zero of=minirt24 bs=4M count=1
mke2fs -L "KNOPPIX Miniroot" -b 1024 -N 8192 -O none -F -q -m 0 minirt24
mount -o loop minirt24 miniroot

# Copy the USB-related modules from the old miniroot to the new one
mkdir -p miniroot/modules/scsi
for n in `ls old_miniroot/modules/scsi|egrep 'usb|hci'`
do
	cp old_miniroot/modules/scsi/"$n" miniroot/modules/scsi
done

# Copy everything except the "scsi" dir from the old miniroot to the new
# one
rm -rf old_miniroot/modules/scsi
cp -af old_miniroot/* miniroot/

# Unmount both
umount old_miniroot
umount miniroot

# Compress the miniroot again
gzip -9 minirt24

# Create a 1.44MB file which will contain the boot image, format it as a
# DOS FS, and mount it.
dd if=/dev/zero of=$TMPDIR/boot.img bs=1k count=1440
mkdosfs $TMPDIR/boot.img
mount -t msdos boot.img floppy -o loop

# Grrr... "mount" weirdness requires waiting, then remounting in order to
# have it read-writeable. Perhaps the 'mount' maintainer should get a bug
# report?
sleep 2
mount floppy -o remount,rw

# Copy the required files from Knoppix's boot dir to the image we're building
FILES="boot.msg f2 f3 german.kbd isolinux.cfg linux24 logo.16"
(cd knoppix/boot/isolinux/; cp -f $FILES $TMPDIR/floppy/)

# Copy the new miniroot into it - we're almost done!
cp minirt24.gz floppy/

# Rename and tweak the config file to conform to the SYSLINUX usage
mv floppy/isolinux.cfg floppy/syslinux.cfg
[ -n "$LANGUAGE" ] && perl -pi -e "s/lang=de/lang=$LANGUAGE/g" floppy/syslinux.cfg
[ -n "$LANGUAGE" ] && perl -pi -e "s/lang=us/lang=$LANGUAGE/g" floppy/syslinux.cfg

# A little cleanup...
umount knoppix
umount floppy

# Make the image bootable! Since it's not an actual device, 'syslinux' is
# going to complain - but we're tough and can handle it.
syslinux boot.img 2>/dev/null

# Put the boot image back where we started
cp -i boot.img $ORIG_DIR

printf "The boot diskette can now be created with 'dd if=boot.img of=/dev/fd0'.\n"

---

There's still the issue of the very strange-looking mouse pointer in Knoppix on the VAIO: it looks like a 100x100px square of TV interference. I'm told that tweaking the X configuration file will fix this, but I have not yet had the time to devote to it. Perhaps the fact of having written this article will provide sufficient motivation...

---

Ben is the Editor-in-Chief for Linux Gazette and a member of The Answer Gang.

Ben was born in Moscow, Russia in 1962. He became interested in electricity at the tender age of six, promptly demonstrated it by sticking a fork into a socket and starting a fire, and has been falling down technological mineshafts ever since. He has been working with computers since the Elder Days, when they had to be built by soldering parts onto printed circuit boards and programs had to fit into 4k of memory. He would gladly pay good money to any psychologist who can cure him of the recurrent nightmares.

His subsequent experiences include creating software in nearly a dozen languages, network and database maintenance during the approach of a hurricane, and writing articles for publications ranging from sailing magazines to technological journals. After a seven-year Atlantic/Caribbean cruise under sail and passages up and down the East coast of the US, he is currently anchored in St. Augustine, Florida. He works as a technical instructor for Sun Microsystems and a private Open Source consultant/Web developer. His current set of hobbies includes flying, yoga, martial arts, motorcycles, writing, and Roman history; his Palm Pilot is crammed full of alarms, many of which contain exclamation points.

He has been working with Linux since 1997, and credits it with his complete loss of interest in waging nuclear warfare on parts of the Pacific Northwest.

Introduction to Shell Scripting, part 6

By Ben Okopnik

Originally published in Issue 57 of Linux Gazette, September 2000

Random Wanderings

Well, this should be the last article in the "Introduction to Shell Scripting" series - I've had great feedback from a number of readers (and thank you all for your kind comments!), but we've covered most of the basics; that was the original purpose of the series. I may yet pop up at some point in the future ("Oh, rats, I forgot to explain XYZ!"), but those of you who've been following along should now consider yourselves Big-Time Experts, qualified to carry a briefcase and sound important... erm, not. :) At least you should have a pretty good idea of how to write a script and make it work - and that's a handy skill.

A Valued Assistant

Quite a while ago, I found myself in a quandary while writing a script; I had an array that contained a list of command lines that I needed to execute based on certain conditions. I could read the array easily enough, or print out any of the variables - but what I needed was to execute them! What to do, what to do... as I remember, I gave up for lack of that one capability, and rewrote the whole (quite large) script (it was not a joyful experience). "eval" would have been the solution.

Here's how it works - create a variable called $cmd, like so:

Odin:~$ cmd='cat .bashrc|sort'

Now, you can echo the thing -

Odin:~$ echo $cmd
cat .bashrc|sort'

- but how do you execute it? Just running "$cmd" produces an error:

Odin:~$ $cmd
cat: .bashrc|sort: No such file or directory

This is where "eval" comes into its own: "eval $cmd" would evaluate the string contained in the variable as if it had been entered at the command line. This is not something that comes up too often... but it is a capability of the shell that you need to be aware of.

Trapped Like a Rat

One of the standard techniques in scripting (and in programming in general) is that of writing data to temporary files - there are many reasons to do this. But, and this is a big one, what happens when your users interrupt that script half-way through execution? (For those of you who have scripts like that and haven't thought of the issue, sorry to give you material for nightmares. At least I'll show you the solution as well.)

You guessed it: a mess. Files in "/tmp", perhaps important data left hanging in the breeze, files thought to be updated that are not... Yuck. How about a way for us to exit gracefully, despite a frantic keyboard-pounding user who just has to run Quake RIGHT NOW?

The "trap" command provides an answer of sorts (shooting said user is far more effective and enjoyable, but may get you talked about).

 
#!/bin/bash

function cleanup ()
{
	# Ignore 'Ctrl-C'; let him pound away...
	trap '' 2
	
	echo "Wake up, Neo."
	sleep 2
	clear
	echo "The Matrix has you."
	
	echo "He's at it again."|mail admin -s "Update stopped by $USER"
	
	# Restore the original data
	tar xvzf /mnt/backup/accts_recvbl -C /usr/local/acct
	
	# Delete 'tmp' stuff
	rm -rf /tmp/in_process/
	
	# OK, we've taken care of the cleanup. Now, it's REVENGE time!!!
	rm /usr/games/[xs]quake
	
	# Give him a nice new password...
	chpasswd $USER:~X%y!Z@zF%HG72F8b@Moron!&(~64sfgrnntQwvff########^
	
	# We'll back up all his stuff... Oh, what does "--remove-files" do?
	tar cvz --remove-files -f /mnt/timbuktu/bye-bye.tgz /home/$USER
	# Heh-heh-heh...
	umount /mnt/timbuktu
	
	trap 2 # Set Ctrl-C back to normal
	exit        
	# Yep, I meant to do that...
}

trap 'cleanup' 2
...

There's a little of the BOfH inside every admin. <grin> (For those of you not familiar with the "BOfH Saga", this is a must read for every Unix admin; appalling and hideously funny. Search the Web.)

DON'T run this script... yes, I know it's tempting. The point of "trap" is, we can define a behavior whenever the user hits `Ctrl-Break' (or for that matter, any time the script exits) that is much more useful to us than just crashing out of the program; it gives us a chance to clean up, generate warnings, etc.

"trap" can also catch other signals; the fact is that "kill", despite its name, does not of itself `kill' a process - it sends a signal. The process then decides what to do with that signal (this is a crude description, but generally correct). If you wish to see the entire list of signals, just type "trap -l" or "kill -l" or even "killall -l" (which does not list the signal numbers, just names). The ones most commonly used are 1) SIGHUP, 2) SIGINT, 3) SIGQUIT, 9) SIGKILL, and 15) SIGTERM (this last one is the default for 'kill' when no signal name or number is specified.)

There are also the `special' signals. They are: 0) EXIT, which traps on any exit from the shell, and DEBUG (no number assigned), which can - here's a nifty thing! - be used to troubleshoot shell scripts (it traps every time a simple command is executed). DEBUG is actually more of an "info only" item: you can have this exact action without writing any "trap"s, simply by adding "-x" to your shebang (see "In Case Of Trouble...", below).

"trap" is a powerful tool. In LG#37, Jim Dennis had a short script fragment that created a secure directory under "/tmp" for just this sort of thing - temp files that you don't want exposed to the world. Pretty cool gadget; I've used it myself a few times since.

In Case Of Trouble, Break Glass

Speaking of troubleshooting, Bash provides several very useful tools that can help you find the errors in your script. These are switches - part of the "set" command syntax - that are used in the shebang line of the script itself. These switches are:

• -n Read the shell script lines, but do not execute
• -v Print the lines as they're read
• -f Disable wildcard expansion
• -x Prints $PS4 (the "level of indirection" prompt), interprets, executes, and prints the command.

I've found that "-nv" and "-x" (and perhaps "-xf") are the most useful invocations: one gives you the exact location of a "bad" line (you can see where the script would crash); the other, `noisy' though it is, is handy for seeing where things aren't happening quite the right way (when, even though the syntax is right, the action is not what you want). Good troubleshooting tools both. As time passes and you get used to the quirks of error reporting, you'll probably use them less and less, but they're invaluable to a new shell script writer.

Use The Source, Luke

Here's a line familiar to every "C" programmer:

#include <stdio.h>

- a very useful concept, that of sourcing external files. What that means is that a "C" programmer can write routines (functions) that are used repeatedly, store them in a `library' (an external file), and bring them in as they are needed. Well - have I not said that shell scripting is a mature, capable programming language? - we can do the same thing! The file doesn't even have to be executable; the syntax that we use in sourcing it takes care of that. The example below is a snippet of the top of my function library, "Funky". Currently, it is a single file, a couple of kB long, and growing apace.

There's a tricky little bit of Bash maneuvering that's worth knowing: if you create a variable called BASH_ENV in your .bash_profile, like so:

export BASH_ENV="~/.bash_env"

then create a file called ".bash_env" in your home directory, that file will be re-read every time you start a `non-login non-interactive shell' - i.e., a shell script. That's where I source "Funky" from - that way, any changes in it are immediately available to any shell script. It can also be sourced right from the command line.

calc () # Integer-only command-line calculator
{
    printf "$(($*))\n"
}

getch () # silently gets a char from keyboard, returns $GETCH
{
    OLD=`stty -g`
    stty raw -echo
    dd if=/dev/tty bs=1 count=1 2>/dev/null
    stty $OLD
}

colsel () # Color selector - iterates through all the $TERM's color choices
{
trap 'echo -en "\E[$40;1m"; clear' 0	# Reset on exit
n=49	# Max foreground color value
while [ "$n" -ne 0 ]
do
	m=39	# Max background color value
	while [ "$m" -ne 0 ]
	do
		echo -en "\E[$m;${n}m"
        	clear
		echo "This is a test."
		echo -en "\E[$40;1m"
        	echo -n " $n $m "
        	read
		(( m-- ))
	done
	(( n-- ))
done
}

Not too different from a script, is it? No shebang is necessary, since this file does not get executed by itself. So, how do we use it in a script? Here it is (we'll pretend that I don't source "Funky" in ".bash_env"):

#!/bin/bash
. Funky
declare -i Total=0
leave ()
{
    echo "So youse are done shoppin'?"
    [ $total -ne 0 ] && echo "Dat'll be $total bucks, pal."
    echo "Have a nice day."
    exit
}

# Exec the 'leave' function on exit
trap 'leave' 0

clear

# Infinite loop!
while :
do
    echo
    echo "Whaddaya want? I got Cucumbers, Tomatoes, Lettuce, Onions,"
    echo "and Radishes today."
    echo
    
    # Here's where we call a sourced function...
    input=`getch`
    # ...and reference a variable created by that function.
    case $input
    in
	C|c) Total=$Total+1; echo "Them are good cukes." ;;
	T|t) Total=$Total+2; echo "Ripe tomatoes, huh?" ;;
	L|l) Total=$Total+2; echo "I picked da lettuce myself." ;;
	O|o) Total=$Total+1; echo "Fresh enough to make youse cry!" ;;
	R|r) Total=$Total+2; echo "Real crispy radishes." ;;
	*) echo "Ain't got nuttin' like that today, mebbe tomorra." ;;
    esac
    sleep 2

 done

Note the period before "Funky": that's an alias for the "source" command. When sourced, "Funky" acquires an interesting property: just as if we had asked "bash" to execute a file, it goes out and searches the path listed in $PATH. Since I keep "Funky" in "/usr/local/bin" (part of my $PATH), I don't need to give an explicit path to it.

If you're going to be writing shell scripts, I strongly suggest that you start your own `library' of functions. (HINT: Steal the functions from the above example!) Rather than typing them over and over again, a single "source" argument will get you lots and lots of `canned' goodies.

Wrapping Up The Series

Well - overall, lots of topics covered, some "quirks" explained; all good stuff, useful shell scripting info. There's a lot more to it - remember, this series was only an introduction to shell scripting - but anyone who's stuck with me from the beginning and persevered in following my brand of pretzel-bending logic (poor people! irretrievably damaged, not even the best psychologist in the world can help you now... :) should now be able to design, write, and troubleshoot a fairly decent shell script. The rest of it - understanding and writing the more complex, more involved scripts - can only come with practice, otherwise known as "making lots of mistakes". In that spirit, I wish you all lots of "mistakes"!

Happy Linuxing!

---

References

The "man" pages for 'bash', 'builtins', 'stty'
"Introduction to Shell Scripting - The Basics", LG #53
"Introduction to Shell Scripting", LG #54
"Introduction to Shell Scripting", LG #55
"Introduction to Shell Scripting", LG #56
"Introduction to Shell Scripting", LG #57
"Introduction to Shell Scripting", LG #59

---

Ben is the Editor-in-Chief for Linux Gazette and a member of The Answer Gang.

Ben was born in Moscow, Russia in 1962. He became interested in electricity at the tender age of six, promptly demonstrated it by sticking a fork into a socket and starting a fire, and has been falling down technological mineshafts ever since. He has been working with computers since the Elder Days, when they had to be built by soldering parts onto printed circuit boards and programs had to fit into 4k of memory. He would gladly pay good money to any psychologist who can cure him of the recurrent nightmares.

His subsequent experiences include creating software in nearly a dozen languages, network and database maintenance during the approach of a hurricane, and writing articles for publications ranging from sailing magazines to technological journals. After a seven-year Atlantic/Caribbean cruise under sail and passages up and down the East coast of the US, he is currently anchored in St. Augustine, Florida. He works as a technical instructor for Sun Microsystems and a private Open Source consultant/Web developer. His current set of hobbies includes flying, yoga, martial arts, motorcycles, writing, and Roman history; his Palm Pilot is crammed full of alarms, many of which contain exclamation points.

He has been working with Linux since 1997, and credits it with his complete loss of interest in waging nuclear warfare on parts of the Pacific Northwest.

User-Centered Design

By Mike Orr (Sluggo)

Software developers are good at making programs that work. We're less good at making programs that do what the users want, or are convenient to use. That's because developers often misunderstand what users need, even when they try hard to "think like a user". My development strategy is a common one: (1) get requirements from management, (2) draw out a design, (3) code it, (4) debug, (5) beta test, (6) rollout, (7) DONE! (Except documentation and periodic maintenance, of course.) But the past few months I've been fortunate to work with a woman who's getting a PhD in Cognitive Science and leads workshops in user-centered design and usability testing. I've been amazed at how well these techniques identify missing features and misfeatures in programs, things developers would not have considered. I've also been fortunate to have an enlightened management team willing to try these techniques in our projects. So I wanted to share a bit about these techniques.

Usability testing is based on the premise that it will happen whether planned or not. Either the developers will do it in their labs, or the customers will do it after they've bought the product. The latter leads to frustrated and angry users, and an expensive redesign down the road. Either you build a prototype and test it with typical users, or your version 1.0 is a de facto prototype, a beta disguised as a final product.

It may surprise people that many these principles were already known in the 1970s. Surprising because they still haven't trickled very far into programming practice twenty-five years later, as anybody who has sworn at a perfectly-running but incorrigible program -- or wanted to throw a version 1.0 off a cliff -- can attest. One of the seminal research papers is Designing for Usability: Key Principles and What Designers Think (PDF, 1.6 MB), written in 1985 by John D Gould and Clayton Lewis, two IBM researchers. The paper discusses three principles of user-centered design: (A) early focus on users and tasks, (B) empirical measurement, and (C) iterative design. It shows how designers often don't do these even when they think they are, and then presents a case where the principles were successful. The paper has amusing 1980s assumptions; e.g., Wang word processors are common, computers are mostly "terminals", managers don't have computers, the Apple Lisa was recent, etc. The "case" was a project to build a dictation system with a telephone interface. That is, a manager would call the service, press a few buttons, record his letter, then later a secretary would later type up a paper copy and deliver it.

The first thing the developers did was to think about the users, as discussed below. They then invited users into the design process, to tell the developers what they wanted. The developers built prototypes and devised usability tests to verify they were going in the right direction. A usability test is an empirical measurement; e.g., can 80% of users perform a specific task correctly in X minutes with only Y type of help? What mistakes do they make? Do these mistakes suggest defects in the design? This process is iterative, meaning feedback leads to changes in the prototype, which leads to more feedback, which leads to more changes, etc. Eventually the suggestions become fewer and more trivial, meaning you are close to completion.

The prototype had a table-driven user interface so changes could be made easily. Keys are linked to API functions via a keymap, and some keys lead to other keymaps (submenus). Output messages are kept in another table. This allowed them to reorganize the user interface based on user feedback without touching the underlying code, and they could also add additional user interfaces for different types of users. Another advantage was that when the prototype was finally deemed acceptable, the work was done: the prototype was the final product. ("How long will it take you to implement this for real? ---No time.")

This whole process led to major benefits which would not have been possible otherwise. Early usability tests showed that a "dictation system" was not really worthwhile: the users didn't take to it and it was inefficient. What the users did like was the ability to listen to messages they or others had recorded. This was an unintended side effect but it became the primary feature. So a "dictation system" became a "voice message" system in an era when voice mail was unknown. This would never have happened in a linear development process where the design was fixed at an early stage, as in my step 2 above. Even if the users were asked at the beginning what features they wanted, they could not have said. They had to actually play with the product before they knew what they wanted. But by the time they saw the product in the beta test it would have been too late, especially if I had not had the foresight to make the user interface code isolated and flexible.

User-centered design doesn't replace the linear development model; it goes on top of it. Every stage includes user analysis and usability testing, and occasionally discoveries require looping back to an earlier stage. But you're still going in the same general direction. Just expect a lot of build-test-refine-test-refine cycles.

The rest of this article is a cookbook of ways to evaluate the usability of your product. These are just a few ideas, the tip of the iceberg. If you know a usability expert, I would highly recommend sitting in on a design session or hiring their services, because they have many ingenious ideas up their sleeve that I am only beginning to explore.

General

When recording user feedback or brainstorming, it's helpful to write in two columns. On the left put observations; on the right put implications for the product. For instance, "several users thought they were supposed to do X" is an observation. "Have a popup window that explains not to do X" is an implication. Just list implications for later analysis; don't dwell on them now. Dwelling on implications takes time away from getting feedback, and may distort the quality of the feedback.

If you're concerned about how long this will take, remember that usability research can be done simultaneously with other development, especially if more than one developer is available. This initial stage may take longer, but the results will be seen in the quality of the product, and you may even be able to make up time by avoiding mistakes.

Also, keep in mind that it's OK to defer some features to "phase 2". At some point you have to get a working product out the door. Maybe production use will uncover flaws more significant than the phase 2 features. Or maybe the users will decide those features aren't that important after all, and they'd rather have something else in phase 2.

Once you've identified some questions and ideas that work, make them into a checklist for future projects. That will make ongoing design all the much easier.

Who are the users?

• Who will be interacting with the product most frequently? E.g., data entry operators, customer support representatives.
• Who will use the product less frequently? E.g., managers viewing quarterly summaries, sysadmins creating user accounts or doing configuration.
• Who does not use the product directly but is affected by those who do? E.g., for a store checkout system, the cashier's customer.

Beware of know-it-all supervisors or buyers. If they aren't the main users themselves, they probably understand less than they think they do about what system would be the most productive and satisfying for the users. Sometimes this is difficult because the supervisors are your clients and won't allow you to talk to the users. In this case, try to impress on them how essential interaction with users and usability testing is for the quality of the product. Or maybe it's a sign not to take that job, since the clients will no doubt blame you for any shortcomings in the product.

Observing users

• Observe users doing their daily tasks. Which tasks are most frequent or most important? How do your product's tasks fit into the overall picture?
• Is your product replacing an existing product? How do users interact with the current product? Are they satisfied with it? What do they do when it's broken?
• Are the users enthusiastic about their job in general or just punching the clock?
• How do they deal with emergencies or unusual situations?
• What constraints (lack of resources) do they have? Is the room too small? Not enough computers? Are the computers maxed out in their performance?
• What are the users' job types, professional levels, skill levels, education backgrounds, language backgrounds, physical/mental disabilities?
• Is it possible that future users will need more accommodation than current users? E.g., accessibility, simple instructions, online help.
• Do the users like to explore new programs and figure out how to do things (inductive), or would they rather get an overview and then learn the details (deductive).
• Did the users get formal training on the existing system? Was the training adequate?
• How often will they use the new system? How much turnover will there be? Both of these determine what kind of instructions and help they will need.
• Are the users required to use the system or is it a discretionary choice? If users don't find it easy and convenient, they won't use it.

If you can't observe the users in action, you'll have to use another means such as interviews, written answers, secondary users, or managers. But be aware this information will likely be lower quality.

Sharing your impressions with the users and managers will often elicit further suggestions. It'll also impress the managers with your thoroughness and insight.

Beware of underestimating the diversity of users. Also beware of how difficult a "simple" task can appear to a user, who doesn't have the developer's background knowledge.

Identifying Goals

• Who should be using the product (as opposed to who is using it)? What incentives can we give to those who should be using it but are not? What alternatives can we give to those who should not be using it?
• List step-by-step task sequences the users typically perform. Is this the most efficient sequence for the user? Are there steps we'd like to drop or let the computer perform automatically? What constraints do users' tasks place on the system? E.g., features that must exist, accommodation for users without web access or using a slow modem.
• For tasks that require multiple persons, who does what part?
• Does program input come from another program? What format is it in? Does output go to another program? What format does it have to be in?
• Have the user draw screens and write down what they expect to type or click on at each step.
• List the nouns and verbs that represent the concepts the product needs to support. This can lead to a preliminary object model.

  E.g., in a doctor's office, a Patient object has attributes for name, phone, insurance ID, and medical history. A Drug object has the drug's name, principal effect, side effects, indications (who should use it), contraindications (who should not use it), interactions with other drugs, a list of manufacturers/brands/prices, and the doctor's personal notes about the drug's effectiveness. The doctor logs in, finds the patient and his chart, writes notes in the chart, browses the drug selection, and writes a prescription.

• Have users write short paragraphs on flashcards describing a "usage story": how they'd like to interact with the product and what it should do. Lay the flashcards on a large table or pin them to a bulletin board, and move them around into logical groups. (Fans of eXtreme Programming will like this.)
• What measurable tests can the user think of that will show how well the product is meeting its goals?

Usability tests

Decide on a test that will measurably show whether the product is getting closer to its goal.

• Build a working prototype that fulfills the basic requirements, even if it doesn't have all the features or a pretty interface.
• If the requirements are too lofty to build a prototype in a week, break them up into smaller pieces that can be tested separately.
• Draw screenshots of what the program would look like, showing each screen the user would interact with.
• "Play computer". Sit in the workplace and have the users come to you and tell you what buttons they'd press and what input they'd give, and you tell them how the computer would respond. Or have the users write down the keys they would press.
• Draw workflow diagrams showing what role each person plays in the whole.
• Before writing the program, write the users' manual and ask for feedback.
• Ask users to "think aloud" as they try to complete a task. This can provide valuable insight regarding the program's navigation and layout. A user can also keep a diary about their impressions.
• Ask the user to read a section of documentation and summarize what it means.
• Are the most frequently-used or important controls in a prominent location on the first screen? Does the layout guide the eye to them? Do the dialogs contain seldom-used or overtechnical text that distracts the mind? Maybe these should be banished to a separate screen and reworded, or maybe the screen needs a "legend" page or an application-wide glossary.
• Log calls to the help desk or the use of online help. See which questions appear most frequently.

For general open-source products like KOffice where there are thousands of users worldwide, it may make sense to continue the practice of releasing alphas and betas and having a bug-tracking database, but also send out more focused surveys on what is good/bad about the product.

I hope this gives you a taste of what is possible, and perhaps piques your interest in learning more about usability research. There are several good textbooks available from your friendly college bookstore, including Human Aspects of Computing edited by Henry Ledgard, Usability Testing and Research by Carol M Barnum, User and Task Analysis for Interface Design by JT Hackos and JC Redish, and others. These are the ones I consulted for the checklist above. Good luck and happy designing.

---

Mike is a Contributing Editor at Linux Gazette. He has been a Linux enthusiast since 1991, a Debian user since 1995, and now Gentoo. His favorite tool for programming is Python. Non-computer interests include martial arts, wrestling, ska and oi! and ambient music, and the international language Esperanto. He's been known to listen to Dvorak, Schubert, Mendelssohn, and Khachaturian too.

Transporting Files between Linux and Windows

By Dale Raby

A long time ago in a galaxy far... no that isn't quite right. Well, it was a while ago, 1999 or so, as I recall. In any case, it was at that particular Barbourian Now when I finally decided to jump into "modern" times and abandon my old Tandy 600 laptop for something that could actually "surf the web", as it was known back in those innocent times. So I went out and bought a used machine running Windows 95.

Having been rather flush with cash at the time, I also bought a Hewlett-Packard printer and an IBM parallel port scanner. Shortly after this, I discovered what a really rotten OS Windows of that era was. I think it was after the third or fourth time I had to take the machine in for yet another fifty dollar repair that I began to search for alternatives and discovered Linux. It was a boxed copy of Mandrake 6.5... which was even packaged with a ready-made boot disc.

Unfortunately, Linux did not support my scanner... and it still doesn't. I did without it for a time, but eventually I got another Windows machine up and limping just so I could have scanner capability. Transferring image files to the Linux machine was a laborious process involving copying to an Iomega Zip disk and then re-copying them to the Linux machine's hard drive, or emailing them to myself from the Windows machine and receiving them on the Linux machine. This was also a laborious task... especially with the 28.8 modems I was using at the time.

Eventually, I set up a LAN... which was a terrifying prospect at first that I put off for several years until I finally broke down. I had since acquired a Sony Mavica camera, which was also not supported under Linux, though I had a workaround in the floppy discs the Mavica could use. It was much easier and faster to transfer the images from the Sony Memory Stick to the Windows machine, however.

The LAN made it possible to transfer files, from one computer to the other, though it was by no means easy. I don't care what anyone says; SAMBA IS NOT simple to set up! By this time, I had pretty much abandoned Windows for all uses except supporting my legacy scanner and camera, and was getting to be fairly comfortable with command lines in a Bash shell and the use of common Linux applications like the GIMP.

I still had no easy way to get the files to my Linux machine, even though there was no theoretical hardware limitation. I am many things, but I am not by any stretch an IT professional. I was however, blessed with a web-buddy of genius level IQ; one Mae Ling Mak, formerly of the late Maximum Linux magazine. She dropped a few terms I had never heard before; 'scp' and 'Cygwin'. Now, it being too embarrassing for a studly alpha male type such as myself to actually admit to an attractive young woman that I didn't know what those terms meant, I went Googling. I find that I often do quite a bit of Googling whenever I receive an email from Mae Ling Mak.

OK - Cygwin is, for all practical purposes, a Windows application that gives you a Bash shell. Within this shell, one can run many common Linux/Unix applications on top of the Windows OS. When it is installed, one makes the choices of which applications one needs. If you want Mutt and GnuPG, for example, you simply check those boxes during the setup process, and they are installed for you.

'scp' is the "secure copy protocol". It allows one to transfer files from one location to another within the LAN or even to a server on the Internet. Using the '-r' option, one can transfer entire directories intact with all their embedded children. One of the nice things about 'scp' is that anything sent this way is automatically encrypted so that nobody can read what is sent. Read between the lines here.

Now, using 'scp' from a Cygwin Bash shell will allow one to transfer files from the Windows machine with obsolete non-Linux supported hardware to the Linux machine using a command line.

Two problems then manifested themselves; I was not familiar enough with the 'scp' command to remember the procedure from one week to the next, and the Windows directory hierarchy is complex and confusing to anyone used to Unix/Linux. Also, as noted in the illustration, one cannot navigate double-named directories with Bash, so my default Windows ME directories My Pictures, My Documents, and Program Files, are still unreachable with Cygwin.

[ In fact, they are indeed reachable - but, just like filenames that contain whitespace in *nix, they require a bit of twiddling. Namely, surrounding the file or directory name with quotes - i.e. cd "My Pictures", etc. Conversely, you could use wildcards: ls *Pictures or even ls My*Pictures should work fine. -- Ben ]

By doing a little Googling, I got the proper command sequence ironed out. Then Mae Ling jumped into my head from a few years back when she wrote an article about scripts. After a little consideration, I created a text file containing the command sequence to transfer my files to the host computer called "beam".

The simplest way to do this is to invoke 'vi', as "vi beam", and paste the text below into it, suitably modified to suit your own system. You will need to substitute your own username on the Linux system, and you may be able to use the domain name of the host computer, rather than the IP address I used, depending on how you have your LAN set up. The '-r' option recursively copies the entire specified directory and its contents - in this case, that's "/home/dale/transporter" - to the host computer. The comments are, of course, optional.

 
# this is an scp command file. To use it, transfer files to the
# "transporter" directory and then invoke the command line
# below or simply type "./beam" in a Cygwin bash shell.

scp -r transporter dale@192.168.1.12:/home/dale

Next, I created a new directory, thusly: "mkdir transporter". Now I had a command file to "remember" the command sequence for me, as well as a place to store documents I wished transported to the host computer (the "transporter" directory). This directory can be accessed using the Windows GUI, which sidesteps the double name problem.

By simply typing in "./beam", one can initiate transport. When you do this, you will be prompted for the password you set up on the Linux machine and after entering it, the directory "transporter" magically appears in your home directory on the host machine. Upon browsing it, you will find all your files intact.

No fuss, no muss. Now you can open all those .bmp images with the GIMP and alter them to your heart's content.

For proper housekeeping, one must clear the transporter platform after every use... on both ends! If you do not do this, you may have to dig through a pile of tribbles to find what you just transported. Note also, that any file of the same name will be overwritten by the subsequent version of it. I usually access the files as transported and after modifying them, use the "save as" option from the file menu of most Linux applications to put them in different directories.

[ This kind of problem in *nix is traditionally handled by creating a new, time-stamped directory at the "receiver" end during each upload. This avoids conflict with existing files, but requires occasional cleanup to conserve disk space. -- Ben ]

Then I do a "./jayne":

 
#this script sends Jayne and Vera to "clear" the transporter platform.
rm -rf transporter

You can use the 'jayne' command file only with caution, like Adam Baldwin's character. 'jayne' is dangerous and will not care if you forgot to move the files off the transporter platform... he will simply kill them all and give them to the Reavers. You will not be able to recover them. If you want to watch Jayne and Vera do their evil work, you can use the '-v' option, and then you will see a listing as Jayne makes each kill.

The 'jayne' command should not be used on the Cygwin end of things, as it deletes the "transporter" directory. If you want to run a 'jayne' command on both ends, you have to remember to "mkdir transporter" before you can use the transporter again.

If you want to, I suppose you could make another command file and call it either "scotty", or "kaylee", depending upon whether you are a member of Star Fleet or the Browncoats. Scripts do indeed invoke a certain amount of Serenity.

---

Dale A. Raby is an ornery old man who started out on the original IBM PC back in the day of running MS-DOS programs while convalescing in Ireland Army Community Hospital and working for Captain James. Upon release from that particular episode of his military service, he bought a Tandy 600 laptop which still works after a fashion.

He picked up a more "modern" computer in 1998 and began publishing a general interest webzine, The Green Bay Web. Quickly discovering that Wind0ws 95 was about as reliable as a drunken driver with sleep deprivation, he made the conversion to Linux over the protestations of every member of his household. He now uses Fedora Core and since discovering Yum, has managed to keep his systems relatively up to date.

Dale is a graduate of the University of Wisconsin-Green Bay with a background in photography and print journalism. He is also a shade tree blacksmith who can often be seen beating red-hot iron into shape in his driveway. He has been known to use hammers and other Big Tools to "repair" uncooperative computers. He is a conservative WASP, abhors political correctness, and... not to be too cliché... enjoys hunting and shooting. Yes, that is a shotgun. No, it is not a rifle. Yes, there is a difference.

SEO and PHP

By Pete Savage

In today's fast-paced world, the importance of Search Engine Optimisation and usability has been thrust into the limelight. More and more companies and employers are hearing the buzz that is SEO, and want reassurance that their new Web site will deliver. They all want to be top of the search engines, and we all know that that will rarely happen. There are, however, things we can do to help the issue, and make life a little easier for those lovable bots and spiders who crawl our pages.

Introduction

Whether you believe the fact that search engines discriminate against ID numbers in URL strings or not, the fact of the matter is that

[1] https://www.a_mucky_page.com/products?id=00234987&category=990003429

will never look as nice to the end user, or search engines, as

[2] https://www.a_nice_place_to_be.com/products-modems/speed-baud-5000.html

Getting rid of GET parameters is also an advantage, as some search tools will discriminate against pages based on the number of parameters.

This article is a primer to help overcome this problem, using PHP/MySQL/Apache and a pinch of mod_rewrite thrown in for some spice. In some cases, this may not be the best solution, but is always worth considering, as mod_rewrite is an extremely powerful tool in your PHP Web development toolkit.

To begin with, you will need a Web server running Apache with mod_rewrite installed. If you own the server, this is going to be easy. If not, you may have trouble getting the administrators to install mod_rewrite. The reasons for this are simple; the administrators are not trying to annoy you, but one false move inside mod_rewrite code, and the CPU load goes through the roof. This article assumes you already have some knowledge of LAMP systems (Linux/Apache/MySQL/PHP), and that you have mod_rewrite installed.

Structuring

Structuring your database is an important step in the process, and must be carefully thought about; however, it may be that your database is well enough structured already - in which case, well done. Keeping your data tidy not only helps you but also will automatically make for a more SEO (Search Engine Optimised) system. We are going to use the example of a single-tier categorisation system. By that, I mean that products are sorted into a single category that fits them best. We will have two tables, one for categories and one for products. Their structure will be as in the tables below. You can see that the product table is linked to the category table through the category_id field.

Category

id

title

description

Products

id

category_id

title

description

price

Preliminary Coding

Let us write some PHP code to pull out the record information based on the URL line [1] above. We have the two parameters we need: product and category. The customer wants the category information listed on the page with the product. Code for this may look like the example below:

<?php
//Setup Database
mysql_connect(127.0.0.1, blark_inc, my_password);
mysql_select_db(blark_inc);

//Get the GET parameters
$category=$_GET['category'];
$id=$_GET['id'];

//Call in data for category and products
$category  =  mysql_fetch_array(mysql_query('SELECT * FROM category
WHERE id=\"'.$category.'\"'));
$product   =  mysql_fetch_array(mysql_query('SELECT * FROM products
WHERE id=\"'.$id.'\"'));

//Output the information
echo 'Category Name : '.$category['title'].'<br>';
echo 'Category Description : '.$category['description'].'<br>';
echo 'Product Name : '.$product['title'].'<br>';
echo 'Product Description : '.$product['description'].'<br>';
?>

So, in our simple example, the IDs of both tables are called with the GET method, and their relevant information pulled from the database and output to the end user. As stated previously, though, this method uses a URL string that does not look pretty in the least; rather, it's hideous. You may argue that the category ID does not need to be stated, and while this is true for a single-tier categorisation system, other more complicated types of system may well need this capability. Just imagine if a product were to appear in more than one category.

Enter mod_rewrite

It is now that we pick up our pot of spice, with mod_rewrite scrawled in friendly letters on the site, and begin to add in that little bit extra. Up until now, we have not really discussed what mod_rewrite does - we have simply put it forward as an answer to all our problems. So, let us delve a little deeper. mod_rewrite is an Apache module that will rewrite URLs according to certain rules. In effect, a browser will request a file by name, e.g., my-life.html, and may be returned a completely different file, e.g., my-friends-life.php, but it all happens transparently: i.e., the user will still think he or she is viewing my-life.html. It is similar to the notion of symbolic links in Linux, but a lot more powerful. Let us look at a few examples of how this could be used. Please note this is not actual code, just basic examples.

Change all .html to .php
blark.html would become blark.php
Would give the effect of a static site, all links would be .html.

Redirect requests pages under maintenance
index.php would become maintain.php
Could modify a specific filename to point to a maintenance page.

Use the page name as a GET parameter for another page
my-information.php would become pages.php?page=my-information
Useful for having one script to run the show.

Note:
mod_rewrite will only modify the URL if Apache is used to collect the file. It makes no difference to files stored on your Web server. For example, includes in PHP will remain unaffected, as they do not obtain the file through the HTTP protocol but use the local file system.

It is the last one of these examples that is of interest to us. Let us make a simple .htaccess file to test some of the examples we have just written. The .htaccess file contains all the rules for mod_rewrite within that directory, an example of which is below.

RewriteEngine on

#First example - modify all .html to .php RewriteRule ^(.*).html$ $1.php

#Second example - modify index.php to maintain.php RewriteRule ^index.php$ maintain.php

#Third example - Use pagename as a get parameter RewriteRule ^(.*).php$ pages.php/?page=$1

Note:
If you make a mistake in the .htaccess file, and the resulting code that mod_rewrite finds is invalid, you will be alerted with an Internal Server error page, Error 500. Do not worry; this is normal. Just alter the line, and try again.

The expressions' syntax can take some time to understand, and indeed I had a rather long experience learning this, when someone forgot to put a escape character '/' before the '?' in a tutorial. The rules follow the format of

RewriteRule What_I_am_looking_for What_I_want_it_to_become

Mod_rewrite Xplained !

The '^' means start matching the filename from the beginning of the URL string after the host. For example, with https://www.my-life.com/test.html, mod_rewrite will only look at what comes after https://www.my-life.com/, i.e., test.html. The '()' are used to catch data. Anything that matches and falls inside these parentheses will be stored. This can then be recalled by using a '$1' in the rewritten expression, as can be seen in the first example. The '.*' within the brackets in the first example catches all characters, and the '$' denotes the end of the URL string. In this example, for a file to fit the criteria, it must be a set of characters, followed by '.html' with nothing trailing on the end. When mod_rewrite finds a match, it takes the value inside the brackets and puts it back to work in the rewrite expression '$1.php'. $1 means use the data from the first set of brackets. If you had another set of brackets in the matching expression, then using the data from it would mean using '$2' in the rewrite expression.

The second example should be obvious now. It matches the term index.php exactly with no variations, and rewrites it to maintain.php.

The last example is the one that should prove of most interest to us. We are matching anything before the '.php' and rewriting this as the GET parameter of another file called pages.php. Please take careful note of the '/' in front of the '?'. '?' is a special character in mod_rewrite code, and must be escaped using the '/'.

Note:
For full details on mod_rewrite, head over to https://httpd.apache.org/docs/mod/mod_rewrite.html.

Let's Bake a Product Database (Bleugh)

We now have everything we need to make our search engine-optimised product catalogue. All that is needed is to remove those harmful IDs and to replace them with something else. Why not make a separate field in the table that can hold a unique identifier of a product, but written in text instead of numbers? It may sound like a tiresome task and unnecessary, but it can help you out. We will add a separate field to each table in our database, and call it mod_page. This will hold a modified version of the product/category title, and this will be used as a unique identifier. For example the product 'Speed Baud 5000 Enhanced modem' may have a mod_page value of 'speed-baud-5000'. It is up to you how you create mod_page. It may be that you want to type each one in individually, or it may be that you use a simple PHP script to translate one into the other.

Mod_rewrite to the Rescue

We now have to create a mod_rewrite rule that will interface with the code we wrote previously, as closely as possible. Obviously, now that we are using mod_names instead of IDs to call records, there will have to be some changes, but the structure of it should remain the same. Referring to the above code, it should be clear that we are expecting two parameters. One called 'id' and the other 'category'. Let us sculp a mod_rewrite expression that fulfils these criteria.

To make the URL user friendly I have chosen the format www.blark_inc.com/products-(category name)/(product_name).html .

RewriteRule ^products-(.*)/(.*).html$ products.php/?category=$1&id=$2

This expression will take two pieces of data: The first is the word, or character string after the 'products-' and the second is the name of the page in this phantom directory. Remember that the /products-whatever/ directory does not even exist. Rather, it is being used to fool the user and search engines into thinking that the site is structured in that manner.

To take our example from before,

https://www.blark_inc.com/products-modems/speed-baud-5000.html

will be magically and transparently transformed into

https://www.blark_inc.com/products.php?category=modems&id=speed-baud-5000 .

See how easy it is !

We now need to make a few changes to the products page code in order for it to pull the records out of the database. All that needs to be changed are the field names in the database query lines.

$category = mysql_fetch_array(mysql_query('SELECT * FROM category WHERE
id="'.$category.'"'));
$product = mysql_fetch_array(mysql_query('SELECT * FROM products WHERE
id="'.$id.'"'));

becomes

$category = mysql_fetch_array(mysql_query('SELECT * FROM category WHERE
mod_name="'.$category.'"'));
$product = mysql_fetch_array(mysql_query('SELECT * FROM products WHERE
mod_name="'.$id.'"'));

and thus the total code becomes:

<?php
//Setup Database
mysql_connect(127.0.0.1, blark_inc, my_password);
mysql_select_db(blark_inc);

//Get the GET parameters
$category=$_GET['category'];
$id=$_GET['id'];

//Call in data for category and products
$category  =  mysql_fetch_array(mysql_query('SELECT * FROM category
WHERE mod_page=\"'.$category.'\"'));
$product   =  mysql_fetch_array(mysql_query('SELECT * FROM products
WHERE mod_page=\"'.$id.'\"'));

//Output the information
echo 'Category Name : '.$category['title'].'<br>';
echo 'Category Description : '.$category['description'].'<br>';
echo 'Product Name : '.$product['title'].'<br>';
echo 'Product Description : '.$product['description'].'<br>';
?>

Summary

As mentioned previously, this is a nice way to make your site look well structured, to both user and search engine. It has been mentioned that mod_rewrite does take a little more CPU load to run than if there were no mod_rewrite at all, but I personally have never had a problem with it. Providing that it is used in the right way, and not used to solve every mis-extensioned file, it should not be discounted, and should form a part of your PHP toolkit.

---

Pete has been programming since the age of 10 on an old Atari 800 XE. Though he took an Acoustical Engineering degree from the world-renowned ISVR in Southampton UK, the call of programming brought him back and he has been working as a Web developer ever since. He uses both Linux and Windows platforms. He still lives in the UK, and is currently living happily with his wife.

Design Awareness: What Parachute Is Your Color?

By Mark Seymour

Colors are, for all of us except those unfortunate enough to be blind to them, much of the way we perceive the world. They are so powerful that they've even made themselves part of our language, as written on our very faces: green with envy, red with anger, gray with pain.

We use them every day, almost without thinking, to create any of the visual media: painting, photography, design. In traditional forms, your eye and hand skills were all you had to create, compare, and reproduce colors, and the number of colors you can create from oil paints or watercolors, for example, is nearly infinite. Computers have given us powerful tools to manipulate color (Gimp and Photoshop are two common examples), yet have forced us into ever narrower color gamuts.

Gamut is one of those 'techie' words many of us use without exactly understanding its meaning. The earliest dated reference I could find was "Gamut, the scale, or rudiments of music" in a book entitled The Sacred Harp, A Collection of Psalm and Hymn Tunes, Odes, and Anthems, Selected from the Most Eminent Authors: Together with Nearly One Hundred Pieces Never Before Published; Suited to Most Metres, and Well Adapted to Churches of Every Denomination, Singing Schools, and Private Societies. With Plain Rules for Learners. It was published in Philadelphia in 1860, as a "New and Much Improved and Enlarged Edition", by B.F. White and E.J. King, who knew a thing or two about writing titles, if nothing else.

The Oxford English Dictionary gives this definition:

1. the complete range or scope of something
2. Music: a complete scale of musical notes; the compass or range of a voice or instrument
3. Historical: a scale consisting of seven overlapping hexachords, containing all the recognized notes used in medieval music

from the Latin gamma ut (in sense 4): the Greek letter gamma was used for bass G, with ut indicating that it was the first note in the lowest of the hexachords example: run the gamut; to experience, display, or perform the complete range of something [1]

The glossary of the School of Design at Arizona State University defines it as an "entire series of recognized notes" along with numerous mathematic and geometric definitions, though oddly enough without any color reference. The glossary at the Rochester Institute of Technology defines it as "The entire range of perceived color that may be obtained under specified conditions", a delightfully vague academic definition. (I've appended a list of glossaries at the bottom of this column; you may find them useful for other graphics terms.)

So it appears the term began in the music world and then purloined by the design world, but still means basically the same thing: the range of perceivable items, whether notes or colors. However, that's not the same as the range of everything we, as observers, can visually perceive. It's the range of whatever device (computer monitor, printer, ink system, film, camera CCD, etc.) we're using can perceive. And they, lamentably, are all different from each other and from our eyes.

There have been many color-definition systems set up, each with its own gamut, in an attempt to standardize and codify the use of color. Few in this industry are old enough to remember printing prior to the development of the Pantone system of printing inks, but imagine trying to tell your printer exactly what green you wanted to use: "Sort of an Irish mossy green, with just a hint of lemon, really, and a touch of blue like that cloudless sky I saw when I went to New Mexico and got drunk and fell down last summer." This sort of ambiguity led to endless rounds of 'ink drawdowns' (a quaint and now almost-unheard-of practice of actually mixing a little can of ink to your nebulous specifications, rolling it out onto high-gloss proof paper, drying it, and sending the sheet over to your office for approval and revision: "No, no, a little more yellow") and arguments over exactly what color any particular color actually was. (Try 'matching' a color to an object before there were scanners!) Fortunately, in the early 1960s the Pantone Matching System (thus the phrase 'PMS color') was released to printers and designers, and things pretty much settled down until the advent of the Macintosh.

Oh, there was the constant struggle to 'match' a PMS color to its rough equivalent in CMYK inks (the first of many gamut disparities), but Pantone and other ink systems like Toyo (though to view a classic example of the worst of Japanese design see their Japanese web site, where a flying cartoon lion first paints in their logo on-screen and then goes to sleep and blows snot bubbles; would I kid you about a thing like that?) soon issued their official 'cracks' of their colors, and you became pretty much stuck with whatever they showed.

But the gamut compatibility problem really got going when you began to display color in RGB on color monitors, and the argument heated up over what color you were really looking at versus what color would appear when the file was either output to film (and thus converted to CMYK) or, worse yet, output on some other device, like an ink jet or laser writer printer.

Let's look at the differing gamuts we commonly work with, and see why this gamut war is still on-going and may never be resolved.

You're reading this on a computer monitor which displays information in RGB (red, green, and blue, the colors originally generated by the phosphors activated by the electron beam in a television). This column was created using Adobe GoLive on a Macintosh flat-screen LCD monitor. GoLive allows me to define the color of objects on the screen in RGB (the 'native' gamut for monitor-based material), CMYK (the gamut for process color printing inks), HSB (hue, saturation, and brightness), and HSV (hue, saturation, and value); the latter two gamuts are derived from classic color theory and use color 'wheels' to describe color:

Photoshop, like other graphic design software, also provides a wide range of color pickers including, along with the Pantone and Toyo colors, the ANPA, DIC, Focoltone, HKS, and Trumatch systems. (It also has a 'Lab' color picker, which I confess to not understanding at all, try as I might. If anyone out there does, send your explanation along.)

No matter what gamut you pick, however, it limits you to significantly different numbers of colors:

• Toyo inks come in 1050 colors
• Pantone inks provide 1114 standard colors, and even their 'hexachrome' system (CMYK + hexachrome orange + hexachrome green), while supposedly "meeting or exceeding the RGB gamut", has only about 2000 numbered colors:

• HSB and HSV each allow a gamut (360x100x100) of 3,600,000 colors
• RGB gives a wider gamut (256x256x256) of 16,777,216 colors
• CMYK provides the broadest gamut (100x100x100x100) of 100,000,000 colors (and don't be fooled by software; while the sliders for CMYK in GoLive show 256 steps for no apparent reason, your printer can only differentiate between 100 steps per color, and you'll be lucky if they can hold a standard within 2% either side of a particular ink percentage)

Yet browsers navigating the Internet are limited by the convention of HTML to 216 'web-safe colors', from FFFFFF to 000000. Is it any wonder that designing for multiple mediums (print & web) can be a pain? Let's say you have a logo that you want to print in PMS 123, a nice golden yellow:

Yet, what is that color really? Pantone says it's simply ink number 123 on coated stock. Easy enough to specify, and easy for the printer to mix and print. But let's say you want to print it in a brochure along with color photographs, thus you need its equivalent in process (CMYK) color to make it cheaper and easier to print. The 'crack' for that color in Photoshop (I'm trusting them here; I didn't check my Pantone book) is 0C 24Y 94M 0K (which I will now translate into the unpatented SeymourCMYK system nomenclature, 0.24.94.0, which we will use henceforth), yet that color isn't available in web-safe colors for use on your web site, so we have to nudge it to 4.21.87.0, which translates in hex to FFCC33. While PMS 123 is defined as 255.196.36 in the RGB gamut in Photoshop, when entered as such via the RGB picker in GoLive it displays as the non-web-safe hex color FFC424. Resetting it to FFCC33, per our Photoshop definition, it becomes 255.204.51 in the RGB gamut. Worse yet, the CMYK sliders equate that to 0.51.204.0, which no one will ever understand.

So, what color are you using? Depends. If you take the exact same PMS color and attempt to reproduce it in Photoshop, InDesign, and GoLive (hey, I've got friends at Adobe, what can I say?), let alone the Apple applications, you'll come up with completely different colors. Here are screen captures of what several different applications generated as PMS 123, for comparison; the distinction is subtle, but obvious:

Let's attempt to look at using color, now that we've thoroughly confused ourselves as how to define it, to describe objects or feelings or states of being. Because that's what we really do in design, isn't it? Some one says they want their logo to be a nice apple red. Do they mean the red of an apple you buy in the grocery store (and which variety, and is it ripe or not ripe?), or do they mean a nice Apple red? Back in the day, the logo of Apple Computer used to be PMS 185, which looked a lot like this (on my screen, at least) when printed:

Yet that color red is 0.255.255.10 in the GoLive CMYK picker, while PMS 185 is defined as 0.91.76.0 in the Photoshop CMYK picker, which looks like this color when you set the equivalent (0.233.195.0) in GoLive:

Do we go with what looks right (and to whose eye, and on what monitor, and when was the last time you calibrated it and to what?), or do we go by the numbers? Depends. Are you just displaying it on someone's monitor via the web, or are you trying to match a printed color? If it's web-only, and especially if you can test it across a suite of CPUs and monitors, so much the better. If you're trying to match something printed, whether it's a PMS color or a CMYK color, that pretty much hopeless, as we've seen.

We'll go with what looks right, and hope it looks 'right' on your monitor as well. (For those of you benighted people viewing this on a CRT monitor running Windows, good luck.)

Choose an object or a feeling to mimic in color. Something difficult to describe. Something subtle. That sultry blonde you saw on the beach during your vacation in Brazil, say. (If you find yourself tasked with creating a travel brochure, you can bet that's what the client is seeing in his head...) Or the cool blue tones of a fresh snowfall. (Remember our work with Alpine Gear?) Or a delicious dark bar of chocolate. (Milk chocolate? Semi-sweet? With nuts or without? Almonds or peanuts? See how hard this is?) Even the "golden yellow" we were trying to imitate with PMS 123 isn't really gold, but trying to represent the color of the actual metal, whether printed or on-screen, is nearly impossible:

Worse yet, try and combine these disparate things and see where the string of adjectives leads you:

a sultry, tan Brazilian blonde, in a bikini the sea-green color of shallow Bahamian waters, eating a thick bar of Swiss milk chocolate while standing on gold-plated skis in the midst of an icy Norwegian glacier.

Sure, you can see her in your head, but try deciding which colors you should use to represent that image... (For those whose gender identification requires it, please substitute 'blond' for 'blonde' and 'his' for 'her'.)

But we're idiots, we designers, so we'll try. And we'll do them all in the HSB gamut (just to be a nuisance), leaving the conversions for someone else:

her tan
her blonde hair
her bikini
the chocolate
the skis
the glacier

Nice, but not quite the picture you formed in your head, is it? But they are certainly evocative colors, and you could play around endlessly with tweaks to the formula to find some that were closer to that bikini-clad, chocolate-eating skier you (or the client) were imagining.

Applying this palette to your client's brochure for chocolate (or bikinis or ski equipment or resort travel), you can now hope that every design feature (headlines, tables, text blocks, leader lines, color backgrounds) will somehow evoke the tantalizing picture that inspired the choice of these colors.

But now let's try and pick colors to represent a real Brazilian woman standing in real Brazilian water (and what intelligent Brazilian woman would ever find herself on a Norwegian glacier, even to eat chocolate?):

Much harder, isn't it? (And that's why photography replaced artwork early on. Look back at ads from the 1950s, with their painted and airbrushed illustrations: flat colors and simplified forms. Yet it's considered very retro to mimic that today.) So which part of her, precisely, shall we pick to stand for 'tan'? Should wet hair or dry hair represent 'blonde'? Which of the several colors of her suit cry out 'bikini'? What part of the surf would say 'ocean'? What part of the sky might mean 'sunset'? Tricky business, this color.

Where does this all leave us, besides pissed off and frustrated with the vagaries of color systems, software programmers, ink manufacturers, and the limitations of technology in general? With the notion, first of all, that no amount of technology or software gimmickry can truly replace a good eye. If you have one, bless you and use it well. If you don't, and not every designer does, you'll have to decide where your strengths lie and work around them. For instance, I can't open Photoshop and 'paint' an image any more than I ever could with a box of crayons. Actually, I do better with the crayons. But if you think we've come a long way since we were kids, remember that HTML can handle barely twice as many colors as Crayola:

The parti-colored images and Flash animations flooding the web these days will never come out of my box of tricks. But I can, if I work at it, come up with a color way for a logo, a brand, or a product that can be utilized effectively across print and video and the web. By analyzing the needs of the piece, so can you. But turning those colors into artful designs that entice the viewer and sell the product (and thus please the client), that's what will separate you from a guy or gal who can just turn on the computer and double-click the Photoshop icon. Solving the what-color-is-this problem? Perhaps not fixable. My suggestion is to determine where the majority of the work will be seen, whether web or print, and choose your gamut accordingly. CMYK, of course, if you're going mostly to print, and use the official Pantone (or other patented color system) 'crack' to represent its flat colors in CMYK. You can reproduce the CMYK fairly easily in any web-content generator. RGB if you're going web, and do the best you can to represent that in CMYK for any print that results. Remember, no matter how good the software, no ink-on-paper version will ever have the luminosity or depth of colors displayed on a good computer screen, even black.

I hope this has inspired you to wrestle with the complexities of color. It's worth the battle, unless you like to see the world this way:

As ever, let me know what design issues you'd like explored.

---

[1] Not to be confused with "running the gantlet", let alone the often-misused "running the gauntlet", like the Clint Eastwood film of that name. A gantlet is "receiving blows while running between two rows of men with sticks", while a gauntlet is "a stout glove with a long loose wrist". The English insist on using the same spelling for both, but that's just being silly...

We also received a great logomatopoeia submission from a viewer (a professor of design history in Cleveland, no less), the logo for Davey Tree, a national tree service company. My thanks, and keep 'em coming:

---

Graphic term glossaries:
https://www.4dimension.com/glossary.html
https://amol.org.au/capture/course/glossary.html
https://www.rockprint.com/dictionary.shtml
https://www.globalimaginginc.com/resources/glossary.shtml
https://www.creativepro.com/printerfriendly/story/11132.html
https://www.binarygraphics.com/glossary/color.html
https://www.colourguru.com/glossary.html

---

I started doing graphic design in junior high school, when it was still the Dark Ages of technology. Bill Gates and Steve Jobs were both eleven years old, and the state of the art was typing copy on Gestetner masters. I've worked on every new technology since, but I still own an X-acto knife and know how to use it.

I've been a freelancer, and worked in advertising agencies, printing companies, publishing houses, and marketing organizations in major corporations. I also did a dozen years [1985-1997] at Apple Computer; my first Macintosh was a Lisa with an astounding 1MB of memory, and my current one is a Cube with a flat screen.

I've had a website up since 1997, and created my latest one in 2004. I'm still, painfully, learning how web design is different from, but not necessarily better than, print.

HelpDex

By Shane Collinge

These images are scaled down to minimize horizontal scrolling. To see a panel in all its clarity, click on it.

All HelpDex cartoons are at Shane's web site, www.shanecollinge.com.

---

Part computer programmer, part cartoonist, part Mars Bar. At night, he runs around in a pair of colorful tights fighting criminals. During the day... well, he just runs around. He eats when he's hungry and sleeps when he's sleepy.

Ecol

By Javier Malonda

The Ecol comic strip is written for escomposlinux.org (ECOL), the web site that supports es.comp.os.linux, the Spanish USENET newsgroup for Linux. The strips are drawn in Spanish and then translated to English by the author.

These images are scaled down to minimize horizontal scrolling. To see a panel in all its clarity, click on it.

All Ecol cartoons are at tira.escomposlinux.org (Spanish), comic.escomposlinux.org (English) and https://tira.puntbarra.com/ (Catalan). The Catalan version is translated by the people who run the site; only a few episodes are currently available.

These cartoons are copyright Javier Malonda. They may be copied, linked or distributed by any means. However, you may not distribute modifications. If you link to a cartoon, please notify Javier, who would appreciate hearing from you.

---