The idea behind this converter came
about on the OpenOffice.org
Franocophone native language list.
I'll indicate the general
outline of the application on this pages, where I see the project to
be going in the future, and the various details of the source code
that is used. I would add that this is only represents my personal
view of the converter and is in no way an official representation
from the OpenOffice.org project.
The
Tools
OpenOffice.org version 1.1 beta was used. I chose
this version because it can natively export files to the PDF format,
as well as record macros. The host machine uses a Windows operating
system., on which I've installed easyPhP (version 1.6) that includes
Apache and PhP4. All of this is connected to a DSL with a dynamic DNS
for the domain name
Call for help : I'm
looking for a server with 24h availability that would be able to host
this converter. I reckon, from the tools that I've used, that it
should be possible for it to run on any OS. If you think you can help
out, drop
me a line.
The Architecture
Originally, this converter had been intended
just to produce online PDF export capabilities for SXW files. The
resulting file was initially sent to the requester by e-mail. The
project then evolved into an attempt to provide a greater variety of
export formats. Since I received several comments from users
pertaining to user data privacy and the law in France, I unplugged
the mailing functionality, which is just as well because the server
wasn't intended to the final home of the converter anyway. As a
result of this, once the file is processed, a link is now offered
that gives the user the choice of viewing or downloading the
converted document.
On the first page, the user indicates the
type of OpenOffice.org that he/she wants to convert, and the intended
converted output format.
The form that is filled in is checked for
conformity and then sent to a PhP
script that does the following :
starts the OpenOffice.org conversion macro
saves a session file
creates a zip archive if the result contains several files
creates a link to the generated file
In this way, the user can see the result of the
conversion immediately, just by clicking on the link, and then
“saving as” if he/she is satisfied with the appearance.
The session files are kept at most for 24h.
I would like to thank Frederic Labbe for his advice on the use of
PhP and e-mail, as well as the whole community for having
participated in the tests, that are still ongoing...
Supported
Export Format Table
Writer SXW, STW, SDW, VOR |
|
||||||||||||||||
Calc SXC, STC, SDC |
|
||||||||||||||||
Draw SXD, STD, SDD, SDA |
|
||||||||||||||||
Impress SXI, STI, SDP |
|
Warning: Not all of
these combinations have been tested yet. Please inform me of any that
do not work or cause problems.
Unanswered Questions
Of course, nothing is perfect !!
Here are a few points where I'm still experiencing problems
each time the macro is started, a new session
of OpenOffice.org is opened. This isn't catastrophic as such, but
does consume resources, and becomes a bother when I'm trying to do
something else on the machine (and no, I don't sit there watching,
mouth agape, my server going about its business). Is there some way
of starting this command in a silent mode
:
oDocument=oDesktop.loadComponentFromURL(surl,"_blank",0,Noargs())
What
I'm looking for is a reference to oDocument, but without it being
visible, much like the invisible switch when you start
OpenOffice.org from the command line
I got the answer to
this from Fred Vuillot (thanks Fred):
dim args(0) as new com.sun.star.beans.PropertyValue
args(0).Name ="Hidden"
args(0).Value = True
Warning : this seems to be unstable on Beta 1.1
Impress and Draw don't apparently have
a macro recorder. Do the same export functions exist, and if so,
what are the arguments to be passed ?
I
found the list FilterName
For the Draw export, these filters were of
no use to me. You can get all of the available filters using this
small macro:
The export of some HTML formatted documents
raises a few issues with “unrecognized characters"
I
avoided this problem, by changing the properties in OOO (remember
I'm in beta 1.1 here)
Tools - Options - Load/Save - HTML
Compatibility - Character Set = Unicode (UTF-8)
From time to time,
the PDF export asks questions on the number of pages, image
transparency, etc ... The problem with this is that is blocks the
script and leaves the session open. Is there a way of getting around
this problem ? Are there any export parameters that can be used ?
Once we understand arguments passing behaviour, MediaDescriptor structures (search for it in the SDK), solutions come easily ;-)
But, with the help of the mailing list dev@api.openoffice.org (Thanks to Stephan Wunderlich)
sub ExportDocumentPDF
rem -----------------------------------------------------
rem define variables
dim doc as object, desktop as object
dim args() as new com.sun.star.beans.PropertyValue
rem -----------------------------------------------------
rem get access to the document
oDesktop=createUnoService("com.sun.star.frame.Desktop")
sUrl="file:///test.sxw"
doc=oDesktop.loadComponentFromURL(surl,"_blank",0,args())
rem -----------------------------------------------------
Dim PDFArgs(1) as new com.sun.star.beans.PropertyValue
PDFArgs(0).Name = "FilterName"
PDFArgs(0).Value = "writer_pdf_Export"
PDFArgs(1).Name = "CompressMode"
PDFArgs(1).Value = 0 'Possible Values : 0 - 1 -2
doc.storeToURL("file:///test.pdf",PDFArgs())
doc.dispose()
end sub
There are 2 interresting XML files in OpenOffice directories
/share/registry/data/org/openoffice/Office/TypeDetection.xcu
/share/registry/data/org/openoffice/Office/Common.xcu
The home page contains some javascript
in order to, among other things, dynamically offer a list of
available conversion formats as a function of the file extension
that has been chosen.
Browsers based on Mozilla seem to suffer
from a bug.
, since they don't react to the onChange command
coming from FileInput. I've therefore had to create a special page
for these kind of browsers based on onBlur, that gets around the
problem. If anyone knows of a better solution, let me know, I'm all
ears.... If javascript is deactivated, then the problem becomes a
more general one.
I rewrote the main page. Now, even if javascript is not allowed, the available export list is defined. Validation will then be server-side handled
If you have any questions, and
particularly if you have any answers to my questions, please drop
me a line.
Future Developpement
Insofar as possible, I would like to look down a couple of these roads :
extension of the export to all of the supported formats
make the script into a "Webservice" that could deliver the transformed documents to a third party application
Source Code
The sources published here are made freely available
under the Gnu
LGPL. If something seems a bit unclear,
just get in touch with me, I may be a bit convoluted in my
programming at times...