Keeping block fonts and linetypes consistent across CAD software

Two boring settings cause most of the visible problems

If I had to name the two things that cause the vast majority of why-does-this-block-look-different complaints across CAD software, it wouldn't be anything exotic, it would be fonts and linetypes. Neither is glamorous, both get set once during block creation and then ignored, and both are exactly the kind of detail that only becomes visible when a drawing crosses from one CAD program to another and something that used to look fine suddenly doesn't.

What makes them worth a dedicated look, rather than lumping them in with every other compatibility factor, is that they're both entirely preventable with habits you build once into how you create a block, rather than something you're stuck troubleshooting after the fact on someone else's machine.

SHX versus TrueType, and why it matters more than it seems

AutoCAD and its DWG-compatible alternatives support two font systems, SHX fonts, which are AutoCAD's own vector font format going back decades, and TrueType fonts, the same system used across the rest of your operating system. SHX fonts tend to be more universally available across CAD software specifically, since they're bundled with basically every DWG-compatible program, whereas a TrueType font depends on whatever's actually installed on that particular machine's operating system. For a block library meant to travel across AutoCAD, BricsCAD, ZWCAD and similar programs, standard SHX fonts like txt.shx or romans.shx are the safer default, and if you do use a TrueType font, stick to something as common as Arial rather than anything decorative.

I'll occasionally see a block that uses a stylized architectural font for its labels, something that looks sharp in isolation, and while I understand the appeal for a firm's own internal drawings, it's exactly the wrong choice for anything meant to leave the building or cross software, since the odds of that specific font being installed elsewhere drop fast.

A concrete example makes this easier to spot ahead of time, if you build a block using a decorative font for a dimension tag and it looks perfectly proportioned at your normal working scale, try opening that same block at a noticeably different zoom or plotting it at a different sheet scale before you finalize it, since font substitution problems have a habit of hiding at one scale and showing up plainly at another. I keep a short reference drawing with the same test string set in romans.shx, txt.shx and a couple of common TrueType options side by side, and I'll glance at it whenever I'm unsure whether a font choice is safe enough to use across a shared library.

What actually happens when a font is missing

When a program opens a DWG referencing a font it doesn't have installed, it doesn't just fail silently, most CAD software substitutes automatically using a font mapping file, Autodesk's version is called an FMP file, that pairs missing fonts with reasonable fallbacks. The substitution keeps the drawing usable, but it changes character width and spacing, which means any text tightly fit into a label box on a block, a dimension callout or a tag, can suddenly overflow its boundary or overlap adjacent geometry. This is exactly the kind of thing that's invisible on your own machine and only shows up the moment someone else opens the file, which is why it's worth testing on a second machine before you assume a block is finished.

Most programs will also flag the substitution somewhere, a small dialog or a note in the command line, but it's easy to click past that warning without really registering it, especially mid deadline, which is exactly when a shifted label is most likely to slip through unnoticed into a finished drawing.

Linetypes live in a definition file, not the block itself

This is the part people misunderstand most often. A linetype like DASHED or CENTER isn't embedded directly in the geometry, it's a reference to a definition that lives in a LIN file, and standard linetypes ship with every major DWG-compatible program so they display correctly everywhere without extra work. Custom linetypes, the kind you might build for a specific fencing pattern or a gate mesh texture, only display correctly on a machine that has that specific custom LIN file loaded. Miss that step and the linetype silently falls back to a continuous line, which is easy to overlook because nothing throws an error, the geometry just quietly loses its pattern.

This one is genuinely rare on furniture and hardware blocks specifically, since the standard dashed and hidden linetypes cover most of what those objects need, but it shows up more often on site or landscape content where a custom pattern is doing real representational work, like distinguishing a chain link fence from a solid boundary wall.

Linetype scale, the setting everyone forgets exists

Even with the correct linetype definition present, how long the dashes and gaps actually appear depends on the LTSCALE and PSLTSCALE system variables, and these are drawing-level settings rather than something baked into the block. A block that looks correctly dashed in the original drawing can appear either solid, because the dashes are too small to render, or wildly spaced out, because they're too large, once it's inserted into a drawing with a very different scale setting. This isn't really a cross-software compatibility issue in the strict sense, since it happens even within the same program, but it gets blamed on software differences constantly because that's usually the moment someone notices it.

The fix, when a linetype looks wrong after insertion, is almost never to touch the block itself, it's to adjust LTSCALE on the host drawing until the dash pattern reads correctly at that drawing's particular scale, which is a drawing-level setting you'd need to check regardless of which software everyone involved happens to be running.

I've walked a junior drafter through this exact confusion more than once, they'll insert a block with a dashed boundary line, see it render as a solid line, and go looking for a corruption in the block itself when the actual fix is a single command on the host drawing. A quick way to confirm it's a scale issue rather than a genuine missing linetype problem is to select the line and check its properties panel, if the linetype name still shows correctly as DASHED or HIDDEN rather than falling back to Continuous, you know the definition loaded fine and it's purely an LTSCALE value that needs adjusting, not the block or the linetype file itself.

A short standard worth adopting

Stick to a short approved list of SHX and common TrueType fonts across your whole block library, use only standard linetypes unless there's a strong specific reason not to, and if you do need a custom linetype, document and distribute the LIN file alongside the blocks that use it. None of this takes long to implement once, and it removes two of the three most common sources of this-looks-wrong-on-my-end messages for good, leaving you to actually worry about the geometry itself rather than chasing font and linetype ghosts.

It's a small enough standard that you can write it on a single page and it genuinely covers the majority of cross-software text and line rendering issues I've run into over the years, which is a better return than most drafting standards manage for the effort involved.