# Phase 8: 图片显示修复 - Research

**Researched:** 2026-05-23
**Domain:** DTCoreText image attachment sizing, WXRead alignment
**Confidence:** HIGH

## Summary

Phase 8 plan 08-02 focuses on fixing image display in the native text rendering path (DTCoreText). Three image types have sizing issues: (1) `qrbodyPic` images can overflow page height because no max size constraint is applied, (2) cover images use screen-size baselines but lack a unified ceiling, (3) footnote images have inconsistent height calculations across three separate code paths.

The core fix is to add a unified maximum size constraint (`CGSize(width: 1080, height: 1920)`) to ALL image attachments in `prepareHTMLElementForReaderRendering`, applied BEFORE any type-specific handling. This directly mirrors WXRead's `_WRPostProcessElementTree` approach. The fix is surgical: one new code block at the top of the existing function, plus removal of redundant height logic in two other locations.

**Primary recommendation:** Add a unified max-size block at the top of `prepareHTMLElementForReaderRendering` that constrains all images to 1080x1920 via aspect-ratio-preserving scaling. Then simplify footnote handling to width-only (no explicit height), matching WXRead's `replace.css`.

<user_constraints>
## User Constraints (from CONTEXT.md)

### Locked Decisions
- **D-01:** Unified max image size `CGSizeMake(1080, 1920)` for all image attachments
- **D-02:** Scale proportionally when exceeding max width (matching WXRead `_WRPostProcessElementTree`)
- **D-03:** Implementation location: `prepareHTMLElementForReaderRendering`, BEFORE existing footnote/cover special handling
- **D-04:** Cover images keep screen-size base (`UIScreen.main.bounds.insetBy(dx: 20, dy: 28)`), constrained by unified max
- **D-05:** Keep `configureCoverIfNeeded` UIImageView path unchanged
- **D-06:** Cover images still processed via cover branch in `prepareHTMLElementForReaderRendering`, but must not exceed unified max
- **D-07:** Footnote images: only set `width:1em`, no height (align with WXRead `replace.css`)
- **D-08:** Remove footnote height calculation in `prepareHTMLElementForReaderRendering` (`pointSize * 0.54`)
- **D-09:** Remove height override in `normalizeInlineAttachments` (`pointSize * 0.14`)
- **D-10:** Keep CSS `width:1em` in `normalizeAttachmentHTMLMarkers`, remove `height:1em`
- **D-11:** No special handling for `qrbodyPic` — unified max size implicitly fixes overflow
- **D-12:** Keep existing CSS rules for `qrbodyPic` unchanged

### Claude's Discretion
- Whether to auto-add `bodyPic` class to all images (like WXRead does)
- Whether `wr-vertical-center-style` semantic marker is needed (Phase 7 already handles this)
- Specific implementation details of the unified max-size block

### Deferred Ideas (OUT OF SCOPE)
- Image caching mechanism (belongs to plan 08-01)
- `wr-vertical-center-style` full implementation (Phase 7 already completed)
- Image tap-to-zoom feature (new capability, not in scope)
</user_constraints>

<phase_requirements>
## Phase Requirements

| ID | Description | Research Support |
|----|-------------|------------------|
| QUAL-01 | Cache layout frame / pagination results | Not in scope for 08-02 (belongs to 08-01) |
| QUAL-02 | Improve pagination quality for complex illustrated chapters — reduce bad page breaks, orphan/widow lines, abnormal whitespace around images | Image sizing fix directly addresses image-related pagination quality |
| QUAL-03 | Image/attachment sizing strategy, dark mode adaptation, page background — must have verifiable processing rules, not rely on DTCoreText defaults | Unified max size + explicit CSS rules provide verifiable rules |
| QUAL-04 | Pagination improvements must not significantly degrade first-screen time, re-pagination time, or interaction smoothness | Image sizing is a lightweight operation in willFlushCallback, negligible performance impact |
</phase_requirements>

## Architectural Responsibility Map

| Capability | Primary Tier | Secondary Tier | Rationale |
|------------|-------------|----------------|-----------|
| Image max-size constraint | Swift `willFlushCallback` (renderer) | CSS `replaceCSS` | Swift handles absolute pixel ceiling; CSS handles responsive width |
| Footnote image sizing | CSS (`width:1em` in HTML preprocessing) | Swift (vertical alignment) | CSS controls width; Swift only sets alignment |
| Cover image sizing | Swift (`prepareHTMLElementForReaderRendering`) | `configureCoverIfNeeded` (view layer) | Swift constrains in attributed string; view layer only extracts for UIImageView display |
| Page-break control around images | Layouter (pagination) | CSS (`page-break-inside: avoid`) | Layouter decides actual breaks; CSS provides hints |

