Preserve full-sweep HATCH boundary angles - #1237
Conversation
|
The methods that you are replacing do the same as the change, it seems a redundant change. |
|
Thanks for reviewing. I checked the exact CSUtilities revision pinned by ACadSharp ( For this full sweep:
The DXF reader only converts those values back with Would you consider reopening this PR? If you prefer, I can instead fix the unused |
|
I see, the issue then is in CSUtilities, it should allow the option for non absolute values in range of -360 to 360, reopening the PR. |
Group codes 50 and 51 of a hatch boundary arc or ellipse were each converted with MathHelper.RadToDeg, which normalises. A circular boundary is stored as a full sweep - -PI to PI, or PI to 3*PI - so both endpoints normalised to the same number, 180 and 180, and the 360 degrees between them were gone. The reader only calls DegToRad, so nothing downstream can get the sweep back: the boundary, and the fill with it, disappears from the file. Both endpoints now convert without normalising, through the absolute flag that CSUtilities accepted and ignored until the companion commit there. AutoCAD 2027 was asked, on a minted fixture rather than a client drawing, because writing one of those to DXF makes a 54 MB file that accoreconsole refuses either way: written the old way AUDIT opened, 0 errors, extents (60,100)..(60,100) - a point written this way AUDIT opened, 0 errors, extents (60,60)..(140,140) - the circle Note the audit column. AutoCAD never complains about the old file; it simply has no hatch in it. That is why this went unnoticed while every gate here stayed green. The PI..3*PI shape writes 180 and 540, outside the -360..360 range the maintainer named in DomCR#1237, so that case was put to AutoCAD too: opened, 0 errors, and the extents are the whole circle. Measured on the client corpus: twenty-five such boundaries across four drawings out of 13,371 arc and 338 ellipse boundary edges. A DXF round trip of one of them returned three arcs with a zero sweep before this change and none after. Three regression tests, all three red when either half of the fix is reverted. Suite 2954/0, no in-scope loss, twenty AUDIT channels clean, extents 21 of 21, corpus gate green with the DXF channel holding its baseline. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
|
Hi @mediummandoo, CSUtilities has been updated. |
|
One last change and is good to go! |
Description
Preserve full-sweep HATCH arc and ellipse boundaries while keeping DXF angles in
-360..360. Converting negative angles to positive equivalents can collapse a sweep such as-90..270to equal endpoints.Both edge types use
MathHelper.RadToDeg(..., normalize: true, absolute: false). A HATCH-only adjustment preserves full sweeps whose normalized endpoints would otherwise coincide:180..540is written as-180..180, not180..180or an angle above 360. No common utility or other entity conversions are changed.Tasks done in this PR
WriterSingleObjectTests.SingleCaseGeneratorand register it inData.DxfWriterSingleObjectTests.Related Issues / Pull Requests
Notes for reviewer
net9.0writer tests: 859/859 passed with the repository's CI settings:The 12 angle cases assert round-trip results independently of
SELF_CHECK_OUTPUT. The shared fixture also passes all 11 DXF/DWG file-generation and re-read cases with self-check enabled.net48builds successfully. AutoCAD display behavior has not been checked locally.