Download it now!
Bug 61094 - headless requires RENDER extension when converting doc file with image to html
Summary: headless requires RENDER extension when converting doc file with image to html
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: Other Linux (All)
: medium normal
Assignee: Radek Doulik
Depends on:
Reported: 2013-02-19 02:38 UTC by clkao
Modified: 2016-05-09 20:07 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:

doc file containing image (2.75 MB, application/msword)
2013-02-19 02:38 UTC, clkao

Note You need to log in before you can comment on or make changes to this bug.
Description clkao 2013-02-19 02:38:38 UTC
Created attachment 75083 [details]
doc file containing image

$ /opt/libreoffice4.0/program/python ./unoconv/unoconv -f html LCIDC01_1020302_00002.doc 
unoconv: RuntimeException during export phase:
Office probably died. void cairocanvas::Canvas::initialize(),
SpriteCanvas::SpriteCanvas: No RENDER extension

This seems somehow triggered the extension check in cairo related module.

Other doc files without images are fine.

converting to -f xhtml works fine.

A success headless build (configured --enable-headless) works fine for -f html as well.
Comment 1 Thorsten Behrens (CIB) 2013-02-19 09:36:13 UTC
pure --headless just means "show no UI". if additionally you don't want it to use X, unset DISPLAY in the process that starts your office instance.
Comment 2 clkao 2013-02-19 10:59:23 UTC
(In reply to comment #1)
> pure --headless just means "show no UI". if additionally you don't want it
> to use X, unset DISPLAY in the process that starts your office instance.

This is a server environment and there's no DISPLAY in env.

Like I said, if I build LO from scratch with --enable-headless, this works fine, and so is converting other doc files without images in them with regular build.

So I think expecting the regular build to be able to convert doc file with images in server environment is quite reasonable.
Comment 3 Thorsten Behrens (CIB) 2013-02-19 19:40:36 UTC
Hi Rodo, seems the emf+ image in this file triggers cairocanvas, which in turn wants X - can we somehow either fallback to vclcanvas there, or to plain EMF during rendering?
Comment 4 QA Administrators 2015-04-19 03:21:58 UTC
** Please read this message in its entirety before responding **

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

   *Test to see if the bug is still present on a currently supported version of LibreOffice (4.4.1 or later)

   *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior
   *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System

Please DO NOT

   *Update the version field
   *Reply via email (please reply directly on the bug tracker)
   *Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 

1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3)

2. Test your bug 
3. Leave a comment with your results. 
4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 
4b. If the bug was not present in 3.3 - add "regression" to keyword

Feel free to come ask questions or to say hello in our QA chat:

Thank you for your help!

-- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Comment 5 lyforever62 2015-06-02 16:00:42 UTC
It seems bug was fixed.

OS: Mac OSX 10.10.3
Comment 6 clkao 2015-06-03 02:41:59 UTC
This should be linux-specific, hence the verification on MacOSX should not close the issue.  Reopening this and pending verification on newer LO.
Comment 7 Buovjaga 2015-10-09 18:18:50 UTC
clkao: so is this still an issue for you with LibO 5?

Change to UNCONFIRMED, if the problem persists. Change to RESOLVED WORKSFORME, if the problem went away.
Comment 8 QA Administrators 2016-05-09 20:07:26 UTC
Dear Bug Submitter,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INVALID 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

This INVALID Message was generated on: 2016-05-09