Keeping CAD blocks readable across AutoCAD, BricsCAD, ZWCAD

Three programs, one file format, and one recurring set of gotchas

AutoCAD, BricsCAD and ZWCAD cover a huge share of the DWG-based CAD market between them, and I get some version of the same message from readers pretty regularly, they've downloaded a block, it opened fine in whichever program they use day to day, and then a collaborator on a different one of the three reports something looks off. Nine times out of ten it's the same handful of causes, and none of them are exotic once you know what to look for.

What makes this genuinely worth writing down is that the fixes are almost entirely preventive, small habits you build into how you create or curate a block in the first place, rather than something you fix after the fact once a collaborator has already reported a problem.

Fonts cause more support tickets than anything else

If I had to rank the causes by how often they actually trip people up, fonts would be first by a wide margin. AutoCAD, BricsCAD and ZWCAD all ship with the standard SHX font library and common TrueType fonts, but the moment a block uses something outside that common set, a decorative font someone grabbed for a title block years ago, each program substitutes differently, and text spacing shifts enough to push a label outside its intended box or overlap a dimension line. The fix is boring but effective, stick to the handful of fonts that ship with all three, txt.shx, romans.shx, or a genuinely universal TrueType font like Arial, and this entire category of problem disappears.

I keep a short approved font list pinned above my desk, more or less, and I check any new block against it before it goes into a shared library. It's a five second glance, but it's saved me from shipping a font problem into a client's drawing more than once.

Text style definitions compound this too, not just the font file itself, since a text style saved with a specific oblique angle or width factor tuned for one font can look distorted if the substituted fallback font has a very different natural character width, a decorative script font swapped for a plain sans serif, for instance, can end up looking compressed or unusually wide rather than just a different typeface. Sticking to the safe font list handles both problems at once, since a consistent, widely available font also means the text style settings built around it behave predictably no matter which of the three programs is doing the rendering.

Layer 0 discipline pays off here specifically

I've written about this convention before because it comes up in almost every compatibility question, but it's worth repeating in this context specifically, drawing block geometry on layer 0 with color and linetype set to ByLayer means the block inherits whatever layer it lands on, in any of the three programs, rather than carrying its own hard-coded appearance around. A downloaded Sofa Set Plan 1 block built this way will show up the same shade of whatever your furniture layer is set to whether it's inserted in AutoCAD, BricsCAD or ZWCAD, because that inheritance behavior is defined by the DWG format itself, not by any one vendor's implementation of it.

It's genuinely one of the few conventions in CAD drafting that costs nothing to adopt and pays off consistently regardless of which of the three programs eventually opens the file, which is why I bring it up in nearly every compatibility conversation I have with other drafters.

I would also flag block scale specifically as something worth double checking across the three, since all of them honour the insertion scale stored with a block reference the same way, but a block built with its geometry drawn at a nonstandard base unit, millimeters when the rest of your library is centimeters, for instance, can insert at a visibly wrong size on any platform if the drawing's insertion units are not set to match, which is a modelling habit issue rather than a cross software one but shows up in exactly this kind of mixed office far more often than in a single platform shop.

File version is the quiet lever most people forget

Autodesk revises the DWG format periodically, and BricsCAD and ZWCAD, both of which build their DWG engines independently rather than licensing Autodesk's, typically catch up within a version or two rather than day one. So saving your shared library down to a slightly older, well established DWG format, the 2013 or 2018 revision rather than whatever just came out, removes an entire class of open failures before they happen. This one setting change has fixed more it-won't-open reports for me than any other single adjustment.

It costs you nothing functionally either, since a 2D furniture or hardware block doesn't rely on anything introduced in the newest DWG revisions, so there's genuinely no downside to saving down a version or two for the sake of broader compatibility.

Worth knowing specifically is that both BricsCAD and ZWCAD tend to publish their DWG compatibility updates within roughly six to twelve months of a new Autodesk format revision, which is a reasonable lag for planning purposes, if your office adopts the newest AutoCAD release the moment it ships, budget for the other two platforms in the building to need that same window before they fully support files saved in the newest format, and saving your shared library down a version or two, as already covered, sidesteps needing to track that lag at all for content that does not require anything from the newest revision.

XRef paths and folder structure

Blocks themselves rarely use external references, but drawings built around them sometimes do, and this is where a folder structure that works on one machine can quietly break on another. An XRef saved with an absolute path, something tied to a specific drive letter or username, will fail to resolve the moment the file opens on a different machine running a different program, regardless of which of the three you're using. Relative paths, or a consistent shared folder structure that's identical across every machine in the office, avoid this entirely, and it's worth checking once rather than debugging a missing reference mid-deadline.

A quick way to test this before it becomes a real problem is to zip the whole project folder, move it to a completely different location on the same machine, and reopen it. If anything breaks, you've just found an absolute path problem in a controlled setting instead of in front of a client.

A short habit list worth adopting

Stick to standard fonts, keep block geometry on layer 0 with ByLayer properties, save down to an established DWG version, and use relative or consistently structured folder paths for anything with external references. None of these habits cost you anything in terms of what the block looks like or how it functions day to day, and together they cover the overwhelming majority of the compatibility complaints I've actually seen cross my desk between AutoCAD, BricsCAD and ZWCAD users.

The reason I keep coming back to the same short list rather than a longer, more exhaustive one is that in practice these four habits genuinely do account for nearly everything, and layering on more rules than that tends to make a standard harder to follow rather than more effective.