Migrate WebUI to EnvelopeGenerator.Server
Updated documentation to reflect the migration from WebUI to EnvelopeGenerator.Server, including a new "Documentation Catalog" in `AGENTS.md`. Adjusted route mappings, render modes, and directory structure for Blazor components. Revised coordinate system documentation and CSS for status colors to align with the new architecture. Updated YARP proxy and PDF.js configuration paths. Migrated `MIGRATION_PLAN.md` to modernize `EnvelopeGenerator.Service` with C# Worker Service equivalents. Updated `FORM_APPLICATION_CONTEXT.md` and `RECEIVER_PDF_VIEWER_CONTEXT.md` to reflect the new architecture and planned viewer integration. Fixed German translation issues in `fix-report-label-read-and-confirmed.md`. Standardized formatting and terminology across all files.
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# EnvelopeGenerator — Receiver PDF Viewer Context
|
||||
# EnvelopeGenerator — Receiver PDF Viewer Context
|
||||
|
||||
## Purpose
|
||||
This document summarizes the active receiver-side PDF viewing and signing experience so that other agents can understand the current implementation quickly without re-reading all related files.
|
||||
@@ -765,7 +765,7 @@ The migration should preserve this capability contract at the page level even if
|
||||
|
||||
### 8. Planned migration strategy
|
||||
|
||||
#### Phase 1 — Confirm the `DxPdfViewer` integration surface
|
||||
#### Phase 1 — Confirm the `DxPdfViewer` integration surface
|
||||
|
||||
Use `EnvelopeReceiverPage_DxPdfViewer.razor` as a reference and determine exactly what `DxPdfViewer` exposes for:
|
||||
|
||||
@@ -785,7 +785,7 @@ Key question:
|
||||
If yes, overlays can be positioned relative to the rendered page.
|
||||
If no, a wrapper-based approximation or alternative integration is required.
|
||||
|
||||
#### Phase 2 — Replace the main render surface in `EnvelopeReceiverPage.razor`
|
||||
#### Phase 2 — Replace the main render surface in `EnvelopeReceiverPage.razor`
|
||||
|
||||
The current custom `canvas + text layer + signature layer` block should be replaced with a `DxPdfViewer` host region while keeping:
|
||||
|
||||
@@ -798,7 +798,7 @@ The current custom `canvas + text layer + signature layer` block should be repla
|
||||
At this stage, only the main document display needs to work.
|
||||
Signature overlays may temporarily be disabled while the host geometry is established.
|
||||
|
||||
#### Phase 3 — Introduce a dedicated overlay host above `DxPdfViewer`
|
||||
#### Phase 3 — Introduce a dedicated overlay host above `DxPdfViewer`
|
||||
|
||||
The new viewer surface should be wrapped with a custom page container.
|
||||
|
||||
@@ -813,7 +813,7 @@ Planned structure:
|
||||
|
||||
The overlay layer must be independently controlled by our code and not depend on internal `PDF.js` DOM ids.
|
||||
|
||||
#### Phase 4 — Rebuild page/zoom geometry acquisition
|
||||
#### Phase 4 — Rebuild page/zoom geometry acquisition
|
||||
|
||||
Because the current implementation derives position using only `sig.x * scale`, the target implementation must determine:
|
||||
|
||||
@@ -829,7 +829,7 @@ At redraw time, the adapter must produce page-relative pixel coordinates for:
|
||||
|
||||
This should be centralized in one geometry function rather than scattered across multiple viewer actions.
|
||||
|
||||
#### Phase 5 — Move signature overlay state to a canonical model
|
||||
#### Phase 5 — Move signature overlay state to a canonical model
|
||||
|
||||
The current JavaScript keeps runtime state in:
|
||||
|
||||
@@ -849,7 +849,7 @@ Preferably:
|
||||
If necessary, applied signature state should be re-sendable from .NET after viewer redraw.
|
||||
That prevents losing visual signatures when page layout changes.
|
||||
|
||||
#### Phase 6 — Re-implement signature placeholder rendering on top of `DxPdfViewer`
|
||||
#### Phase 6 — Re-implement signature placeholder rendering on top of `DxPdfViewer`
|
||||
|
||||
The current implementation filters placeholders by:
|
||||
|
||||
@@ -868,7 +868,7 @@ Rendering rules to preserve:
|
||||
The existing scaling behavior uses `baseScale = 1.5` as the visual reference.
|
||||
That visual convention should be preserved initially unless a new normalized sizing model is intentionally introduced.
|
||||
|
||||
#### Phase 7 — Re-implement applied signature rendering on top of `DxPdfViewer`
|
||||
#### Phase 7 — Re-implement applied signature rendering on top of `DxPdfViewer`
|
||||
|
||||
The current applied signature overlay includes:
|
||||
|
||||
@@ -888,7 +888,7 @@ Required behavior:
|
||||
- applied signature repositions on page/zoom changes
|
||||
- applied signature is hidden when the user navigates to a different page
|
||||
|
||||
#### Phase 8 — Re-implement page navigation through a central page-change pipeline
|
||||
#### Phase 8 — Re-implement page navigation through a central page-change pipeline
|
||||
|
||||
The following actions must all converge into a single page navigation routine:
|
||||
|
||||
@@ -906,7 +906,7 @@ That routine must do all of the following in order:
|
||||
4. redraw placeholder overlays
|
||||
5. refresh signature navigation counter state
|
||||
|
||||
#### Phase 9 — Re-implement zoom through a central zoom-change pipeline
|
||||
#### Phase 9 — Re-implement zoom through a central zoom-change pipeline
|
||||
|
||||
The following actions must converge into one zoom update path:
|
||||
|
||||
@@ -926,7 +926,7 @@ That routine must:
|
||||
|
||||
The current implementation already treats redraw after zoom as mandatory. That must remain true.
|
||||
|
||||
#### Phase 10 — Preserve signature navigation independently from the viewer engine
|
||||
#### Phase 10 — Preserve signature navigation independently from the viewer engine
|
||||
|
||||
Current navigation logic is driven by the global ordered signature list and not by PDF rendering internals alone.
|
||||
|
||||
@@ -940,7 +940,7 @@ This behavior must remain engine-independent:
|
||||
|
||||
If `DxPdfViewer` changes scrolling mechanics, the `scrollToElement` / `scrollToButton` logic must be adapted, but the traversal rules must remain unchanged.
|
||||
|
||||
#### Phase 11 — Thumbnail sidebar should remain custom unless `DxPdfViewer` can match all current behavior
|
||||
#### Phase 11 — Thumbnail sidebar should remain custom unless `DxPdfViewer` can match all current behavior
|
||||
|
||||
The current sidebar is not just decorative. It also provides:
|
||||
|
||||
@@ -963,7 +963,7 @@ If `DxPdfViewer` cannot provide matching thumbnails directly, a hybrid solution
|
||||
|
||||
This still satisfies the requirement that `DxPdfViewer` becomes the main viewer technology.
|
||||
|
||||
#### Phase 12 — Keep signature capture popup unchanged unless integration forces a minimal adjustment
|
||||
#### Phase 12 — Keep signature capture popup unchanged unless integration forces a minimal adjustment
|
||||
|
||||
`receiver-signature.js` and the popup flow should remain mostly untouched.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user