PPTX: same-row shapes are read top-first instead of left-to-right

Đang mở
  • Có gì không ổn?
#2,571 2 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

@aImErYbArRaUlT đang làm issue này rồi.

Từ ngày 1/10/2026.

  • #2572 của @aImErYbArRaUlT — đang mở

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
25/100
Loại issue
Lỗi
Độ rõ ràng
Đặc tả rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
python
Lĩnh vực
tooling

Hướng nghiên cứu

Start at PptxConverter.convert() and reproduce the ordering with the provided synthetic slide and tests/test_files/test.pptx, slide 2. Compare the current and proposed row-band ordering, preserving None/top-zero handling. Done means shapes are emitted in the expected row-major order without any shape being dropped or duplicated, and the existing test suite passes.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Shapes that share a visual row (a two-column body, a right-aligned value next to a label, a caption beside a figure) come out in the wrong order: the right-hand shape is emitted before the left-hand one whenever its box starts a little higher.

Repro
from pptx import Presentation
from pptx.util import Inches
from markitdown import MarkItDown

prs = Presentation()
slide = prs.slides.add_slide(prs.slide_layouts[6])  # blank

def box(left, top, text):
    tb = slide.shapes.add_textbox(Inches(left), Inches(top), Inches(4), Inches(3))
    tb.text_frame.text = text

box(0.5, 1.5, "LEFT column body")
box(5.0, 1.4, "RIGHT column body")   # right box starts 0.1" higher
prs.save("repro.pptx")

print(MarkItDown().convert("repro.pptx").markdown)

Expected: LEFT column body then RIGHT column body. Actual: RIGHT column body then LEFT column body.

PptxConverter.convert() sorts shapes by (x.top, x.left), so it orders by top first and has no notion of "same row". This also reproduces on the bundled tests/test_files/test.pptx (slide 2, a two-column text + image body).

The fix (and the one decision I'd like your steer on)

Group shapes that overlap vertically into row bands, read the bands top-to-bottom and the shapes left-to-right within a band. A full-height sidebar beside a grid is lifted onto its side so the grid stays row-major, and a full-width title/caption sharing a chart's or table's frame is read on the correct side of it. No shape is added or dropped; only the order changes.

Measured against a known reading order on synthetic slides with seeded jitter (mean Spearman rank correlation, higher is better; benchmark script: https://gist.github.com/aImErYbArRaUlT/6b9ee69160719ae7bc77b9480a185cce):

layout current (top, left) fix
two-column body 0.88 1.00
same-row label / value 0.90 1.00
grid 0.88 1.00
grid beside a full-height sidebar 0.38 - 0.95 1.00
full-width title over a row 0.58 1.00
newspaper / column-major (out of scope) 0.48 0.67

It preserves the None / top-zero handling from #2408: a missing top still sorts first, and a real top of 0 is not treated as missing.

The change is default-on. I made it default-on because on this benchmark it is monotone: it never scores below the current order on any layout, including the out-of-scope newspaper case, so there is no layout it makes worse. The linked PR implements it default-on; if you would rather gate it behind a kwarg until it has some mileage, say so and I will switch it.

Real-deck check

I also rendered the 40 slides where the new order differs from the current one (across docling, Unstructured and Apache POI decks), boxed and numbered each shape, and scored the two orders blind - one scorer, not knowing which image was which - before unsealing the key. Of 22 slides that have a single correct order, the fix read right on 19 and the current sort on 3; the fix beat the current sort 18 to 2. The other 18 are dense diagram / risk-matrix slides with no single correct order, where neither is better.

That blind pass surfaced two slides where a first cut read worse than the current sort: a full-width title banded with the row below it (a Diageo "benefits" slide) and a full-width caption nested in a table's frame (a "this is kinda backwards" slide). Both are fixed. An intermediate bands-only version had actually reversed that nested caption (Spearman -1.00 on a synthetic version of it), which is why the final rule reads a full-width row on the correct side of the frame rather than purely left-to-right.

Known limitations
  • It does not reconstruct column-major "newspaper" order (reading straight down one tall column before starting the next); it improves but does not solve that case.
  • It does not claim to linearize arbitrary 2D diagrams where no single correct order exists; there the content is preserved and the order is heuristic, never worse than today.
  • Separate, pre-existing quirk worth a follow-up: a table's GraphicFrame can report a stale bounding box, which may mis-band it. Out of scope here; happy to file it on its own.

Validated on the benchmark above, a corpus of 66 real decks / 740 slides (no shape ever dropped or duplicated), and the blind render pass. The PR is written and tested.

Ngôn ngữ chính
Python
Star
194k
Fork
14.5k
Merge trung bình
22 phút
Pull request đã merge (30 ngày)
5

Chuẩn bị môi trường

Mở trong Codespaces

Khởi chạy dev container của dự án ngay trên trình duyệt, bằng tài khoản GitHub của bạn.

  • Có Dockerfile hoặc tệp Docker Compose
  • Không có mẫu pull request
  • Không có hướng dẫn đóng góp

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của microsoft/markitdown

Tất cả issue của microsoft/markitdown

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.