egg
e1e97c54cf
fix: correct Phase 3 implementation and remove invalid OCR track alignment
Address Phase 3 accuracy issues identified in review:
**Issue 1: Invalid OCR Track Alignment Code**
- Removed alignment extraction from region style (lines 1179-1185)
- Removed alignment-based positioning logic (lines 1215-1240)
- Problem: OCR track has no StyleInfo (extracted from images without style data)
- Result: Alignment code was non-functional, always defaulted to left
- Solution: Simplified to explicit left-aligned rendering for OCR track
**Issue 2: Misleading Task Completion Markers**
- Updated 5.1: Clarified both tracks support line-by-line rendering
- Direct: _draw_text_element_direct (lines 1549-1693)
- OCR: draw_text_region (lines 1113-1270, simplified)
- Updated 5.2: Marked as "Direct track only"
- spacing_before: Applied (adjusts Y position)
- spacing_after: Implicit in bbox-based layout (recorded for analysis)
- indent/first_line_indent: Direct track only
- OCR: No paragraph handling
- Updated 5.3: Marked as "Direct track only"
- Direct: Supports left/right/center/justify alignment
- OCR: Left-aligned only (no StyleInfo available)
**Technical Clarifications**
- spacing_after cannot be "applied" in bbox-based layout
- It is already reflected in element positions (bbox spacing)
- bbox_bottom_margin shows the implicit spacing_after value
- OCR track uses simplified rendering (design decision per design.md)
**Modified Files**
- backend/app/services/pdf_generator_service.py
- Removed lines 1179-1185: Invalid alignment extraction
- Removed lines 1215-1240: Invalid alignment logic
- Added comments clarifying OCR track limitations
- openspec/changes/pdf-layout-restoration/tasks.md
- Added "(Direct track only)" markers to 5.2 and 5.3
- Changed 5.3.5 from "Add OCR track alignment support" to "OCR track: left-aligned only"
- Added 5.2.6 to note OCR has no paragraph handling
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude <noreply@anthropic.com>