Description: Summary: What I see in ODT file (LibreOffice UI) is not what I see when I export it to PDF When I export the attached `example.odt`, I get the attached `example.pdf`. Visually, the PDF file doesn't match what I see in LibreOffice UI. See the attached `png` file for what I see in the LibreOffice UI. Note that there is no "black strip" whatsoever in the ODT file, but somehow the PDF file picks it up. FWIW, the chapter headings have "hidden" font effects. I am not sure if that is creating the problem. Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: c9e5640c8fcad7beb42a66f9bee0252eee9fe323 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: en-IN (en_IN.UTF-8); UI: en-US TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-03-18_08:37:30 Calc: threaded ~$ uname -a Linux debian 5.10.0-8-amd64 #1 SMP Debian 5.10.46-4 (2021-08-03) x86_64 GNU/Linux ~$ dpkg -l | grep libreoffice rc libreoffice7.0-debian-menus 7.0.0-3 all LibreOffice 7.0 desktop integration ii libreofficedev7.2 7.2.0.0.alpha0-1 amd64 Brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-base 7.2.0.0.alpha0-1 amd64 Base brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-calc 7.2.0.0.alpha0-1 amd64 Calc brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-debian-menus 7.2.0-0 all LibreOfficeDev 7.2 desktop integration ii libreofficedev7.2-dict-en 7.2.0.0.alpha0-1 amd64 En dictionary for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-dict-es 7.2.0.0.alpha0-1 amd64 Es dictionary for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-dict-fr 7.2.0.0.alpha0-1 amd64 Fr dictionary for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-draw 7.2.0.0.alpha0-1 amd64 Draw brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-en-us 7.2.0.0.alpha0-1 amd64 Brand language module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-impress 7.2.0.0.alpha0-1 amd64 Impress brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-math 7.2.0.0.alpha0-1 amd64 Math brand module for LibreOfficeDev 7.2.0.0.alpha0 ii libreofficedev7.2-ure 7.2.0.0.alpha0-1 amd64 UNO Runtime Environment.0.0.alpha0 ii libreofficedev7.2-writer 7.2.0.0.alpha0-1 amd64 Writer brand module for LibreOfficeDev 7.2.0.0.alpha0 ii lodevbasis7.2-libreofficekit-data 7.2.0.0.alpha0-1 amd64 Libreofficekit data files for LibreOfficeDev 7.2.0.0.alpha0 Steps to Reproduce: 1. Open attached `example.org` 2. Click `Export directly as PDF` icon in the editor window 3. View the PDF file Actual Results: `example.pdf` file doesn't visually match the `example.odt` Expected Results: `example.pdf` file should visually match the `example.odt` Reproducible: Always User Profile Reset: No Additional Info: The attached png files show the screenshot of page 3 as seen in LibreOffice UI and as seen in PDF file.
Created attachment 175234 [details] example.odt
Created attachment 175235 [details] example.pdf: Where does the back strip come from ..? Why is some text hidden ...? Why does the PDF file /differ/ from what I see in LibreOffice UI?
Created attachment 175236 [details] pdf-export-doesnt-match-odt.png: PDF export doesn't match ODT Screenshots of what I see in LibreOffice UI and what I see in exported PDF. PDF viewer I am using is ~$ dpkg -l | grep evince ii evince 40.4-2 amd64 Document (PostScript, PDF) viewer ii evince-common 40.4-2 all Document (PostScript, PDF) viewer - common files ii gir1.2-evince-3.0:amd64 40.4-2 amd64 GObject introspection data for the evince libraries ~$
Created attachment 175237 [details] same-page-as-see-in-mupdf-viewer.png: Same page as seen mupdf viewer Screenshot of one of the problmatic pages as seen in mupdf viewer. ~$ dpkg -l | grep mupdf ii mupdf 1.17.0+ds1-2 amd64 lightweight PDF viewer ii mupdf-tools 1.17.0+ds1-2 amd64 command line tools for the MuPDF viewer
Since both `evince` and `mupdf` render `example.pdf` identically, I am inclined to conclude that the problem is NOT with PDF viewer but with the LibreOffice's PDF export.
This link is for submitter's / my reference https://github.com/kjambunathan/org-mode-ox-odt/issues/97. LibreOffice team, please ignore this comment.
Created attachment 175246 [details] Bird's eye view of example.odt.png: Bird's eye view of `example.odt` Note that there are no `black strips` and all text (save for hidden chapter headings) are visible. Compare this with what you see in the `example.pdf`.
Created attachment 175247 [details] Bird's eye view of example.pdf in evince.png Compare the bird's eye view of the ODT file and this pdf file. Do you notice the black strips (which possibly is hiding the text content)
No issue with PDF export on Windows build The PDF subset embeds the same fonts as defined in each of the styles used in the ODT: SimSun TimesNewRomanPS-BoldMT TimesNewRomanPSMT But the PDF generated on your system shows NotoSerifCJKjp-Bold-VKana as a Type 1 font, suspect that wonky font fall back caused the issue for the 'Content Heading' and then backing of subsequent paragraphs. =-testing-= Version: 7.2.1.2 (x64) / LibreOffice Community Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to V Stuart Foote from comment #9) > No issue with PDF export on Windows build Same for me Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: d5e55d204b71710eb5eb5d2c683dd6698626df3c 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
The black strip is caused by a transparent strip in the background image.
(In reply to V Stuart Foote from comment #9) > No issue with PDF export on Windows build > > The PDF subset embeds the same fonts as defined in each of the styles used > in the ODT: > > SimSun > TimesNewRomanPS-BoldMT > TimesNewRomanPSMT > > But the PDF generated on your system shows NotoSerifCJKjp-Bold-VKana as a > Type 1 font, suspect that wonky font fall back caused the issue for the > 'Content Heading' and then backing of subsequent paragraphs. > > =-testing-= > > Version: 7.2.1.2 (x64) / LibreOffice Community > Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 > CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: > win > Locale: en-US (en_US); UI: en-US > Calc: threaded I don't have the SimSum font on my debian machine. To eliminate, font fallback issues I have removed the east asian script that sneaked in to "Contents Heading". I am attaching the following files that has only english / latin script and fonts. 1. example-latin-only.odt 2. example-latin-only.pdf: Above file exported to pdf 3. Bird's eye view of example-latin-only.odt.png 4. Bird's view of example-latin-only.pdf-in-evince.png 5. 'StandardPage' page style's preview tab shows the black strip.png 6. Play with Tiling Properties and see MULTIPLE strips appearing.png Images 5 & 6 are annotated. My question is why does the black strip DOES appear in the page style preview and pdf, but NOT in libreoffice UI. Even if there is a "misconfiguration" of how the image is tiled in 'StandardPage', my contention is that the LibreOffice UI should reflect what a user will ultimately get. So, the correct behaviour is one of 1. LibreOffice UI should show the black strip -- if it can show it in preview why can't it show in the compose window 2. The PDF export should show no black strip, because the LibreOffice compose window doesn't show one. I am not sure where the bug lies, ATLEAST the LibreOffice UI and PDF export /must/ provide a consistent view of the document. I am also attaching the following images which are used as page backgrounds. (I have simply extracted the images from `example-latin-only.odt`) 1. 10000000000003AC000002C16B4304CB01673EB1.png 2. 10000000000003AC000002C1E6E482E8A2E80086.png 3. 10000000000003AC000002C1FAF82061274AB7EC.png FWIW, `example-latin-only.pdf` shows the following font information, and these fonts are very much present in my system, and hence there the question of 'fallback' doesn't arise.
I expect the LibreOffice UI and PDF export to be consistent. I have ruled out non-availability of Asian font and consequent 'font fallback' as part of the problem. See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175254 [details] example-latin-only.odt See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175255 [details] example-latin-only.pdf See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175256 [details] Bird's eye view of example-latin-only.odt.png See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175257 [details] Bird's view of example-latin-only.pdf-in-evince.png See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175258 [details] 'StandardPage' page style's preview tab shows the black strip.png See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175259 [details] Play with Tiling Properties and see MULTIPLE strips appearing.png See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175260 [details] This is the tiled bitmap image for 'StandardPage' See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175261 [details] This is the background image for 'OrgTitlePage' See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
Created attachment 175262 [details] This is one another background image embedded in the document, it is of no concern for this bug See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c12
(In reply to qiang from comment #11) > The black strip is caused by a transparent strip in the background image. You have a workaround to achieving what you want. That doesn't mean that there is no bug. The bug is this: inconsistency between LibreOffice UI and PDF export. I, and for that matter anyone will expect a WYSIWYG when moving between LibreOffice Editor and PDF export. What OS are you using? Is it Windows? If that is the case, then this is a platform-specific Linux-only bug. I would appreciate if one another linux-using soul could independently confirm the behaviour I am seeing.
(In reply to Jambunathan K from comment #12) > (In reply to V Stuart Foote from comment #9) > > No issue with PDF export on Windows build > > > > The PDF subset embeds the same fonts as defined in each of the styles used > > in the ODT: > > > > SimSun > > TimesNewRomanPS-BoldMT > > TimesNewRomanPSMT > > > > But the PDF generated on your system shows NotoSerifCJKjp-Bold-VKana as a > > Type 1 font, suspect that wonky font fall back caused the issue for the > > 'Content Heading' and then backing of subsequent paragraphs. > > > > =-testing-= > > > > Version: 7.2.1.2 (x64) / LibreOffice Community > > Build ID: 87b77fad49947c1441b67c559c339af8f3517e22 > > CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: > > win > > Locale: en-US (en_US); UI: en-US > > Calc: threaded > > > I don't have the SimSum font on my debian machine. > > To eliminate, font fallback issues I have removed the east asian script that > sneaked in to "Contents Heading". > > I am attaching the following files that has only english / latin script and > fonts. > > > 1. example-latin-only.odt > 2. example-latin-only.pdf: Above file exported to pdf $ pdffonts example-latin-only.pdf name type encoding emb sub uni object ID ------------------------------------ ----------------- ---------------- --- --- --- --------- BAAAAA+TimesNewRomanPS-BoldMT TrueType WinAnsi yes yes yes 28 0 CAAAAA+TimesNewRomanPSMT TrueType WinAnsi yes yes yes 23 0
Yep, no font caused impact here. The black strip *is* mishandling of a transparent strip in the GIMP 2.10.24 generated 10000000000003AC000002C1E6E482E8A2E80086.png image, attachment 175260 [details] [1] used as the tiled bitmap 'Area' of the "StandardPage" Page Style of the affected pages. Export to PDF gets mishandled differently depending on the os/DE, unnoticeable in Windows based export and preview--but still is mishandled. =-ref-= [1] ImageMagick details: PS C:\Users\vsfoote\downloads> identify -verbose 10000000000003AC000002C1E6E482E8A2E80086.png Image: Filename: 10000000000003AC000002C1E6E482E8A2E80086.png Format: PNG (Portable Network Graphics) Mime type: image/png Class: DirectClass Geometry: 940x705+0+0 Resolution: 37x37 Print size: 25.4054x19.0541 Units: PixelsPerCentimeter Colorspace: sRGB Type: TrueColorAlpha Base type: Undefined Endianness: Undefined Depth: 8-bit Channel depth: Red: 8-bit Green: 8-bit Blue: 8-bit Alpha: 1-bit Channel statistics: Pixels: 662700 Red: min: 0 (0) max: 255 (1) mean: 242.18 (0.949727) median: 255 (1) standard deviation: 55.4911 (0.217612) kurtosis: 15.0248 skewness: -4.12153 entropy: 0.0477442 Green: min: 0 (0) max: 255 (1) mean: 241.914 (0.948681) median: 255 (1) standard deviation: 56.1885 (0.220347) kurtosis: 14.5196 skewness: -4.06348 entropy: 0.0463244 Blue: min: 0 (0) max: 255 (1) mean: 241.924 (0.94872) median: 255 (1) standard deviation: 56.1462 (0.220181) kurtosis: 14.5225 skewness: -4.06375 entropy: 0.0482924 Alpha: min: 0 (0) max: 255 (1) mean: 242.34 (0.950355) median: 255 (1) standard deviation: 55.3889 (0.217211) kurtosis: 15.195 skewness: -4.14669 entropy: 0.284889 Image statistics: Overall: min: 0 (0) max: 255 (1) mean: 242.09 (0.949371) median: 255 (1) standard deviation: 55.8037 (0.218838) kurtosis: 14.811 skewness: -4.09849 entropy: 0.106812 Alpha: none #00000000 Colors: 343 Histogram: //truncated for space 32900: (0,0,0,0) #00000000 none ... //above are the transparent px, below is bg, deleted the rest - vsf ... 628547: (255,255,255,255) #FFFFFFFF white Rendering intent: Perceptual Gamma: 0.454545 Chromaticity: red primary: (0.64,0.33) green primary: (0.3,0.6) blue primary: (0.15,0.06) white point: (0.3127,0.329) Matte color: grey74 Background color: white Border color: srgb(223,223,223) Transparent color: none Interlace: None Intensity: Undefined Compose: Over Page geometry: 940x705+0+0 Dispose: Undefined Iterations: 0 Compression: Zip Orientation: TopLeft Profiles: Profile-exif: 2440 bytes Profile-icc: 672 bytes Properties: date:create: 2021-09-25T14:06:06+00:00 date:modify: 2021-09-24T13:20:56+00:00 exif:BitsPerSample: 8, 8, 8 exif:ColorSpace: 1 exif:DateTime: 2021:09:07 19:05:14 exif:ExifOffset: 190 exif:ImageLength: 705 exif:ImageWidth: 940 exif:Software: GIMP 2.10.24 exif:thumbnail:BitsPerSample: 8, 8, 8 exif:thumbnail:Compression: 6 exif:thumbnail:ImageLength: 192 exif:thumbnail:ImageWidth: 256 exif:thumbnail:JPEGInterchangeFormat: 316 exif:thumbnail:JPEGInterchangeFormatLength: 2118 exif:thumbnail:PhotometricInterpretation: 6 exif:thumbnail:SamplesPerPixel: 3 icc:copyright: Public Domain icc:description: GIMP built-in sRGB icc:manufacturer: GIMP icc:model: sRGB png:bKGD: chunk was found (see Background color, above) png:iCCP: chunk was found png:IHDR.bit-depth-orig: 8 png:IHDR.bit_depth: 8 png:IHDR.color-type-orig: 6 png:IHDR.color_type: 6 (RGBA) png:IHDR.interlace_method: 0 (Not interlaced) png:IHDR.width,height: 940, 705 png:pHYs: x_res=3701, y_res=3701, units=1 png:text: 1 tEXt/zTXt/iTXt chunks were found png:text-encoded profiles: 1 were found png:tIME: 2021-09-07T11:05:14Z signature: 0d97bc8be7a72ab4c5a5f48445895007aaff8452be188e861f8fcdf4a59ad6fd Artifacts: verbose: true Tainted: False Filesize: 11188B Number pixels: 662700 Pixels per second: 70.5443MP User time: 0.031u Elapsed time: 0:01.009 Version: ImageMagick 7.0.11-12 Q16 x64 2021-05-09 https://imagemagick.org
Created attachment 175269 [details] as a test, here is the background PNG used as a layered image on an ODT canvas
Created attachment 175270 [details] and to test in Draw canvas, here it is layered between two text boxes On Windows, get functional transparency in PDF exported from both Writer and Draw canvas--in addition to the export when used as Tiled area fill. Check to see how the PNG transparency is handled on Export with different os/DE, if it has similar issues to the page area tiled fill.
Created attachment 182013 [details] Sample .odt file with two images with transparency When export to PDF, the original color (although with 0% of opacity now/100% transparency) is shown with 100% of opacity. The upper image has black transparent background; the lower image has white transparent background. Version: 7.2.7.2 (x86) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: en-US Calc: threaded
Created attachment 182014 [details] PDF of file with two images with transparency
Black strip not seen in export from Linux or Windows with attachment 175234 [details] Black background of logo in attachment 182013 [details] only seen on Windows and only with Skia. I created a new report for it: bug 153279. I think this report could be closed. Jambunathan, what do you think?
Created attachment 186131 [details] bug144700-feedback-dtd. March 22, 2023 (LO 7.6 alpha).zip The feedback here is based on Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 4bcf6d9c905e7b5558ee8d9f7f616ce61eadb8f8 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: en-IN (en_IN); UI: en-US Calc: threaded running on (base) ~$ uname -a Linux debian 6.1.0-1-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.4-1 (2023-01-07) x86_64 GNU/Linux (base) ~$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: n/a Codename: bookworm Contents of `bug144700-feedback-dtd. March 22, 2023 (LO 7.6 alpha).zip` - example-latin-only.odt Same as https://bugs.documentfoundation.org/attachment.cgi?id=175254 (see https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c14) - example-latin-only.pdf - LO version is 7.6.0.0alpha0+.png Version of LO I am using (This is development build less than 6 months old as on Mar 22, 2023) - Birds's eye view of example-latin-only.odt on LO 7.6 alpha.png Not sure if I should see the the two thin black strips (I am not knowledgeable to comment on if the two black strips---I believe they are border pixels---should appear or not. My gut feeling is that the two black strips shouldn't appear.) I will leave the decision to you. - PDF rendering of example-latin-only.od on LO 7.6 alpha.png The PDF rendering matches with what I see in LibreOffice GUI. Good! The "consistentcy" part of my original report is addressed. - bug144700-pay attention to black strips appearing preview image.mp4 Note that "Preview" doesn't show the thin black strips. So there is an incosistency between what the "Preview" window shows and what the LibreOffice compose area shows. This "inconsistency" is a bug. Also note that, as I change the tiling parameters the tiny black strips appear in some cases, and doesn't appear in some cases. There seems to be some inconsistent handling. My gut feeling is that some fine tuning is required. - unzipped This folder contains unzipped version of `example-latin-only.odt`. `Pictures/10000000000003AC000002C1E6E482E8A2E80086.png' is the background image that gets tiled.
(In reply to Buovjaga from comment #30) > Black strip not seen in export from Linux or Windows with attachment 175234 [details] > [details] > > Black background of logo in attachment 182013 [details] only seen on Windows > and only with Skia. I created a new report for it: bug 153279. > > I think this report could be closed. Jambunathan, what do you think? See https://bugs.documentfoundation.org/show_bug.cgi?id=144700#c31 for my feedback. 1. I see two thin black strips (as opposed to a big rectangular black patch) I am not quailified enough to comment on whether these black strips should appear or not. My gut feeling is that they shouldn't. 2. While there is consistency between what I see on LibreOffice composer and what I get in PDF export, there is a inconsistency between the what the "Preview" window (of tiled background), and the end result. See the mp4 video in the zip file. ----- Qiang CCed this bug is the original own of the ODT files. He may have some insights on WHY there is transparent strip in the background image, and what END RESULT he wanted to achieve in the first place. ------ So, The question (1) has to be resolved (2) requires some tuning.
(In reply to Buovjaga from comment #30) > Black background of logo in attachment 182013 [details] only seen on Windows > and only with Skia. I created a new report for it: bug 153279. I don't have access to Windows machines. So, I wouldn't able to test this part.
(In reply to Jambunathan K from comment #32) > > Qiang CCed this bug is the original own of the ODT files. He may have some > insights on WHY there is transparent strip in the background image, and what > END RESULT he wanted to achieve in the first place. > The transparent strip is an accident during editing the background image, I cut the strip area away and it looks white, I didn't know it's transparent and has borders.
So the remaining issue here is that there is a visible border around the PNG's transparent strip? I noticed that the border is visible in the PDF in Chromium, Evince and Okular, but not in Firefox. Which would make this issue a graphics stack problem rather than a PDF export problem. Tested with: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 642f2d7177ea3e6c365da2c2082a50a5137cd988 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Dear Jambunathan K, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Dear Jambunathan K, Please read this message in its entirety before proceeding. Your bug report is being closed as INSUFFICIENTDATA due to inactivity and a lack of information which is needed in order to accurately reproduce and confirm the problem. We encourage you to retest your bug against the latest release. If the issue is still present in the latest stable release, we need the following information (please ignore any that you've already provided): a) Provide details of your system including your operating system and the latest version of LibreOffice that you have confirmed the bug to be present b) Provide easy to reproduce steps – the simpler the better c) Provide any test case(s) which will help us confirm the problem d) Provide screenshots of the problem if you think it might help e) Read all comments and provide any requested information Once all of this is done, please set the bug back to UNCONFIRMED and we will attempt to reproduce the issue. Please do not: a) respond via email b) update the version field in the bug or any of the other details on the top section of our bug tracker Warm Regards, QA Team MassPing-NeedInfo-FollowUp