A file format conversion isn’t a neutral pass-through. Every format represents geometry, text, and metadata using its own internal rules, and converting between them means translating from one rule set to another. Translation is where data gets dropped, not because software is careless, but because the source format sometimes describes something the target format has no way to represent. Here’s what’s happening, piece by piece.
Curves Aren’t Stored the Same Way Everywhere
A vector curve isn’t a picture of a curve. It is math. Most modern formats represent curves as cubic Bézier paths, defined by anchor points and control handles. But not every format handles curve math the same way, and some don’t support true curves at all.
When a curve moves into a format that can’t represent it natively, the conversion has one option: approximate it with a series of short straight-line segments (a polyline). Visually, at a glance, this can look identical to the original. But two things change under the hood: the file gets larger (a smooth curve that was two anchor points and two handles might become dozens of tiny line segments), and the curve is no longer truly editable as a curve. You’re now reshaping individual short segments instead of adjusting a handle. Zoom in or rescale significantly, and faceting can become visible where a smooth arc used to be.
Layers Often Don’t Survive Structurally
Layers are a workflow concept, not a universal file format requirement. Formats that don’t support layers the way your source file does will typically flatten everything into a single layer or collapse your layer structure into one group. The visual result can look correct. What’s lost is the ability to isolate, hide, or independently edit the pieces you separated out for a reason in the first place, dimensioning on its own layer, annotations on another, base geometry on a third.
Text Takes One of Two Paths, and Only One Preserves Editability
When text crosses a format boundary, it either survives as a live text object, or it gets converted to outlines, vector paths shaped like the letters. Outlined text looks correct and prints correctly. But it’s no longer text: it can’t be searched, spell-checked, translated, or resized without distorting stroke weight the way real text would. It’s also typically a larger set of objects than the string of characters it replaced. Whether text survives as text usually comes down to whether the destination format supports text objects at all, and whether the specific import/export filter you’re using is configured to preserve them.
Metadata Is the Most Fragile Layer of All
Geometry and text are visible, so data loss there tends to get noticed quickly. Metadata doesn’t announce itself the same way. Hotspots, part IDs, embedded object attributes, and the kind of structured data that ties a technical illustration back to a parts list or a source drawing, this is the layer most likely to disappear silently in a conversion, because it has no visual representation to check against. If your workflow depends on that metadata downstream (a documentation system that reads part IDs, or a hotspot that needs to stay clickable in a PDF), you must verify it explicitly after conversion. A visually identical file is not proof that the metadata survived.
This is exactly why CGM (Computer Graphics Metafile) matters so much in aerospace, defense, and manufacturing workflows. CGM isn’t one generic format. It has industry-specific import filters, like CGM/ATA (Air Transport Association) for aerospace interoperability and CGM/PIP (Petroleum Industry Profile) for seismic data workflows, built specifically to preserve the metadata and hotspot structures those industries depend on. A generic CGM handler that ignores those profiles can open the file and show you the right picture while quietly dropping the data that made it useful.
Precision Is a Setting, Not a Given
It’s easy to assume coordinate precision is fixed and automatic. In formats like CGM, it isn’t it’s an explicit export choice. CGM export offers a VDC (Virtual Device Coordinate) Precision setting with two options: 16-bit integer or 32-bit fixed. That’s a real, visible tradeoff in coordinate accuracy, not an abstraction. Choose the wrong one for a large-format or highly detailed technical drawing, and you can introduce measurable coordinate drift; the kind that matters when a drawing feeds into fabrication, review, or compliance documentation.
Compliance Profiles Gate Whether a File Even Gets Accepted
Some format variants exist purely to satisfy a documentation standard, not a visual requirement. CALS compliance (Computer-aided Acquisition and Logistics Support) is a U.S. Department of Defense standard for migrating from hardcopy to paperless technical documentation, and it’s commonly required in aerospace and defense workflows. A file that’s technically valid CGM but not CALS-compliant can be visually perfect and still get rejected by a downstream system that requires it. Compliance profiles like this are a case where “the file opens and looks right” and “the file is correct” are two different questions.
What to Actually Check After a Conversion
A visual check isn’t enough. After converting a technical illustration between formats, it’s worth verifying:
Curves: Are they still true, editable curves, or have they become dense polylines?
Layers: Is your original layer structure intact, or has everything flattened into one?
Text: Is it still a live, editable text object, or has it silently become outlined paths?
Metadata: Are hotspots, part IDs, and attributes still present and functional — not just visually correct?
Precision: Does the coordinate precision setting match what your downstream use actually requires?
None of these show up by eyeballing the result. They show up when you try to edit, search, or query the file the way you’ll need to later.
Haven’t tried canvasxdraw yet? See what precision without compromise feels like.
Working with a format we didn’t cover here? Let us know and we’ll dig into it.