Bug Watch May 2004

AutoCAD 2005 arrives, complete with politely presented features and very venerable creatures.

I'd like to express my gratitude to Autodesk for ensuring that AutoCAD 2005 happily coexists with its predecessors. This is despite the fact that 2005 is based fairly closely on 2004. Not repeating that mistake makes life much easier for paranoid users like me and for people evaluating the new release, such as CAD managers. Making life difficult for people with 2000i and 2002 was never Autodesk's smartest move.

Also, unlike 2000i and 2002, there's no obvious loss of existing functionality. In fact, I don't expect Autodesk to be in a hurry to do anything like removing the Express tools again, given the reaction it got the last time.

Finally, Autodesk has learned that making interface changes is fine, but they shouldn't always be shoved in your face. AutoCAD Today, introduced in 2000i, died in 2004 because of adverse reaction in user-land. I suspect its aggressive, uninvited intrusion into every user's life triggered that reaction more than anything else. Active Assistance was also once thrust in your face when you fired up the new release, resulting in at least one workplace nicknaming it Active Hindrance. This feature is now where it should be-available from the Help menu on request.

One change introduced by AutoCAD 2005 is support for Microsoft's current trend toward a nasty mix of a single and a multiple document interface. With this new feature, every time you start or open another drawing, one more button appears in your Windows task bar. This is probably the most annoying thing about Word 2000, which I'm using to type this (click here for more), and it would've had the potential to annoy a lot of new AutoCAD 2005 users.

That won't happen because Autodesk got two things right. First, it made the feature optional (it's controlled by the TASKBAR system variable). This is something Microsoft didn't get right the first time. Second, it turned off the new feature by default. It's natural for developers to attract attention to new features rather than downplay them, so congratulations to Autodesk for resisting that temptation. AutoCAD 2005 does offer to show you its new features, but it doesn't ram them down your throat. This is something Microsoft has yet to learn.

What's the buzz? (Release 13 to 2005)
A bug has been buzzing around since Release 13, when Autodesk introduced the complex linetype feature. Like me, you may have been scratching your head over this one for nearly a decade. Thanks to Ted Schaefer for pointing out that I have never before written about this most venerable insect. Autodesk has a technical document for this bug on its Web site, but it's incomplete and inaccurate.

If you use complex linetypes that contain text, from time to time you may see that text lean to the left or the right as its obliquing angle changes all by itself. To make life more interesting, some of the complex linetype text may be obliqued and some not, even though the same linetype definition is used. This may change in seemingly illogical ways as you work on the drawing.

Unlike traditional text objects, the obliquing angle of complex linetype text can't be defined on an object-by-object basis. It should always be determined by the setting of the text style used in the linetype definition. Instead, it's sometimes determined by the obliquing angle of the last text or attribute object that AutoCAD regenerated.

Let's try an example. In a new drawing, load the GAS_LINE linetype. Draw a text object, then a line, then another text object, then another line. Change the lines to use the GAS_LINE linetype. So far, so good. The complex linetype text all has an obliquing angle of 0, which matches that of the style STANDARD specified in the linetype definition.

Now change the first text object to an obliquing angle of -20 and the second to 30. Regenerate the drawing, and the first line has text at -20 and the second line at 30. Now move the second text object a little, then move the first line a little. The first line changes to use an obliquing angle of 30! This is because moving the text object forces AutoCAD to regenerate it. That makes it the last-regenerated text object, so its obliquing angle "wins" when the move forces the line to regenerate. Regenerate the drawing again and the line reverts to -20. As an exercise, try copying the objects in different ways and examining the results. The copied lines will have different obliquing angles, depending on the order in which you pick the objects (note that Window and Crossing will select in reverse order) and the obliquing angle of any other text objects created before each line is copied. For even more fun, try playing with the objects' draw order (Tools/Display Order).

Workaround: If you need obliqued text and nonobliqued complex linetypes in the same drawing, there's no practical solution to this problem. The ideas suggested by Autodesk at best give only transitory relief for individual objects. You can try manipulating the draw order of the various objects in your drawing, but that's a lot of work and future edits can easily mess things up again. If you're really desperate, you could make your own shape (as opposed to font) SHX file and define your own linetypes to use that instead. You then need to ensure that the SHX file accompanies your drawing wherever it goes.

Txt2mtxt torture too (2000 to 2005)
The Txt2mtxt command (Express/Text/Convert Text to Mtext) doesn't respect underlining. If a text object contains the underlining codes %%u, these are carried over intact instead of being converted to their mtext equivalents. This makes the text look rather messy.

Workaround: Manually edit the resulting mtext object.