Description: I have imported two "hal-page" images onto a new oo document. They look fine when I view the page, but when I print both the preview and final product on paper only show the lower (2nd) image. To fix this I must take a screenshot of the page to get it all into one image, then I can import that image into the document (after deleting prior 2) and it prints fine. Steps to Reproduce: 1. import 2 images into a new document (1/2 page size desirable and easier) 2. align to top and bottom of page resp. (not overlapping) 3. try to print Actual Results: Both preview and final paper show just the 2nd lower image Expected Results: I should see exactly what I see in the tool in my tool window. Reproducible: Always User Profile Reset: No Additional Info: I can give you sample images if you like, but I doubt you need them. I use screen shots from another window.
Sample is necessary and it must correspond to bug description. You may also try with LO master Appimage and to search in existing bugs.
Created attachment 174558 [details] OO document after save This is a saved version (which now works - see comments).
Created attachment 174559 [details] upper image upper image
Created attachment 174560 [details] lower image
MOST interesting. I reproduced the problem exactly and once again it failed BUT Then I saved the document, closed the window and re-opened. IT NOW WORKS FINE. I suspect that the saved document has the images imported and not in a limbo state - perhaps before saving.
I did testing (to see if save or reload of doc. fixed it). From a new document (page settings changed to .25" borders and 4 lines of "text" so I can control where the images are placed - "upper" and "lower" and 2 blank lines), I insert the images at the 2nd and 4th lines which are BLANK. The first time I did this - somehow a 2nd BLANK page was made when I tried preview, only the lower image of the 1st page shows on preview So I deleted the ONE line carrying over into the BLANK second page. after that, the preview of page 1 is correct. The behavior is most peculiar, but very easy to fix manually - feel free to close this bug as it is annoying but the fix is easy. UNLESS you too are intrigued. Why this happens is sure weird. Sorry to bother you.
Please see https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status, Reopened is wrong status. If you think there's consistent bug, yOu need again to attach sample and precise steps, unlike comment 6 that's not clear. And set Unconfirmed then. If yu cannot, then it's InsufficientData. You should also search in existing bugs, see bug 132222, bug 89818.
1. Download upper & lower image 2. Insert -> Image -> Upper 3. Deselect the inserted image 4. Insert -> Image -> Lower 5. Drag lower to bottom position 6. Press CTRL+P or Print -> Look at the print preview... top image lacking 7. Save 8. Reload 9. CTRL+P -> Now it's OK Repro Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: f58f35b2c8ca1efbacec642a8f3de5b0c499bc6b CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Also in Version: 6.4.0.0.beta1+ (x64) Build ID: 20be5cd0bdc57d812bf34a2debfe48caa51de881 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL 6.3 inserted 'to paragraph' not 'to character' by default. However this doesn't appear make any difference, if I change the default anchoring 'to paragraph' [tools -> Options -> Writer -> Formatting aid] the same happens..
OK, my final takes. Setup from new document with the two images I sent 1) set page borders - all 4 to .25" (not sure if matter but I did this) 2) make a 4 line document (the words do not matter and no quotes used" "upper" BLANK line "lower" BLANK line 3) insert upper.img at beginning of first blank line 4) insert lower.img at beginning of second blank line ---> print (or just print-preview is enough) AT THIS POINT - YOU see that the print page is wrong (not the doc you see) PS - I originally did this exactly the way Telesto described (dragging) but learned that making the "4 line document" above obviated the need to drag and was easier. The only defaults I changed were the page border settings (as noted). To fix EITHER save the document, exit and reload OR cut off the new 2nd blank page which was generated by steps 1-4 in BOTH cases above, preview shows what it should. My experience is that preview always shows what will really print so I did not test by printing. I had no need of the real document except to print so I had not tried the first until I sent a copy to you and opened it again then trying print-preview (to verify what I sent). Humble apologies for changing status improperly. I understand and am out of the cycle now (retired many years ago). This is a real bug but the fix is easy for me, now that I understand what is happening. Thanks for all you guys do.
Looks intended. bibisect-linux-64-6.4 901cb9b91c2690b6b0d55d939c984ddf5fc6268f is the first bad commit commit 901cb9b91c2690b6b0d55d939c984ddf5fc6268f Author: Jenkins Build User <tdf@pollux.tdf> Date: Wed Jul 31 20:29:20 2019 +0200 source f50363c7008c239d302944144beb256de6a55f38 https://gerrit.libreoffice.org/c/core/+/64804 tdf#54908 Make selection active if there's a selection (Writer) If the user make a selection in Writer and then opens print dialog or PDF export dialog, Print Selection is the default option. Can you verify that you see an image if you select "all pages" in Print dialog?
As raal explained, just mark all pages or some pages instead of Selection, if image is selected. So this is NotABug, meaning it's working as intended. (yeah, not obvious if you don't pay attention, but useful to print just selection)
*** This bug has been marked as a duplicate of bug 139164 ***