cesnimda
3.2 KiB
S01 root cause — initial verified findings
Baseline26d531c; application/renderer/font/preview sources unchanged from5032ccb. Original goldens and2mm oracle are untouched. This diagnosis does not accept a new reference or close the existing PDF gate.
Every revised failure is explained by an incorrect test assumption: scripts/verify-cv-fidelity.py compares DOM Range.getClientRects().top with pdfplumber/pdfminer's word.top. These are different metric boxes. DOM Range uses the browser font ascent/descent; installed pdfminer builds a one-em character cell from the PDF descriptor's descent, rather than the DOM ascent or actual glyph outline. Neither top is the visible glyph top.
The installed primary sources are pdfminer.layout.LTChar.__init__ (horizontal bbox from descent and fontsize) and pdfminer.pdffont.PDFFont.__init__ (normalises positive descriptor descent to negative). Actual native PDF text matrices and descriptors, current browser DOM ranges, an inline zero-height baseline sentinel and independent canvas ascent were measured. In all36 documents on each platform, sentinel/canvas baselines agree without changing geometry; the descent-cell formula reproduces the original S01 discrepancy to less than0.01px.
The initial unchanged corpora reproduce 28 Windows /20 Linux failures, all S01-only. Actual baseline differences are at most 0.2232mm Windows /0.4878mm Linux, within the existing2mm physical bound; separate actual-raster name-ink differences are at most3px. These are diagnostic results, not an approved replacement gate. Font sizes, marker/page membership, other marker positions, completeness/bounds and full-height sidebars remain independently checked.
Windows and Linux emit different descriptor metadata for the same bundled fonts. For Selawik-Bold the measured Windows ascent/descent is1079.10156/+250.97656, Linux989.74609/−210.44922; Roboto-Bold also differs. Arimo/Gelasio/Poppins descent magnitudes agree, while signs and some other metadata differ. The formula normalises signs as the installed extractor does. Some actual baseline rounding differs by about1px too, but does not explain the multi-mm cell-top discrepancy. Linux's smaller descent-cell offset takes the four technical and four nordic documents below the original cutoff; code/modern/executive/elegant remain above it. The final per-document report must verify these sets from actual fresh results, not assume this initial count.
No layout change is justified merely to force unequal coordinate conventions to agree: it would move correctly aligned visible text or alter intended title sizing. No clipping, lost content, misplaced photo/sidebar or pagination defect was established by these S01 failures. Finite automated findings do not establish human typography/whitespace/print acceptance.
Remediation proposed for owner decision: retain the historical oracle and results; adopt a like-for-like native text-baseline diagnostic with the same2mm bound for revised S01, alongside actual-raster evidence and all existing font/content/page/color/other-marker checks. Keep this supplementary until explicit approval. No golden regeneration, arbitrary threshold increase, renderer change or automatic Phase10 entry is performed.