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

Abierto
  • ¿Algo no está bien?
#2,571 2 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@aImErYbArRaUlT ya está trabajando en esto.

Desde el 1/10/2026.

  • #2572 de @aImErYbArRaUlT — abierto

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
25/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
python
Área
tooling

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.

Lenguaje dominante
Python
Estrellas
194k
Forks
14.5k
Merge medio
24 min
PR fusionados (30 d)
7

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de microsoft/markitdown

Todos los issues de microsoft/markitdown

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.