Collect a list of the linetype records containing the tell-tale DGNLSDEF entry in the extension dictionary.Find out the “unreferenced” DGN linestyles in the drawing.So what can be done to help purge the various unwanted objects? Which can be a problem as it turns out they can occupy quite a lot of space, as linestyles can often require lots of different strokes. The main issue with this picture is that all these “hard” references between objects prevent them from being purged, even when the entities that refer to them have been erased. Complex strokes can refer to each other and also to anonymous blocks in the Block Table.Īll in all a little complicated, as you can tell. They might be simple (in the case of STROKE1, above) or more complex. The objects in this dictionary represent the “strokes” in the linetype. These objects contain references to objects in the “ACAD_DGNLINESTYLECOMP” dictionary (which is inside the root Named Objects Dictionary). Complex DGN linestyles – that presumably cannot be mapped directly to standard AutoCAD linetypes – have entries in their Extension Dictionaries named “DGNLSDEF”.
(This is meant to be representative, of course – and is actually somewhat simplified.)īasically the entities created by the DGNIMPORT command have references to entries in the Linetype Table – just as any standard AutoCAD entities do.
Here’s my attempt at showing the types of object that participate in the display of DGN linestyle data inside AutoCAD: They’ve been working with a number of customers regarding large files resulting from importing DGN data into AutoCAD: it turns out that the internal structure for complex DGN linestyles created by the DGNIMPORT command – while working very well when the data is “live” – makes the data difficult to remove once no longer needed. I had an interesting question from a member of our Product Support team, last week.