Carto - News

Latest Version is 0.9.8 which was uploaded 3/3/05 9:06 PM


The version I uploaded last week didn't seem to work. It was a packaging problem, so the uploaded version didn't work, even though the one I have at home did. Let's try again. The version that I think might work is 0.9.1.

I have also implemented the feature that makes curves move with survey updates. That is really needed to make the new workflow usable (otherwise the walls won't match the segments after an update).

That introduced new bugs (now fixed, but some of the buggy versions were on the web for a while), and there are likely to be more bugs to be found, so I strongly recommend saving a copy of your .cto file before you do an update of the survey.

Speaking of bugs showing up, I just found a bug that was present in the very first publicly available version of Carto. It took me a while to figure out why the bug stayed hidden, it looked pretty severe. I had to figure that out before I could be sure that it wasn't the old version that was right. It turned out that the whole section of code only really matters if the morph is very bad (e.g. a 180 turn sketched as straight), and everything's a mess then anyway. Otherwise, it only causes a minor performance loss. It's fixed now, but I doubt anyone will notice.


New Work Flow

I have done a lot of work on Carto recently. Much of it was enabling changes that the user can't see, or peripheral features that not all users will care about, but there are also some that change the preferred way to make a working map.

This article applies to Carto version 0.8.29 or latter.

I have not removed any old features, so if you want, you can continue doing things as you have. Carto is a tool, and can be used in different ways. In this message I will describe how I will be using it. The main changes are in how the boundaries of the displayed segments are determined, and in the handling of overlaps (as found in the more three dimensional caves, guess what Memorial Day Cave is doing).

Unfortunately, it takes as long, if not longer, to describe this process as it does to use it, and I bet nobody will understand it all, even though it seems clear enough to me! Questions are welcome.

Starting a new project is exactly as before: use the menu item file/new project.

For existing projects, it is possible to use the new procedure only for new survey, or it is possible to move segments, etc. to passages using cut and paste. I wouldn't bother for projects that are near completion.

After each survey trip:

Update the survey as before.

Look over your bits of sketch, and divide them into contiguous sections of passage. Try to make sure that sketches in the same passage don't overlie each other. Instead of adding segments to the overall plan, you will add plans of each passage to the main plan, and put the segments in the passages. You will be able to change you mind about this latter.

For each passage, create and edit the passage by pressing the "new pas" button in the main edit window (on the 5th row). Zoom in to the part of the survey where the new survey is. Add segments to the passage with the "new seg" button (6th row).

For each segment, mark the survey stations as before. Then mark the segment boundaries. It has been my preference in the past to make fairly detailed boundaries at this stage, closely following the walls of the passage, to make the working map look nice. Don't do that anymore. Instead define only a coarse boundary, paying close attention only to the region where one sketch meets the next.

Once you have added the segments to a passage, use the curve tools (4th row) to mark the walls of the passage. Try to follow the walls as closely as possible, and take some care, in addition to clipping the segments on the working map, this curve will be the walls on the final "inked" map (you will be able to edit them latter). Set the line type of the curve, to "wall" (from the right click dialog), some parts of the curve may need other line types (e.g. where the passage ends with a drop, or where the passage merges into another, where the line needs to be invisible). You set line types by selecting parts of the line (with the "subselect" mode, second button top row), right clicking and using the "line style" tab.

Now tell Carto that the curve you have just drawn is the boundary of the passage. Right click on the curve click the tab "curve" and select the item marked "inside". You can use more than one curve to define the boundary. The "inside" of the passage will be the area inside any curve marked "inside". If you need to have an "island" that is not part of the passage (e.g. a large bedrock pillar) you can mark a curve as "outside". Make sure it is higher in the stacking (use Arrange/bring to top). "Insideness" and "outsideness" work like ink, filling the regions, with the ones "on top" painting over the ones "underneath" (this stacking is not related to elevation in the cave, which is handled below).

Add any annotations to the passage (leads, hydrology, geology, etc.). Eventually you will add floor detail here as well.

When you close the passage's edit window you will see that it has been added to the main plan.

If some of the passages you have added lie directly on top of or under other passages, you need to decide how they will be displayed. Right click on empty space and select the "stacking" tab. The dialog has two lists of items. on the left are regions that can modify the regions on the right. Suppose passage "upper" overlies passage "lower" and "upper" is the one you want to display details of. Then you would select "upper" on the left, and "lower" on the right and press the top button (marked with an icon that is supposed to represent a passage becoming dashed as it passes under another). When you click OK, "lower" will be dashed where it passes under "upper". Alternately you can have "upper" be dotted where it passes over "lower".

There is also an item called "everywhere" which can be used to make all of a passage dotted or dashed.

This sounds complicated but it is just six mouse clicks counting "OK", and opening the dialog.

Now check that your page layout covers all the new passages. If you have added a new major level, you may need to add a page to show it. Create the new page and position it, then right click on it and select the "stacking" tab. Set the stacking in the opposite way from what you used on the main plan (if "upper" hid "lower", make "lower" hide "upper" in the lower level page).

Print out all the pages, and distribute them to your impatient and ungrateful survey teams :-).

