Implement new converter with JODConverter

[GoogleCodeExporter]

XDocReport provides several full Java converters to convert Docx->XHTML, 
Docx->PDF, ODT->XHTML, ODT->PDF. Those converters are quick, full Java (no need 
to install OpenOffice or MS Word) but must be improved. We will continue to 
improve it, but it seems that some XDocReport users use JODConverter to convert 
ODT report to another format.

JODConverter works with OpenOffice/LibreOffice started in headless mode and 
call it to do conversion. So the conversion are very good managed, but you need 
to install OpenOffice/LibreOffice in your server.

It should be cool to implement JODConverter as converter to use 
IXDocReport#convert method to generat ereport and convert it to another format 
with JODConverter. Ex to convert to PDF with JODConverter :

--------------------------------------------------------------------------
IXDocReport report = XDocReportRegistry.getRegistry().loadReport( in, 
TemplateEngineKind.Velocity);

IContext context = report.createContext();
Project project = new Project("XDocReport");
context.put("project", project);

OutputStream out = new FileOutputStream(new File(                  
"ODTProjectWithVelocity_Out.pdf"));
Options options = 
Options.getTo(ConverterTypeTo.PDF).via(ConverterTypeVia.JODCONVERTER);
report.convert(context, options, out);
--------------------------------------------------------------------------

It exists 2 version of JODConverter : 

 * 2.x : http://www.artofsolving.com/opensource/jodconverter 
2.x seems to be stable and provides maven dependency : see 
http://www.artofsolving.com/node/36 but project is give up.
 * 3.x : http://code.google.com/p/jodconverter/
3.x is beta and doesn't provide maven dependency. It seems that it's possible 
to start/stop the OpenOffice server with Java code, there are a lot of 
improvment "improving the reliability and scalability of working with an 
external OOo process". See  
http://code.google.com/p/jodconverter/wiki/WhatsNewInVersion3

I think we should use 3.x, but there is no maven dependency provided. However 
it seems that it uses Mavcen3 
http://code.google.com/p/jodconverter/wiki/BuildingFromSource

@Pascal : what do you think about that?

Original issue reported on code.google.com by angelo.z...@gmail.com on 7 Feb 2012 at 8:40

[GoogleCodeExporter]

Hi,

As you may know, we use JODConverter too inside Nuxeo.

Hi,

We have a forked version on GitHub where we have made some fixes on version 2.0.
I don't remember the exact story, but I know we were in contact with the main 
dev of JODConverter ... I'll check that.

But anyway, if you plan some work on the Converter, we could at least take the 
time to discuss about it, since I think we also need to work on that matter.
We may join forces.

Tiry

Original comment by tdelprat@nuxeo.com on 17 Apr 2012 at 8:24

[GoogleCodeExporter]

Hi Tiry,

Thank for this information. I don't know what we will do that about this issue. 
I think we should use the 3.x, but it seems that there is none activity 
(perhaps fork it?).

I believe too that Pascal want to study that to see if we develop our own 
JODConverter like to have none dependencies to JODConverter because it seems 
that it is not in activity (perhaps fork it?).

Regards Angelo

Original comment by angelo.z...@gmail.com on 18 Apr 2012 at 8:04

[GoogleCodeExporter]

Hi,

My mistake, our forked version is based on JODConverter 3, and yes, we forked 
it because there was no activity :)

Original comment by tdelprat@nuxeo.com on 24 Apr 2012 at 5:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I think the major feature of xdocreport is really not needing a openoffice 
running. Sometimes one needs to deploy to many servers without ssh access and 
can't put binaries inside them. Even if you could, since linux have no binary 
stability, you would need a full static binary to avoid glib issues, I hope 
xdocreport doesn't head that way

Original comment by soler...@gmail.com on 28 Nov 2013 at 1:20

[GoogleCodeExporter]

solerman, don't worry, XDocReport will provide always their full Java XHTML/PDF 
converter. This issue is just to provide a new converter with JODConverter 
because some people (like Nuxeo) uses it, because the result of converter is 
better than our full Java converter.

Original comment by angelo.z...@gmail.com on 28 Nov 2013 at 1:36

[GoogleCodeExporter]

Hi all,

we've been using JODConverter 2.2.1 for close to a year now, using a custom 
implementation of 
fr.opensagres.xdocreport.converter.internal.AbstractConverterNoEntriesSupport 
that utilizes a 
com.artofsolving.jodconverter.openoffice.connection.SocketOpenOfficeConnection 
along with a  
com.artofsolving.jodconverter.openoffice.converter.StreamOpenOfficeDocumentConve
rter to connect to a headless Linux LibreOffice server -- AFAIK works without a 
hitch (no crashes, leaks etc. observed, but maybe Ops does regular 
restarts…). The results are just as beautiful and solid as if exported PDF on 
a Desktop OpenOffice.org (or clone). In case you need custom fonts, you need to 
make them available on the OOOrg-Server. 

The (headless) server has no trouble handling parallel request (but my 
impression is that the server queues them and works them off sequentially). 
Performance is a bit of a bummer, though, as we must send the ODT over the 
socket and receive the PDF back over the socket. If that's an issue (isn't for 
us yet), I think one can resort to using co-installed Libreoffice headless 
servers and use either localhost-connections via the loopback device, or resort 
to using Named Pipes 
(com.artofsolving.jodconverter.openoffice.connection.PipeOpenOfficeConnection), 
but we haven't tried that yet.

Our UI does regular queries on the SocketOpenOfficeConnection via 
connect/disconnect to determine if the server/component is up and running. 

The adapting code to make JODReport play along nicely with XDocReport is quite 
simple -- it's merely a matter of providing an implementation of 
fr.opensagres.xdocreport.converter.internal.AbstractConverterNoEntriesSupport 
and an implementation of 
fr.opensagres.xdocreport.converter.discovery.IConverterDiscovery. As we employ 
the Spring Framework, we also have a custom 
org.springframework.beans.factory.config.BeanFactoryPostProcessor that 
registers our IConverterDiscovery objects of the Spring context 
programmatically with the fr.opensagres.xdocreport.converter.ConverterRegistry.

If there's need, I can ask my client to publish some code.

Hope this helps, 
bye
    Stef

Original comment by stefan.g...@googlemail.com on 3 Dec 2013 at 6:49

[GoogleCodeExporter]

Hi Stef,

Many thank's for your information.

> it's merely a matter of providing an implementation of 
fr.opensagres.xdocreport.converter.internal.AbstractConverterNoEntriesSupport 
and an implementation of 
fr.opensagres.xdocreport.converter.discovery.IConverterDiscovery

Exactly, it was the goal of this issue.

> If there's need, I can ask my client to publish some code.

It should be fantastic, if you could contribute to XDocReport with your 
JODConverter implementation. For Spring context, is it interesting for 
XDocReport to provide a Spring bean factory liek you have done?

Regards Angelo

Original comment by angelo.z...@gmail.com on 3 Dec 2013 at 8:59