## Standard Stack

### Core
| Library | Version | Purpose | Why Standard |
|---------|---------|---------|--------------|
| DTCoreText | (CocoaPod, project-local) | HTML/CSS to NSAttributedString | Existing project dependency; provides `DTTextAttachment`, `willFlushCallback` |
| UIKit | iOS SDK | `UIScreen.main.bounds` for cover sizing | Platform standard |

### Supporting
| Library | Version | Purpose | When to Use |
|---------|---------|---------|-------------|
| Foundation | iOS SDK | `NSRegularExpression` for HTML preprocessing | Already used throughout `RDEPUBTextRendererSupport` |

### Alternatives Considered
| Instead of | Could Use | Tradeoff |
|------------|-----------|----------|
| Swift-side max size in `willFlushCallback` | CSS `max-height` in `replaceCSS` | CSS approach is simpler but DTCoreText CSS parser may not support `max-height` reliably for attachments; Swift is authoritative |
| Removing `DTMaxImageSize` from builder options | Keeping both layers | Keeping both is safer — DTMaxImageSize is the first line of defense at attachment creation time; willFlushCallback is the second pass |

## Package Legitimacy Audit

No new packages are installed in this phase. All changes are to existing Swift source files.

| Package | Registry | Age | Downloads | Source Repo | slopcheck | Disposition |
|---------|----------|-----|-----------|-------------|-----------|-------------|
| (none) | — | — | — | — | — | No new packages |

## Architecture Patterns

### Current Image Processing Pipeline

```
HTML input
  |
  v
normalizeAttachmentHTMLMarkers()     <-- HTML regex: adds inline styles to <img> tags
  |                                      (footnote: width:1em;height:1em)
  |                                      (cover: adds rd-front-cover-image class)
  v
DTHTMLAttributedStringBuilder        <-- Creates DTTextAttachment with DTMaxImageSize
  |                                      (currently screenBounds.size, ~353x757)
  |                                      DTCoreText sets displaySize = min(original, max)
  v
willFlushCallback                    <-- prepareHTMLElementForReaderRendering()
  |                                      Currently: footnote → height calc, cover → screen scale
  |                                      MISSING: unified max-size for ALL images
  v
normalizeReadingAttributes()         <-- normalizeAttachmentDisplayIfNeeded()
  |                                      Currently: footnote → height override (0.14*pt)
  |                                      cover → maxWidth override
  v
configureCoverIfNeeded()             <-- View layer: extracts cover image for UIImageView
  |
  v
normalizeInlineAttachments()         <-- View layer: footnote → height override (0.14*pt)
```

### Recommended Pipeline After Fix

```
HTML input
  |
  v
normalizeAttachmentHTMLMarkers()     <-- CHANGED: footnote <img> only gets width:1em (no height)
  v
DTHTMLAttributedStringBuilder        <-- CHANGED: DTMaxImageSize → CGSizeMake(1080, 1920)
  v
willFlushCallback                    <-- prepareHTMLElementForReaderRendering()
  |                                      NEW: unified max-size block for ALL images first
  |                                      THEN: footnote → only verticalAlignment + inline
  |                                      THEN: cover → screen-size scale (capped by max)
  v
normalizeReadingAttributes()         <-- normalizeAttachmentDisplayIfNeeded()
  |                                      CHANGED: footnote path removed (no height override)
  |                                      cover path can remain as fallback
  v
configureCoverIfNeeded()             <-- UNCHANGED
  v
normalizeInlineAttachments()         <-- CHANGED: footnote height override removed
```

### Pattern 1: Unified Max-Size Block in `prepareHTMLElementForReaderRendering`

**What:** A new code block at the top of the function, before any type-specific handling, that constrains ALL image attachments to 1080x1920.

**When to use:** Every image attachment that enters `willFlushCallback`.

