Please note: The following description is very brief and assumes that you are familiar with installation of PD software in general.
This is simple! If you find a collection of pre-compiled versions of
hp2xx, obtain the file `read.me' and read it to find out the
name of the file which fits to your system. Obtain it, rename it to something
like `hp2xx' or `hp2xx.exe', and place it somewhere on your
search path -- that's it.
There are exceptions, though. AMIGA users should consult their special distribution package and follow directions there. DOS users will find a ZIP package containing files in addition to `hp2xx.exe'. For details, read the accompanying descriptions.
Actually, I anticipate a phasing-out of binaries support as soon as the sources become available. Consequently, future releases of this manual will elaborate on the following subsection instead of this one.
NOTE: Source level installation is in beta state: At this writing,
the hp2xx sources are about to be released, and there have only few
different installations been done. Currently, installation depends too much
on manual work yet. Here is a description how to proceed:
After unbundling all sources, go to subdirectory `./makes'. Select a
makefile most closely resembling your system's needs from the samples given,
copy it to `./sources/makefile', adapt it manually (if necessary),
and run make all.
If everything is set correctly, this results directly in a valid executable
file which you may install at any convenient place on your search path.
There are two types of makefile adaptation: First, let's assume there is a makefile template available for your system. You then have the option to add a few unsupported modes. Do so by un-commenting the appropriate lines near the beginning of the makefile, and by commenting out the corresponding standard lines.
The second type of course applies to systems with special needs which are not yet covered by any makefile template. Currently, you are on your own when it comes to supplying alternate paths, renaming or adding system libraries and alike. Most probably you might have to tell the makefile where to look for the X11 stuff.
Note: Don't feel alarmed if your makefile seems to neglect many source files. Any single installation will make use of only one previewer (two on SUNs with activated SunView support), and there are platform-dependent sources for some output formats which are not always used.
First, study section Introduction for the outline of the modular structure and
general operation of hp2xx.
Let's assume you want to support TIFF format. The probably easiest way
of adding new formats is by modifying copies of existing files. Since TIFF
is a raster format, a good starting point would be `to_pcx.c'.
(Files `to_mf.c' or `to_eps.c' should be considered in case
of a vector format, and `to_vga.c' or `to_x11.c' in case of
a new previewer.) Copy it to a file `to_tiff.c' and edit the latter.
The old code is pretty much self-explanatory. Essentially, the output file
is opened, initializations are performed, and the internal bitmap is
converted into the target format (here, TIFF) scanline-by-scanline.
There is just one routine called from other modules (originally named
PicBuf_to_PCX. Rename it to e.g. PicBuf_to_TIFF ) and adapt
the conversion code.
Once you've done that, the rest (integration of the new format into the
package) is easy: First, edit `hp2xx.h' and add a prototype
line for PicBuf_to_TIFF in analogy to e.g., PicBuf_to_PCX.
Edit the `makefile's and add to_tiff.c to the list of sources
and e.g. to_tiff.o to the list of objects. Now you are ready for
compilation tests (but not for linking yet).
Then, change the main file `hp2xx.c' at various places: Near the
beginning of the file, add `XX_TIFF, ' to the hp2xx_mode typedef,
and a line like `XX_TIFF, "tiff", ' to the ModeList struct below.
Please note the alphabetical order of these lists. Never put anything behind
the termination code XX_TERM! At the end of the file,
add a case statement to the switch list in analogy to e.g.
the PCX entry.
You may also want to add a line to the on-line help to
announce the new format, and change the release number and date.
Look for functions Send_ID and usage_msg at the first quarter
of file `hp2xx.c'!
Now a make all will produce code containing the new format.
If your format turns out to work nicely and seems to be of general interest,
please consider contributing it to the hp2xx project.
The following table lists miscellaneous desirable features for future releases:
Box and sector drawing / filling Other, more rarely used HP-GL commands Color support in UIS and PBM Improved color support in X11 and PCX PCL: Better data compression for DJ500, DJ500C, DJ550; Loadable fonts, e.g. Hershey fonts, or: more built-in fonts Full-screen previewer for OS/2 Easy installation on various platforms, e.g. via a configure script
This section is intended for those few users who might care to
improve the built-in character set of hp2xx.
HP-GL plotters feature built-in fonts with both fixed and variable-width characters. There are commands for font selection and quick switching between two pre-selected fonts, and there is also a way for users to download own character definitions.
hp2xx currently features just one character set (set 0).
Therefore, all HP-GL commands dealing with font selection etc.
have not been implemented.
If you plan to modify this character set or to add more,
you need an understanding of how characters are drawn by
hp2xx. The source file `charset.h' contains a comment
explaining this procedure. Below you find a (modified) copy of
this:
This file defines a standard character set by elementary
"draw" & "move" commands. The format is a very compact one from
the old days where every byte was still appreciated.
A font or character set is an array of strings. Each character is
addressed by its ASCII code.
A character is a (NULL-terminated) string of bytes. Each byte
codes for a draw or move action according to the code below:
Bit: 7 6 5 4 3 2 1 0
p x x x y y y y
p: Plot flag. If set, "draw to" new point, else "move to" it.
xxx: 3-bit unsigned integer (0...7). X coordinate of new point.
yyyy: 4-bit unsigned integer (0..15). Y coordinate of new point.
The baseline is y = 4 instead of y = 0, so characters with parts
below it can be drawn properly. Function "code_to_ucoord" transforms
these coordinates into actual user coordinates.
Example: code for character 'L': "\032\224\324" translates to:
moveto(1,10); drawto(1,4); drawto(5,4);
From the example you can conclude that the font below essentially is
defined on a 5x7 grid:
0 1 2 3 4 5 6 7
15 - - - - - - - - - : unused
14 - - - - - - - - # : always used
13 - - - - - - - - o : sometimes used
12 - - - - - - - -
11 - - - - - - - -
10 o # # # # # - -
9 o # # # # # - -
8 o # # # # # - -
7 o # # # # # - -
6 o # # # # # - -
5 o # # # # # - -
4 o # # # # # - -
3 o o o o o o - -
2 o o o o o o - -
1 o o o o o o - -
0 o o o o o o - -