4v5u09Z5a4Yuc/ReadViewSDK
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs(08): create phase plans for image display fix and pagination cache

Browse Source 
3 plans covering QUAL-01 through QUAL-04:
- 08-01: pagination cache key + wiring into rendering pipeline
- 08-02: unified 1080x1920 max-size for all images, footnote width-only fix
- 08-03: pagination timing instrumentation

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
shen
2026-05-23 18:43:41 +08:00
co-authored by Claude Sonnet 4.6
parent 86e6922f7b
commit 22bb86959c
6 changed files with 287 additions and 51 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.planning/phases/08-pagination-quality-cache-performance/08-RESEARCH.md
+7 -7
View File
@@ -392,22 +392,22 @@ static func prepareHTMLElementForReaderRendering(
| A2 | WXRead's `_WRPostProcessElementTree` checks only width, not height, against maxSize (verified via decompiled source) | WXRead Reference | LOW — source code at line 680 confirms `originalSize.width > maxSize.width` |
| A3 | The `normalizeAttachmentDisplayIfNeeded` function at line 467-505 of RDEPUBTextRendererSupport.swift needs its footnote height override removed (per D-08/D-09) | Pitfall 4 | MEDIUM — if not removed, it will override the willFlushCallback changes |
## Open Questions
## Open Questions (RESOLVED)
1. **Should we also update `DTMaxImageSize` in `dtOptions()` from screen bounds to 1080x1920?**
1. **(RESOLVED) Should we also update `DTMaxImageSize` in `dtOptions()` from screen bounds to 1080x1920?**
- What we know: `dtOptions()` currently uses `UIScreen.main.bounds.insetBy(dx: 20, dy: 28).size` (~353x757)
- What's unclear: Whether changing this affects non-image attachments or has side effects
- Recommendation: Yes, update to `CGSize(width: 1080, height: 1920)`. This is the first-pass constraint at attachment creation time. The willFlushCallback block is the authoritative second pass. Aligning both to the same max size eliminates confusion.
- Resolution: Yes, update to `CGSize(width: 1080, height: 1920)`. This is the first-pass constraint at attachment creation time. The willFlushCallback block is the authoritative second pass. Aligning both to the same max size eliminates confusion. Plan 08-02 Task 1 includes this change.
2. **Should we auto-add `bodyPic` class to all images like WXRead does?**
2. **(RESOLVED) Should we auto-add `bodyPic` class to all images like WXRead does?**
- What we know: WXRead adds `bodyPic` class to every image in `_WRPostProcessElementTree`
- What's unclear: Whether ReadViewSDK's CSS rules depend on `bodyPic` being present for proper centering
- Recommendation: Not required for the immediate fix. The `replaceCSS` already handles `img, svg, video, canvas` with `max-width: 100%; height: auto`, and specific selectors like `.bodyPic img` for centering. Adding the class would be a nice-to-have for full WXRead alignment but is not blocking.
- Resolution: Not required for the immediate fix. The `replaceCSS` already handles `img, svg, video, canvas` with `max-width: 100%; height: auto`, and specific selectors like `.bodyPic img` for centering. Adding the class would be a nice-to-have for full WXRead alignment but is not blocking. Deferred to future WXRead alignment work.
3. **Should `normalizeAttachmentDisplayIfNeeded` (line 467-505) be updated or removed entirely?**
3. **(RESOLVED) Should `normalizeAttachmentDisplayIfNeeded` (line 467-505) be updated or removed entirely?**
- What we know: This function runs in `normalizeReadingAttributes` (post-willFlushCallback) and overrides footnote/cover sizes
- What's unclear: Whether removing the footnote path is sufficient, or whether the cover path should also be simplified
- Recommendation: Remove the footnote height override path (D-08). The cover path can remain as a fallback since it produces similar results to the `prepareHTMLElementForReaderRendering` cover block.
- Resolution: Remove the footnote height override path (D-08). The cover path can remain as a fallback since it produces similar results to the `prepareHTMLElementForReaderRendering` cover block. Plan 08-02 Task 1 includes the footnote path removal.
## Environment Availability