SolidWorks .slddrw Drawing Files — Format Internals, Drawing View Types, and API Reference

Every SolidWorks user has opened a .SLDDRW file thousands of times. You place views, add dimensions, print to PDF, send it to the shop. But what’s actually inside that file? Is it vector graphics — maybe SVG behind the scenes? Is it a database of coordinates? How does a drawing “know” what the 3D model looks like from the front?

We decompiled the SolidWorks interop DLLs, inspected exported symbols from native C++ libraries, and dug through the API documentation to answer these questions. Here’s what we found.

What Is a .slddrw File and Who Uses It?

A .slddrw file is a SolidWorks Drawing — a 2D technical document produced from 3D SolidWorks models. Manufacturing engineers use them to communicate part dimensions, tolerances, surface finishes, and BOM information to suppliers, machinists, and quality teams. If you received one and need to view it without SolidWorks installed, the eDrawings Viewer is the free official option — it opens .slddrw, .sldprt, and .sldasm files on Windows, Mac, iOS, and Android.

For practical guidance on opening .slddrw files, the differences between .slddrw, .sldprt, and .sldasm, and what export formats preserve which data, see the .slddrw format reference. The rest of this post is about what the file contains internally — useful for automation, API access, and understanding why certain drawing operations behave unexpectedly.

How to Open a .slddrw File Without SolidWorks

Four paths work reliably, depending on what you need to do with the file.

eDrawings Viewer (Free — Official)

eDrawings Viewer is Dassault Systèmes’ free viewer for all SolidWorks formats. It opens .slddrw, .sldprt, and .sldasm files and runs on Windows, macOS, iOS, and Android. You can rotate the 3D model (if the drawing references a 3D part), flip through sheets, and measure geometry. What you can’t do: edit dimensions, change views, or extract CAD geometry.

When it doesn’t open: eDrawings expects the .slddrw file’s referenced parts and assemblies to exist at the same folder path they occupied when the drawing was saved — or the drawing must have been saved with “Save referenced geometry” enabled. If the viewer shows missing references or blank views, ask the sender to re-save with that option checked.

Online Viewers

Three browser-based options avoid any installation:

• 3DEXPERIENCE Online — Dassault’s own viewer. Handles SolidWorks drawing files with good fidelity. Requires a 3DEXPERIENCE account (free tier available).
• Autodesk Viewer — Good for .sldprt and .sldasm; drawing file rendering is partial and BOM tables often don’t display correctly.
• ShareCAD — Handles basic SolidWorks drawings and can export to PDF.

None are as reliable as eDrawings for complex drawings with custom BOM tables, revision blocks, or third-party annotation add-ins.

Converting to PDF Without SolidWorks

If you receive .slddrw files regularly and need PDF outputs without involving the sender, two options work:

1. SolidWorks Document Manager API — A lightweight DLL runtime from Dassault that reads SolidWorks files without a SolidWorks license. It can extract metadata, sheet names, and custom properties. It cannot render views to PDF directly, but it can read everything stored in the file’s XML streams.
2. SolidWorks Task Scheduler — On a machine with a SolidWorks license (not requiring a user to be present), Task Scheduler can batch-convert incoming .slddrw files to PDF overnight.

What Data Survives Each Export Format

The rest of this post covers what’s actually inside the .slddrw file format — the OLE container, drawing view types, and the API interfaces that expose them.

No, it’s not SVG

Let’s answer the most common question first. SolidWorks drawing files do not use SVG, PDF, EMF, or any standard vector format internally. There is an lfsvg14nu.dll in the SolidWorks installation directory — it’s a 2006-vintage LeadTools raster codec that handles SVG as an image format, not as a drawing storage format.

The SolidWorks API has no native SVG export. The SaveAs family of methods supports PDF, DXF, DWG, and eDrawings. SVG is not on the list — not in the method signatures, not in the enums, nowhere.

So what is inside a .SLDDRW?

The container: OLE Structured Storage

SLDDRW files use Microsoft OLE Structured Storage — the same compound document format that old .doc and .xls files use. Open one in a hex editor and the first eight bytes are D0 CF 11 E0 A1 B1 1A E1 — the OLE signature.

Inside this container, the file is organized into named storages (like folders) and streams (like files):

The __ZLB suffix on DisplayLists indicates zlib compression. This stream contains the tessellated geometry that SolidWorks uses for on-screen display — the actual lines, arcs, and curves that you see when you open the drawing.

Prior to SolidWorks 2015, these streams were accessible through standard OLE tools like libgsf on Linux or win32com in Python. Post-2015, Dassault added additional protection. You now need the SolidWorks API or the Document Manager API to read internal data programmatically.