Report bugs to me, with much cursing and gnashing of teeth! :-)


Carto: Present and Future

By Ralph Hartley

Carto is my tool for making cave maps. For examples of Carto's use see Memorial day working map and Slides for DC Grotto banquet .

This article has three goals. To describe, at least in part, my vision of Carto and it's evolution, to make an offer, and to make a request.

In a sense, the offer and the request are the same. Carto is ready for a new mix of users. Most users so far have used Carto in the same way: to make a composite map that is then traced over, either with another program, or with actual pencil and ink. This is fine as far as it goes.

The goal of Carto is quite a bit more ambitious than that! It is intended to go all the way to finished maps.

The Morphing and Compositing features of Carto have been used fairly widely, including for some large projects. It's users include people who are as far from being "computer" people as it is possible to find in the geek centric culture of caving. Some of them contributed substantially to the making the program usable. One even contributed the tutorial at

The "Pencil and Ink" features have not been as widely used, and quite frankly, it shows. Bugs and general clunkiness that would never be tolerated by the "Morphing" users persist. I fix things when people bug me about them, and no one has persistently bugged me about problems in the P&I features. Some bugs I know about, but haven't been motivated to fix, others would only be detected by users that did not know how the program works, or how it was intended to be used.

So, what I need now is testers willing to put up with a partially finished and evolving product, users who can separate the "must have" features from the "nice to have".

Early adopters will get something in return. Their views and needs will have greater weight. By tolerating an evolving product, they will determine what it evolves into. The final tool will fit their needs best, and they will get free support, roughly in proportion to their commitment.

OK, you know what I want, now for what Carto offers. In the following I will freely mix, with little distinction, completely debugged features and total vaporware (with most being somewhere in between), but will describe nothing I don't know how to do in principle. A great deal of existing functionality will not be mentioned at all.

Carto is an integrated application specially designed for making more or less conventional cave maps. It is written in Java, so it runs on most platforms. Carto is open source. I could go on for pages on why that makes it vastly preferable to any proprietary program with the same functionality (if there were one, but there is not), maybe another time.

So far as I know the only program with remotely similar goals is Walls.

A basic design goal is that nothing should need to be drawn (or done) twice. When survey data changes (errors fixed loop closed etc.) everything gets dragged along automatically. Different views of the same drawing are based on a single original. The importance of this principle is that whenever something is copied or traced, by someone who is not looking at the actual cave (and may never have seen it), some information is lost. In fact, there is a strong sense in which the morphed sketches are superior to any inked map, they just aren't as pretty.

The basic drawing primitive in Carto is the curve. Curves can have varying thicknesses, line styles, and fills. The tool for drawing curves was loosely modeled on the tool in Adobe Illustrator, but is still evolving. Curves are more important for cave maps than for typical drawings, which have more straight lines.

Carto has a built in concept of a "passage". A passage has an inside, an outside, a boundary between the two (defined by curves), and "details". Details include morphed segments, fill textures, drawn floor details, text notations, etc..

By default, details are only displayed in regions that are "inside" the passage. This avoids (for example) the need to retrace the walls when adding a floor texture.

The cartographer can divide the cave into passages in any way (or not at all), but to take advantage of some features of views (see bellow), they should be defined so that adjacent passages don't overlie each other.

In a cave map, a given piece of passage my be represented more than once, but it is an overriding design goal that nothing should need to be drawn more than once, so Carto has a concept of different views of the same artwork.

The most developed instance of this is in the "page" object. Pages in Carto control how the map is to be printed out. A map can be produced as a single big sheet, or as multiple pages, and at different scales. Single big sheets are inconvenient to print, and to use in cave, individual sheets are not as good for display purposes. By allowing the cartographer to lay out pages, Carto supports both.

