Reproduces on Windows.

Tested with Print Browser mode and this has issues there as well, so adding Blink>Layout label. In print browser mode it looks like the bottom images are shifted down so that the red boxes show up underneath them, and only the tops of the images are visible. This is similar to what happens if you use default margins + Letter paper in Print Preview (the tops of the images move down to a second page).

Unable to reproduce when set to portrait and no margins. If I change the size of the margins or the paper size however it does reproduce in that the bottom images gets pushed to the next document leaving the red boxes on the first page.

This is by design in that we do not split images across pages, if they do not fit *completely* on a page they get pushed to the following page.

Adjust the position to ensure that the images fit on page, or better yet, position them relative to the desired corner.

i.e.
top: 0, left: 0 for top left
top: 0, right: 0 for top right
bottom: 0, left: 0 for bottom left
bottom: 0, right: 0 for bottom right

Thank you all for looking into this issue.

As I mentioned, I sized the '.container' div to match A4 paper size (in 96dpi) as closely as possible, however I realized that I rounded both dimensions up, not down, therefore there was a possibility that  my paper size does not fit A4 completely. That's why I shrinked the .container size by one pixel in both dimensions and added a new attachment, bottom-elements-1.html, for the sake of correctnesss.

> Unable to reproduce when set to portrait and no margins. 
Nevertheless the print preview of bottom-elements-1.html still looks like in the attached screenshot, even though the layout is set to "Portrait", "Paper size" is "A4", and there are no print margins.
Testing in Chrome 61.0.3163.100 (Stable) Version 63.0.3223.8 (Official Build) dev, Arch Linux 64bit.

> This is by design in that we do not split images across pages, if they do not fit *completely* on a page they get pushed to the following page.
But they do fit completely. <Top coordinate of a bottom image> + <image container height> <= <height of the container>, i.e., 929 + 193 = 1022 (please see the newly added attachment, bottom-elements-1.html for correct numbers)
Moreover, if they should be pushed to the following page, then there should be more than one page both in the print preview and in the saved PDF.


> Adjust the position to ensure that the images fit on page, or better yet,
> position them relative to the desired corner.
>
> i.e.
> top: 0, left: 0 for top left
> top: 0, right: 0 for top right
> bottom: 0, left: 0 for bottom left
> bottom: 0, right: 0 for bottom right
Yes, of course, that way it may work, however in our case, we're working on a WYSIWYG tool for authoring pages where we place objects respecting their (x,y) coordinates, something like `style='left: ' + x + 'px;top: ' + y + 'px;'`, therefore we don't have any control of where user places his/her object and resorting to right/bottom workarounds seems quite painful.

Again, thank you very much for looking into this issue.

Deleted: bottom-elements-1.html 1.6 KB

bottom-elements-1.html 1.6 KB View Download

Deleted: screenshot-bottom-images-print-preview.png 242 KB

	screenshot-bottom-images-print-preview.png 242 KB View Download

OK, I found a workaround: adding CSS property `display: inline-block` to the .container element makes bottom images come back, however this produces the second page which is blank.