Bug 157750 - Individual image saved as PDF creates 0-byte file (and invalid PDF before that)
Summary: Individual image saved as PDF creates 0-byte file (and invalid PDF before that)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: filters and storage (show other bugs)
Version:
(earliest affected)
5.3.0.3 release
Hardware: All All
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectRequest, implementationError
Depends on:
Blocks: Image-Caching PDF-Export
  Show dependency treegraph
 
Reported: 2023-10-14 03:06 UTC by Kira Tubo
Modified: 2023-10-17 15:19 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
sample jpeg image (102.30 KB, application/vnd.oasis.opendocument.text)
2023-10-14 03:09 UTC, Kira Tubo
Details
Screenshot export window (240.10 KB, image/png)
2023-10-14 10:49 UTC, m_a_riosv
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kira Tubo 2023-10-14 03:06:42 UTC
Description:
If the user inserts an image into Writer, then tries to save the individual image as a PDF, the file that is generated has a 0 byte size. 

Related to Comment 5 in Bug 135597.

Steps to Reproduce:
1. Open Writer
2. Insert > Image
3. Select any image to insert
4. Right click on inserted image
5. Save
6. Choose PDF format and Save
7. In PDF Options dialog, click OK
8. Navigate to saved PDF file
9. Note size of file

Actual Results:
Individual graphics/images are saved with a 0 byte file size. Tried this with JPEG and PNG images. 

Expected Results:
Individual graphics/images that are saved as PDF should be saved with a non-zero file size. 


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Bibisected win64-7.0 to commit: https://git.libreoffice.org/core/+/36962d9cc105d2c98889ee841438823fce090dfb

Reproduced in:

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1ec2e39cf4d5fe0a592bc783fd8bcdc4345c8cbd
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

NOT reproduced in: 

Version: 6.4.0.3 (x64)
Build ID: b0a288ab3d2d4774cb44b62f04d5d28733ac6df8
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: GL; VCL: win; 
Locale: en-US (en_US); UI-Language: en-US
Calc: CL
Comment 1 Kira Tubo 2023-10-14 03:09:40 UTC
Created attachment 190202 [details]
sample jpeg image

1. Right click image in attachment
2. Save
3. Choose PDF format and Save
4. In PDF Options dialog, click OK
5. Navigate to saved PDF file
6. Note size of file
Comment 2 m_a_riosv 2023-10-14 10:49:42 UTC
Created attachment 190207 [details]
Screenshot export window

It shows the issue about 0 size on the export window.
Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 9eb419b0b0f019f5fbc48ff1a11977e8b041edee
CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: es-ES (es_ES); UI: en-US Calc: CL threaded Jumbo
Comment 3 Kira Tubo 2023-10-15 22:11:53 UTC
(In reply to m.a.riosv from comment #2)
> Created attachment 190207 [details]
> Screenshot export window
> 
> It shows the issue about 0 size on the export window.


In 6.4.0.3, the PDF Options dialog displays 0 bytes, but the actual PDF export shows a non-zero byte file size. Whereas in 7.0.3.1, both the dialog and exported PDF file show 0 bytes. So this may not be the best indicator to use for this specific bug (might be a separate bug altogether).
Comment 4 Stéphane Guillou (stragu) 2023-10-16 09:50:48 UTC
In 6.4, you could rename the file with the .jpg extension and it would show the image. It was exporting the file as a jpg but with PDF as the extension.

In 7.0, we get the 0-byte file.

Same in Calc.

Bibisected with the linux-64-7.0 repository to 2f93d2a88f8daf268f9554bd0c82cde4056a8546 which points to core commit 36962d9cc105d2c98889ee841438823fce090dfb which is a cherrypick of:

commit 7272a2edf113f29edeb8987ce649f85b776d9d23
author	Julien Nabet <serval2412@yahoo.fr>	Tue Jul 07 10:23:28 2020 +0200
committer	Julien Nabet <serval2412@yahoo.fr>	Thu Jul 09 09:10:54 2020 +0200
tdf#60684: graphic type content must correspond with graphic type extension
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/98239

Not calling it a regression, as before that commit the export was already wrong. But Julien, what do you think?
Comment 5 Julien Nabet 2023-10-16 20:16:03 UTC
JPG a raster format saved in a vector graphic data type (here PDF), I don't know at all what should be done here.
Of course, feel free to revert my patch if you feel like.
Comment 6 Stéphane Guillou (stragu) 2023-10-17 15:19:53 UTC
(In reply to Julien Nabet from comment #5)
> JPG a raster format saved in a vector graphic data type (here PDF), I don't
> know at all what should be done here.
> Of course, feel free to revert my patch if you feel like.

Fully agreed that it is an odd use case, so we either:
- get rid of this particular filter path; or
- we make it work in an acceptable way (e.g. embed a bitmap inside a single-page PDF of page size equal to the size of the bitmap)

I had a look at a bit more history, and the PDF option is only available since libreoffice-5.3.0.0.alpha1.

Let's make this an implementation error from back then, and see if someone can bibisect what introduced it.