They are item labels. Truss software in which I label each individual
truss with a name 2 - 8 characters in length. Not being a dxf expert I
assume that they are simple dtext items, and that the dxf output of our
software contains some specifics that are read fine by Autodesk, but
Progecad misreads or cannot handle.
Funny thing is that I can convert it from dxf to same version dxf with
AcmeCAD converter and then it works fine.
Experienced a similar issue with automated saws where our software
generated a file where a number was 1.000 but saw was expecting an
integer. When it saw the decimal point it switched to floating point,
but the saw software could not handle the data as floating point and
crashed. We had invested big bucks trying to get saw running, but with
this and other problems we eventually just put it into the junkpile (we
bought it used as-is.)
jg wrote:
> Is that plain text? I have never had that, but occasionally mtext
> appears with big spaces between lines. It comes good after saving back
> to R14.
>
> Jerry G wrote:
>> One incompatibility I've seen (with Progecad and Progecad LT) is DText
>> from dxf. We use proprietary software that ex****ts to dxf. When I
>> im****t the dxf into Progecad, all the text ends up with the same
>> y-coordinate, ie all in one line with multiple items on top of each
>> other. It's not a UCS problem as far as I can tell, and if I convert
>> it to a dwg first, the problem disappears, but that necessitates
>> running a converter prior to every block insertion, which is a real
>> pain. Autocad doesn't have this problem, so I stay with an out-of-date
>> version of Cad. I can only assume that the dxfin function is with the
>> Intellicad core. If it isn't, I would like to hear about it.
>>
|
