3-D starmaps have a similar problem to maps of the world. The Earth is a three dimensional globe, and maps are two dimensional sheets of paper. This explains the bewildering number of map projections. All of them distort some feature, the trick is to use a map that distorts the features of interest as little as possible, at the expense of less important ones.
In the same way, as the number of stars in your map increases you will quickly reach a point where the stars print on top of each other. Here is a horrible example. A more important problem is the apparently-near-but-actually-far phenomenon. Most 3-D maps are made 2-D by throwing away the altitude co-ordinate (generally the Z coord). So on the map CD-28°302 looks right next to Sol, but it is at Z coord -14 while Sol is at 0. So it is actually 14 parsecs away. This is very confusing.
I'll mention a couple of heavily mathematical techniques that I haven't managed to make work, then the quick-and-dirty technique that I actually use.
In the Landis list of science-fictional faster-than-light starship propulsion, the so-called "Jump drive" is 188.8.131.52. This is very popular in science fiction novels and games, e.g., The Mote In God's Eye by Niven and Pournelle. The important reason for its popularity is the fact that it allows interstellar battles due to the choke points created, but I digress. The jump drive postulates that a given star may be linked to zero, one, or several other stars. The important point is that this makes a star's actual three dimensional position irrelevant. The map may be reduced to a graph of nodes and their connections. The nodes can be moved around to untangle the knot of connections, yet will stay topographically equivalent to the original map.
For our purposes, we can use a similar idea. If we have virtual links between a star and its closest neighbors, we can also reduce our map into a graph of nodes and their connections. Such a map will distort the relation between a star and stars too far to be neighbors, but like the globe on the flat map something is going to have to be distorted.
Thomas Anderson had the idea to use Voronoi tesselations to generate a Delaunay graph. The graph can then be used as a flattened map. Roger Burton West explains how to do it and supplies sample Perl scripts.
Now for my quick and dirty method. It relies upon a freeware program called yEd. The main feature of interest is the autoformatting function. One can input a graph of nodes and their connections, select a style of autoformatting, and it will automatically move nodes around so they do not overlap and the connections are not a tangled mess.
To get the starmap into yEd I use *.gml files. These are similar to XML files, if you know what those are. Here is a sample *.gml file:
It makes two nodes, one for Sol and one for Alpha C, and one "edge" or connection between them.
Here is a sample *.gml file. Download it. Run the yEd editor from the website or download and install it. In yEd, choose File/Open and load the sample file. Note that all the nodes are on top of each other. Then do the autoformat: go to the Layout menu, choose Organic, move right to Smart. When the dialog window appears, click the Apply button and watch the fun.
After it is done you can tweek the map by manually dragging nodes around. The map can then be saved as a *.gif, *.jpg, or other graphic file.
It can save in SVG vector graphics format. Or if you save as Windows Meta File (WMF) file format, the resulting file can be imported into Adobe Illustrator and saved as an Adobe Acrobat or Illustrator vector graphic file.
As for making the *.gml file, here is a Python script that will help you generate *.gml. Read the included documentation to learn how to use it.