Download it now!
Bug 131971 - Draw -> Insert -> Image... PDF file incorrectly scaled
Summary: Draw -> Insert -> Image... PDF file incorrectly scaled
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
Depends on:
Blocks: Image-DPI
  Show dependency treegraph
Reported: 2020-04-07 22:47 UTC by Simon Banton
Modified: 2020-10-19 04:06 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:

Screenshot of same PDF used as Page Background and when Image -> Insert... is used (260.71 KB, image/png)
2020-04-07 22:48 UTC, Simon Banton
A4-sized PDF file for testing (11.64 KB, application/pdf)
2020-04-09 09:43 UTC, Simon Banton

Note You need to log in before you can comment on or make changes to this bug.
Description Simon Banton 2020-04-07 22:47:37 UTC
Draw is able to insert a PDF file as a non-editable, placed image. This is good, and has a different utility to File -> Open... PDF.

However, an A4 PDF file has a MediaBox that is typically defined as 595 x 842 points which is 8.26" x 11.69" at 72 points/inch.

Draw is Insert -> Image... importing the PDF at an effective scale of 96.78 points/inch and as a result the A4 PDF is rendered at a size of 6.15" x 8.7" rather than A4 size.

(Note: When File -> Open... foo.pdf is used, the PDF comes in at the correct A4 size)

Tested on two different MacBook Pros running OS X 10.11 (El Capitan), and with v6.3.5.2 and v6.4.2.2

Using a Draw page size smaller than 6.15" x 8.7" causes the imported PDF to be scaled down to fit the non-margined area of the page (I believe this is expected behaviour).

Using an A4 page size with zero margins does not fix the problem.

Using a page size larger than A4 does not fix the problem. Tested up to A0 in size, inserted PDF continues to come in at the 6.15" x 8.7" dimensions.

Important Note: If I insert the same PDF as a background image on the Master page (Page -> Set Background Image...) then it comes in at the correct size.

Steps to Reproduce:
1. Create new Draw page with 0 margins and A4 in size
2. Use Insert -> Image... and select a PDF file containing one A4 page
3. Observe that resulting inserted image is the incorrect size (not A4)

Actual Results:
The result is an inserted image that is 6.15" x 8.7" in size, instead of 8.26" x 11.69"

Expected Results:
A PDF inserted in this way should be sized based on its MediaBox dimensions scaled at 72 points per inch

Reproducible: Always

User Profile Reset: Yes

Additional Info:
An example PDF is available at

The attached screenshot shows the same example PDF when used for the Page -> Set Background Image (correct size) and the size it appears when Insert -> Image... is used.

Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3
CPU threads: 8; OS: Mac OS X 10.11.6; UI render: default; VCL: osx; 
Locale: en-GB (en.UTF-8); UI-Language: en-US
Calc: threaded
Comment 1 Simon Banton 2020-04-07 22:48:45 UTC
Created attachment 159403 [details]
Screenshot of same PDF used as Page Background and when Image -> Insert... is used
Comment 2 Simon Banton 2020-04-08 11:43:11 UTC
(It's been highlighted to me that Set Background Image automatically scales to fit the entire page anyway, so ignore that element of the report and please just focus on the Insert -> Image ... aspect)
Comment 3 V Stuart Foote 2020-04-09 01:49:48 UTC
I don't find any issue with the unconstrained pdfium import 'insert image' filter implemented for bug 89727 -- it sizes inside margins for the page, section or frame being targeted.  Size resolution of the source PDF is secondary to fitting the target.

Comment 4 Miklos Vajna 2020-04-09 07:19:35 UTC
Please attach a reproducer pdf image and specify what is the expected and actual size of the inserted image shape. Otherwise it's not easy to test this. Thanks!

Tomaz and Kendy did recent work on this front, so that the PDF rendering happens at display time, rather than import time. This might also help with the scaling, i.e. the rendered bitmap size would be ideally dependent on the in-doc size, not the original pdf size. But I didn't follow that in detail. So make sure to test LO master as well, it has improvements since 6.3. See core.git commit 6ac2d66c78d6c080aabfa46157113684c2f3a3b0 e.g.
Comment 5 Simon Banton 2020-04-09 09:43:07 UTC
Created attachment 159443 [details]
A4-sized PDF file for testing

This test page was created in Draw at A4 size and comprises a box drawn at 210 x 297mm surrounding a box drawn at 100 x 100mm.

It was exported to PDF using File -> Export Directly as PDF and then Insert -> Image... was used to import it into a new Draw document of A4 size with margins set to zero.

When imported, the size of the outer box is measured at 156.1mm x 220.9mm, and that of the inner at 74.5mm x 74.5mm.

The PDF's media box and crop box dimensions are both 595.28 x 841.89 points.
Comment 7 Simon Banton 2020-04-09 10:16:46 UTC
I have just installed LO into a Windows XP VMWare instance and the Test.pdf file Insert -> Image... imports at the correct size into an A4 Draw document with zero margins.

Therefore, it appears that this is an Mac OSX-specific issue.

For info: my system is a MacBook Pro (Retina, 15-inch, Mid 2015) running OS X 10.11.6 (El Capitan).
Comment 8 Mike Kaganski 2020-04-09 10:18:45 UTC
Two screencasts from the mentioned discussions:

mine where I can't reproduse the problem:

OP's with the problem demonstrated:
Comment 9 Mike Kaganski 2020-04-09 10:28:22 UTC
This is not macOS-specific; this is HiDPI-specific. Note the "retina" bit in comment 7.

Repro with Version: (x64)
Build ID: 4d2b2b47cca498fed6abf712a36d0788901091eb
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: CL

*when using GUI scaling* (tested with scaling set to 150%).

And no repro without the scaling on the same system.

By the way, in current master, I see the image scaled up (to fit margins of A1 that I used in testing), but is placed shifted (not from margins). No idea how 6ac2d66c78d6c080aabfa46157113684c2f3a3b0 is involved in this (but the physical size should had been kept IMO).