Description: I was able to open a PDF in draw once and edit it, each subsequent attempt leads to an error. Attempts to open a PDF using both the LibreOffice and the Draw applications fail. Other PDF viewing applications work (e.g. Zathura). Neither libreoffice-fresh nor libreoffice-still are able to open any PDF I tried. Steps to Reproduce: 1.Open a PDF file Actual Results: Popup error: "General Error. General input/output error." Expected Results: To open the PDF file Reproducible: Always User Profile Reset: Yes Additional Info: Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 16; OS: Linux 6.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.utf8); UI: en-US 24.8.4-3 Calc: threaded
Please attach a sample file, reduce the size as much as possible without private information.
LibreOffice is not a PDF editor. That is we don't edit the PDF document directly, just read in its contents, converting to ODF drawing objects. Some elements from the PDF don't convert well with missing fidelity to the source PDF. Any "changes" made to the resulting ODF Draw document must then be written back out by filter export to PDF. It can be the same named PDF as "opened" but it will not be the original PDF with edits, the original will be overwritten. Much "safer" to first save the Draw document into its native ODF Drawing .ODG format. Then open that new document to make any edits or formatting. Then print or export (different filters) into a new PDF document. Repeated round trips from PDF without taking the results through ODG will be problem prone.
Created attachment 199370 [details] A PDF guide to Emacs Org Mode I cannot attach the initial form I was using, as it is essentially composed of private info. However, none of the PDFs I attempt to open will do so, all showing the same error. I have included one as an example, but I find it unlikely that the problem is with the particular PDFs given that so many are affected.
(In reply to V Stuart Foote from comment #2) > LibreOffice is not a PDF editor. > > That is we don't edit the PDF document directly, just read in its contents, > converting to ODF drawing objects. Some elements from the PDF don't convert > well with missing fidelity to the source PDF. > > Any "changes" made to the resulting ODF Draw document must then be written > back out by filter export to PDF. It can be the same named PDF as "opened" > but it will not be the original PDF with edits, the original will be > overwritten. > > Much "safer" to first save the Draw document into its native ODF Drawing > .ODG format. Then open that new document to make any edits or formatting. > Then print or export (different filters) into a new PDF document. > > Repeated round trips from PDF without taking the results through ODG will be > problem prone. Thank you! I did not know the best practices for editing PDFs in Draw and this will be useful in the future. As things stand now, for me, all PDF files cause an error
I can open your file in Draw with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: e420583fee9f753e7de5a207637fda25e495ac7d CPU threads: 4; OS: Linux 6.8; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
Also, it is opened with: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a84593ec130b41da35d98fe7d45a71706935909 CPU threads: 16; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win Locale: en-US (es_ES); UI: en-GB Calc: CL threaded + Version: 25.2.1.1 (X86_64) / LibreOffice Community Build ID: e538fb6403facdfd3db0250c3b3278236c675c2a CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded + Version: 24.8.5.2 (X86_64) / LibreOffice Community Build ID: fddf2685c70b461e7832239a0162a77216259f22 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded + Version: 24.2.7.2 (X86_64) / LibreOffice Community Build ID: ee3885777aa7032db5a9b65deec9457448a91162 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Vulkan; VCL: win Locale: es-ES (es_ES); UI: es-ES Calc: CL threaded + Version: 7.6.7.2 (X86_64) / LibreOffice Community Build ID: dd47e4b30cb7dab30588d6c79c651f218165e3c5 CPU threads: 16; OS: Windows 10.0 Build 26100; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded
Likewise no issue on Windwos build to filter open the pdf-Tex prepared PDF into Draw. Extensive font substitutions of course. Nor with round trip--original PDF (pdf-Tex1.40.19) -> ODF drawing .ODG -> export to PDF (LibreOffice 24.8.4). Though no trace of the fonts subset into the original. Are handling the subset fonts the issue? Maybe test with a document originated from LibreOffice using your on system fonts? =-testing-= Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.2.1.1 (X86_64) / LibreOffice Community Build ID: e538fb6403facdfd3db0250c3b3278236c675c2a CPU threads: 8; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a84593ec130b41da35d98fe7d45a71706935909 CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
> LibreOffice is not a PDF editor. asuraheap: On this matter, you may also be interested in my LibOCon presentation on LibreOffice as a PDF editor: Video: https://www.youtube.com/watch?v=98yX0JRHFbQ Slides: https://events.documentfoundation.org/libreoffice-conference-2023/talk/JDSEVU/ Also, did you do anything with the file between the first and second attempts to open it? i.e. did you edit it, or save to it? I can't reproduce the bug with a nightly build from 2025-02-20: Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d1f97a537b576454b2d93406d372cc4ed36d0b32 CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: en-IL (en_IL); UI: en-US
I'm also experiencing this issue, no PDFs open in Draw. I've tried Safe mode, and it gives me the same result (General Input/Output Error). Nothing useful printed to stderr when starting the app from the terminal. Using LibreOffice 25.2.0.3 520(Build:3) on Linux.
I've tried 10 different PDFs and none of them work. I've tried opening PDFs that DID work just some time ago, but they no longer work.
Also tested on LibreOffice 24.8.5.2 480(Build:2) and got the same error
(In reply to Kuba Orlik from comment #11) > Also tested on LibreOffice 24.8.5.2 480(Build:2) and got the same error What operating system are you using? If it's Linux - what distribution name and version? What kernel version? What desktop environment? Also: * Have you seen this on any other machine? * Can you try this in a clean new profile (on a new user profile)?
I can also reproduce this error. Even a simple PDF file that contains nothing more than a few images cannot be loaded. This kind of PDF files could be loaded a month ago. Version: 25.2.0.3 (X86_64) / LibreOffice Community Build ID: 520(Build:3) CPU threads: 16; OS: Linux 6.13; UI render: default; VCL: kf6 (cairo+wayland) Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN 25.2.0-4 Calc: threaded Operating System: Arch Linux KDE Plasma Version: 6.3.1 KDE Frameworks Version: 6.11.0 Qt Version: 6.8.2 Kernel Version: 6.13.4-arch1-1 (64-bit) Graphics Platform: Wayland
Oh, since the original bug reporter mentioned "libreoffice-fresh" and "libreoffice-still", I guess he/she is also using Arch Linux. I installed libreoffice-still, and the error persists. Version info: Version: 24.8.5.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 16; OS: Linux 6.13; UI render: default; VCL: kf6 (cairo+wayland) Locale: zh-CN (zh_CN.UTF-8); UI: zh-CN 24.8.5-1 Calc: threaded Therefore, I guess this error is specific to Arch Linux. Maybe some dependencies are broken after an update. Here is the rebuild history of libreoffice-fresh, which might be useful: https://gitlab.archlinux.org/archlinux/packaging/packages/libreoffice-fresh/-/commits/main
Update: this error has been reported in the Arch Linux package repository: https://gitlab.archlinux.org/archlinux/packaging/packages/libreoffice-fresh/-/issues/6 Then I'm 90% sure this is a downstream packaging bug or a bug in a dependency package.
Hi, Arch Linux package maintainer here. I reported the related https://bugs.documentfoundation.org/show_bug.cgi?id=165433 > Then I'm 90% sure this is a downstream packaging bug or a bug in a dependency package. LFS reported similar breakages on their side, so I guess the former is unlikely (I'll still double check our poppler build just in case). Could indeed be a regression on the poppler side though I guess.
*** This bug has been marked as a duplicate of bug 165433 ***