Another example is where passages overlie each other. The traditional way to handle this is to display details of one passage, and dot or dash the walls of the other, possibly with a detail view with the roles reversed. Carto supports passages hiding of modifying the display of other passages. Which passage is shown, and which hidden, is on a per view basis.

Carto has built in line styles for things like drops and ceiling changes, and the ability to define fairly general additional line styles. Line thicknesses can be defined both in "map" units (e.g. feet), and "display" units (inches, pixels).

Carto also allows user defined symbols and fills. One way for a user to help with the project is by building a symbol library.

Carto is written in Java, and is open source. I strongly recommend against using closed source software for anything important. I am also open to contributions of code. I don't expect people to understand the code just by looking (but you can browse the code at, I will try to answer any questions as best I can.


I have updated the tutorial to reflect changes since it was writen. Following the old version still works.


I worked on Carto a fair amount in December, fixing a number of minor bugs.

I made a third attempt at implementing Morph on Demand, and happily this time I succeeded.

In the old version you had give an explicit command to morph a segment, and you had to remorph all the segments when you restarted carto. Because the segments could be displayed at any scale, they all had to be morphed at full resolution. For large maps with lots of segments, on slow computers with not much memory, this was a problem. You had to wait several minutes at startup, and all your memory was gone.

In the new version, morphing is done automatically, and only when the morphed image needs to be displayed. If it is being displayed very small, only a small morphed image is generated. If you zoom in, it displays the low resolution version until the bigger one is finished. The "morph" commands just erase the morphed images, which forces them to be remorphed.

The version now on the server has Morph on Demand enabled by default. It works, with a few performance related details remaining. I've done some testing, but not exhaustive, and fixed the worst performance problems.

When you open Carto, nothing is morphed, so you have to wait until at least low resolution images are generated. They take very little time to morph, but the unmorphed image files have to be read, and that takes too long (in the meantime the segments are displayed as outlines). Carto will (optionally) save a (low resolution?) morphed version of each segment in the .cto file, which should help.

I haven't implemented this yet, but when memory gets tight Carto will start throwing away morphed images that haven't been used lately, this should result in much fewer memory related problems.

The new version is not always faster, is still a bit clunky, and may even have some bugs, so there is an option in the "morph" preference page called "Morph on Demand". If you deselect that, it will work the old way.

The new version has a number of options. If you want to mess with them click "file/global options" and select "morph". The default settings are the ones I tested most. The best settings may be system dependent.

Performance of Morph on Demand should improve with time, as I fix the slow bits.


A few user interface changes. Segments that are not morphed are now displayed as outlines. If you right click on the corner of one a dialog will pop up that lets you edit or morph that segment. There is a "file/new project" menu item that combines a bunch of steps new users need to get started. Also there is a "new seg" button in the composite editor. It creates a new segment, inserts it into the composite, and opens a window to edit it.

More UI changes may be comming. Many people find the term "composite" confusing. I have been considering words to use instead. Posibilities are:

Map - Pretty discriptive, except there are lots of maps arround. Some composites will also be used for inset views etc. Also the whole .cto file might be thought of as a map.

Plan - This is the one I am leaning towards. When there are also "Cross Sections" and/or "Profiles", this will be pretty self explanatory.

Let me know what you think. I'm pretty sure I have forgotten some posibilities.

Carto now has a "stats" feature. It lists all the segments and composits and a few other things.

Carto now computes an estimate of the cave area. It is the total area enclosed by the boundaries of all the segments, except that if two segements overlap, and they share marked stations, then the overlap region is only counted once. The rational is that if overlapping sketches are truely adjacent then they will include the same stations, but if they are on different levels, they will not.

I might eventually add some mechanism to exclude segments and to override the default behavior for particular segments. The Drawing features of Carto will eventually have an explicit distinction between "inside" and "outside", and should be able to give an exact number.

The area estimate I give now is not perfect, but it is as good as the length estimates commonly used, and is *much* better than an area estimated from left/rights and shot lengths.

It is common to list the surveyed length of caves. It would be interesting to see the sketched area also listed. Maybe someone should start a bigest caves by area list. Of course, at least for now, only people who use Carto will know their cave's area :-).

To see the stats select file/stats or to do several files at once run Carto with the command

java -jar Carto.jar -s file1.cto file2.cto

10/22/02 (PM)

You can now import composites (drawings) from other .cto files, much like the way you could import segments before.

Cut, Copy, and Paste. Both within a .cto file and between files. I still only allow one open file at a time.

Statistics. There is a command line option and menu item to list the segments and composites in a file. It also lists the area of each segment, and the total area of the mapped cave. The "area" given is, of course, subject to at least as many caviots and disclaimers as the "length" that survey programs give.

