Summer of Code 2006
OpenOffice.org Summer of Code Projects
OpenOffice.org is proud to participate in the Summer of Code initiative sponsored by Google. Five projects from the suggestions and one additional interesting subject have been selected. We are glad that we are able to support some additional efforts indepent from SoC.
- 1 OpenOffice.org Summer of Code Projects
Programmability: Dynamic UNOIDL Reference Browser
The OpenOffice.org API is specified in IDL (Interface Definition Language). IDL allows a language independent description of the API and language bindings/bridges allows the use of the same API from various languages where exactly such a language binding/bridge exists. But often it is difficult for users of the API to map the language independent IDL reference documentation to their preferred and used programming language, e.g. Java or StarBasic. But exactly this would speed up their daily work, a Java programmer would like to have a Javadoc like reference of the API. The idea of a “Dynamic IDL Reference Browser” is to develop a new concept for documenting IDL types in XML and a concept to provide a dynamically created representation for different languages. That means in detail that the reference browser would dynamically create a piece of XML code from the IDL definition and the provided XML documentation string for the IDL type. An appropriate XSL transformation would convert the XML representation into the required language representation. For example a Java developer gets the correct Java mapping for an IDL interface type. The dynamically approach has the advantage that we can (in a second step) analyze the navigation path to a type and can show context specific documentation. That can be very useful for generic types which have different meanings in different contexts. For example a return type of a generic type XEnumeration from function F of interface X. The generated documentation for XEnumeration would show exactly the info which is necessary to understand and use XEnumeration in the context of function F from interface X. It shows for example that the enumeration in this context always contains objects of type Y and even more information for more complex context dependent information.
- required skills/knowledge: Java, XML, XSLT
- Juergen.Schmidt at sun.com
Basic IDE: BASIC/UNO Object Browser
Target of this project is to create an UI component that allows to browse through the structure of UNO objects. Unlike the Basic IDE watch window that recently has been improved to display object properties and their values in an reasonable way the object browser should show the objects' API structure (properties, methods, interfaces, services). It has to be specified if this should refer to the Basic API view (Basic types, no explicit distinction of different interfaces) or the UNO view (UNO types, interface oriented) or if the browser should support two modes allowing to switch between Basic and UNO view. A Basic view is more challenging because it requires Basic related knowledge and probably new functionality in the Basic project. Actually the component is more like a type browser as the objects' static class/interface structure should be displayed, but unfortunately most information are only available for a "living" object using the XtypeProvider interface and the Reflection and Introspection API. Nevertheless it would also make sense to support types directly, e.g. to show the new style UNO service / multi inheritance interfaces.
- required skills/knowledge: Java, C++, StarBASIC, UNO
- Andreas.Bregas at sun.com
Native SQLite driver
SQLite (http://www.sqlite.org/) is a SQL database used as lean backend in a number of applications. The task is to write a native SDBC database driver (resp. finalize the existing skeleton: http://dba.openoffice.org/drivers/sqlite/index.html) for OpenOffice.org, accessing SQLite files efficiently.
- required skills/knowledge: C++, relational database concepts
- recommended skills/knowledge: SQLite API
- useful skills/knowledge: OOo's component technology (UNO)
- Ocke.Janssen at Sun.COM
- Info & Student
- aklitzing at openoffice.org
Writer: Import Filter for Word Perfect Graphics files
- Latest progress and screenshots
The writerperfect import filter for WordPerfect(tm) documents, based on libwpd (http://libwpd.sourceforge.net), was integrated into the OOo2.0. The libwpd is a standalone library also used by other projects like KOffice or AbiWord. Another standalone library that reads WordPerfect graphics files would improve the interoperability with the WordPerfect Office Suite. An import filter for this file format based on this new standalone library can become embedded into OOo in the same way as libwpd. Please find more information at http://fridrich.blogspot.com/2006/04/wordperfect-graphics-conversion-wants.html." The base for this work will be the, already existing, even though unreleased, code of libwpg library (http://sourceforge.net/projects/libwpg)
- Being highly comfortable developping using C++ and Standard Template Library. Have in mind that the code has to be strictly portable.
- Not need of knowing the OpenOffice.org API
- Some hints about possible tasks
- Convert all vector graphics records of WPG2 format. It is already done for WPG1 and it works quite correctly (some problems with colours due to an undocumented record, but fixable since we have a kind of documentation now).
- The parameters of the API callbacks should be as close as possible following the SVG properties for a given object (ellipse, circle, path, ...). So that one can use the
wpg2svgto visualize instantly the conversion result. And like that, it will be easier to use the libwpg library with another libraries that render SVG, i.e. librsvg. And, last but not least, the converter code could be than used with anything that generates SVG.
- Still maintain
wpg2rawin order to be able to create a regression test suite.
- Create a
wpg2odgconverter which outputs SAX messages in odg format (handler independent) + write two handlers (very trivial), one for dumping the content.xml into stdout and other for writing a zipped odg file. Because of the OOo document handler, everything should be preferably contained in one single flat
content.xmlincluding styles and metadata if converted. One can use
styles.xmlin the handler that writes the zipped file if we need to set some default styles for third party applications as we do it in the wannabe KWord import filter and in the CVS version of
- Abstract the stream implementation inside libwpg and make the odg filter core not depend on any specific stream abstaction layer. Only the handlers. Write a sample input stream implementation class using C++ STL input stream classes (get rid of dependency on libgsf).
If this is done in short time, the following things could be done, but optional:
- Rewrite the libwpg API so that it is breakage proof like libwpd is currently, possibly using libwpd's public API (
WPXString). Or extend the libwpd's API if the original one is not corresponding to our needs (i.e. the SVG property
points="X1,Y1 X2,Y2 ... Xn,Yn"could be a problem).
- Convert text strings.
- Find a way to extract the bitmap part of WPG2, decode it (run-length encoding) convert it to some simple raster format (*.bmp ???) and add it [maybe base64 encoded] into the resulting xml.
- Practical guidelines
- For a nice integration with OO.o, no STL types should appear in the API. Many distributions use OO.o built against system libraries and OO.o uses internally stlport. STL and stlport types do not have the same signatures, so bad bad if one links a library compiled using STL from inside OO.o build environment.
- Put the libwpg API in a separate namespace in order to avoid possible conflicts with whatever other library OO.o could use.
- Avoid completely "
using namespace std" statement, since it is possible that it will have problems with one or other of the compilers on one of OO.o platforms.
- Fridrich Strba (fridrich_strba at openoffice dot org)
Does concern : OpenOffice.org 2.0.3 or superior, for Mac OS X port (both Aqua and X11 versions)
Subject proposed by : Eric Bachard
(1) analyze current implementation : design, concerned modules, isolate classes and parameters
(2) propose a design for the new one, using Apple API
(3) write and test a proof of concept
If enough time: (4) implement the solution, with possible backport to X11 version.
- Skills : knowledge of languages C / C++ , using Carbon/Cocoa API, knowledge of font systems and font technology
- Eric Bachard (ericb at openoffice dot org)
UNO service for grammar checkers in OOo Writer
Target of this project is to create an API (Application Programming Interface) and a UNO service to plug in grammar checkers in OpenOffice. Similar to SpellChecker service, the GrammarChecker service will provide text data as Strings to a grammar checker and receive objects as results. It should be able focus wrong sentences with a wavy line and be able to replace them as well.
- required skills/knowledge: Java, C++, UNO