Has this ever been confirmed? I can find quite a few threads going back as far as 2008 that talk about the problem but don’t get an answer.
In short, when exporting to PDF, no matter what you do, you cannot get the image width to go beyond about 3/4 of the page width. This has nothing to do with margins, unless I’m missing something?
Thanks
Thanks but that just agrees with my findings. I’m just wondering has it ever been confirmed as a bug from the developers and if a workaround is known.
I don’t know if this topic is being ignored or just misunderstood as every thread that talks about this problem never gets an answer. So to be clear, here are some screenshots of the problem. The first is how things look in Scrivener (Windows v3.1.4.0).
Each image is 50px height and width as shown. I’ve included some text to show where the margins are.
Here’s the PDF output.
As you can see, as soon as the image goes beyond ~500px width, everything begins to scale down.
The compiled PDF page size is Letter 8.5 x 11in. If I compile to paperback 6x9 then the breakpoint max width becomes around just over 300px so I guess somewhere along the lines, pdf images have a max width of roughly 75% / 80% of the page width.
6x9…
Two years later…
This seems still to be a problem. Dos anyone have a work-round?
In my testing, image size is much better preserved when compiling to RTF (and possibly DOCX) and then generating the PDF from your word processor.
Image size issues have been a thorn in the side since 1.0, and mostly all boil down to how the Qt engine treats the native system DPI as the measurement for how many should be in an inch, rather than universal typesetting standards. This has an impact in almost every aspect of how images are dealt with, and has thus been a long slow process of fixing it all. Instead of just letting an image be dropped into the editor, we have to build custom code to override how that happens; instead of letting it just print, we have to build custom code to correct the incorrect scaling; instead of letting the engine set the print size upon input using the dialogue, we have to build custom code to intercept and modify the results; when a document is loaded and the layout engine formats the text and places the images, we have to build custom code to jump in and correct its assumptions… on it goes.
Wherever it hasn’t been fixed yet, this results in images being smaller than they should be, and evidently may also be messing up the limiter that tries to keep images within the margin area. If its measurement of that is incorrect, then it limits earlier than it should.