It is actually just the area inside the boundaries of all the segments. Still, if you make the boundaries close to the walls, and the segments don't overlap too much, it should be about right.


The most recent version of Carto (Version 0.8.4) appears to be broken. It looks like I accedentally placed a non working development version on the web site.

I will post a corrected version tonight, it will have some new functionality as well. If you don't want to wait, you can get an older version.

Thanks to Dwight Livingston for pointing out the problem and sending the error.txt file that helped me identify it.


Still working on the Big Morphing Rewrite. It will be hard to produce upgrades until that is done, so even if I fix minor bugs, the fixes won't appear in the downloads until then.

The new code won't change the morphing algorithm itself, so there should be no visible changes. It's goals are:

Faster (hopefully apparently instantaneous) morphing. No more pixels will be actually generated than are needed for the display or printing that is happening.

Less memory use. For the same reason, plus elimination of some other waste.

No out of memory errors, regardless of how many morphed segments you have. This involves using a cache for the image data, so it will be possible, by adding too many segments (with JUST the wrong properties, the worst case is when they all overlap to fill the entire screen at once) to make it slow way down.

Removal of all the hacks used to work around the morphing being too slow and using too much memory. This includes the need to select "remorph all" after opening a file to make the segments visible, and options like "save morphed images" that never worked right anyway.

Now for the bad news. My first attempt at the rewrite has failed. A somewhat arcane part of the Java documentation was "unclear" (actually it lied). It implied that something would work, but it does not.

I will try another approach, which should use most of the same code from my first attempt.


In the latest upgrade of Carto (the first in some time), I have concentrated on performance.

Morphing is now much (10x?) faster, almost as fast as just reading in the images. The plan is to eventually do all morphing automatically, with remorphing only needed when the survey changes.

