Can somebody explain why this happens, how to fix, and why this is how an alternative to Microsoft Office works out of the box?
Windows 10
Libreoffice 7.3.4.2
Saved format doesn’t matter here, this is the result with both .docx and .odt
The image format is .png and they were inserted via copy-paste and edited using the built-in crop in Google Docs (original .docx generated there, looks fine in Writer as you can see but the .pdf it generates is pixelated).
Read the instructions. Why are you using Microsoft Print to PDF?
Also check if the default has been changed from unticked in Tools > Options > LibreOffice > Print > Reduce bitmaps
And also to receive adapted answers, give details on your case: OS name (Windows apparently, but which one?), LO version, save format (.odt or .doc(x)), image format and how they were inserted.
@EarnestAl
Thanks for the answer. Unfortunately I already did both and the results are the same…
Also will edit the post.
@ajlittoz
Will edit the post.
Caution! If the document was stored in Google Docs before being reimported on your computer, it was damaged by Google Docs which is known not to be fully compliant with ODF. Does it happen on a document fully and exclusively edited on your PC? Note that Writer has its own built-in cropping tool (no need to make a roundtrip via Google Docs; or you can also edit the image in Draw for more complex jobs before pasting the result into Writer).
Can you post the file, so we can check the contents. I’m especially courious, how writer can display the file “fine”, but fail during print/pdf-generation.
Original .odt document ('from scratch"):
The image is effectively considered as a true PNG image. But you applied “non-congruent” scaling, 321% width and 139% height. Considering the image characteristics, height scaling doesn’t matter. However the width-scaling had no “nice” relation to the image (it is not 1/2, 1/4 or 2×, 3×, 4×, …). Rendering needs interpolation. PNG is not a vector-format but a raster one (bit-map). As the bars don’t fall entirely inside “big pixels” but straddles two adjacent ones, some anti-aliasing is applied resulting in gray shades.
If you keep original size and apply integer-multiple scaling, everything is correct.
Imported .docx from Google Docs:
You add conversion compatibility issues to the process.
Images are now translated into Drawing Objects (they are no longer full-fledged images but some transformation into basic shapes). You can no longer use built-in image tools. When you zoom in at 5× or more, you clearly see that the edges of the bars are blurred. They already have undergone an interpolation process.
Conclusion:
Great analisys!
Note that it worked OK in 6.2 - so it’s a regression.
Picture from libreoffice from scratch.odt.
LO 6.2 produces correct pdf.
Correct image also produced by formatting page as Landscape and rotating barcodes to vertical in current versions. In fact crisper than pdf created by LO 6.2.8.2.
It seems to be something to do with rotation, the below odt is the same except for copy of barcode and rotate to vertical. The difference between the two barcodes when exported to pdf is astonishing. Also of note, the horizontal barcode won’t go higher up the page (about half its length from the top).
libreoffice from scratch79392Vert&Horizontal.odt (13.2 KB)
Can you submit a bug report? How to Report Bugs in LibreOffice - The Document Foundation Wiki
Could it be related to tdf#125594? I thought it had been fixed in the 7.x releases though the bug was not closed.
We’re in same context: bar codes are anchored as characters, but bounding box is effectively rotated.
tdf#149943
