Kirk Israel wrote:
And in terms of expanding on that so that it have .doc as input (right now
it seems to only accept .odt) and HTML as output (currently not one of the
options listed in the program), are there any gotchas I should know about or
is it just about finding some appropriate API
Hi Kirk,
No you simply have to discover the right filters which have to be used ;-)
A more appropriate place to ask is:
- dev@api.openoffice.org
- http://api.openoffice.org/DevelopersGuide/DevelopersGuide.html
But once more if you plan to use this snippet in a multi-threaded
environment like
Hi,
there's a fully functional codesnippet available which does show how
document-conversion can happen.
http://codesnippets.services.openoffice.org/Office/Office.ConvertDocuments.snip
If you are running this from a J2EE application you need to take into
consideration that ***one*** OO-Instance
Tom,
thanks, that is very cool.
I was able to get the snippet up and running...
Through trial and error I got the correct Jars from my OOo directory I
needed to compile against,
and then Google indicated I needed to include the OOo/program directory in
the classpath.
Was there a smarter way I
Kirk Israel wrote:
Sorry, I'm not being willfully dense here...I understand that if I'm
doing this through the API, there has to be an instance of OOo
running, but are you saying that the segment of the source responsible
for reading in Doc (and the other segment, reseponsible for spitting
Mathias, thank you for your feedback...I have a few responses.
I think you have a misconception how document conversion in OOo works.
There is no direct translation between input and output format, input
filters always convert the input format into a representation in memory
(the core of a
Hi Krik,
take a look into the SDK example java\DocumentHandling\DocumentConverter
you can easy implement a Java remote client application doing the
conversion for you. But you always need an installed office working as a
server (for example with UI if necessary)
Juergen
Kirk Israel wrote:
On 12/9/05, Laurent Godard [EMAIL PROTECTED] wrote:
you may have a look at this, for a very frist shoot
http://oooconv.free.fr/oooconv/oooconv_en.html
So that's a webpage in PHP, and macro for use in an existing instance
of OOo, making a web application for that kind of conversion?
On 12/9/05, Jürgen Schmidt [EMAIL PROTECTED] wrote:
Hi Krik,
take a look into the SDK example java\DocumentHandling\DocumentConverter
you can easy implement a Java remote client application doing the
conversion for you. But you always need an installed office working as a
server (for example
Kirk Israel wrote:
On 12/9/05, Jürgen Schmidt [EMAIL PROTECTED] wrote:
Hi Krik,
take a look into the SDK example java\DocumentHandling\DocumentConverter
you can easy implement a Java remote client application doing the
conversion for you. But you always need an installed office working as a
Hi kirk
So that's a webpage in PHP, and macro for use in an existing instance
of OOo, making a web application for that kind of conversion?
a 2 1/2 year old first shoot
to give some ideas
better can be done of course (and i will release when time a tool like
this based on python, xml-rpc
On 12/9/05, Jürgen Schmidt [EMAIL PROTECTED] wrote:
Kirk Israel wrote:
On 12/9/05, Jürgen Schmidt [EMAIL PROTECTED] wrote:
Hmm. Is your feeling then, that just the document functionality
might too difficult to extract on a source code level?
Yes exactly, the current architecture doesn't
Hi
Openoffice seems to handle the basic task gracefully through the UI.
Can anyone tell me if there's a commandline version that would enable
this from the commandline? Or, possibly even better, is there a
specific callable module responsible for this, is there an
intermediate in-memory
13 matches
Mail list logo
