Your text matrix already contains the font size
TLDR: A text matrix maps a one-unit em box into place, so the scale is already in it. Setting font-size alongside it multiplies the two. If your extracted labels come out huge, and the ratio looks suspiciously like the font size itself, this is why.
The error
No exception. Extracted labels drew at about 44pt where the PDF says 6.66pt, turning a schematic into a wall of overlapping letters.
The ratio is the tell. 44.4 divided by 6.66 is 6.66. When the error factor equals the value you set, you applied it twice.
The bug class
A transform that encodes size, plus a separate size attribute, both applied to the same element.
It shows up wherever a system hands you a matrix that was built to place a normalised unit. Text matrices in PDF and PostScript. Sprite transforms in game engines. <use> on a symbol with its own viewBox. In each case the matrix already did the scaling, and the friendly-looking size parameter next to it is a second, redundant scale.
The concrete case
pdf.js gives each text item a transform in PDF user space. For a 6.66pt label:
{ str: "ATMEGA2560-15AU", transform: [6.66, 0, 0, 6.66, x, y], height: 6.66 }
The 6.66 in the matrix is the font size. PDF draws glyphs from a font whose em box is one unit; the text matrix is what makes it 6.66 units tall.
Composed with the page viewport transform, that stays 6.66. So the size is recoverable, and the obvious thing to do is recover it and use it:
const m = mul(viewportTransform, item.transform);
const size = Math.hypot(m[1], m[3]); // 6.66, correct
parts.push(
<text transform="matrix(${m[0]} ${m[1]} ${m[2]} ${m[3]} ${m[4]} ${m[5]}) scale(1,-1)" +
font-size="${size}">${item.str}</text>
);
Both halves are right. size is genuinely 6.66. The matrix is genuinely the correct placement. And SVG applies the matrix to an element that has already been laid out at font-size, so the glyphs are scaled to 6.66 and then scaled again by the matrix's 6.66.
Why it is easy to write
Because extracting the size feels like the careful thing to do. You resisted hardcoding a font size, you derived it from the data, and the number you derived is correct. It reads like the responsible version of the code.
The mistake is one level up: having derived the size, you are now obliged to remove it from the matrix, because the matrix is where you got it from.
The fix
Normalise the basis vectors and let font-size carry the scale on its own:
const size = Math.hypot(m[1], m[3]) || 8;
const n = [m[0] / size, m[1] / size, m[2] / size, m[3] / size];
parts.push(
<text transform="matrix(${n[0]} ${n[1]} ${n[2]} ${n[3]} ${m[4]} ${m[5]}) scale(1,-1)" +
font-size="${size}">${item.str}</text>
);
The translation components are untouched. Only the rotation and scale part is divided through, so rotation survives. That matters for the vertical net labels running up the side of a schematic.
The equivalent one-liner is to keep the raw matrix and write font-size="1". It is correct and it is what pdf.js's own SVG backend does, but every debugging session then starts with working out why the font size is 1.
The neighbouring trap
scale(1,-1) in that snippet is not decoration.
PDF text space has y pointing up; SVG has y pointing down. The viewport transform flips the page, which puts the baseline in the right place and leaves the glyphs mirrored. The local flip undoes that.
The version of this bug where you negate the y coordinate instead puts the text in the wrong place AND upside down, and the two errors partially disguise each other.
Preventing the class
Ask what unit the matrix maps. If it maps a normalised box, the size is in the matrix, and any size parameter you also set is a duplicate.
Check whether the error factor equals a value you supplied. 7x wrong when you passed 7 is not a coincidence, and it is faster to notice than to derive.
Test one known label end to end. Pick a string whose size you read out of the source file and assert the rendered size matches. Ours would have failed on the first assertion, and instead it took a screenshot to notice.