DXF中的倾斜标注比较奇怪，尽管在文档中指出了倾斜标注的倾斜角的组码52，但实际我发现该组码并不可用，AutoCAD并不支持该组码，如果DXF文件中指定该组码，AutoCAD甚至根本打不开这个文件。那么AutoCAD如何保存倾斜标注呢？

仔细对比发现，在DXF中的实体部分，倾斜标注与正常标注基本相同，只是标注线的定义点是根据倾斜角算出来的，是不是把这里改掉就可以了呢？答案是否定的。

原来，AutoCAD在保存标注的时候，除了保存该标注的构建信息外（不保存倾斜角),还引用了一个匿名块（组码2），该匿名块中包括了构成该标注的所有实体，定义点，界限线，箭头，标注线和文字。普通标注在保存到DXF中时，我们不需要构造这个匿名块，AutoCAD会根据标注的基本信息重构该标注的组成实体，但由于倾斜标注中没有保存倾斜角的信息，所以为了实现倾斜标注，我们必须自己为倾斜标注构造匿名块及所有实体。

构造实体，程序中是这样实现的：

1) 根据定义点构造标注线的构造线，即标注线所在的直线。

2)根据界限点与倾斜角构造两条界限线的构造线，用这两条构造线与1)中求出的构造线求交，得出标注线的两端点，即箭头定点。

3)根据dimexe，dimexo及倾斜角算出界限线的端点偏移矢量，分别与界限点及标注线定点做矢量加法，算出界限线的端点

4)根据标注的DIMStyle算出标注文字位置，标注文字有可能是用户指定，也可能要程序自动算出

5)引用匿名块的名字有命名规则，*Dn，n自动计数

这样便在DXF中实现了倾斜标注，AutoCAD也可以正常显示该倾斜标注，大功告成？

答案依然否定，在AutoCAD中操作该标注时，如果你要移动该标注，则该标注马上又变成了普通标注，还有什么地方需要设置呢？我也在继续摸索。。。：（

经常会被这样的问题惊醒，我到底做过什么？所做的都有意义吗？

四年前，我仍是一个程序员，要写很多代码，要学习很多代码，能有的学的感觉很好，至少不再是只能依赖MSDN Library 解决问题。这要感谢网络。

对于Open Inventor的研究，应该源于VC4.0（8年前了），那时VC里引入了TGS的Open Inventor 库，并有一些基本介绍，知道是基于OpenGL 做3D显示的，其他的基本上看不明白，资料太少，又没有Internet，无从下手，只是留下了一些遗憾的感觉，或是一种诱惑。那一年，完成了桥梁博士现在的所有图形功能模块，而那些代码能够延用至今无任何修改，不知是由于代码稳定，还是懒惰，呵呵。

4年前，当我得知SGI将OpenInventor做为开源项目，非常兴奋，马上下载了一份，尽管代码全是基于Unix平台的，但我有信心将它移植到Windows上。OI的移植，比想象中的顺利，用了大约1个月的时间。但SoXt的移植要复杂的多，除了编程思路和程序架构，几乎没什么可用的，前后三个月的时间，天天灰头土脸。人在充满希望中度过应该是幸福的，人在没有希望中度过，应该是安逸的，人在不知有没有希望中度过，那就是煎熬。

没有书籍，没有太多资料，但是SGI的程序员们还是相当厚道，有一个比较复杂的例子，赛车的，竟然能在我移植的库上跑起来了，那一刻，我心飞扬。。。

拿着这个半成品，我们到重庆做了重庆大佛寺长江大桥的结构安全监控。非常佩服李老师，很短的时间内，将大佛寺长江大桥真实地展现在程序界面中。一年多以后，突然发现，网上的资料慢慢多起来了，这大概就是开源的魅力。然后国外有公司专门做了OI的移植，比我做的更彻底，更稳定，我没有什么遗憾，毕竟不再有那么大压力去维护，但这种付出，不知究竟是有意义，还是没有意义？

