Description: Bad example: It crashed and fix it now! Steps to Reproduce: 1.Using the command line, convert the following pdf files to png files 2.--headless --convert-to pdf inputFile --outdir outputFolder Actual Results: The program enters an endless loop Expected Results: The pdf file can be converted successfully Reproducible: Always User Profile Reset: Yes Additional Info: none
Created attachment 190179 [details] Command line conversion file to png card dead
1. Please don't ask to "fix it now!", this is quite rude and many people work on a volunteer basis for this project. 2. You talk about converting from PDF to PNG but your command converts to PDF. Please clarify. 3. Please test with the latest release Thank you
Correct command line arguments:--headless --convert-to png inoutFile --outdir outputFolder
This problem still occurs in the latest version
I tested with: libreoffice7.6 --headless --convert-to png renamed.pdf Indeed, the process hangs. I stopped it after three minutes. But I was able to use the same command on other sample PDFs (single-page and multi-page). This kind of conversion should work, at least for the first page: https://ask.libreoffice.org/t/convert-total-pdf-pages-into-images-command-line/5377 https://stackoverflow.com/questions/41802507/how-to-convert-pdf-files-to-jpg-with-soffice-command For converting all pages, see this Ask.LO question, which suggests an imageMagick option: https://ask.libreoffice.org/t/use-soffice-to-convert-from-doc-to-png-images/41621 So the issue lies in this particular sample file. LO also hangs on importing the PDF into Draw. Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Same in OOo 3.3, so inherited.
With a recent trunk build, I get in the terminal many repeated: warn:sdext.pdfimport:548997:548997:sdext/source/pdfimport/tree/pdfiprocessor.cxx:121: PDFIProcessor::setMiterLimit(): not supported by ODF Then it gets stuck after one: warn:xmloff:548997:548997:xmloff/source/draw/ximpstyl.cxx:365: unknown attribute urn:oasis:names:tc:opendocument:xmlns:style:1.0 style:writing-mode value=lr-tb
Seems to work with my fix of tdf#113050 and I see that the file does use that type of fill; all the slides have this pretty stippled background. *** This bug has been marked as a duplicate of bug 113050 ***