The three-level architecture

Inside the API, a SolidWorks drawing is organized in a strict hierarchy:

IDrawingDoc
  └── ISheet (one per page)
        └── IView (one per drawing view)
              ├── Projected model geometry
              ├── User-sketched geometry
              └── Annotations (dimensions, notes, symbols)

IDrawingDoc is the top-level interface. It inherits from IModelDoc2 (the same base as parts and assemblies) and adds drawing-specific methods — creating views, managing sheets, inserting dimensions, controlling layers and line styles.

ISheet represents one physical page. It has a paper size, scale, template name, and provides GetViews() to enumerate all views placed on that sheet. Each sheet also stores its own format (title block), magnetic lines for view alignment, and revision tables.

IView is where the geometry lives. Each view is an oriented projection of a 3D model at a particular configuration. It stores a reference to the source document, a transform matrix, and two completely separate sets of geometric data.

Two geometry systems that don’t mix

This is one of the most important things to understand about SolidWorks drawings, and the API documentation doesn’t make it obvious. Every IView contains two independent sets of geometry that are accessed through different methods and never overlap.

System 1: Projected model geometry

These are the 2D projections of the 3D solid’s edges — the lines you see in a wireframe or hidden-lines-removed view. They’re accessed through:

• GetPolylines7() — returns all visible model edges as tessellated polylines. Arcs and circles are preserved as parametric data (center, radius, start/end angles), but splines and ellipses are approximated as polyline points.

• GetPolyLinesAndCurves() — the higher-fidelity version. Returns splines as full B-spline representations (degree, rational flag, control points, knot vector) and ellipses as parametric equations. This is the method you want for DXF export where curve accuracy matters.

The data format from GetPolylines7 is a flat double array:

[Type, GeomDataSize, GeomData[], LineColor, LineStyle, LineFont, LineWeight, LayerID, LayerOverride, NumPolyPoints, [x,y,z]...]

Where Type=0 is a polyline and Type=1 is an arc/circle with center, start point, end point, and normal vector.

GetPolyLinesAndCurves extends this with additional types:

• Type 2 — ellipses (center, major/minor axis vectors, radii, parameter range, normal)
• Type 3 — B-splines (degree, rational flag, control points, knot vector)

System 2: User-sketched geometry

These are entities that the user drew directly on the drawing sheet — sketch lines, arcs, splines added manually. They’re accessed through completely different methods:

• GetLines4() — user-drawn lines
• GetArcs4() — user-drawn arcs
• GetSplines3() — user-drawn splines (returned as tessellated points, not B-spline parameters)
• GetEllipses5() — user-drawn ellipses
• GetParabolas2() — user-drawn parabolas

These two systems are mutually exclusive. GetPolylines7 never returns user-sketched entities. GetLines4 never returns projected model edges. If you call only one set of methods, you’ll miss half the geometry.

How a drawing view gets its geometry

When you place a drawing view, SolidWorks doesn’t just take a screenshot. It computes a precise 2D projection of every visible edge in the 3D model. Here’s the pipeline we traced through the native DLLs.

Step 1: The 3D source

The geometry starts as a Parasolid B-Rep — boundary representation data stored in pskernel.dll (1,291 exported functions). Parasolid is Siemens’ geometric modeling kernel, and SolidWorks has used it since its inception. Every face, edge, and vertex in the 3D model is a Parasolid entity.

The view links to its source through IView.ReferencedDocument (which part or assembly) and IView.ReferencedConfiguration (which configuration of that model to display).

Step 2: Projection and hidden line removal

This is the computationally expensive step. SolidWorks needs to project every 3D edge onto a 2D plane and figure out which edges are visible, which are hidden behind other geometry, and which are silhouette outlines of curved surfaces.

The work is done by the CATIA HLR engine — cattessellationhlr.dll with 1,060 exported symbols. The class names tell the story:

• CATHLRPlanarProjection — sets up the projection plane. Takes a math point (eye position), a direction vector, and a projection type (parallel or perspective).
• CATHLRMotor / CATHLRComputer — orchestrates the HLR computation. These are the main driver classes.
• CATHLREdge / CATHLREdgeExact — edge representations with an IsSmooth method that distinguishes tangent edges from sharp ones.
• CATHLRResultPart — classifies each edge using TypeVisibility and TypeOcclusion enums (visible, hidden, occluded).
• CATHLRDiscretizer — discretizes curves for intersection testing during visibility determination.
• CATHLRLissage — smooths the result curves (“lissage” is French for smoothing).

There’s also a CGM-specific layer in cattessellationhlrcgm.dll (220 exports) with CATHLRGeometry2DFactory that creates the final 2D output geometry from the projected edges.

