A polyline is a group of lines, gaps, and arcs (?) which are associated with one another. They can be edited to add, delete, or move a vertex, move a line segment, etc. A width should be associated with the polyline; perhaps double walls could be special polylines. Assigned to Duff Kurland. Done by Dan Drake in 2.1.
John Walker has been experimenting with a cross-hatching technique which seems to work. We should implement the standard hatching patterns for various structural materials (concrete, steel, mud, etc.), and should consider a general user-defined pattern fill capability. Would be an extra-cost option. The project has been assigned to Mike Riddle. Done by John Walker in 1.4.
John Walker has also been researching various spline drawing methods. We had hoped that IGES would point us in the right direction here, but it doesn't point anywhere. Release 9.
Architects require this feature. A center line capability is also needed. Polylines might do the job here. Provided in AEC.
Several topics are covered by this item. First, we need to standardize on our color representations. For instance, the first eight colors should be:
0 black (erase)
1 red
2 green
3 blue
4 cyan
5 yellow
6 magenta
7 white (black on plotter?)
On monochrome devices, 0 means black (off), and any nonzero value means white (on).
Up until now, some AutoCAD implementations have used various bits of the ``color'' number to select the dotted/dashed line features of hardware devices (Scion Microangelo, NEC APC, plotters). While this has the desirable effect of allowing monochrome displays to differentiate between colors, it has two undesirable effects and must be avoided. First, it tends to make the color numbers difficult to work with (red + dashed line = 1 + 32 = 33). Second, it conflicts with the need for standardized line types.
One area which was not discussed at the meeting was the choice of colors for things AutoCAD (not the user) draws, like crosshairs and grids. My feeling is that the crosshairs should always be white, while the grid might be best in green. 1.3.
This is the ability to draw a line which intersects another entity in some specified manner (tangent to arc, perpendicular to line, etc.). 2.0.
It should be possible to select two points on a line, and split the line into two segments with a gap spanning the two selected points. This should not be limited to simple lines, however. Polylines, walls, traces, circles, and arcs should be breakable. 2.0. Polylines: 2.5.
Fillets are arcs which smoothly connect two lines. We should have a method of applying fillets after the lines have been drawn, and a method (FLINE command, or POLY command) of drawing them on the fly. 1.4.
Creation and reading of IGES-format interchange files should be
implemented. Could be an extra-cost option. Seen as large design
project with quick implementation involving adaptation of DIFIN
and DIFOUT functions.![[Footnote]](i/foot.gif){kind=small}
Assigned to Peter Goldmann. Done by Ben Halpern and
John Walker in 2.5.
Currently, our BLOCK command allows dynamic creation of a new block, but the new block is INSERTable only in the current drawing. We need a way to write the block to a new drawing file, so that it may be INSERTed in other drawings as well. 1.4.
Once a block has been INSERTed in a drawing or created via a BLOCK command, its definition rides around in the drawing file. In one respect, this is nice; the drawing file for the INSERTed part need not be present after the initial INSERT is done. However, it makes it difficult to update the part definition in all the drawings which include it. Even if all references to the block are erased from the drawing, the definition remains; the only way to delete it is to write a DXF file, edit it to remove the block definition, and load the DXF file back in. This is awkward. We need a way to delete or redefine an existing block definition. 1.4.
Our dimensioning facility can only draw horizontal and vertical dimensions. Several additional capabilities have been requested:
Our internal coordinate system uses 16-bit integers, giving a range of 0-32767 points in the X and Y directions. We are now seeing large (48-inch) plotters with 0.001 inch resolution. We need to support them, but they exceed our limits. A workaround might be to use only half of the plotter's resolution for the time being. 1.3.
So far, we've been producing a custom user manual for each machine implementation. This probably cannot continue. The basic reasons for separate manuals up to this point have been:
It might be best for us to produce a generic AutoCAD-86 manual, documenting all the commands, and control keys which will work on every machine. I would suggest the following keys:
Cursor left CTRL-H
Cursor right CTRL-L
Cursor up CTRL-K
Cursor down CTRL-J
Flip screens ESC 1
Select graphic cursor ESC 2
Select menu cursor ESC 3
Return to keyboard ESC 4
Slow cursor ESC 5
Fast cursor ESC 6
A note such as ``on some machines, the CTRL key is marked ALT; see the AutoCAD installation/user guide for your machine'' could be added. Operating system differences would be noted, as well. A separate installation/user guide and reference card would be associated with each machine, and would include exceptions from the main user manual and a list of alternate function keys if applicable. 1.4.
The AutoCAD reference card for each machine should include a list of the function keys available on that machine.
Rudolf Künzli has been working on various foreign language versions of AutoCAD, translating not only the user manual, but also the messages generated by the program. As things stand, he must re-apply his changes each time we send him new source disks.
We decided to use compile-time tests for each language, so that the text of each message could be provided once and maintained in the master source files. 1.3, later redone using the automatic translation utility.
Editor: John Walker