The coordinate range.The natural unit of length in HP-GL is 1/40 mm = 0.025 mm, so a typical A4 page covers roughly 11000 x 7500 natural units. Typically, coordinates in HP-GL commands will be found in the range 0 ... 12000. hp2xx will tell you the maximum and minimum coordinates ("picture limits") it finds in your HP-GL picture for both x and y direction. These values usually roughly cover this range. Even if your HP-GL source plots in user-specific coordinates (realized via HP-GL command `SC;' (SCale) ), this remains true, since hp2xx internally transforms all points back to natural coordinates. Whenever the above range is grossly violated, you may suspect corrupted data, because no real plotter would be able to plot such a file.
If you ever discover a picture limit equalling plus or minus 10^10, your HP-GL probably didn't draw anything. Initially, hp2xx's internal picture limits are set to impossibly large (or small) values, i. e., +- 10^10, but the first plot command will set them to values found therein, and successive plots push the limits outward. Example: xmax starts at -10^10, the first plot command may change it to 2536, the next to 3470, the next 20 command fall short, etc. Eventually, xmax assumes the largest value and stays there. Knowledge about these details may sometimes be crucial.
hp2xx uses the picture limits internally for scaling and fitting the data into the supplied limiting rectangle (see section Sizing your output). You can also affect the picture limits yourself for special effects (see section Fixed scaling).
Fixed scaling.
As noted earlier, hp2xx does not draw to scale, but rather it fits a picture into a given limiting window. While this is very handy in most applications, it may be undesirable when a series of pictures must be drawn to the same scale. Unless all pictures possess the same picture limits (modulo offsets), e.g., because all of them are surrounded by some fixed frame, hp2xx would scale them all up differently to fit each of them tightly into the limiting window.
There are two simple cures: First, make use of the true size option `-t'. If the original HP-GL sizes do not fit, adjust picture limits to guarantee a constant scaling: Make a preview of all pictures and note the coordinate ranges hp2xx reports. Then, determine picture limits which cover all of these individual limits. Finally, run hp2xx to create your desired outputs using options `-xXyY' to tell hp2xx about the picture limits it should use. If the pictures do not share common offsets, you may have to correct for offsets manually. Use the preview mode for testing. You'll get the same scale as long as the limiting window and (xmax - xmin) and (ymax - ymin) remain constant for all pictures.
WARNING: hp2xx does not clip lines. If the picture limits which you manually can pre-set via options `-xXyY' are chosen too narrow, they will be pushed outside just as described in the last section, resulting in a different scale. Check the coordinate ranges hp2xx reports. The should match the values supplied by options `-xXyY'!
Scaling to true size.
Earlier releases of hp2xx (binaries) did not offer option `-t', which does everything you'll need for producing output with exactly the sizes shown on a real plotter. The following paragraph shows how to manually emulate the working of this option. Though outdated, I left it in the manual as background material:
Sometimes you might want to create pictures sized exactly as if they were drawn on a real plotter. There is a little trick which allows you to do so using hp2xx: As notes above, the natural unit of length in HP-GL is 0.025 mm. Therefore, you can calculate the true picture size from the picture limits reported by hp2xx. Transform these data into mm and simply specify the limiting window accordingly! Example: `hp2xx truesize.hp' reports the following coordinate ranges: xmin = 250, xmax = 5250, ymin = 100, ymax = 3100. Thus, the picture is (xmax - xmin) * 0.025 mm = 125 mm wide and ymax - ymin) * 0.025 mm = 75 mm high, and `hp2xx -w125 -h75 truesize.hp' will draw it in true size.
Swapping.
hp2xx allocates memory for an internal bitmap dynamically. Large pictures, high resolution, and use of colors may combine to let your computer run out of memory (especially on non-swapping operating systems like DOS).
In this case, hp2xx swaps the bitmap to disk, slowing down considerably. Redirecting swapping to a fast disk, preferably a RAM disk, might speed up things. You can replace the default swap file `hp2xx.swp' using `-s `swapfile''. NOTE: If for some reason hp2xx is aborted during swapping, you might have to delete the swap file manually.
Dots and lines.
Here are some basics about the generation of dots and lines within hp2xx. I mention them, because there is something left to be improved here...
Some HP-GL codes cause hp2xx to generate points rather than lines of length zero. There is a subtle difference between both. Depending on the current output format, special code for points will be generated, and occasionally, a point will look different from a zero-length line. Use `-m epic' for such an example.
Line thicknesses can vary. Especially for thick lines, the matter of line caps (how lines are ended, e.g. with a round cap) becomes relevant. hp2xx does not do an elaborate job here. If line caps matter to you, use `-m eps', edit the resulting Encapsulated PostScript file, look for a line with setlinecap in it (near line 45), and select the line cap of your choice by modifying the PostScript command setlinecap accordingly. You can also use Metafont (via `-m mf') and replace the picked pen "pencircle" by some other type. However, both methods are far from convenient.
The internal rasterization done by hp2xx is a simple process and may someday be replaced by something more efficient: A "draw point" command essentially sets a single pel in the internal buffer. If line with grows (2 - 4 units), a square of 2 to 4 pels length will be set. Vector drawing is broken down to point drawing by the Bresenham algorithm. Therefore, there is no notion of controlled line caps. The shapes of line ends simply result from plotting these squares. In addition, plotting all those pels is not really efficiently implemented, so if anybody out there looks for a good place for speeding up hp2xx, this code (located in file `picbuf.c') is a good place to start.
Currently there are no plans by me to introduce different line caps into hp2xx, so waiting for them will be of no use.
Unsupported formats.
This is just a brief note, not a real manual entry -- sorry.
PIC
ATARI format, e.g. for the text processor Signum. Try to replace by IMG.
PAC
ATARI format, e.g. for the CAD program STAD
DJ_GR
DOS previewer, based on DJ Delorie's gcc port and extender go32. Works fine, but will be replaced by DOS/OS2 EMX version.
OS2
Full-screen OS/2 2.x and DOS previewer. I don't yet have the right development system, so this code is still missing. However, it *will* be supported as soon as possible!
PM
OS/2 2.0 PM previewer. Working, but without redirection of messages to stderr into a second window.
TeX formats.
TeX was designed for typesetting, not for handling graphics. Putting graphics directly into TeX therefore is always somewhat clumsy. hp2xx offers four different compromises to do that, and much better, though more indirect ways.
`-m mf' generates Metafont source code. Run Metafont and gftopk, and you'll end up with a special pk font containing the single letter Z which represents your picture. Placing this Z somewhere in your document using standard TeX commands draws your picture there.
If you want to avoid fiddling with additional programs and fonts, if you work with LaTeX, and if you do not need high-quality plots, the macros within epic.sty may help you. `-m tex' causes hp2xx to generate appropriate TeX source code which you can `\input{}' into LaTeX sources.
For emTeX users, there are yet another two way: `-m em' creates TeX code containing many commands like `\special{em:...}' for line drawing. The line drawing task will therefore be handled not by TeX itself but by the emTeX drivers which can handle arbitrary line slopes etc. Similarly, `-m cad' produces code based on the same principle, but compatible with program `TeXcad.exe', which is distributed as a part of emTeX, and which offers editing and drawing features for the desired HP-GL figure(s).
Please note that all methods for generation of graphics within TeX are compromises which usually work only for simple graphics. You'll probably prefer using external methods like including EPS vector graphics files with Tom Rokicki's dvips driver, or PCX files via the emTeX drivers, or you'll generate special fonts with convenient programs like F. Sowa's bm2font. hp2xx can help you in all of these cases. The following table shows the pros and cons of the various approaches (all are based on PD software):
Internal methods (all allowing DVI previewing of graphs):
via Metafont
+: Machine-independent; fully compatible with TeX
-: Slow; capacity problems with Metafont / gftopk / some DVI drivers
if used with large and/or complex graphics
via epic.sty
+: Machine-independent; single-step, native LaTeX approach; PD software
-: Slow; requires LaTeX; low-quality lines; just one line thickness;
complex graphs may exceed TeX capacity
via emTeX's \special{em:...}
+: No TeX capacity problem; good line quality; single-step procedure;
rasterization on demand, giving optimal resolution
-: Slows down drivers; driver capacity may be exceeded; emTeX required
External methods:
via PCX file inclusion:
+: Easy and fast; DVI preview of graphics
-: Requires emTeX drivers (only available on DOS and OS/2)
via special fonts:
+: Easy, fast, and trouble-free font generation via bm2font;
DVI preview of graphics (!); portable
-: Many files for fonts etc.; confusing for novices
via EPS:
+: High-quality results; easy; no burden for TeX or drivers
-: No DVI preview; PostScript printer (or, e.g., GhostScript) required;
PostScript previewing is slower than DVI previewing.
Custom Search
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 commenti:
Post a Comment