[cre8ive-marketing]

Closes #489. This follows the plan agreed there and covers both points from your ACadSharp 3.8.0 check.

What it does

CAD presets get an AutoCAD version choice, in a new "CAD drawing" card in the preset editor. It shows when the target is DWG or DXF. The options are:

• 2018 (the default, unchanged)
• 2013, 2010, 2007, 2004, 2000
• Same as the source: the drawing's own version, within what can be written. Anything older than 2000 becomes 2000.

DWG → DWG and DXF → DXF are now routes too, so a preset can just change the version. SVG → DXF (tracing) honours the choice as well.

Version names stay "AutoCAD 2018" and so on in every language. The settings schema doesn't change: CadOptions.Version is a new enum that defaults to 2018, read with LenientEnumJsonConverter.

Your two points

1. DWG 2007 can't be written. Picking 2007 for a DWG writes 2004, which AutoCAD 2007 opens. "Same as the source" for a 2007 DWG writes 2010, as you suggested, which keeps the text in UTF-8. DXF 2007 is written as 2007.
2. Text before 2007. CadCodePages picks the code page from the text when writing 2004 or older:
   • The rule: the page that holds the most distinct non-ASCII characters wins. On a tie, the drawing's own page wins.
   • East Asian pages: these come first only for their own script, because they also hold Greek, Cyrillic and each other's characters. Hangul gives ANSI_949, Kana gives ANSI_932, and Chinese characters give ANSI_950 before ANSI_936. That way traditional text, which both hold, gets Big5, and simplified text, which Big5 lacks, gets GBK.
   • Escapes: any character the chosen page can't hold is written as \U+XXXX, so mixed scripts survive. Characters outside the BMP become ?, because \U+ takes four hex digits only.
   • What I found in 3.8.0: ACadSharp doesn't know the name ANSI_949. With that header it writes the DXF text as UTF-8 and the DWG as 1252. It does know KCS5601, which encodes CP949 correctly. So Korean is written with KCS5601, and the DXF header is then renamed to ANSI_949, the name AutoCAD writes. This is the reverse of what OpenDxf already does on reading.

Objects the version doesn't have

These are left out with a note (notice.cad_newer_left_out), and the file is still written:

• tables and arc dimensions, before 2004
• multileaders and PDF underlays, before 2007
• meshes, before 2010

ACadSharp writes all of them into any version without complaining, but older AutoCAD can't read them.

Tests (CadVersionTests, and an editor test in RenderTests)

• Every version × DWG/DXF:
  • reads back in the expected version, with the same entity census
  • keeps a Korean text, a simplified Chinese text and a Korean + Chinese + Latin MTEXT unchanged (as shown, \U+ decoded)
  • the source says ANSI_1252, as you described
