mirror of
https://github.com/storytold/pdfcraft.git
synced 2026-10-26 19:19:10 -06:00
Hamza
645a8ca205
`path_as_rect` decided a path was a rectangle from its element count and from the four corners of its bounding box being covered. Its comment names the shape it means to match -- one MoveTo, three LineTo, one ClosePath -- but `len() != 5` also admits one MoveTo and four LineTo, a five-point open polyline, and covering the corners says nothing about the points between them. Both call sites then paint `device.draw_rect(bbox)`, so such a path was drawn as its own bounding box. Rendered through `pdfcraft-cli render`, an open zigzag whose ends reach the corners of its bounding box 80 38 m 80 21.75 l 60.571 29.875 l 40 21.75 l 40 38 l S lost its middle peak and gained a straight edge the file does not contain: no dark pixel near the peak, and 36 along the bounding box's top. A six-point zigzag and a real rectangle both drew correctly, which is why this shows on some art and not the rest -- and `s` escapes it because its ClosePath makes six elements. A point that is not a corner now rejects the path. A rectangle still matches whether written `m l l l` and closed or `m l l l l` back to its first corner, since every one of its points is a corner. The same mistake also discarded a clip of that shape, through `push_clip_path`, which this fixes too. Found from craft-libs' ATTRIBUTION note that the shared reader centralizes the patched Hayro trees from PdfCraft: the same flaw is in craft-libs, sent there as storytold/craft-libs#175.