https://bugs.documentfoundation.org/show_bug.cgi?id=171146
Bug ID: 171146
Summary: Impress PDF export incorrectly clips images when
fo:clip aspect ratio is inconsistent with image pixel
dimensions
Product: LibreOffice
Version: 25.8.5.2 release
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: UNCONFIRMED
Keywords: filter:pdf
Severity: normal
Priority: medium
Component: Printing and PDF export
Assignee: [email protected]
Reporter: [email protected]
When an Impress presentation contains images whose fo:clip (graphic crop)
values encode a total extent (frame + clip amounts) with an aspect ratio that
does not match the image's actual pixel aspect ratio, the screen renderer
displays the image correctly but the PDF exporter clips at the wrong position.
== Steps to reproduce ==
1. Open the attached crop_bug_slide82.odp (1-slide minimal reproducer)
2. Observe the four images in LibreOffice Impress -- all appear correctly
cropped on screen
3. Export to PDF: File > Export as PDF > Export
4. Open the resulting PDF
== Expected result ==
PDF images match the cropping visible in Impress.
== Actual result ==
Two of the four images are clipped to the wrong portion in the PDF.
Specifically, the top-center and top-right figures (molecular biology diagrams)
show incorrect regions.
== Technical analysis ==
ODF stores image crop as fo:clip="rect(top, right, bottom, left)" in the
graphic auto-style. LibreOffice internally represents this as a GraphicCrop
struct (fields in 1/100 mm). The total rendered image extent is:
total_width = frame_width + clip_left + clip_right
total_height = frame_height + clip_top + clip_bottom
For the crop to be geometrically consistent, total_width/total_height must
equal the image's pixel aspect ratio (px_width/px_height). When they differ, a
non-uniform scale is implied.
In the attached file, two image frames have an AR mismatch:
Style | Image px | Image AR | Total extent (cm) | Extent AR | Match?
gr168 | 950x767 | 1.239 | 11.08 x 14.38 | 0.770 | NO
gr169 | 1800x1049 | 1.716 | 36.08 x 24.59 | 1.467 | NO
gr48 | 706x606 | 1.165 | 7.11 x 6.11 | 1.165 | OK
gr170 | 1800x2085 | 0.863 | 44.38 x 51.74 | 0.858 | OK
The screen renderer compensates for the mismatch and shows the correct image
region. The PDF exporter applies the clip values literally without this
compensation, producing a clip rectangle that cuts the wrong portion of the
image.
The mismatched values appear to arise when a user crops an image and
subsequently resizes the image frame: LibreOffice updates svg:width/svg:height
but does NOT update the fo:clip values proportionally, leaving stale crop
amounts that no longer correspond to the current frame dimensions.
A secondary contributing factor: the affected images lack a pHYs (DPI) metadata
chunk, while the correctly-cropped images have pHYs at 72 DPI. Without physical
dimension metadata, different code paths may resolve the image scale
differently.
== Relevant source locations ==
- xmloff/source/style/XMLClipPropertyHandler.cxx -- reads/writes fo:clip <->
GraphicCrop
- vcl/source/gdi/pdfwriter_impl.cxx -- applies crop during PDF export (apparent
source of the symptom)
- svx/source/svdraw/svdograf.cxx -- SdrGrafObj display rendering (compensates
correctly)
== Related bugs ==
Bug 111340 -- "cropped image aspect ratio fails on saving and re-opening .odp
file and on export to PDF" (NEW since 2017, reported as intermittent). The
present report provides a deterministic reproducer and identifies the specific
mechanism (AR mismatch between fo:clip total extent and image pixel
dimensions).
Bug 92375 -- "Impress loses cropped image ratio on saving and re-opening in
different LO versions" (missing pHYs metadata; related contributing factor).
== Environment ==
LibreOffice 25.8.5.2 580 (Build:2), Linux x86_64
--
You are receiving this mail because:
You are the assignee for the bug.
