Cannot get rid of AutoCAD recovery mode

[timoria21]

I've made the simplest DWG containing only one circle and I still get the Recovery Mode when opening it in AutoCAD 2007. From what I can see, LibreDWG is unable to write accurate DWG files, in all cases.

I'm attaching the files, just in case I am missing something. I don't believe that these warnings are meaningful in this respect.

files.zip

[rurban]

Set the RECOVERAUTO variable

[rurban]

Fix the wrong type in APPID (2004+ only), leading to the NOD being ignored. I think it might be this encode problem: Warning: Wrong object size: 31084 + 375 = 31461 != 31462: -1 off

[rurban]

yes. this was it. 14527d3eed139a23a6cd165ed591be8337ad18ba should fix those problems.

[rurban]

That being said, getting rid of the recovery dialog on acad import is not a goal for this library. We try to keep as much information as possible, and don't simply skip half-known information. acad recovery is doing its thing fine. there are so many unstable objects still, so there will always be a recovery prompt if you don't set to automatic. only with r2000 -> r2000 conversion without any unstable object there will be none

[timoria21]

I understand your point but nobody will trust a DWG file with this error in AutoCAD, how can you tell that the recovered entities are 100% of the DWG content? Will anybody in the industry use a DWG file with this problem?

If you have any idea of where to start investigating this issue, I will try to help with this cause. Would skipping half-known information help? Where do I start?

Thanks.

[rurban]

Sorry, but a 100% perfect DWG is a none-goal. Data-loss is a worse problem then a message that the dwg needs to be recovered. There are also other CAD programs which read and write DWG's and will need the 99% information in these DWG's.

[rurban]

There will never be 100% certainty. Even AutoCAD itself crashes on invalid input.

AutoCAD allows arbitrary 3rd party classes serialized to the Dwg. Teigha supports about 60% of them. We support about 40%, with some more common bugs. But no constraints and no parametric blocks yet. Not even proper acid solids or surfaces. Simple dwg libs support about 10% and just skip the rest.

[timoria21]

I did a test by myself, removing from JSON file all the problematic objects (most of them not related to geometry at all) and I was very close to get rid of the recovery mode error. Unfortunately, an issue with the one and only text style prevents me to succeed. Can you help me to understand what's wrong with this text style? Is there any text style data I can reset to avoid the problem?

All the documents attached.

322.zip

[rurban]

Still working on it. See GH #326

[timoria21]

Can I expect a valid text style with your latest commit? Thanks.

[timoria21]

Can this issue be related to x64 bitness, as your recent discovery on this one? Thanks.

[rurban]

Yes, I suspect a mingw64 problem with sizes

[timoria21]

Hello,

Here is a detailed list of the steps that I'm doing in order to help you reproduce this issue on Linux. You can find all the logs in the attached file logs.zip.

I'm testing on a linux VM with Debian 11.

Some information on the OS, you can find the outputs of these commands inside info/: apt list --installed -> /info/apt-list.txt cat /etc/os-release -> /info/os-release.txt hostnamectl -> /info/hostnamectl.txt

regarding apt-list, I installed specifically: Build-Essential, Autoconf, Libtool, TeXinfo, GIT

From now on it's very straightforward, I just did the README.md steps one by one:

See INSTALL for generic instructions. Basically, you do: $ sh ./autogen.sh (if you checked out the source code from git) $ ./configure [--enable-trace] [--disable-write] [--disable-shared] $ make $ make check $ sudo make install

And again you can find all the respective outputs in the attached files (inside build/).

Finally, I tried to read a DWG file (Polyline3D.dwg, version AC1015 - ~2000) into a .json and then write it back to a DWG. These are the commands that I've used (already tried with sudo too):

