Rhino 8 (8.18.25070.14001, 2025-03-11)
One single layer named “Standard”.
The layer color is black.
One line on layer “Standard” from 11.111,22.222 to 33.333,44.444.
DXF export scheme Acad 2018 default - in this scheme the color handling is by RGB.
That results in the group code 420 for the color value, the value is 0 (=correct).
The AutoCAD color index gets written as well, group code is 62.
(In the LAYER table, under group code 62, we can read 18.)
This color index value is wrong.
The correct color index value is 7.
The error is the mismatch of group code 62 and group code 420.
For a test, I set the color handling in the DXF export scheme Acad 2018 to by AutoCAD color index.
Then the group code 420 is not in the output DXF.
Only group code 62.
And the color index is correct then: 7.
I don’t really know this stuff well. I inherited the code from Lowell, who did know it very well, but has retired. Tell me in the simplest terms possible what is wrong and I will make a YouTrack issue to track it. I would just fix it but I’m not sure at this point if I know how. It seems like if the color is set to rgb then there should not be any aci stuff in the file. Is this just something you noticed or is it showing up in downstream apps?
Yes, the wrong color showed up in a downstream app.
This app uses colors to manage elements.
Otherwise I wouldn’t have noticed.
I think the ACI color should be written too when output is set to RGB.
Looks like the exporter writes the nearest ACI color when there is no exact match - which is good.
It works for all colors except black.
DXF file has wrong ACI color for black
-and link to this thread
When you say “Acad 2018 default” are you speaking of “2018 Natural”? When I export your DXF.3dm file with the latest inhouse build using “2018 Natural” I do get 7 and not 18.
I sort of doubt the version of Rhino has anything to do with it. Nothing has changed in that regard for a long time. There was that SDK issue where dxfs were getting written with the wrong line endings on Mac. Did you update since that problem was fixed? I’d like to be able to fix this but I don’t know what to change since I don’t see the problem myself.
Nasty. A wild guess:
Maybe it’s a problem with the decimal separator.
I’m on German Rhino 8 on a German Windows.
That would explain why the issue is considered fixed on YT.
I have set the decimal separator to point in Windows.
No change in the DXF.
Still 18 for black.
And I have set the Rhino UI to English now.
Also still 18 not 7.
I humbly apologize. I was confused. I looked harder at the output and I do see it locally. My error was I thought there was only one layer table record, there are two. The first one is ok, the second has 18 instead of 7. I’ll make a YT for this and try to get it figured out.
OK. There is a fix coming. It turns out anytime the color is black, 18 was getting written to the dxf file as the color index. Your file had the layer color set as black and the object as color by layer. If you set the object color to black you’ll see it move to the entity. There are other places in the dxf file that have 62 → 18 but they must be something set by the SDK, we’re not setting those colors explicitly. It was fixed a long time ago for ACI but not RGB. I don’t know if Lowell didn’t realize that was the case for RGB or there was some other reason it never got addressed. Regardless, it will get set to 7 in the upcoming releases.
By default, all work is done in the 8.x branch, which is the current public service release candidate + 1 version. This way, things are at least somewhat tested internally before a public release and tested for a complete month by some users before getting into the stable SR. When a developer is very very sure that the change won’t impact other things or when fixing a crash bug, the fix can go into the current candidate.
-wim