**Example:**
```swift
// Source: WXRead WREpubTypesetter.m §672-701 (_WRPostProcessElementTree)
// Placed BEFORE existing footnote/cover handling in prepareHTMLElementForReaderRendering

static func prepareHTMLElementForReaderRendering(
    _ element: DTHTMLElement,
    style: RDEPUBTextRenderStyle
) {
    guard let attachment = element.textAttachment else { return }

    // --- NEW: Unified max image size (aligns with WXRead _WRPostProcessElementTree) ---
    let maxImageSize = CGSize(width: 1080, height: 1920)
    let originalSize = attachment.originalSize
    if originalSize.width > maxImageSize.width || originalSize.height > maxImageSize.height {
        let scale = min(maxImageSize.width / max(originalSize.width, 1),
                        maxImageSize.height / max(originalSize.height, 1))
        attachment.displaySize = CGSize(
            width: round(originalSize.width * scale),
            height: round(originalSize.height * scale)
        )
    }

    // ... existing footnote/cover handling follows ...
}
```

### Pattern 2: Footnote Width-Only Sizing

**What:** Footnote images get `width:1em` in HTML preprocessing, with no explicit height. DTCoreText calculates height from aspect ratio.

**When to use:** In `normalizeAttachmentHTMLMarkers` for `qqreader-footnote` images.

**Example:**
```swift
// Source: WXRead replace.css §100-103 (.qqreader-footnote { width: 1em; })
// Changed: removed "height:1em" from styleFragments

normalized = replaceMatches(
    using: footnoteRegex,
    in: normalized
) { tag in
    mergeHTMLAttributes(
        into: tag,
        requiredClass: nil,
        styleFragments: [
            "width:1em",
            // "height:1em"  <-- REMOVED per D-10
            "vertical-align:middle",
            "display:inline-block"
        ]
    )
}
```

### Anti-Patterns to Avoid

- **Separate max-size blocks for each image type:** WXRead applies one unified block to ALL images. Do not duplicate the scaling logic for qrbodyPic, cover, and footnote separately.
- **Removing `DTMaxImageSize` from builder options:** The DTCoreText-level max size is the first line of defense (applied during attachment creation). The `willFlushCallback` max size is the second pass. Keep both.
- **Setting explicit height on footnote images:** WXRead only sets `width:1em` on `.qqreader-footnote`. DTCoreText's `setDisplaySize:withMaxDisplaySize:` handles width-only cases by calculating height from aspect ratio (line 231-236 of DTTextAttachment.m).

## Don't Hand-Roll

| Problem | Don't Build | Use Instead | Why |
|---------|-------------|-------------|-----|
| Aspect ratio calculation | Custom scaling math | DTCoreText's `DTCGSizeThatFitsKeepingAspectRatio` or the existing `min(w/maxW, h/maxH)` pattern | Consistent with DTCoreText internals |
| Image type detection | New classification system | Existing CSS class + filename detection (`lowercasedClasses`, `lowercasedPath`) | Already works, battle-tested in Phase 7 |

## Common Pitfalls

### Pitfall 1: DTMaxImageSize vs willFlushCallback Ordering
**What goes wrong:** If the max-size constraint is only in `willFlushCallback`, DTCoreText's initial `setDisplaySize:withMaxDisplaySize:` uses the old (screen-size) max. The `willFlushCallback` then overrides it. This works but the intermediate state could confuse debugging.
**Why it happens:** DTMaxImageSize is consumed at attachment creation time; willFlushCallback runs after.
**How to avoid:** Update BOTH: change `DTMaxImageSize` in `dtOptions()` to `CGSize(width: 1080, height: 1920)` AND add the max-size block in `prepareHTMLElementForReaderRendering`. The willFlushCallback block is the authoritative constraint; DTMaxImageSize is the first-pass optimization.
**Warning signs:** If only one is updated, images may briefly appear at wrong size before being corrected.

### Pitfall 2: Footnote Aspect Ratio Without Explicit Height
**What goes wrong:** After removing `height:1em` from HTML preprocessing AND removing the height calculation in `prepareHTMLElementForReaderRendering`, footnote images might render with incorrect aspect ratio if `originalSize` is not available.
**Why it happens:** Some images in EPUBs may not have `width`/`height` attributes, so `originalSize` could be `CGSizeZero`.
**How to avoid:** DTCoreText's `setDisplaySize:withMaxDisplaySize:` (line 218-237 of DTTextAttachment.m) handles the case where `originalSize` has width but not height (and vice versa) by calculating from aspect ratio. If `originalSize` is completely zero, the image falls back to the `DTMaxImageSize` constraint. This should be safe, but verify with the demo sample.
**Warning signs:** Footnote images appearing at 0x0 or unreasonably large sizes.