programs/dwgread -v9 -o ~/Desktop/dwgtest/Polyline3D.json ~/Desktop/dwgtest/Polyline3D.dwg 2>&1 | tee ~/Desktop/dwgtest/read_output.txt programs/dwgwrite -v9 -o ~/Desktop/dwgtest/Polyline3DTEST.dwg ~/Desktop/dwgtest/Polyline3D.json 2>&1 | tee ~/Desktop/dwgtest/write_output.txt

But when I open "Polyline3DTEST.dwg" with AutoCAD 2007 Windows I get the following message:

C:\Documents and Settings\Administrator\Desktop\Polyline3DTEST.dwg Unable to open this drawing. It contains incorrect or corrupted information. The RECOVER command may be able to restore undamaged material from this drawing.

However, if I do recover the file everything seems fine. You can find all the files and outputs inside dwg/.

What am I doing wrong? If you want I can send you the VM that I'm using, VMware but I should be able to export it to other formats too.

Thank you.

[rurban]

You are doing it right. AutoCAD just doesn't fully accept it yet, Reading handle 11 object type AcDbTextStyleTableRecord Error 67 (eDwgObjectImproperlyRead)

[timoria21]

Ah, so we are back to this issue again?

Thanks.

[rurban]

Seems to be the same error. I've detected some slack/undocumented 12 bits ("010000010010") after the bigfont_file, which should be written back into the style, probably. smoke/style-gh322

[timoria21]

Thanks. Is "win64" still appropriate in the title of issue #346?

[rurban]

Thanks. Is "win64" still appropriate in the title of issue #346?

No idea. But I would appreciate if this fixed your issue. I'm investigating further what this additional STYLE data means, probably 2 more TTF fields which are usually stored as EED.

[timoria21]

Do you mean I can try the latest changes already? Or do you still need to work on this?

I can repeat the test on Linux and let you know.

[rurban]

Should work with the smoke/style-gh322 branch, yes. And now in master, i.e. in tonights nightly

[timoria21]

Ok, will try tomorrow.

[timoria21]

I've done various tests with the same .DWG file of the previous comment, Polyline3D.dwg, but this time I tried with multiple versions. You may find everything here.

Here are the results:

• r14, Read Ok, Write Recovery Mode
• 2000, Read Ok, Write Crashes
• 2004, Read Ok, Write Recovery Mode
• 2007, Read Ok, Write Crashes

I've done the exact same operations of the previous comment. This time, I also tried to open the files on AutoCAD 2018 for MacOS, but nothing changed. (The files were saved with AutoCAD 2007 for Windows)

Again, if I recover the file, everything seems correct.

If you have the possibility, could you also try to write one of these?

[timoria21]

Can you repro? Do you need any other tests from my side?

Thanks.

[timoria21]

Hello Reini,

So here we are stuck again, like two years ago...

Please let me know if I can do something else to help you with this issue: https://github.com/LibreDWG/libredwg/issues/322

Or even if a further donation would help.

Thank you again,

Dave

---

From: Reini Urban @.> Sent: Thursday, March 30, 2023 6:03 AM To: LibreDWG/libredwg @.> Cc: David J. Harris @.>; Author @.> Subject: Re: [LibreDWG/libredwg] Cannot get rid of AutoCAD recovery mode (#322)

Should work with the smoke/style-gh322 branch, yes.

— Reply to this email directly, view it on GitHubhttps://github.com/LibreDWG/libredwg/issues/322#issuecomment-1490033100, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ATBSPWOJZ6DT4DIWHPXAR5LW6VK7PANCNFSM4YOKEZRQ. You are receiving this because you authored the thread.Message ID: @.***>

[rurban]

Working on this in smoke/oda for a while. Already fixed HATCH, VX_CONTROL, TABLECONTENT

problems still with downconverting TABLESTYLE, AcDbRasterImageDefReactor, AcDbMLeader and some weird CRC error without any hint where

See also #764 . I've integrated roundtrip checks via ODA. if the encoded DWG is valid, can be read back with ODA/Teigha

[xsxWang]

Automatic

how

Set the RECOVERAUTO variable

how to set the RECOVERAUTO variable?