Some work has also been done on printing. Eventually this will allow production of more output formats (there is a preference page for that, but most options don't work yet). I fixed some memory leaks etc., this should permit the printing much larger pages. I can now do an 8x10 inch page at 300dpi with no trouble.

I am now using Java version 1.4 for my development, and am recommending that other users do the same.


I took a bit of a break from Carto over the holidays, and had a couple of smaller software projects to work on as well.

I did, however, get a fairly general mechanism for aligning symbols in a drawing to work (there are still features remaining to add). This required some major surgery, some of the most basic parts of the program had to be rewritten almost from scratch.

This rework was really needed anyway; it was necessary for a number of important features, nearly all of them related to the drawing part of the program.

The morphing portion of the program was hardly touched by this at all. It remains stable, and is not expected to change from a users viewpoint in the foreseeable future. There will be some recoding for performance improvements, but that can wait (There appears to be an unrelated serious Win95 only performance problem that I will work on). Bug fixes will continue.

I have refrained so far from widely advertising Carto on major mailing lists, instead relying on "word of mouth" and a couple of live demonstrations. I haven't exactly been keeping it secret, I talk about it to anyone who will listen (or even sit still), and I never told anyone else not to talk about it either, but I wanted a stream of users not a flood, and that is more or less what I got. Also, the program was (and alas probably still is) only suitable for "early adopters", less forgiving users might have seen how bad it was and been lost forever.

I am considering changing this policy soon for two reasons. First, morphing and combining sketches is a sufficiently useful function, and is sufficiently mature, that it could easily support a much wider group of users. Those users need not be deterred by missing features in the drawing portion of the program. I would hope that as the ability to produce final maps entirely in Carto matures, some of those users would take advantage of that.

A major reason the morphing part of the program is so much more mature (besides being a much less ambitious project) is that it has been used more. The numerous bug reports, either entered into the bug tracking system, or communicated informally, have helped enormously (Bob Zimmerman and John Gantor have been the most important contributors). I suspect that for the drawing part of the program to reach the same state, it will require the same treatment, so I am hoping to recruit some users interested in that.


Though lots of progress has been made, there is still quite a bit of work to do. But I am starting to look at endgame questions such as "What is needed for Carto 1.0?" I would appreciate any opinions on this! If you were designing a drawing program for cave mapping from scratch, what features would you like to have? Which would you consider most important? Which could you absolutely not do without? What would have to be added/changed in Carto for you to consider using it to draw maps?

I will accept advice or comments in almost any form. Many of the features I think are needed are listed as bugs on the bug tracker, vote for the ones you think matter most. Add new bugs to the list. Send email to me or to the carto list. Call me ((202)404-4942w (301)340-9046h), send Carrier pigeons!

Next week I am going to try teaching a somewhat less technophilic user to use the morphing features, I think that might be very instructive. I am also starting a project where I will use Carto to produce a finished cave map. That should help see exactly what needs to be done, and what their relative importances are.

If anyone is interested, the web site now includes a browsable form of the source. This is much more convenient for the casually curious, or for someone seriously looking for a bug, than downloading and unpacking the whole source distribution.


Bug summary:
127 bugs
28 active
99 resolved
80 fixed (included in resolved)

Lots of new features. Lots of bugs fixed.


It appears that some of the later versions have had an experimental option enabled by default. Please make sure that the preference "Discard morphed images when memory low" on the "morph" page is not checked.

I do not believe that leaving the option checked causes any loss of data, but I know that it can have a dramatic negative effect on performance.

Versions after today will disable the option automatically on start up.


Versions 0.7.0 and above have a new installation procedure The program is packaged as a jar file, which does not need to be unpacked. Because the program files and other resources stay inside the file, the directory is much less cluttered.


John Ganter has written a tutorial on the use of Carto for morphing sketches.


With two months between Cassel surveys, and the morphing and printing features somewhat under control, I have actually been able to work on some important new features for drawing maps.

The user can now control line thickness in a fairly general way. Each named choice ("major", "medium", etc) determines a thickness that can be set in a preference. The thicknesses can depend on the scale at which the line is being displayed (so that zooming in does exactly what magnifying a real map would), or can be a fixed distance in pixels or (after a calibration) in absolute units (inches etc). It can also be scaled between upper and lower limits.

There is also a feature that allows lines to not be shown at all if the scale is too small. That way zooming way out does not produce thousands of lines, all on top of each other.

I have just (mostly) finished a rather general set up that allows the user to define "layers" and decide which are to be displayed.


Bug summary:
75 bugs
18 active
57 resolved
42 fixed (included in resolved)

Carto can now print to a particular scale, and has facilities for calibrating the printer and screen (bug 30), and for dealing with different units.

Next in line are bugs 39 and 49, printing directly to the printer, and user control of line thickness as a function of scale. Bug 39 has been waiting a long time, but it couldn't be fixed before bug 30.

Keep the reports coming. I can't guarantee that they will be fixed in any particular order (or even at all), but none will be forgotten. It doesn't hurt to have a list of easy ones to work on when I don't have time or energy to tackle a big new feature.


Carto now has a working online help window.

Unfortunately, the window doesn't contain much actual information yet.

However, unlike many help systems this one is user editable. So whenever I explain how something works in email I will try to remember to add the explanation to the help window.

Whenever you figure out how to do something, unless it is TOTALLY obvious, I would appreciate it if you would write a help item (or a short text note) and send it to me so I can include it in the distribution.


I'm back from OTR (big eastern US caver event). More people have expressed interest in using Carto. The more users I have the better I can make it work.

I have upgraded my development system to Java version 1.3, and am now recommending Carto users to do the same.

I am currently not aware of anything in Carto that is broken in the new Java version, and there are some bug fixes in Java that should help. Also, it may be difficult to reproduce bugs if everyone is not using the same version.

If the upgrade causes new bugs do not hesitate to let me know. I will fix them as fast as I can.


Bug summary:
60 bugs
23 active
37 resolved
25 fixed (included in resolved)

I am now recommending that carto always be called with an option to allow use of more memory:
java -Xmx64m Carto
In place of the number 64 use the amount of actual memory installed on your computer.

I am planning to upgrade my development system to Java version 1.3. When I have done that I will also recommend that users do the same. Eventually I will use features of 1.3 and 1.2 will no longer work. Version 1.3 is reported to be faster and more reliable than 1.2. Note that Java2 is version 1.2 (but version 1.3 is not Java3).


(was missing from web page until 8/7/00)

I haven't been doing much to carto itself except for obvious bug fixes (I don't want to break anything just before my talk at convention), but I do have some significant additions to the web site (

There are now some screen shots of the program on the page. They are a by product of preparing my talk.

More importantly, there is now an on line bug tracking system. It allows anyone to add bug reports, feature requests, etc. and to keep track of or comment on the progress of bugs that they or other people added. They can also vote for which bugs they consider most important. It can be reached from the main carto page or at .

The system is quite extensive, it is the same system used by Netscape to keep track of bugs in their new browser.


Printing to images works.

To use it you need to set up a set of pages. You do this by clicking the "Page" button on the composite editor screen and then clicking and dragging to place each page. Each rectangular region marked this way will be printed as a separate page.

Once the pages are set up they are a permanent part of your file.

Properties of a page can be set by right selecting it and right clicking on its center marker. If you unselect "lock rotation" and select "edit rotation" the page can be rotated. The "aspect" field controls the page's shape (square or rectangle). The "resolution" setting sets the scale of the image (width height or pixels/unit). If the "Index" checkbox is selected, the the page will show other pages (ie it can be used as an index map).

There are two checboxes that determine how the page can be printed. All pages with "print to printer" checked will be printed to the printer (maybe, printers are a bit flaky in Java1.2) when the file-print menu item is selected. Similarly "print to image" causes the page to be printed as an image file with the "print images" menu item (alt f i).

You can set the file to write each page to. If you don't. the filename will be based on the "Name" field. The name field is set by default to try to make the names unique.

The default values of these options can be set from the preferences dialog (file-preferences).

At this point the only format that can be written is png. (which can now also be read). Others might be added in the future if free code for writing them can be found (but NOT gif format for legal reasons).

Ralph Hartley


There is now a Carto mailing list. Just in case anyone is interested.

The web page has been revamped.

Many bugs were found during a 5/4/00 session with Bob Zimmerman. All these "Zimmers" have now been fixed, as well as several others bugs and new features.

On the Segment edit page, the stations are labeled. The fixed stations, the selected station, the line plot, and the border of the segment are all marked in different colors. The colors are user settable.

There are now user preferences. Only a few exist now but more can be added fairly easily. Preferences are remembered from session to session. Implemented preferences include the colors used by the segment editor, and an option to open the last file that was open at start up.


Carto now uses much less memory. The resolution of morphed images is now adjustable.


I did quite a bit of work on Carto lately, Fixing a number of problems:

Carto chokes if image files move - Fixed. Now if an image is not found it asks for a new file. (Minor quirk - You have to give it one, it keeps asking until you do.)

Carto doesn't remember the last directory used from one session to the next - Fixed. It keeps information that should be persistent in a (binary) file called persist.sta . Now it is just the last directory used and the number of times Carto has run, but I may add more.

No keyboard shortcuts - Partially fixed. All menu items can be accessed from the keyboard using alt sequences. My new policy is to add the shortcut when I implement the function, so menu items without an underlined letter are ones that don't work yet. I haven't done shortcuts for non menu buttons yet, I will use the control key for them.

Carto produces error messages that are too long to see in a dos window - Fixed. It now saves all error messages in the text file error.txt . When someone has a problem they can email that file along with the description of the problem, and it may help me find out what is wrong.

When adding a point to a segment boundary, the point is added to the end instead of breaking the nearest line segment - Fixed. This one required a bit of work, but it is all invisible. Adding points to the boundary now works more or less like one would expect, in particular dragging from the middle of a line segment works.

The segment window does not have scroll bars - Fixed.

The composite window sometimes does not display scroll bars when they are needed - Fixed. Now they are always displayed.

The overlay of the survey on the segment window is backwards when the survey is from compass (.plt) - Fixed. North and East were swapped when reading .plt files. The composite window appeared OK because of the next bug, which partially canceled it out.

In the composite window North is down and East right (this is very wrong) - Partially fixed. North is now at the top. There are still some issues where fixing this bug resulted in new bugs. These concerned sub composites and library symbols, they will not effect people who do not use the CAD features.

When marking the stations on the segment window, it is hard to tell which station is which if the sketcher did not label them clearly - Workaround, Look at the survey in a composite window, they are labeled there. Possible fix - The segment window could label the stations on the overlay.

For the test done on 5/4/00 the morphed segment in the composite window was blank - Working on it. Java appears to have run out of memory. It may be sufficient to tell Java to allocate more memory (you can do that). The section of code involved is on my list of things to rewrite. The new version should be faster, produce higher quality morphed images, and use less memory.


The distribution packaging now uses zip files instead of jars. It seems that Sun does not think the jar unpacking function is needed by people who only have the runtime system, so they didn't include it.

The example files are no longer hard coded into the program. To get to the old starting point, use "set survey", "new segment", and "new composite".

Version 0.2.2. Printing almost works (but doesn't). Still coming soon, image quality settings, reading compass files.


OK, here it is. Lots of features are still unimplemented. Coming soon - printing, reading images and surveys other than the ones I hard coded for testing, image quality/speed settings, property editors, getting scaling right.