PDF Signing Mixed Dimension Clipping | Skills Pool
스킬 파일
PDF Signing Mixed Dimension Clipping
Diagnose SpotDraft signing-view bugs where the left side of a PDF is clipped, unreachable, or distorted during the signing phase even though preview or setup looks fine. Use when support reports mixed-size or wide PDF pages, signer-side content not visible on the left, navigation that can move down or right but not back to hidden left content, auto-navigation landing incorrectly on mixed-dimension pages, or mobile/desktop scaling regressions for PDFs with non-uniform page widths. Do not use for OnlyOffice DOCX preview bugs or backend send-for-signing failures.
SpotDraft0 스타2026. 3. 30.
직업
카테고리
문서
스킬 내용
Use this skill for the March 2026 symptom family where the signing UI renders a mixed-size PDF incorrectly and the signer cannot reach left-side content or fields.
The core pattern is:
document preview or setup may look acceptable
the actual signing view is broken
pages often have different widths or oversized first pages
there is usually no backend error, task failure, or API 500
Quick Routing
Use this skill when all or most of the following are true:
the issue happens in the signer-facing PDF signing view
the left side of the page is clipped, cropped, or unreachable
support says the document has varying page sizes, wide pages, or an A1-style page
navigation can move vertically but cannot recover hidden left-side content
signature fields on the left are inaccessible or auto-navigation lands incorrectly
Do not use this skill when:
the bug is OnlyOffice or DOCX preview specific and downloaded files look fine
use onlyoffice-preview-left-clipping
the main problem is send-for-signing, execution, document generation, provider failure, or corrupt versions
관련 스킬
use contract-signing-triage
the issue is a PDF upload artifact or conversion artifact before the signing experience
check pdf-upload-visual-artifacts
First Identifiers To Collect
workspace_id
contract_id
contract_version_id
cluster
affected signer name or recipient
whether preview looks correct while signing looks wrong
whether the PDF has mixed page widths or unusually wide first pages
whether support can reposition fields in setup as a temporary workaround
Jira / incident links if already created
For the Brick&Bolt incident, the key identifiers were:
If this is the symptom family, treat it as a client-side signing-view rendering problem first, not a backend signing pipeline failure.
Step 2: Rule Out The Wrong Failure Mode Quickly
Do not start with GCP logs or Groundcover unless the report also includes API failures, task failures, or UI error banners.
In the March 25, 2026 incident, the strongest signal was the absence of backend failures:
no API failure was described
no task failure was needed to explain the symptom
the failure point was the PDF viewer container and page rendering behavior
If preview is correct and only signing is wrong, prioritize frontend viewer behavior.
Step 3: Check For Mixed-Dimension PDF Geometry
This issue most often correlates with:
pages of different widths
oversized first pages
blueprint-style or drawing-heavy PDFs
documents where normalization or print-to-PDF changes behavior
The shipped frontend work treated this as a mixed-dimension rendering problem, not just a one-off field-position bug.
Step 4: Check Whether This Is Pre-Fix Or A Regression
Important dates:
incident opened on March 25, 2026
frontend fix merged on March 27, 2026 in angular-frontend PR #14899
support confirmed the fix had reached production on March 30, 2026
Use these references:
customer-impact ticket: SPD-42773
shipped frontend work: SPD-42617
commit: 0878f4b5dd86a517135136bbcbf01dcfab8d01ad
If a production report happens after March 30, 2026 and shows the same behavior, assume one of these until disproved:
regression against the mixed-dimension fix
incomplete rollout
stale browser state or cached assets
a new geometry variant not covered by the original fix
Step 5: Apply The Safe Mitigation
Use the least-destructive mitigation first:
move signature fields toward the right side where possible
ask the signer to use View Details from the three-dot menu for hidden content
If that is insufficient, consider PDF normalization only with explicit caveats.
The incident thread documented these risks for blueprint or drawing-heavy PDFs after print-to-PDF or similar normalization:
scale invalidation
loss of detail in thin lines or labels
aspect-ratio distortion
flattening of layers and metadata
If the customer relies on blueprint fidelity, prefer waiting for the permanent fix over forcing a normalized PDF unless they accept those tradeoffs.
Customer-Shareable RCA
Use this wording as the starting point and adapt only if the facts differ:
We identified a rendering issue in the signing interface for PDFs with non-uniform page dimensions. In affected documents, parts of the page on the left side could become inaccessible during signing even though the document content itself was intact. We implemented a frontend fix to improve how mixed-dimension PDFs are rendered in the signing experience and deployed it to production on March 30, 2026.
If the customer asks about temporary workarounds, add:
As an interim workaround before the fix reached production, signature fields could be moved toward the right side and hidden content could be viewed through the document details menu. For drawings or blueprint-style PDFs, we avoided recommending print-based normalization unless the customer accepted possible scaling or fidelity tradeoffs.
the shared scroll container selector .ng2-pdf-viewer-container
What The Shipped Fix Changed
PR #14899 described the production fix as:
forcing the mixed-dimension signing renderer into a stable zoomed mode
updating auto-navigation to use effective page height per page
handling mobile and desktop scale differently so content stays legible
fixing dynamic resize, font scaling, and field span behavior on mixed PDFs
That means a fresh incident should not be reduced to "just a CSS centering bug." Check all of these dimensions:
full-page rendering
left-side reachability
next-field auto-navigation
mobile readability
desktop scaling for oversized first pages
Regression Checklist
When verifying a suspected recurrence, test at minimum:
different-dimension PDFs
different zoom levels
different screen sizes
Acceptance criteria from the original pod-sign request:
the problematic mixed-dimension PDFs render completely in the signing flow
no new regressions appear in sign flows while zooming or resizing
auto-navigation still lands on the correct field
Related Incident Notes
The original Slack investigation explicitly treated this as different from prior PDF visibility incidents that had similar symptoms but different causes.
The support workaround was approved before the permanent fix landed.
The incident was mitigated after support verified the production fix on March 30, 2026.
Escalation Triggers
Escalate to the signing/frontend owners when:
the same left-clipping behavior appears on current production after March 30, 2026
auto-navigation is still wrong on mixed-size PDFs after the fix
the bug reproduces only on certain screen sizes or only on mobile
the document cannot be safely normalized because blueprint fidelity matters
the report starts resembling a new geometry or scaling class not covered by PR #14899