This is the ability to attach a name to a designated point, and to use that name in subsequent relative coordinate specifications, geometric snaps, etc. 2.1, via Variables and Expressions, later AutoLisp.
This is the ability to more finely describe the entities to be selected. Possible additional criteria would be layer, color, entity tag (see below), and entity type. Mike Riddle has already done some work in this area. Done by Kern Sibbald in Release 9.
These are text items which would be carried around with each entity drawn. They could be used to construct a bill of materials. 2.0 Attributes.
A sample program was suggested to demonstrate the capabilities of DXF files (or was it for entity tags?). 2.0.
This would be an extended CHANGE command, to allow modification of any of the properties of an existing entity. Extension of the CHANGE command from 1.3 to Release 9.
The OOPS command restores the last thing(s) which were erased. We need a more general ability to ``undo'' the previous command (e.g., MOVE). 2.5.
In some systems, the user can try drawing an entity; if it doesn't turn out as desired, he can reject it and try again. For continue commands like LINE, this seems like a nice approach. 2.0 for lines, 2.5 UNDO for everything else.
Currently, the ``L'' modifier allows the user to select the last entity in the redraw file. A more general ability to select the same set of entities as most recently selected would be useful. 2.5.
The current LAYER command, with its embedded COLOR option, is confusing to users and should be reworked. Ongoing process. Dialogue box introduced in Release 9.
Our current GRID command produces a square grid with specified spacing (within certain limits), with the grid origin at (0,0). We have been asked to provide grids with differing X and Y spacing, isometric grids, offset and rotation capabilities, and something better than the ``5 to 50'' dot limits. 2.0.
Similar to the above GRID enhancements. Differing X and Y spacing, isometric snaps (or is that isometric ORTHO?), offset, rotation. Also, the ability to snap to the nearest of a list of arbitrary points. 2.0.
Some systems can display not only a list of the available drawing parts, but a sample of each one. This is desirable. Release 9.
To list a disk directory or delete a file, it is first necessary to exit AutoCAD. These facilities should be provided while in the Drawing Editor. 1.4.
This would allow the user to rotate the display to work on a section of his drawing which is not easily visualized horizontally. Release 10.
Currently, the only way to draw an ellipse is to create a CIRCLE block and INSERT it with adjusted X and Y scales. 2.5.
Anything which can be done via INSERT should be possible via ordinary commands (see ELLIPSE, above).
Allow scale factors and rotation to be applied to the individual entities in an ``INSERT *''. 2.5.
We can now left-justify and center text fields. Right-justification would complete the set. 1.3.
Architects like to work with feet and inches. We should be able to handle them in input, and display them in STATUS, LIMITS, DIST, and DIM command outputs. 1.4.
Names should be assigned to many of AutoCAD's internal variables, and commands implemented to display and change their values. Some of the names could be documented for users, while others would remain secret for development and debugging. 2.1.
Discussion here included ``smart parts'' and ``parametric entities'', which would prompt the user for any needed parameters and use those parameters in expressions. It was also felt that a good macro feature would enable us to create all sorts of new entities easily. Perhaps more importantly, the users could create them also, taking some of the burden off us. AutoLisp in 2.1.
Now that we've done a few conversions and have the package running on a variety of machines, we should take a careful look at the device driver routines, with an eye toward restructuring them. Some new common service routines might reduce the work needed for future conversions. Ongoing process.
Users sometimes forget what layer they're on, and whether or not SNAP or ORTHO is in effect. Use of the bottom right-hand corner of the display to indicate mode settings was proposed. 1.3, improved in 1.4.
When drawing something like a continued sequence of lines, it is sometimes necessary to SNAP or ORTHO only some of the segments. Currently, the user must end the LINE command, issue the appropriate mode command, and begin a new LINE command. We could provide control keys to allow mode switching during a command. 1.4.
Again, this might fall under the general polyline-with-width implementation. 2.1. Doughnut command in 2.5.
Some hardware displays can draw ``rubber band'' lines and rectangles very quickly. A rubber band could be used along with the cross-hair when entering the ``to'' point of a line or trace, and when pointing to indicate a rotation angle. A rectangle could be used when selecting the objects in a window. The core program could indicate the preferred cross-hair type, and the base point, to the ``DSMARK'' routine, which would draw a normal cross-hair if it couldn't do the preferred type. ``DSMARK'' would save the necessary information so that ``DSCMRK'' could clear the previous cross-hair when needed. 1.3.
An ability to add a slant of a specified angle to an existing text font would be useful, but we should avoid prompting the user for too many things; the TEXT command already asks for insertion point, height, and angle as well as for the text string. 2.0.
Some design work has been done on a new capability for text font definitions (to support more than just 16 vector directions), and some fancier text fonts, including italic, have been constructed and are waiting for this feature. 1.4.
The LOAD command permits the user to load a new text font at any time. What we don't tell him in the manual is that the next time he REGENs the drawing, all his old text will now appear in the new font. Only one font at a time is actually supported. We should look into adding a multi-font capability. Again, we should be careful not to overload the user with prompts from the TEXT command. 2.0.
Our numeric ZOOM factors are confusing to users. ``ZOOM 2'' does not necessarily mean ``double the size''; it is relative to the original drawing size, not the current display.
Also, ``ZOOM 0.1'' might result in a small drawing in the lower left corner of the screen, and a subsequent ``ZOOM 1'' might leave you with a blank screen. 1.4.
It was proposed that the user could assign ``view'' numbers to various portions of his drawing (with associated zoom, etc.). This would allow switching from one area to another rapidly, without the need for several PAN or ZOOM commands. This might fit in nicely with the ``point variable'' feature (e.g., ``VIEW KITCHEN''). 2.0.
Performance optimization. Freeze and thaw in 2.1.
The REPEAT/ENDREP facility is limited, and can cause confusing results. A capability to form a radial array would be useful. Array command in 1.4 REPEAT/ENDREP removed in 2.5.
Currently, our redraw file contains only vectors. Circles, for example, are composed of many small vectors, and cannot utilize the circle-drawing capabilities of various displays and plotters. Even if we could use these hardware features, we'd still need a way to identify such an object when it is pointed to; this currently depends on the vector approach.
This is the ability to simply select a polygon (polyline) and compute its area or perimeter. Our present AREA command requires the user to specify the polygon vertex by vertex. 2.6.
Currently, QPLOT operates only on Epson printers. Other dot matrix printers are popular as well, and could conceivably be used. This might require additional code in the new Configurator. General printer plotter support added in 2.1.
A three-dimensional capability is desirable. It appears that an ``extrusion'' feature might be relatively simple to implement and sufficient for some users. Could be an extra-cost option. 2.1.
Editor: John Walker