This is CATIA heritage. When Dassault Systèmes acquired SolidWorks in 1997, the CATIA kernel’s HLR engine came with it. Every CAT-prefixed class in SolidWorks traces back to this lineage. The same engine that computes hidden lines in CATIA drawings does it in SolidWorks.

Step 3: Silhouette computation

Silhouette edges are a special case. They don’t correspond to actual model topology — they’re the outlines of curved surfaces (cylinders, spheres, splines) that are visible from a particular viewing angle. As you rotate the model, silhouette edges move.

The HLR engine computes these with ComputeFacesSilhouetteSubdivision and AddPolySilhouette. The result is an ISilhouetteEdge in the API — and here’s the undocumented catch: when GetPolylines7 returns silhouette edge data, the corresponding entries in the edge array are null. The documentation buries this: “an edge does not actually exist.” A silhouette is purely a computed artifact of the viewing angle, not a topological edge on the model.

Step 4: Store as 2D primitives

The projected, visibility-classified edges are stored as parametric 2D curves. The native DLL cat2dpolygonclip.dll (237 exports) provides the primitive types:

A CATPrt2DClippingTool handles view clipping — cropping the geometry to the view boundary.

This is the actual stored representation. Not SVG paths. Not pixel data. Parametric 2D curves in a proprietary binary format, compressed with zlib inside the OLE container.

Step 5: Render to screen

For on-screen display, SolidWorks uses OpenGL via catvisopengl.dll with HOOPS (admhoops.dll, 86 exports) as a scene graph manager. HOOPS Visualize by Tech Soft 3D provides the rendering pipeline — it’s the same graphics engine used by eDrawings across all platforms.

Shaded views take a different path entirely. Instead of projected edges, they use tessellated triangle strips from sldtessellationu.dll (342 exports). The tsFaceTessellationHandle_c class provides VertexCoords(), NormComp(), IndexedTriangleIndices(), and NumFacets() for GPU rendering.

The view transform

Every view stores a precise mathematical link between 3D model space and 2D drawing space:

• IView.GetViewXform() — returns 13 doubles: elements [0–8] are a 3×3 rotation matrix, [9–11] are the translation vector, and [12] is the scale factor.
• IView.ModelToViewTransform — a MathTransform object that maps model coordinates directly to view coordinates.
• IView.GetXform() — returns 3 doubles: X and Y position relative to the sheet origin, and the view scale.

All geometry from GetPolylines7 and GetLines4 is returned in view space. To get sheet-space coordinates, you combine these with the values from GetXform.

Display modes and their quirks

Drawing views support multiple display modes, controlled through IView.SetDisplayMode3():

Here’s the undocumented behavior that trips up API developers: GetPolylines7 returns no data when the view is in Shaded, Shaded with Edges, Draft Quality, or Fast HLR/HLV mode. The polyline data simply doesn’t exist for those display modes. You must switch to Wireframe, HLR, or HLV first.

And there’s another trap: polylines are lazily generated. SolidWorks only computes polylines for edges that are within the visible viewport when the drawing is opened. If you open a drawing while zoomed in, off-screen edges may have no polyline data. The workaround is to call IModelDoc2.ViewZoomtofit2 before extracting geometry — this forces SolidWorks to compute polylines for the entire view.

The annotation layer

On top of the projected model geometry and user sketches, every view carries an annotation system accessed through IDisplayData. This is the rendered geometry for dimensions, notes, leaders, and symbols:

• Lines — extension lines, leader lines, witness lines
• Arcs — arc dimensions, radius callouts
• Polylines — complex annotation shapes
• Arrowheads — dimension arrows, leader terminators
• Triangles — filled annotation elements
• Text — with font name, height, position, angle, and box style

IView.GetDisplayData3() returns an IDisplayData object, and each primitive type is accessed by index: GetLineAtIndex3(), GetArcAtIndex2(), GetTextAtIndex(), and so on.

Section and detail views

Section views and detail views have their own geometry pipelines:

Section views use Parasolid’s PK_BODY_make_section and PK_BODY_section_with_sheet to cut through the 3D model with a plane, generating new cross-section edges that don’t exist in the original model. The section line geometry is accessible through IView.GetSectionLineInfo2() and the IDrSection interface.

Detail views extract a circular or profile-bounded region from a parent view, scaled up. IView.GetDetailCircleInfo2() returns the circle parameters, and IDetailCircle provides access to the detail boundary.

Both generate their projected geometry through the same CATIA HLR pipeline — they just feed it different input geometry.

Detailing mode: proof of cached geometry

