A user posted on r/SolidWorks asking why exporting a multi-view drawing to DXF produced a file with only one view. The replies suggested sheet templates, view scaling, and the usual draft-quality toggles. None worked. The actual cause was buried two dialogs deep: the DXF version dropdown in Tools → Options → File Locations → Export → DXF/DWG was set to R12. R12 cannot store layouts. SolidWorks wrote the model space and silently dropped everything else.
This is one of the most common DXF debugging mistakes. The dialog gives you eight or nine version options with cryptic names like AC1009 and AC1027, defaults to whatever was set in your last install (often R12 for legacy compatibility), and offers no warning when the chosen version cannot represent what you are trying to export. Splines collapse to polylines. TrueType text turns into SHX. Multiple paper space layouts vanish. Dynamic blocks become anonymous block references.
The fix is knowing which version supports which features and matching it to what your downstream tool actually consumes. Most shops never look this up.
DXF version reference table
The DXF format is versioned with an $ACADVER header value. Each release of AutoCAD adds capabilities and bumps the version. SolidWorks supports exporting to a subset of these versions through ExportToDWG2 and the save-as dialog. Here is what each one can carry:
| Year | AutoCAD release | $ACADVER | DXF dialog label | Layouts | Splines | TrueType | Multi-leader | Dynamic blocks |
|---|---|---|---|---|---|---|---|---|
| 1988 | R10 | AC1006 | R10 | No | No | No | No | No |
| 1992 | R11/R12 | AC1009 | R12 | One paper space | No | No | No | No |
| 1994 | R13 | AC1012 | R13 | One paper space | Yes | No | No | No |
| 1997 | R14 | AC1014 | R14 | One paper space | Yes | Partial | No | No |
| 1999 | R2000 | AC1015 | R2000-2002 | Multiple | Yes | Yes | No | No |
| 2003 | R2004 | AC1018 | R2004-2006 | Multiple | Yes | Yes | No | No |
| 2006 | R2007 | AC1021 | R2007-2009 | Multiple | Yes | Yes | Yes | Yes |
| 2009 | R2010 | AC1024 | R2010-2012 | Multiple | Yes | Yes | Yes | Yes |
| 2012 | R2013 | AC1027 | R2013-2017 | Multiple | Yes | Yes | Yes | Yes |
| 2017 | R2018 | AC1032 | R2018+ | Multiple | Yes | Yes | Yes | Yes |
The cliff is between R12 (AC1009) and R2000 (AC1015). Below R2000 you have one paper space tab, no splines as native entities, and no TrueType fonts. Above R2000 most things work, with progressive additions for advanced annotation features.
DXF R12 vs R14 vs R2000 — What’s Actually Different
Three versions account for most of the selection decisions you will encounter in practice.
R12 (AC1009): The compatibility floor you pay for. R12 handles a 1988 feature set. Curves are polylines. Text is SHX shape-based. You get exactly one paper space block, so a multi-sheet SolidWorks drawing loses every sheet after the first. Every DXF reader built in the last 30 years handles this version — including laser controllers from the late 1990s. That is R12’s only genuine advantage. If a downstream tool explicitly requires R12, test it with R2000 first. The job ticket is usually out of date, and the actual controller has supported R2000 for over a decade.
R14 (AC1014): Splines appear, but little else changes. R14 introduced the SPLINE entity. A curve exported at R14 carries the NURBS control points and knot vector instead of a chord-approximated polyline. For CAM toolpaths on a 5-axis mill this matters: the post-processor receives geometric intent rather than a polygon approximation. TrueType text is also present in R14, though some readers still fall back to SHX until R2000. In practice R14 is rarely the deliberate target. If you need native splines, R2000 is more compatible. If you need R12 compatibility, R14 does not help you.
R2000 (AC1015): The practical minimum for everything else. R2000 is where the format becomes fully modern. Multiple paper space blocks mean a three-sheet drawing exports three sheets intact. TrueType text is fully specified with font name and character set. DXF layer names extend to 255 characters (R12 allowed 31). Extended entity data (XData) for custom property embedding works reliably across all R2000-capable readers. If you do not have a specific constraint forcing R12, R2000 is the lowest version that makes sense for new work. For laser cutting, R2010 is the better default — every modern controller supports it and splines export as splines.
What each “drops silently” failure actually looks like
When SolidWorks exports a feature the chosen DXF version cannot represent, the writer falls back to an approximation rather than refusing the export. This is by design — a lossy export is more useful than no export — but the loss is invisible unless you compare files entity by entity.
Layouts collapse to model space. R12 has exactly one paper space block (*Paper_Space). A SolidWorks drawing with three sheets writes the first sheet’s model space to *Model_Space and dumps the additional sheets either as nothing (the SolidWorks behaviour) or as overlapping geometry in the same paper space (some other writers). If you opened your drawing in AutoCAD after export and saw only sheet 1, this is why.
Splines become polylines. Pre-R13 versions have no spline entity. The writer samples the spline at a fixed angular tolerance and writes a polyline through the samples. For laser cutting this is usually fine; the kerf width hides the chord deviation. For CAM toolpaths on a 5-axis mill it is not. The polyline has hundreds of short segments and the toolpath generator slows to a crawl.
TrueType text becomes SHX. Versions before R14 (and partially R14 itself) only support SHX shape-based fonts. A text annotation in Arial gets remapped to txt.shx or whatever fallback the writer picks. The text is still there but the kerning is wrong, the metrics differ, and any character outside Latin-1 is replaced with a question mark or a box.
Multi-leaders become old leader entities. R2007 introduced the MULTILEADER entity. A pre-R2007 export converts it to a regular LEADER plus separate MTEXT or TEXT entities. The result usually looks fine but it loses the smart formatting: the text no longer follows the leader if anyone moves the arrow, and styles do not propagate.
Dynamic blocks become static. A dynamic block with parameters (length, visibility states) collapses to a regular block reference at the current parameter values. The block becomes uneditable in any way that matters, but it still reads correctly as geometry.
Object data and extended entity data drop. Custom XData attached to entities by SolidWorks (custom property mappings, layer metadata) only survives in DXF versions that AutoCAD’s writer at the time supported. R12 and earlier have a 256-character XData limit per entity. SolidWorks truncates without warning.
What downstream tools actually want
The right DXF version is the highest version your downstream tool reads cleanly. Higher is not always better — old laser-cutting controllers genuinely cannot read R2018 — but defaulting to R12 because “everything reads it” trades real fidelity for compatibility you do not need.
Laser-cutting bureaus and fab shops. Most modern controllers (TruTops, Bystronic ByVision, Trumpf, Amada AP100) read R2010 (AC1024) without complaint. A handful of older Mazak and Mitsubishi controllers from the late 90s genuinely require R12. If you are sending to a contract laser cutter and they have not specified, R2010 is safe. If they specified R12, ask them whether they actually need it or whether their job ticket template is just out of date — most will say it is the latter.
CAM software (Mastercam, Esprit, Fusion 360 CAM, Gibbs). All current CAM systems read R2018+. R2013 (AC1027) is the practical minimum because that is when geometric tolerance entities were finalised. If your part has GD&T annotations you want to survive the round trip, do not go below R2013.
AutoCAD-based downstream design. AutoCAD opens any version, but it converts on save. If your client opens your DXF in AutoCAD 2024 and saves it back, the file becomes R2018 regardless. Sending them R2010 or R2013 means the round-trip diff is small and they can spot real changes. Sending them R12 means the diff is enormous and changes are invisible in the noise.
CNC plasma and waterjet (FastCAM, Hypertherm ProNest). These are usually fine with R2007 or later. Some older FastCAM installations only read up to R2004. If you cannot find out, R2000-2002 (AC1015) is the lowest version that handles splines as splines and is widely supported.
SVG/PDF intermediate flows. Some shops convert DXF to SVG or PDF for visual proofing. The conversion tools (Inkscape, ezdxf, Aspose) all handle R2010+ better than R12 because the entity model maps more directly. R12 splines-as-polylines force the converter to either honour the polyline literally (jagged curves at any zoom) or re-fit a spline (slow and lossy).
What to set in SolidWorks and where
The DXF version dropdown lives in two places, and they do not always agree.
Drawing-time export (File → Save As → DXF). This uses the version set in Tools → Options → System Options → Export → DXF/DWG → Version. Change it once, restart SolidWorks, and it persists. The dropdown labels are the AutoCAD release names (“R12”, “R2000-2002”, etc.) but the file headers carry the AC numbers from the table above.
API export via ExportToDWG2. The method signature has no version parameter. The version used is whatever was last set in System Options. This catches macro authors out — a macro that worked yesterday produces R12 today because someone changed the dropdown for a one-off export and forgot to set it back. The fix is to set the version in code before calling export:
Dim swApp As SldWorks.SldWorks
Dim swModel As ModelDoc2
Dim swExt As ModelDocExtension
Set swApp = Application.SldWorks
Set swModel = swApp.ActiveDoc
Set swExt = swModel.Extension
' Set DXF version to R2010 (AC1024) - "27" is the SolidWorks enum value
swApp.SetUserPreferenceIntegerValue _
swUserPreferenceIntegerValue_e.swDxfOutputType, 27
' Now export - it picks up the version we just set
swModel.SaveAs3 outPath, 0, 0
The integer values for the version are not documented in a stable way across SolidWorks releases, but decompiling SolidWorks.Interop.swconst.dll shows the mapping in the swDxfOutputType_e enum. They have been stable since SW 2018:
swDxfFormat_R12 = 12
swDxfFormat_R13 = 13
swDxfFormat_R14 = 14
swDxfFormat_2000 = 15
swDxfFormat_2004 = 18
swDxfFormat_2007 = 21
swDxfFormat_2010 = 24
swDxfFormat_2013 = 27
swDxfFormat_2018 = 32
These are the same numbers as the AC version digits (AC1015 = 15, AC1024 = 24, AC1027 = 27). That correspondence is intentional — Autodesk publishes the AC numbers, and SolidWorks chose to mirror them so macro authors do not have to memorise yet another mapping.
Performance task export. SolidWorks Task Scheduler runs DXF exports headlessly using whatever version is set in the user-level System Options for the account running the scheduler service. If your scheduled export started producing wrong-version DXFs after a server reboot, check that account’s System Options. The swUserPreferenceIntegerValue call above does not affect Task Scheduler exports because Task Scheduler runs in its own SolidWorks process.
The practical defaults
For shops that do not have a specific downstream constraint, these are the versions I recommend setting:
- R2010 (AC1024) as the everyday default for sheet metal flat patterns going to laser cutting. Splines as splines, TrueType text, multi-layer support, fully readable by every modern controller.
- R2013 (AC1027) if you have any GD&T or geometric tolerance annotations that need to survive.
- R2000-2002 (AC1015) as the low-compatibility fallback for older CAM systems. Still supports splines and TrueType. Avoid R12 unless the customer explicitly insists.
- R2018 (AC1032) only when the downstream tool is also new enough to read it. The new entities (point clouds, geographic data) are not relevant to most sheet metal workflows.
If your shop sends DXFs to multiple downstream destinations with different requirements, the right pattern is two profiles: one drawing template configured for R2010 (the common case), and a save-as-with-version step in the export macro for the legacy customer who still wants R12. Do not let the System Options dropdown be the source of truth — it is a single global, and the moment one user changes it for an experiment, every export from that machine is wrong until they remember to change it back.
CadShift’s batch DXF export sets the version explicitly per export rather than reading it from System Options. The version is part of the export profile, alongside layer mapping, file naming tokens, and metadata embedding. If you have one profile for Customer A (R12) and one for Customer B (R2010), neither can clobber the other’s settings, and headless task-scheduler runs use the profile’s version regardless of who is logged into the workstation. For more on the larger picture of DXF entity export settings that actually matter and what fabricators actually need from your DXF files, the version is the first thing to lock down before you touch anything else.
Summary checklist
Before exporting:
- Open Tools → Options → System Options → Export → DXF/DWG and check the version dropdown.
- If you have a multi-sheet drawing, you need at least R2000 (AC1015) to keep all sheets.
- If you have splines (curved 3D-projected edges), you need at least R13 but practically R2000+ for clean spline preservation.
- If you have TrueType text annotations, you need at least R2000+ to keep the font.
- If you are exporting via API or Task Scheduler, set the version explicitly in code, not via the GUI.
- If you do not know what the customer wants, ask, and assume R2010 if they shrug.
A misconfigured version dropdown is the cheapest debugging fix in the entire SolidWorks export workflow. Knowing which version supports which features is what separates a five-minute fix from a half-day of trying to figure out why the customer’s cutter ate your part. For batch workflows where this needs to be locked down across users and runs, see how SolidWorks creates flat patterns and where the export pipeline diverges and the format comparison for picking the right interchange.