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
平均合併
1 天 23 小時
30 天內合併 PR
7

環境準備

  • 沒有 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 摘要。