SolidWorks 2020 introduced Detailing Mode (IDrawingDoc.IsDetailingMode). In this mode, a drawing opens without loading the referenced 3D models at all. You can add dimensions, notes, and annotations to a drawing even when the source parts aren’t available.

This is only possible because the .SLDDRW file caches the projected 2D geometry internally. The Contents/DisplayLists__ZLB stream contains everything needed to render the drawing views — the complete set of projected edges, stored as those CATPrt2D* primitives, compressed with zlib.

When you open in Detailing Mode, SolidWorks reads the cached geometry instead of re-projecting from the 3D model. This also explains why lightweight drawing mode loads faster — it skips the HLR recomputation and uses cached display data.

Export: how SolidWorks writes DXF and PDF

When you save a drawing as DXF or DWG, the export is handled by slddwgu.dll. Internally, this DLL uses the ODA SDK (Open Design Alliance) for DWG/DXF file format handling — confirmed by the OdReplayPopEnabled / OdReplayPushEnabled symbols in the exports.

The entity model conversion goes through CATIA’s CATDxfDataExchange.dll (452 exports), which maps internal geometry to DXF entities:

PDF export also lives in slddwgu.dll (via the SaveFileAsPDF export). The IExportPdfData interface lets you select which sheets to export and whether to include 3D PDF content.

For more on how DXF export works with flat patterns, we covered the ExportToDWG2 pipeline in detail in a separate post.

The constraint solver

Drawing sketches use the same constraint solver as part and assembly sketches — Siemens’ D-Cubed 2D DCM (dcu2d70.dll, 1,833 exports). When you add geometric constraints to sketch entities in a drawing (horizontal, vertical, coincident, tangent), D-Cubed solves the system of equations.

The SolidWorks wrapper in sldvrmlu.dll provides a solver_wrapper_c class with methods like add_g (add geometry), add_d (add dimension constraint), add_e (add equation), and autoConstrain for the automatic constraint feature.

Key DLLs and what they do

View types

For reference, here are the drawing view types exposed through the swDrawingViewTypes_e enum:

Note that value 1 (swDrawingSheet) is the sheet itself. When you call ISheet.GetViews(), the first view in the array is always the sheet — actual drawing views start from the second element. This catches many API developers off guard.

Display mode values

The view-level display mode enum (swViewDisplayMode_e):

Remember: GetPolylines7 only returns data for modes 1, 2, and 3.

Line styles and weights

Every edge in a drawing view carries style and weight metadata:

Line styles (swLineStyles_e):

Line weights (swLineWeights_e):

How CadShift uses this knowledge

Understanding the dual geometry system is critical for reliable DXF batch export. When CadShift exports drawing views, it knows to query both GetPolyLinesAndCurves (for projected model edges with full curve fidelity) and the GetLines4/GetArcs4 family (for user-sketched entities). Missing either set means an incomplete export.

We also know that GetPolylines7 fails silently in shaded mode — it returns an empty array with no error. CadShift checks the view display mode before extraction and temporarily switches to wireframe if needed, then restores the original mode afterward.

For teams dealing with file format conversion challenges, understanding that SLDDRW files cache their geometry explains why a drawing can appear correct even when the referenced model has changed — the cached display data may be stale until the views are rebuilt.

Building against these APIs inside a SolidWorks add-in introduces its own hazards — the DLL loading context for in-process automation creates type resolution failures that don’t appear in standalone tools. See resolving assembly dependencies in SolidWorks COM add-ins for the specific failure modes. If you’re weighing whether to build a COM add-in at all, our comparison of SolidWorks COM add-in vs modern .NET API approaches covers the trade-offs in depth.

Takeaways

• SLDDRW files are OLE Structured Storage containers, not SVG, PDF, or any standard vector format. The geometry is stored as parametric 2D curves (Bézier splines, arcs, ellipses, polylines) in a proprietary binary format, compressed with zlib.
• Drawing views contain two separate geometry systems: projected model edges and user-sketched entities, accessed through different API methods that never overlap.
• The CATIA HLR engine (cattessellationhlr.dll) computes hidden line removal — projecting 3D Parasolid B-Rep edges onto a 2D plane and classifying visibility. This is inherited CATIA code, not SolidWorks-original.
• GetPolylines7 has critical undocumented limitations: it returns nothing in shaded mode and only generates data for edges within the viewport when the drawing was opened.
• Detailing Mode proves the file caches geometry — drawings can open without their source models because the projected 2D curves are stored internally.
• DXF/DWG export uses the ODA SDK, with CATIA’s CATDxfDataExchange.dll handling entity conversion. PDF export goes through the same slddwgu.dll.