大佛寺长江大桥的安全监控，是在一片混乱中完成的。一个月的时间，要完成挠度，振动，应变，温度和索力的数据采集，显示和分析，几乎所有的代码都是从零开始编写。第一次爬主塔，坐绗车，布线，安装传感器，在不到一人高的下位机房调试数据采集设备，与合作方讨论数据交换，晚上回宾馆编程序。几乎每天编程到凌晨4、5点钟，然后8点半起床，9点专车送往现场。

在验收评审组的专家们的脚踏进监控室的那一刻，刚完成了对代码最后一次修改的编译。验收还算顺利，验收总结报告中不乏赞誉之词，后来也获得了一个交通部科技进步三等奖。但随后的几个月，所有的电缆，光缆，数据线，据说都被一盗而光，系统自然瘫痪。这个项目中，首次应用了OI，报表的大部分工作都在期间完成，完成了结构模态分析模块。不能说一无所获，但项目最终是失败的，将近200万的投入，变成了几百元的电缆回收费，我们的劳动，算是有意义，还是没意义？

 报表模块的工作，主要涉及到表格的合并，各种图形模块的插入，打印等工作。但近年来，需求不断增加，而市场上商业报表模块的日渐成熟，客户要求报表与Office的兼容，原有的报表模块已经似乎变成了鸡肋。继续维护下去，有意义，还是没有意义了？

最令人头疼的是C语言脚本解释器的工作。想法当然源于当年用Delphi写的那个系统的思路，但用Delphi实现起来，要简单地多。当然C脚本对开发人员来说似乎更直观，数据类型更一致。但最终的用户能接收这样输入方式吗？桥博3.0发布一年多了，我还没有接到用户对脚本输入的技术支持需求。那我们做这样的模块，有意义，还是没有意义？

海口世纪大桥的结构安全监测相对于大佛寺要轻松很多，我们也承担了大部分的数据采集任务，系统更稳定，更成熟，三年多了，系统仍正常运转，从采集的数据来看，也非常有意义，挠度数据能真实反映出一辆重载卡车过桥所引起的挠度变化过程。结构振动数据也能争确分析出结构模态的10阶振型。但如果没有专业人员去分析，这样的数据我们去采集有意义，还是没有意义？

DXF文件的读写，相对来说是最没有技术含量的，但最烦琐，除了Autodesk的DXF规范之外，也没有太多资料可查。大量的规范之外的东西，只能通过大量比对去揣摩，去猜，一年多了，断断续续地维护，至今也没有最终完善。。。而且越做越没有激情，开发计划拖到现在，实在是疲了。

网站与论坛的建设，实在是力所不能及，有时真想做一个非常成功的网站，个人能力实在有限，无论是美工，还是编辑，我都不在行。想为土木工程师奉献点资料，哈哈，突然发现，我几乎一无所有。

4年来，所有的代码加起来，没超过60万行，平均每天40行，远低于日均300行的标准，实在是愧为程序员的称呼。

不知大家都在忙些什么?平均下来每天能写多少字？能写多少代码？欢迎交流

DXF格式是以带标记数据的形式表示 AutoCAD 图形文件中包含的所有信息。带标记数据是指文件中的每个数据元素前面都带有一个称为组码的整数。组码的值表明了组码后面的数据元素的类型，还指出了数据元素对于给定对象（或记录）类型的含义。实际上，图形文件中所有用户指定的信息都可以用 DXF 格式表示。

在 DXF格式中，对象和图元二者的定义是有区别的：对象没有图形表示，图元有图形表示。例如，词典是对象而不是图元。图元也称为图形对象，而对象称为非图形对象。

图元出现在 DXF 文件的 BLOCK 和 ENTITIES 段。组码在这两段中的用法相同。

定义图元的某些组码始终显示；其他组码是可选的，仅当其值与默认值不同时才显示。

编写程序时请不要按照此处显示的次序。图元的结尾由下一个 0 组表示，该组表示下一个图元的开始或指示此段已结束。

注意  如果以表驱动的方式编写 DXF 处理程序，忽略未定义的组码，且对图元中的组码次序不做任何假定，则该程序将比较容易针对 AutoCAD 后续版本中的 DXF 文件进行调整。每次发行新版本的 AutoCAD 时，都会在图元中添加一些新组码，以提供附加功能。