### Pitfall 3: Cover Image Double-Scaling
**What goes wrong:** The unified max-size block scales the image, then the cover-specific block scales it again, resulting in an image that's too small.
**Why it happens:** Two sequential scaling operations compound.
**How to avoid:** The cover-specific block in `prepareHTMLElementForReaderRendering` already uses `UIScreen.main.bounds.insetBy(dx: 20, dy: 28)` as its max, which is approximately 353x757 points. This is SMALLER than 1080x1920. So the unified max-size block will be a no-op for cover images (they're already within bounds). The cover block then applies its own tighter constraint. This is correct behavior — no double-scaling occurs.
**Warning signs:** Cover images appearing smaller than expected.

### Pitfall 4: normalizeAttachmentDisplayIfNeeded Still Overrides
**What goes wrong:** After fixing `prepareHTMLElementForReaderRendering`, the `normalizeAttachmentDisplayIfNeeded` function (called from `normalizeReadingAttributes`) still overrides footnote and cover sizes.
**Why it happens:** This function runs AFTER `willFlushCallback` in the pipeline.
**How to avoid:** Per D-08/D-09, remove the footnote height override in this function too. The cover path in this function can remain as a fallback (it uses `maxWidth = max(UIScreen.main.bounds.width - 48, font.lineHeight * 8)` which is similar to the cover block in `prepareHTMLElementForReaderRendering`).
**Warning signs:** If footnote images still appear at wrong size after the fix, this function is the likely culprit.

## Code Examples

### WXRead Reference: _WRPostProcessElementTree (Objective-C)

```objc
// Source: Doc/WXRead/decompiled/WREpubTypesetter.m §672-701
if (element.textAttachment) {
    DTTextAttachment *attachment = element.textAttachment;

    CGSize maxSize = CGSizeMake(1080, 1920);
    NSNumber *maxW = options[@"maxImageWidth"];
    if (maxW) maxSize.width = maxW.floatValue;

    if (attachment.originalSize.width > maxSize.width) {
        CGFloat scale = maxSize.width / attachment.originalSize.width;
        attachment.displaySize = CGSizeMake(
            attachment.originalSize.width * scale,
            attachment.originalSize.height * scale
        );
    }

    element.textAttachment.attributes = @{
        WREpubTypesetterVerticalCenterStyleAttribute: @(2)
    };
    [element addClass:@"bodyPic"];
}
```

**Key observations:**
1. Max size is applied to ALL images, unconditionally (no class check)
2. Only width is checked against max (`originalSize.width > maxSize.width`), not height
3. `bodyPic` class is auto-added to every image
4. `wr-vertical-center-style: 2` is set on every image

### DTCoreText's setDisplaySize:withMaxDisplaySize: (Objective-C)

```objc
// Source: ReadViewDemo/Pods/DTCoreText/Core/Source/DTTextAttachment.m §216-245
- (void)setDisplaySize:(CGSize)displaySize withMaxDisplaySize:(CGSize)maxDisplaySize {
    if (_originalSize.width!=0 && _originalSize.height!=0) {
        if (displaySize.width==0 && displaySize.height==0) {
            displaySize = _originalSize;
        } else if (displaySize.width==0 && displaySize.height!=0) {
            CGFloat factor = _originalSize.height / displaySize.height;
            displaySize.width = round(_originalSize.width / factor);
        } else if (displaySize.width!=0 && displaySize.height==0) {
            CGFloat factor = _originalSize.width / displaySize.width;
            displaySize.height = round(_originalSize.height / factor);
        }
    }
    if (maxDisplaySize.width>0 && maxDisplaySize.height>0) {
        if (maxDisplaySize.width < displaySize.width || maxDisplaySize.height < displaySize.height) {
            displaySize = DTCGSizeThatFitsKeepingAspectRatio(displaySize, maxDisplaySize);
        }
    }
}
```

**Key observation for footnote width-only approach:** When `displaySize.width != 0` and `displaySize.height == 0`, DTCoreText calculates height from the aspect ratio. This means setting only `width:1em` in CSS (which translates to a display width) will automatically produce correct height. This confirms D-07 is safe.

### Recommended: Updated prepareHTMLElementForReaderRendering

```swift
// Source: Sources/RDReaderView/EPUBTextRendering/RDEPUBTextRendererSupport.swift §217-262
static func prepareHTMLElementForReaderRendering(
    _ element: DTHTMLElement,
    style: RDEPUBTextRenderStyle
) {
    guard let attachment = element.textAttachment else { return }

    // --- NEW: Unified max image size (WXRead alignment) ---
    let maxImageSize = CGSize(width: 1080, height: 1920)
    let originalSize = attachment.originalSize
    if originalSize.width > 0, originalSize.height > 0,
       (originalSize.width > maxImageSize.width || originalSize.height > maxImageSize.height) {
        let scale = min(maxImageSize.width / originalSize.width,
                        maxImageSize.height / originalSize.height)
        attachment.displaySize = CGSize(
            width: round(originalSize.width * scale),
            height: round(originalSize.height * scale)
        )
    }

    let lowercasedClasses = (((attachment.attributes["class"] as? String)
        ?? (element.attributes["class"] as? String) ?? "")).lowercased()
    let lowercasedPath = attachment.contentURL?.lastPathComponent.lowercased()
        ?? ((attachment.attributes["src"] as? String)
        ?? (element.attributes["src"] as? String) ?? "").lowercased()
    let pointSize = max(element.fontDescriptor.pointSize, style.font.pointSize)

    // Footnote: width-only sizing, no explicit height (WXRead alignment)
    if lowercasedClasses.contains("qqreader-footnote") || lowercasedPath == "note.png" {
        attachment.verticalAlignment = .center
        element.displayStyle = .inline
        // Note: NO height calculation here. Width is set via HTML preprocessing
        // (normalizeAttachmentHTMLMarkers adds width:1em). DTCoreText calculates
        // height from aspect ratio automatically.
        if !didLogFootnoteAttachment {
            didLogFootnoteAttachment = true
            print("[EPUB][Attachment] footnote classes=\(lowercasedClasses) path=\(lowercasedPath) original=\(string(from: originalSize)) display=\(string(from: attachment.displaySize)) font=\(pointSize)")
        }
        return
    }

    // Cover: screen-size base, already constrained by unified max above
    if lowercasedClasses.contains("rd-front-cover-image") || lowercasedPath == "cover.jpg" {
        let maxSize = UIScreen.main.bounds.insetBy(dx: 20, dy: 28).size
        let currentOriginalSize = attachment.originalSize
        if currentOriginalSize.width > 0, currentOriginalSize.height > 0 {
            let scale = min(maxSize.width / currentOriginalSize.width, maxSize.height / currentOriginalSize.height)
            if scale < 1.0 {  // Only re-scale if larger than screen
                attachment.displaySize = CGSize(
                    width: round(currentOriginalSize.width * scale),
                    height: round(currentOriginalSize.height * scale)
                )
            }
        } else {
            attachment.displaySize = CGSize(width: round(maxSize.width), height: round(maxSize.height))
        }
        attachment.verticalAlignment = .baseline
        element.displayStyle = .block
        if !didLogCoverAttachment {
            didLogCoverAttachment = true
            print("[EPUB][Attachment] cover classes=\(lowercasedClasses) path=\(lowercasedPath) original=\(string(from: currentOriginalSize)) display=\(string(from: attachment.displaySize))")
        }
    }
}
```

## State of the Art

| Old Approach | Current Approach | When Changed | Impact |
|--------------|------------------|--------------|--------|
| DTMaxImageSize = screen bounds | DTMaxImageSize = 1080x1920 | This phase | All images get correct ceiling at creation time |
| Footnote: explicit height calc (0.54*pt in renderer, 0.14*pt in view) | Footnote: width-only from CSS, height auto-calculated | This phase | Consistent with WXRead, simpler, no conflicting overrides |
| Cover: screen-size only, no unified max | Cover: screen-size + unified max ceiling | This phase | Rare edge case: very large cover images get proper constraint |
| qrbodyPic: no max constraint | qrbodyPic: constrained by unified max | This phase | Fixes height overflow for image-heavy chapters |

**Deprecated/outdated:**
- `pointSize * 0.54` footnote height calculation in `prepareHTMLElementForReaderRendering` — replaced by width-only approach
- `pointSize * 0.14` footnote height override in `normalizeInlineAttachments` — removed entirely
- `pointSize * 0.14` footnote height override in `normalizeAttachmentDisplayIfNeeded` — removed entirely

## Assumptions Log

| # | Claim | Section | Risk if Wrong |
|---|-------|---------|---------------|
| A1 | DTCoreText correctly calculates height from aspect ratio when only width is set on an attachment (verified via DTTextAttachment.m source code reading) | Pattern 2: Footnote Width-Only | LOW — code at line 231-236 explicitly handles this case |
| 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

1. **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.

2. **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.

3. **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.

## Environment Availability

> No external dependencies required — all changes are to existing Swift source files.

| Dependency | Required By | Available | Version | Fallback |
|------------|------------|-----------|---------|----------|
| Xcode / Swift compiler | Build & run | ✓ | (project toolchain) | — |
| DTCoreText (CocoaPod) | Image attachment API | ✓ | (project-local) | — |
| Demo EPUB sample | Visual verification | ✓ | 宝山辽墓材料与释读 | — |

**Missing dependencies with no fallback:** None
**Missing dependencies with fallback:** None

## Validation Architecture

### Test Framework
| Property | Value |
|----------|-------|
| Framework | None (no unit test target for EPUBTextRendering) |
| Config file | none |
| Quick run command | `xcodebuild build -project ReadViewDemo/ReadViewDemo.xcodeproj -scheme ReadViewDemo -destination 'platform=iOS Simulator,name=iPhone 16'` |
| Full suite command | Same as quick run (build-only verification) |

### Phase Requirements → Test Map
| Req ID | Behavior | Test Type | Automated Command | File Exists? |
|--------|----------|-----------|-------------------|-------------|
| QUAL-02 | Images don't overflow page | manual visual | Build + run demo + navigate to 图文章节 | N/A |
| QUAL-03 | Image sizing rules are verifiable | code review | Verify max-size constant is 1080x1920 | N/A |
| QUAL-04 | No performance degradation | manual timing | Compare pagination time before/after | N/A |

### Sampling Rate
- **Per task commit:** `xcodebuild build` (compilation check)
- **Per wave merge:** Build + run demo + visual inspection of 图文章节
- **Phase gate:** Visual verification that all three image types display correctly

### Wave 0 Gaps
- [ ] No automated image size assertion tests — manual visual verification required
- [ ] No snapshot/regression test infrastructure for image rendering

## Sources

### Primary (HIGH confidence)
- `Doc/WXRead/decompiled/WREpubTypesetter.m` §672-701 — `_WRPostProcessElementTree` max size logic
- `Doc/WXRead/decompiled/WRCoreTextLayoutFrame.m` §615-635 — cover image drawing
- `Doc/WXRead/resources/css/replace.css` §91-103 — `.bodyPic`, `.qrbodyPic`, `.qqreader-footnote` CSS
- `Sources/RDReaderView/EPUBTextRendering/RDEPUBTextRendererSupport.swift` §217-262, §302-343, §345-404, §467-505 — current implementation
- `ReadViewDemo/Pods/DTCoreText/Core/Source/DTTextAttachment.m` §216-245 — `setDisplaySize:withMaxDisplaySize:` implementation
- `ReadViewDemo/Pods/DTCoreText/Core/Source/DTTextAttachment.h` — `originalSize`, `displaySize`, `verticalAlignment` API

### Secondary (MEDIUM confidence)
- `ReadViewDemo/ReadViewDemo/book/宝山辽墓材料与释读_副本/OEBPS/Text/Chapter_5.xhtml` — `qrbodyPic` HTML structure
- `ReadViewDemo/ReadViewDemo/book/宝山辽墓材料与释读_副本/OEBPS/Text/cover.xhtml` — cover HTML structure
- `ReadViewDemo/ReadViewDemo/book/宝山辽墓材料与释读_副本/OEBPS/Styles/stylesheets.css` — EPUB's own CSS rules

## Metadata

**Confidence breakdown:**
- Standard stack: HIGH — DTCoreText is the existing project dependency, API is well-understood
- Architecture: HIGH — pipeline is clearly documented, code paths are traced
- Pitfalls: HIGH — all pitfalls identified from direct source code reading

**Research date:** 2026-05-23
**Valid until:** 2026-06-23 (stable — DTCoreText and project code are not changing rapidly)