Open GoogleCodeExporter opened 9 years ago
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
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
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
[deleted comment]
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
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
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
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
Original issue reported on code.google.com by
angelo.z...@gmail.com
on 7 Feb 2012 at 8:40