Hello,
I export with the newest version of RHINO3D ( version 8.17) and when I import a dxd file on my plotter there is a problem with invalid label and a whole bunch of other incorrect things.
I am attaching the file to see what it is.
Thank you I can’t find the solution.
Before the last update no problems.
SILVERHENRY.dxf (304.6 KB)
Third report of this so far… nobody has responded yet. What got changed with ACAD exports for 8.17??
Working on a macbook pro Retina, 13-inch, Early 2015
running on OCLP Sequoia 15.3.1
Rhino Version 8 (8.17.25049.13002, 2025-02-18)
No issues, I could easily import the dxf file. No errors reported.
It’s not about reimporting the dxf into Rhino, that works. It’s about importing the dxf into AutoCAD or some other program - I have two reports of some CAM software refusing to open a dxf exported from 8.17 when it worked with 8.16 and previous.
the same file with 8.16 is ok for importing the dxf file in another software. But with 8.17 it’s over. It’s weird. A bug in 8.17 version.
They made 0D 0A → 0D.
0D 0A is the usual combination in Windows.
This is Carriage Return + Linefeed.
Means the LineFeed (0A) is missing.
Software which expects 0D 0A think the whole file is a single line then.
I thought perhaps it’s adjustable.
Not found…
…but a surprising dialog in Dark Mode:
Nice catch @Charles !
@wim - can we please get this fixed quickly? I have CAM customers that can no longer get their Rhino files into their CAM software for processing. I have them reverting to 8.16 for now.
Hi -
I’ve put this on the list as RH-86319 File IO: 8.17 Breaks DXF Export
-wim
Hi All,
The thing that changed is we updated the SDK we use to the current version from 25.1 to 25.12. It will be easy for me to make 8.17 go back to using 25.1 and I’ll do that asap.
Having said that. It would be good to know the details, ie. which acad flavor you’re using for export (maybe it’s all of them, that would be good to know too). That way I can take it up with Open Design Alliance and get them to fix the SDK so we can be up date again.
I wholeheartedly agree with Mitch. Nice catch Charles.
Tim
So I have all of the details, can someone confirm, is this only happening on the Mac platform or is it on Windows too? So far it looks like Mac only to me.
With just some quick tests I thought this may be related to French characters being written to the file. If I change the layer “Défaut” to “test” the file will write out as ANSI instead of UTF-8. On Windows the line returns are CR+LF for either file type. On Mac when it’s UTF-8 the line return is LF (unix style) and when it’s ANSI it’s CR.(mac style).
Still digging into the details with their current but I hope to have Rhino 8.17 using ODA 25.1 by the end of the day.
@voileriepaimpol can you please try changing “Défaut” to “test” in your 3dm file and export a dxf file and try opening it in your plotter app? That should create an ANSI file instead of a UTF-8 file. Let me know if that works, I suspect it wont. I want to confirm that the problem is the line ending and not the character encoding. It’s a problem regardless, I’m just building data to layout before Open Design in the bug I file with them.
Hi @voileriepaimpol. I’m not sure what I said is necessary. I reverted to 8.16 on my Mac and a UTF-8 file, with CR+LF, gets written whether the layer is named “Défaut” or test.
The next release candidate, on Tuesday, will have the fix in it (older SDK). If you need something sooner let me know and I’ll see what I can do.
No, I see it on Windows, didn’t check Mac.
Hi Charles,
That’s weird. Attached is a file I exported from Windows V8, dated Feb 24. So I know it’s using the busted SDK but, to me at least, it looks like it has the right line endings. I used the binary editor in visual studio to look at it, what are you using?
Regardless, the old SDK was put back in both platforms so it should be remedied for anyone who gets a new version after today.
Tim
v8test.dxf (922.1 KB)
