The drawing comparison marks every sheet as changed

If a comparison between two issues comes back with differences on every sheet, the most likely explanation is that the two files are not being read in the same coordinate space, or not being drawn by the same renderer. The tool is reporting pixels that moved rather than content that changed. Set-wide reissues are real and they do happen, but they are the rarer case, and one test tells you which of the two you are looking at.

The failure is self-concealing, which is what makes it expensive. Nobody reads a change list with 400 entries, so the list gets ignored and the one sheet where a beam moved is ignored with it. Within two issues the team is back to reading revision clouds by eye.

Run it first on sheets you know did not change

The whole diagnosis rests on having a known-clean pair. Pick the sheets from the drawing register rather than from the comparison output, because a sheet the tool skipped will not appear in its own results.

1. Choose three sheets whose revision tables carry no new entry between the two issues, and make them different in kind: one architectural plan, one services sheet from a different consultant, one detail sheet.
2. Compare each pair on its own, outside the batch run, so nothing is inherited from a set-level alignment.
3. Record where the flagged regions sit rather than how many there are. Whole sheet, one edge, the title block band only, or text only are four different diagnoses.
4. Zoom one flagged region to 400 percent and decide whether the geometry differs or only its rendering — a line in a different weight, a fill in a different pattern, a substituted font.
5. Read the producer metadata on both files in the document properties. Two different producing applications between issues is the single most common cause of rendering-only noise.
6. Repeat the comparison with the two sheets forced to the same paper size. If the noise disappears, you had a scale mismatch and nothing else.

Clean control sheets mean the tool is aligning correctly and the differences on the other sheets are content, at which point the work is triage rather than repair. Noisy control sheets mean registration or rendering, and every minute spent tuning a sensitivity slider before fixing that is wasted.

The millimetre that flags an entire sheet

Scale mismatch produces a different and very recognisable signature. If one issue was distributed at full size and the next as half-size prints, the linear scale is 50 percent — A1 to A3, or ANSI D to ANSI B — and a comparison that anchors at one corner shows almost no difference there and tens of millimetres of it at the opposite corner. Differences that grow across the diagonal are a paper-size problem every time. A uniform shift with no growth is a crop-box or margin difference instead, and both are fixed by registering on something the sheet actually guarantees: the border, or two opposite corners of the title block, which is the only metadata on a sheet set you can rely on.

Same geometry, different pixels

The second family of noise has nothing to do with position. The two sheets are aligned perfectly and still differ everywhere, because they were made into PDFs by different means.

• The producing application changed. One issue was published from the CAD or BIM tool directly, the next was printed through a PDF writer on someone's laptop. Line joins, hatch spacing and text kerning all shift slightly, and a pixel comparison reports every one of them.
• One issue is rasterised. A reissued sheet that came back as a scan has no vector geometry left to compare, so the difference is between drawn lines and a photograph of drawn lines. The resolution and skew thresholds that decide whether that file is usable at all are in extraction that works on issued sheets and fails on scans.
• Fonts were not embedded. The viewer substitutes whatever it has, every text string changes width, and room names, notes and dimension text all flag while the geometry beneath them is untouched.
• Annotation layers were flattened differently. An issue exported with markup or viewport layers visible carries geometry the other does not, and it will be flagged as added content because that is exactly what it is.
• The sheet was rotated or mirrored on export. Rare, obvious once seen, and everything differs.

The differences that are real and still worth nothing

A third group survives perfect alignment and identical rendering, because the geometry genuinely did change — just not in any way a trade needs to know about.

• Revision clouds and delta markers. They are new linework added specifically to advertise a change, so they are flagged as content. They are the most useful annotation on the sheet and the noisiest thing in a diff.
• The title block issue row. A set reissued as a whole gets a new date, revision letter and often a new purpose-of-issue stamp on every sheet, which is a real difference on all of them simultaneously.
• Approval and status stamps. A sheet moving from tender issue to construction issue changes visibly without a single dimension moving.
• Drawn-by, checked-by and scale-bar blocks, which change when the consultant reassigns work rather than when the design moves.
• Sheet indexes and key plans, which change on every issue by design and which no subcontractor prices differently.

The fix here is region filtering rather than threshold tuning: exclude the title block band and the revision column from the difference count, and count clouds separately as a signal rather than as content. Filtering is not deletion. The excluded regions still belong in the record of what was issued, because that record is what a drawing transmittal has to prove later.

A comparison that flags everything is not being cautious. It is telling you that it never managed to line the two sheets up.

Reading the pattern: which of the five problems you have

The last row is the one no configuration change improves. A consultant who reissues a full set for two corrected details is following normal practice, and the comparison is reporting the truth. What you can still do is reduce what a human reads: sort sheets by changed area, drop anything under a threshold you set once — 2 to 3 percent of sheet area is a workable starting point — and route the rest to the discipline that owns it.

What a correct comparison still will not give you

Even with clean registration and filtered regions, the output is a set of changed pixels grouped into rectangles. It is not a change list. It does not know that a moved duct means a coordination clash, that a changed schedule row means a product substitution, or that a specification section changed with no drawing revision at all. Turning a difference set into something a project team acts on is a separate job, and comparing two issues of a sheet set into a change list people will act on is the method for it. It does nothing either about what happens after the list is published: a change identified and not written to the one place everyone reads is the same single-write-path failure behind a submittal log that says approved while the inbox says otherwise.

The durable version of this is small and scheduled rather than a platform: on receipt of an issue, match sheets to the previous one, run the comparison with the registration and region rules already set, score each sheet for noise, and email the project manager the sheets that changed materially plus any sheet the tool could not align. That last category is the one worth alerting on, because a sheet that failed to align silently is indistinguishable from a sheet with no changes. It is the same shape of build as a delivery booking system that still leaves trucks queueing at the gate — the data existed, the report that made it actionable did not — and the kind of narrow work we scope under internal tools and ops. This page sits inside drawings, specs and construction document intelligence, within our construction and contracting work.

• revisions
• sheet sets
• document ai
• drawing comparison