I’m proud to announce that AODL is now part of the ODF Toolkit project of OpenOffice.org. The sourcecode
has already moved to the CVS server of OpenOffice.org. You will find more information and a detailed description
of how to do a CVS checkout at OpenOffice.org on the AODL Wiki page
at OpenOffice.org.
The first part of the Master Page Styles implementation is done and already checked in into the CVS repository. Now, you can set up the page properties like page orientation and the margins for the different page sides. The following code snippte will show you how to do this.
TextDocument document = new TextDocument();
document.New();
// you can modify the default Master Page Style
TextMasterPage txtMP =
document.DocumentStyles.TextMasterPageCollection.GetDefaultMasterPage();
// or you can query for other existing Master Page Styles
// e.g. document.DocumentStyles.TextMasterPageCollection.GetByStyleName(string styleName);
txtMP.TextPageLayout.MarginLeft = “6cm”;
txtMP.TextPageLayout.MarginRight = “6cm”;
txtMP.TextPageLayout.PageOrientation = “landscape”;
….
…
You can also access the page footer and header, but this part isn’t completed and full usable, up to now. Now, I will work on at this part to make it full usable as soon as possible. At least, I’ve also checked in the first attempt for image and table conversation for the PDF Exporter.
Since I’ve promised you to implement also the page setup handling for the OpenDocument to PDF exporter for AODL I have to make a short stop with the PDF export implementation. I’ve decided to do this, because the OpenDocument master page handling in AODL is up to now very rudimentary, but for generating the PDF layout I will need nearly all of the info stored within the master pages elements of an OpenDocument file. Of course, this will result in a later release date for the PDF exporter, but it has the nice side effect that the next version of AODL will also offer an easy handling for master page styles. Since the different OpenDocument formats needs also different handlings the next AODL version will as a start only offer full support for master page styles in text documents. When this will be done I will went back to the PDF exporter implementation. I hope to finish this task within the next two or three days.
During the last two days I was able to implement the image support. The images should be positioned well, whether with or no surrounding text parts and keeping possible resize info of embed pictures alive. Therefor I have extended the AODL ODF graphic implementation in this way that the object will also offer all necessary base info e.g. real size, dpi y, dpi x, … needed by a resize recalculating for PDF. This mean if an embed graphic in an OpenDocument file is resized this will be also the case in the PDF document. Additional to that I have also implemented the handling of page breaks und the layout transformation from DTP points to in and cm with regarding the DPI output resultion. Now, the PDF view is very near to the ODF view. Of course only for supported ODF objects. First parts are available through the CVS repsoitory. I hope to do another check in this evening.
After a lot of coding for the PDF exporter add on for AODL this weekend I have reached the first running state for simple PDF table support. On the way to the simple table support I have also successfully implemented paragraphs, simple text, formated text, whitespaces, headings, fonts, font properties like color, bold, etc., paragraph styles, parent-style fallbacks and a simple support for tabstops. Whereas tabstops only will be simulated within the exporter, because they doesn’t exists in the PDF. Since it’s only a simple simulation without recalculating the real distances the conversation of a “tabstop layouted” area like simulating columns won’t offer an optimal result. However, I still hope to finish a first preview version for public download within this week. Next to the features which are already implemented I will also try to implement page properties like margin and orientation, simple graphic conversation and table layouts. For a demonstration about the possibilties of the PDF exporter I’m going to write a small application which could generate bills in the OpenDocument text and the PDF format. Any feedback is welcome ….
Due to the increasing number of questions for a PDF export feature for AODL.
I’ve decided to write a light weight PDF exporter for AODL vers. 1.x and started
last evening. After a few hours of programming a first PDF exporter implementation
was finished. Up to now, it could export all ITextContent (text) objects of an OpenDocument
text document to a PDF file. The PDF exporter will become an own assemblie and the exporter object can
be passed to the now overloaded SaveTo method of a IDocument objects. As you can see in the
following code snippet the usage is as simple as possible.
AODL.ExternalExporter.PDF.PDFExporter pdfExporter =
new AODL.ExternalExporter.PDF.PDFExporter();
AODL.Document.TextDocuments.TextDocument doc =
new AODL.Document.TextDocuments.TextDocument();
doc.Load("E:\MyDocuments\simple_text.odt");
doc.SaveTo("E:\MyDocuments\simple_text.pdf", pdfExporter);
Since it will be available as a seperat dll it don’t have to be deployed within a project
if it isn’t used. Also the possibility to pass an external exporter object to the overloaded
SaveTo method will give you the option to write your own exporter dll. Therefor you only
have to implement the IExporter interface of the AODL main dll. Since the early state
of implementation this dll isn’t available for download or through the CVS repository.
I hope to make a first alpha version available within the next week.
Before OpenOffice version 2.x the only possible way to automate OpenOffice was using
Reflection. Okay, it was possible but it was not elegant and there were many hidden traps by using
the UNO api through reflection and COM interop. Since version 2.x OpenOffice offers the CLI UNO bindings
as .net assemblies and much of the work that was difficult before is much more easier now. Only add the
CLI assemblies to your .net project and start developing. However, also with the new assemblies
there were a large count of new questions. Since over one year I’ve recieved dozens of questions about
OpenOffice automation with C# using the CLI UNO assemblies. Most of them occour while starting the first
application and seeing that most of the code offered by the CLI assemblies are only interfaces. Yes,
that’s the design principle of the OpenOffice API it based on interfaces and as developer you have to program
against interfaces and some of them you have to implement. So far so good, this shouldn’t a real problem for most of the
.net developer. The problem is to find out how the interfaces works together.
A good starting point for finding answers to your questions is the OpenOffice Developer Guide. Over 1100 pages
really cover all areas of client and UNO component development. A small disadvantage for pure .net developer would
be that there are only a few pages about the CLI UNO bindings with a few example codes. If you have a good knowlegde
of C++ or Java, you should be able to port the dozens of examples from the other chapters to .net. If not,
programming with the CLI UNO bindings could become a very hard job.
In the OOforum.org where I answered dozens of questions about programming for OpenOffice with .net, I saw many good
ideas about integrating OpenOffice into .net based software. Some of these ideas died , because of the lack
of information about OpenOffice programming with .net. This often results in an high expenditure of time which
in turn isn’t acceptable by the project leader and or the customer.
I really believe in OpenOffice and think that it is a good idea to use OpenOffice automation instead of MS Office.
OpenOffice is not only free avalaible it also offers the same comfort for end users and developers as MS Office (My opinion ).
For making OpenOffice client developing easier in the future I decieded to write a free (LGPL) .net 2.0 library (CLI_UNO_EX).
The most importent intentions of CLI_UNO_EX are to hide the real complexity of the UNO implementation, to simplify
often used tasks and to be well documented. Whereby hiding not mean that the CLI_UNO_EX close the “door” to the access
of the UNO objects! It use the wrapper pattern to encapsulate the different types of UNO objects therefor it implements the
required UNO interfaces of these objects and can offer you so to program against real classes instead of interfaces.
For showing you the differences take a look at the following examples which shows you the loading and displaying of
a document. First by using CLI assemblies only and second by using CLI_UNO_EX.
ComponentContext componentContext = Bootstrap.bootstrap();
Desktop ooDesktop = new Desktop(componentContext);
Component component = ooDesktop.LoadComponentFromURLEx(@"D:MyDocssome_doc.odt", "_blank", 0, new Hashtable());
When comparing these two examples you can see that in the CLI only version you have to know which object
offer which interfaces as in the CLI_UNO_EX version you don’t see any type casts. These casts will be all
done automaticaly in the library. Of course also by using the CLI_UNO_EX library you have to know
which class offer the features you are looking for, but this can be simply taken from the documentation. All
classes, properties and methods are documented. As I said before the access to the UNO objects isn’t
closed and all CLI_UNO_EX classes offers access to the UNO objects they encapsulates via a public property.
Also through the fact that they implements the UNO interfaces they can be simply be casted to these types.
This will then look smilar as shown in the first example.
While comparing the document load methods loadComponentFromURL and LoadComponentFromURLEx you see more
features. The loadComponentFromURL require the path in the url file format as the LoadComponentFromURLEx
method accept it in the standard Windows format. The library offer a public Path helper class which can be
used to convert file pathes into formats required by UNO / OpenOfffice. At least you can see that the
last parameter is a simply .net Hashtable instead of an UNO PropertyValue object. Also for this
conversion the library offer a converter class.
And where can I download the library? Up to now there is no downlad package. The library is only avalaible through SVN.
You can check out the latest version from the following URL (https://aodl.svn.sourceforge.net/svnroot/aodl/CLI_UNO_EX).
Or you can browse the repository online within this URL
Browse SVN.
Notice: The library is an early development state and shouldn’t be used within important projects. I can’t
guarantee that there are no major changes in future versions which wont be compatible with this version.
For any kinds of questions use the forum. To get to the forum click here.
Here is a short info on how to run C# code snippets for OpenOffice programming within the Snippet Compiler.
Sometimes you only want to test a method or an interface of the OpenOffice CLI UNO binding, but for
every test you probably build a new testproject in Visula Studio. Of course you can also write
test implementations for NUnit, but this often not realy necessary while you only want to know
how something of CLI works. A great tool for testing your short OpenOffice C# code is the Snippet Compiler.
This little tool let you compile and run your little tests without using Visual Studio. Before
you can use the CLI assemblies inside your test code you have to add these as references to the
Snippet Compiler. Simply go to Tools -> References, select the File System tab page, browse to
the OpenOffice CLI assembly folder, select all CLI assemblies, click the Select-Button and then
OK (see Screenshot). Now, the Snippet Compiler refresh his cache. After that you can use
the CLI assemblies namespace and run your OpenOffice test codes. That’s it
While recieving so many of email questions about AODL, AODC, OpenDocument format and OpenOffice .net / C# development I’ve decieded to add a forum for all these kinds of question. You can reach it via the left main menus item Developer & User Forum.
After I didn’t found enough time during the last few month to make significant changes or to add new features I’ve decieded to continue the development of AODL and AODC, now. The first part of development will be a bugfixing of outstanding bugs which were still in the AODL code base. Nothing realy worth, but of course I will fix them While the 1.x branch of AODL is based on the 1.1 .net framwork and the 2.0 .net framework offer more features of XML handling I will switch within the next version of AODL (2.x) to the .net 2.0 framwork. It would be possible to simply import the old 1.1 based project into a 2.0 based one, but I guess this isn’t the best choice. So before I will start with version 2.x I wish to hear your meaning about. So feel free to post all kinds of suggestions and info into the forum.
First of all I want to say that I really love NDoc . Which I think is one of the most useful .net tools ever. Last week I've decided that it was time to publish a little wepage for my AODL library. The page should simply list all AODL namespaces and their class, interfaces and delegates. Also every class should have a short description. This description should be same as used within the compiled HTML help of AODL. So I've started to play aoround with NDoc, but the results wasn't realy what I've looking for. After try some google'ing and don't found something useful. I've thought it's a good decision to write my own little documentator tool which should exactly do what I want to have and so I did. The result is a little command line tool which create a namespace and class hierarchy html page from an the xml documentation file of an Visual Studio project. If you think this could be useful or handy tool for you, you can download from the download area.
My Blog 
, because of the lack
).
