Blog · DXF · 1 Oct 2026 · 6 min read

Why dimensions change size when you paste DXF drawings into one file, and the fix

Paste several DXF drawings into one sheet and the dimensions change: text bigger or smaller, arrows huge, dimensions stuck to the part. Nothing is broken. A DXF dimension carries the name of its style, not the values. The mistake that cost us a month, and the per-drawing style name that fixed it.

Short answer: a DXF dimension does not carry the values of its style. It carries the name. When you paste drawings into another file, the CAD program looks for that name in the destination and applies whatever values it finds there. If twenty drawings all use a style called Default (ISO), the first definition imported wins and the other nineteen get its settings. Give each drawing's dimension style a name of its own (for example the style name plus the drawing code) before merging.

This one cost us a month of failed attempts. Here is the whole story, so your AI agent does not repeat it.

The symptom

The words we heard: "when I paste the drawings into the booklet the style changes: the dimensions are no longer spaced from the edge, they're stuck on, and the text style changes."

Variants of the same problem:

• the text of a small part grows after pasting;
• the text of a large part shrinks;
• the dimensions touch the part outline;
• move one dimension and its arrows become huge, while the text stays right, so no text check notices.

The cause, measured

We compared the same style name in a drawing exported from Inventor and in the destination file:

dimexo = 0 is exactly "stuck to the edge". And the colliding name was the most common one there is: Inventor's default.

Two more facts make it worse:

• The visible height is dimtxt x dimscale. Inventor writes DIMSCALE = 1 / view scale, so it is different on every drawing. Our own 20 drawings had dimscale from 0.585 to 18.629 under one name. On one small part the text would have gone from 4.1 to 23.8, nearly six times.
• Exported dimensions are frozen inside an anonymous *D block. Changing the style does not redraw them until something regenerates them. That is why the damage shows up later, when someone moves a dimension.

The destination file had 50 dimension styles, many called ...$7, ..._F7, ..._F8: clones the CAD program makes on paste when it meets a name conflict.

Why it took a month

Every attempt changed dimtxt: 3.0, then 30, then 12.5, then 7. Six rounds of the drawing rule, one number at a time. The number that mattered was dimscale, and the cause was the name. Measuring both files, done at the end, gave the answer in ten minutes.

Lesson for the agent: before changing a value, measure the source and the destination and compare them. Don't tune.

The fix: one style name per drawing

After export, a Python script with ezdxf renames the dimension style in each DXF, using the drawing code, not a counter: Dimensions_TAV_P-055. A name taken from the file survives reordering. It is also what the destination file was already doing by hand, with one style per scale.

def rename_dimstyle(doc, old, new):
    table = doc.dimstyles
    if not table.has_entry(old):
        return False
    entry = table.get(old)
    entry.dxf.name = new
    table.discard(old)        # without discard + add_entry, get(new) fails:
    table.add_entry(entry)    # the table index still has the old name
    return True

for dim in doc.modelspace().query("DIMENSION"):
    if dim.dxf.dimstyle == old:
        dim.dxf.dimstyle = new

Rename the child styles too (names ending in $7 and similar). Without discard and add_entry, get(new) raises DXFTableEntryError. It looks like a damaged file. It is the table index.

Result, measured: drawings whose text height changed compared with the single DXF: 0. Drawings whose content changed: 0 out of 20 (952 drawn elements).

When the dimensions were drawn by the client

There is a second case. If the dimensions you are pasting were drawn in the destination's own style (for example, cells drawn by hand in the client's template), renaming is wrong. The fix is the opposite: set the same default style in the destination before pasting. When the CAD program finds the same name with the same values, everything pastes unchanged. Bring along the style's text style and its arrowhead blocks (dimblk, dimblk1, dimblk2, dimldrblk), or ezdxf fails when writing.

So the first question is always: where were these dimensions made? Exported from Inventor: one name per drawing. Drawn in the destination's style: copy the style across first.

We did not ask that question once, and rebuilt the collision we had already paid for. Three attempts, all wrong.

What does not work

Same name, different values: compare before renaming

When merging the client's own sheets, the agent compares the values behind the name and renames only if they differ:

KEYS = ("dimtxt", "dimtxsty", "dimscale", "dimasz", "dimexe", "dimexo",
        "dimgap", "dimdec", "dimlfac", "dimclrt", "dimtad",
        "dimblk", "dimblk1", "dimblk2", "dimldrblk")

existing = doc_out.dimstyles.get(name)
same = all(src.dxf.get(k, None) == existing.dxf.get(k, None) for k in KEYS)
if not same:
    own = f"{name}_{suffix}"
    if own not in doc_out.dimstyles:
        copy_dimstyle(doc_out, doc_in, src, own)
    dim.dxf.dimstyle = own

Seven client sheets all named their style the same, with dimscale 15, 15, 15, 10, 25, 20 and 15.

The rule behind it

In one DXF, a name can mean only one thing. That holds for dimension styles, text styles and blocks. "If the name exists, skip it" is the shortcut that produces all three collisions. Blocks have the same problem: sections and weld symbols in the wrong place.

Do and don't

Do

• Measure the style values in source and destination before changing anything.
• Name dimension styles per drawing, from the drawing code.
• Compare values, not names, before reusing a style.
• Check the result: text height and content per drawing, before and after the merge.

Don't

• Don't tune dimtxt by trial and error.
• Don't leave Inventor's Default (ISO) name on exported drawings.
• Don't rewrite the *D blocks by hand.
• Don't explode drawings to dodge the problem.

Questions people ask

Why does the problem appear only after I move a dimension? The exported dimension is frozen in its block. The CAD program redraws it with the destination style only when something regenerates it.

Can an AI agent fix files already merged? It is far easier before the merge. After, the agent has to find which dimension came from which drawing, and that information may be lost.

Does this happen with AutoCAD as well as Inventor exports? The mechanism belongs to the DXF format: any file whose dimensions refer to a style by name. We saw it with Inventor exports pasted into client files.