bug/trim-large-pages: hi_res page trimming keeps the wrong slice when the MediaBox does not start at y=0

未关闭 适合新手
  • 哪里不对？
#363 0 条评论 0 个 reaction 已指派 0 人 在 GitHub 查看

还没有人认领这个 Issue。

评估

难度
2/5
预计耗时
1-3 小时
新手友好度
87/100
Issue 类型
缺陷
描述清晰度
描述清楚
活跃度
活跃
技术栈
python
领域
backend

调研方向

阅读 unstructured_client/_hooks/custom/split_pdf_hook.py，重点关注 SplitPdfHook._trim_large_pages 及其调整 MediaBox 的方式。按照 issue 的建议，添加一个参数化单元测试，覆盖 MediaBox 原点非零的情况；现有测试目前会模拟掉这个方法。完成标准是在每个原点都保留顶部 4000pt，同时原点为零的框保持现有行为不变。

由索引模型根据 Issue 内容生成。

描述

Describe the bug

With strategy="hi_res" and PDF splitting, SplitPdfHook._trim_large_pages trims any page taller than MAX_PAGE_LENGTH (4000pt) to its top 4000pt. It does that by setting mediabox.top = mediabox.height and then bottom = top - 4000, which assumes the MediaBox starts at y=0. When the MediaBox has a non-zero bottom edge, the window it keeps is shifted down by that offset:

  • MediaBox [0, 1000, 612, 6000] becomes [0, 1000, 612, 5000]: the top 1000pt of the page are dropped and the bottom part is kept instead.
  • MediaBox [0, 5000, 612, 10000] becomes [0, 1000, 612, 5000], which doesn't overlap the page at all, so that chunk goes to the API as a blank page.

To Reproduce

On main (c1b153f, unstructured-client 0.47.0, pypdf 6.21.4):

import io, sys
from pypdf import PdfReader, PdfWriter
from pypdf.generic import RectangleObject
from unstructured_client._hooks.custom.split_pdf_hook import SplitPdfHook, MAX_PAGE_LENGTH

origin = float(sys.argv[1]) if len(sys.argv) > 1 else 1000.0
w = PdfWriter()
page = w.add_blank_page(width=612, height=5000)
page.mediabox = RectangleObject([0, origin, 612, origin + 5000])  # 5000pt tall, bottom edge at y=origin
buf = io.BytesIO(); w.write(buf); buf.seek(0)

before = PdfReader(buf).pages[0].mediabox
after = SplitPdfHook()._trim_large_pages(PdfReader(buf), {"strategy": "hi_res"}).pages[0].mediabox
print("original:", [float(x) for x in before])
print("trimmed: ", [float(x) for x in after])
print("expected:", [0.0, float(before.top) - MAX_PAGE_LENGTH, 612.0, float(before.top)])

origin 0     trimmed [0, 1000, 612, 5000]   expected [0, 1000, 612, 5000]
origin 1000  trimmed [0, 1000, 612, 5000]   expected [0, 2000, 612, 6000]
origin 5000  trimmed [0, 1000, 612, 5000]   expected [0, 6000, 612, 10000]

Expected behavior

Keep the top 4000pt of the page wherever the MediaBox sits. Dropping the top assignment and only moving the bottom edge does that:

if page.mediabox.height >= max_page_length:
    page.mediabox.bottom = page.mediabox.top - max_page_length

With that change all three cases above match the expected box, and it is the same result as today for MediaBoxes that start at 0. _trim_large_pages has no direct test right now (the unit tests patch it out); I'd suggest a parametrized one over the MediaBox origin like the script above.

Additional context

This only runs when the hook actually splits (hi_res, more pages than one split or a page range). I found it reading the hook, not from a customer file, so I don't know how common offset MediaBoxes are in practice; they do show up in cropped or imposed PDFs. I saw CONTRIBUTING asks for issues rather than PRs, so filing it here.

主要语言
Python
星标
120
派生
22
平均合并
2 天 3 小时
30 天内合并 PR
6

环境准备

  • 没有 Dockerfile 或 Docker Compose 文件
  • 没有 Pull Request 模板
  • 阅读贡献指南

从这里开始

  1. 先读完整个 Issue，再读项目的贡献指南。
  2. 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
  3. Fork 仓库，在一个分支上完成修改。
  4. 提交 Pull Request，并在描述里引用这个 Issue 编号。

Unstructured-IO/unstructured-python-client 的其他 Issue

查看 Unstructured-IO/unstructured-python-client 的全部 Issue

相似的 Issue

更多 Python Issue

把新 issue 发到你的邮箱

精选适合新手参与的 GitHub issue 摘要。