• A 2004 DXF has $DWGCODEPAGE ANSI_949, the Korean text in CP949 bytes, and 这 written as \U+8FD9.
• Code page choice: Korean, simplified and traditional Chinese, Japanese, Cyrillic, ASCII only (keeps the drawing's own page), and name parsing.
• "Same as the source" mapping, including 2007 DWG → 2010, R14 → 2000 and R12 → 2000.
• Multileader and mesh are left out of a 2000 DWG with the note, and kept in 2018 with no note.
• DWG → DWG is a one-step route.
• Editor: the card shows for DWG and DXF, saves the version and reloads it, and doesn't keep it behind another target.
• docs/ENGINES.md (Writing) describes all of this.
• 5 new strings in all 14 language files.
• dotnet format --verify-no-changes is clean. Full dotnet test: Platform 48, Core 504, CLI 27, Setup 149, Engines 1629 and App 904 pass, none fail (before merging current main, which brought in Recognize text in scans and pictures with Tesseract (OCR, #288) #429; after the merge, the CAD, preset editor and localization tests pass again).

Not checked: opening the files in real AutoCAD 2000/2004/2007. I don't have those versions, so the round trips are through ACadSharp's own reader.

[KnifeLemon]

Thanks @cre8ive-marketing, this covers both points from #489 well, and finding the ANSI_949 / KCS5601 quirk was a good catch. I merged it with current main and ran dotnet format --verify-no-changes, the build, the CAD / DXF / DWG / SVG engine tests (72 passed), Core (510) and the preset editor and localization App tests (115). All 14 language files have the 5 new keys.

I also checked the round trip with a local test, not committed. It saved drawings as 2000, 2004 and 2018, in both DXF and DWG, and read them back with CadFile.Read. The drawings had TEXT, MTEXT, an attribute definition and attributes in Korean, simplified and traditional Chinese, Japanese and Russian, each starting from ANSI_1252:

• Every text came back unchanged.
• The DXF headers said ANSI_949, ANSI_936, ANSI_950, ANSI_932 or ANSI_1251 as expected, and Chinese in a Korean drawing went out as \U+XXXX.
• 2007 DWG → 2004 and "Same as the source" for a 2007 DWG → 2010 both match what we agreed.

One thing needs fixing before it goes in:

1. Names aren't counted when the code page is picked. A drawing with a layer named 벽체 and only English text, saved as 2000 or 2004, gets ANSI_1252, and the layer comes back as ?? in both DXF and DWG. Korean layer names with English labels are very common in Korean drawings. Please count the names of layers, blocks, text styles, dimension styles, linetypes and layouts, and attribute tags, in CadCodePages.Choose. If you can, escape names the chosen page can't hold the same way as text. A test with a Korean layer and ASCII-only text would cover it.

Smaller ones:

2. A character outside the BMP (an emoji) comes back as ??, one ? for each half of the surrogate pair. One ? per character would be tidier.
3. The DWG header gets code page index 25 (KSC5601) for Korean and 31 (GB2312) for simplified Chinese, while the DXF header says ANSI_949. Korean and Chinese AutoCAD write 40 / 39 / 41 (ANSI_949 / ANSI_936 / ANSI_950). ACadSharp reads both back the same way. If it's easy to write the ANSI_ index, DWG and DXF would agree. This is optional, since neither of us can open the files in AutoCAD 2000/2004.
4. Tables are kept in 2004, but the text in their cells doesn't go through the code page choice or the escapes. This is optional too, and a note in docs/ENGINES.md is fine.

The CI build failure is ToolbarPaletteModelTests.Deleted_profile_loses_its_cache_entry, which this PR doesn't touch. It should pass on a re-run after merging main. You're right that no settings migration is needed. We'll adjust the Korean strings to the app's usual tone ourselves, so leave those as they are.

To get this into the next release, we'll push the remaining changes to your branch ourselves today if you haven't by then. Have a look at the commits when they land.

To get this into the next release, we'll push the remaining changes to your branch ourselves today (maintainer edits are on). Have a look at the commits when they land, and tell us if anything looks off.

[cre8ive-marketing]

Thanks @KnifeLemon, and for the round-trip check across scripts. Done in b75684c and 0edb87b:

1. Names count. CadCodePages counts these when it picks the code page, and escapes them the same way as text:

   • layer, block, text style, dimension style, linetype and layout names
   • attribute tags, on definitions and on inserts' attributes

   *Model_Space, *Paper_Space and anonymous blocks are skipped. New tests:

   • a 벽체 layer, a Korean attribute tag 도면번호 and only English text, saved as 2000 and 2004 in DXF and DWG: the layer and tag come back unchanged
   • a mixed-script layer 평면 这 saved as 2004: 这 goes out as \U+8FD9 and decodes back

2. Emoji: a character outside the BMP is now one ?. The test text 한글 도면 😀 끝 comes back as 한글 도면 ? 끝.

3. DWG code page index: I left this one. ACadSharp 3.8 encodes from its enum, and the only Korean name it maps (KCS5601) writes index 25. Writing 40 would mean patching the DWG header bytes after the writer, and we can't check that against real AutoCAD 2000/2004. docs/ENGINES.md notes the difference, and both read back the same.

4. Table cell text is noted in docs/ENGINES.md as not escaped.

All 61 CAD tests pass and dotnet format --verify-no-changes is clean. The CI build will run again on the merge with main, which already has #498.