<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<head>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
	<TITLE>Developer projects</TITLE>
	<META NAME="GENERATOR" CONTENT="StarOffice 8  (Linux)">
	<META NAME="CREATED" CONTENT="20070211;19270200">
	<META NAME="CHANGEDBY" CONTENT="Kai Ahrens">
	<META NAME="CHANGED" CONTENT="20070211;19485000">
	<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
	<SCRIPT SRC="/js/dba_default.js"></SCRIPT>
	<STYLE TYPE="text/css">
	<!--
		H2 { background: transparent; page-break-before: auto }
		H2.western { font-family: "Albany", sans-serif; font-size: 14pt; font-style: italic }
		H2.cjk { font-family: "HG Mincho Light J"; font-size: 14pt; font-style: italic }
		H2.ctl { font-family: "Arial Unicode MS"; font-size: 14pt; font-style: italic }
		H2.ueberschrift-western { font-family: "Albany", sans-serif; font-size: 14pt; font-style: italic }
		H2.ueberschrift-cjk { font-family: "HG Mincho Light J"; font-size: 14pt; font-style: italic }
		H2.ueberschrift-ctl { font-family: "Arial Unicode MS"; font-size: 14pt; font-style: italic }
	-->
	</STYLE>
</head>
<body LANG="de-DE" DIR="LTR">
<P STYLE="margin-bottom: 0cm"><B>Project Sections</B>: <A HREF="../index.html">Home</A>
| <A HREF="index.html"><B>Development</B></A><BR><B>Development
Sections</B>: <A HREF=""><B>Developer Projects</B></A> 
</P>
<HR>
<H1><A NAME="dba_dev_projects"></A>Developer Projects</H1>
<P>Below is a list of projects which could be implemented by
interested developers. Most of these projects are relatively
self-contained, and do not require too much knowledge about OOo's
code infrastructure.</P>
<P>Note that this list doesn't claim to be a complete repository of
what will be done in the near/medium future. There may be items on
the list which will never be realized, and there definately are items
which are not on the list, but will be implemented.</P>
<P>If you are interested in anything from the list, please speak at
<A HREF="mailto:dev@graphics.openoffice.org">dev@graphics.openoffice.org.</A>
We'll gladly help you to get started on this.</P>
<P>Also, make sure you don't miss <A HREF="http://development.openoffice.org/todo.html">OpenOffice.org's
global TODO list</A>, which also contains interesting projects for
developers.</P>
<H3>General Notes</H3>
<P>Whenever we talk about user interface work, this implies working
with VCL, the Visual Class Library in OpenOffice.org. If you are not
familar with it, you will curse it, since especially some of the
older parts never heard the word &quot;documentation&quot;. On the
other hand: In opposite to the native platform controls, everything
is there as source code, so if you like &quot;learning by debugging&quot;,
you will love VCL 
<IMG SRC="../images/smile.gif" NAME="Grafik1" ALT="smile" ALIGN=BOTTOM WIDTH=19 HEIGHT=19 BORDER=0>.</P>
<P>Additionally, be aware of the fact that feature implementations in
OpenOffice.org require a specification (you may visit <A HREF="http://specs.openoffice.org/">the
specifications project</A> for more information). There's a rule that
nothing is checked into the master branch which doesn't have a
specification which all stakeholders agreed upon - so unlike other
open source projects you may know, the specification really is an
important part. Stakeholders are: the documentation team, the user
experience team, the quality assurance team, and development.
Usually, one representative from every team needs to accept your
specification.</P>
<P>Well, don't let this hinder you in starting. Just be aware that
there will be a time when a specification is finally needed. Most
developers don't like writing such documents (and some people even
claim that <A HREF="http://www.joelonsoftware.com/articles/fog0000000034.html">they
shouldn't</A>). Thus, you need to clarify who will take this for you,
if you can't/don't want.</P>
<P>A note about the effort: This is a rather rough guess at the
moment. In general, it may be a good idea to add two or more weeks or
so simply for becoming familar with the code and some concepts, so if
it is &quot;2 weeks&quot;, don't expect to start today and finish it
in 14 days ...</P>
<HR>
<H2 CLASS="ueberschrift-western">Creating a Visio filter for OOo Draw</H2>
<P>OOo currently lacks support for a Visio import filter, so that it
would be good to have someone starting to write such a filter from
scratch utilizing the OOo API for direct creation of the document or
the ODF format as input format to be loaded by the OOo application.
Although a full blown filter seems to be unrealistic to be written
within the short timeframe, large parts of Visio documents should be
able to be filtered correctly.</P>
<P><I>Required skills/knowledge:</I> good C++ or Java expertise,
graphics programming</P>
<P><I>Recommendend skills/knowledge:</I> Visio file format / ODF or
OOo API</P>
<P><I>Contact:</I> <A HREF="mailto:Sven.Jacobi@Sun.COM">Sven.Jacobi@Sun.COM</A></P>
<HR>
<H2 CLASS="ueberschrift-western">Creating a Freelance Graphics filter
for OOo Draw</H2>
<P>OOo currently lacks support for a Lotus freelance import filter,
so that it would be good to have someone starting to write such a
filter from scratch utilizing the OOo API for direct creation of the
document or the ODF format as input format to be loaded by the OOo
application. Although a full blown filter seems to be unrealistic to
be written within the short timeframe, large parts of Freelance
documents should be able to be filtered correctly.</P>
<P><I><SPAN STYLE="text-decoration: none"><SPAN STYLE="font-weight: medium">Required
skills/knowledge</SPAN></SPAN></I>: good C++ or Java expertise,
graphics programming</P>
<P><I>Recommendend skills/knowledge:</I> Freelance Graphics file
format / ODF or OOo API</P>
<P><I>Contact:</I> <A HREF="mailto:Sven.Jacobi@Sun.COM">Sven.Jacobi@Sun.COM</A></P>
<HR>
<H2 CLASS="ueberschrift-western">Creating an OrgChart component</H2>
<P>Currently, the OpenOffice.org package does not have a tool to
allow users to easily create and manipulate organizational charts. 
OpenOffice.org's main competitor, the Microsoft Office suite, does
provide such a capability for its users. Therefore the addition of
such a tool to OpenOffice.org will help.</P>
<P>OpenOffice.org to attract new users and retain current users. The
user will be able to create org charts using a library of pre-defined
objects.  These objects will support multiple user-definable fields.
Objects will be manipulated using a drag-and-drop interface.  An
auto-alignment function will allow the user to place objects easily. 
</P>
<UL>
	<LI><P>The following features should be included in the OrgChart
	component:</P>
	<LI><P>A library of pre-defined object shapes that can be used</P>
	<LI><P>A drag-and-drop interface for manipulating objects</P>
	<LI><P>An auto-alignment function</P>
	<LI><P>A library of chart templates</P>
	<LI><P>&quot;Smart&quot; connectors to allow users to easily connect
	objects</P>
</UL>
<P><I>Required skills/knowledge:</I> good C++ / Java expertise,
graphics programming</P>
<P><I>Recommendend skills/knowledge:</I> ODF or OOo API</P>
<P><I>Contact:</I> <A HREF="mailto:Christian.Lippka@Sun.COM">Christian.Lippka@Sun.COM</A></P>
<HR>
<H2 CLASS="ueberschrift-western">Creating a native Quartz2D canvas
for Mac OSX</H2>
<P>The current presentation module relies on a component model,
allowing to use different backends for rendering purposes. Currently,
there are backends available for MS DirectX and for the internally
used VCL graphics layer. For Mac users, it would be great to have an
optimized rendering backend using the Quartz2D API.</P>
<P><I>Required skills/knowledge:</I> MacOSX and Quartz2D API</P>
<P><I>Recommendend skills/knowledge:</I> enhanced graphics
programming</P>
<P><I>Contact:</I> <A HREF="mailto:Thorsten.Behrens@Sun.COM">Thorsten.Behrens@Sun.COM</A></P>
<HR>
<H2 CLASS="western">Creating a MultiPage-Tiff importer</H2>
<P>MultiPage-Tiff files are oftenly generated from FAX documents and
sent via Email, in case the recipient doesn'n own a FAX machine by
herself, or to just embed it into the final document.</P>
<P>The current TIFF filter is able to import such files. We now need
to ask the user what the destination for his Multipage TIFF file
should be: just a simple graphics import or a more sophisticated
graphics import, assigning each of the several frames of the TIFF
file to a consecutive page of the current/new document.</P>
<P><BR><BR>
</P>
<P><I>Required skills/knowledge:</I> C++</P>
<P><I>Recommendend skills/knowledge:</I> TIFF format knowledge, OOo
internals about the filtering process</P>
<P><I>Contact:</I> <A HREF="mailto:Sven.Jacobi@Sun.COM">Sven.Jacobi@Sun.COM</A></P>
<HR>
<H2 CLASS="ueberschrift-western">Enhanced SVG export filter</H2>
<P>Due to the limitations the old export filter has, there have been
made some efforts in the past to create an optimized export filter.
This already available filter offers the possibility to create SVG's
containing multiple slides, that you can navigate trough with mouse
or key events. The functionality of this filter module is comparable
with the functionality of the Flash export filter contained in
StarOffice 7, which means that it doesn't offer any slide
transitioning effects, object animations or sound support at the
moment although the current internal structure of the new filter has
been prepared to handle such topics more easily.</P>
<P>Availability in this case means that there exist some source code
inside the filter project of StarOffice, that can be build upon
request. Due to the fact that there have been strong requests for a
filter containing such functionality for quite a long time, the 
suggestion  in this case would be to release a development snapshot
on OOo within a package component.</P>
<P><I>Required skills/knowledge:</I> good C++, graphics programming</P>
<P><I>Recommendend skills/knowledge:</I> SVG specification, OOo API</P>
<P><I>Contact:</I> <A HREF="mailto:Kai.Ahrens@Sun.COM">Kai.Ahrens@Sun.COM</A></P>
<HR>
<H2 CLASS="western">SVG Tiny import filter</H2>
<P>Their have been several inquiries in the past, asking for a SVG
import support in StarOffice. Beside integrating SVG graphics into a
document, people are also asking for a vector  based interchange
format that doesn't rely on the proprietary WMF/EMF
(WindowsMetafile/EnhancedMetafile) format offered by MS. This format
could be used to store OLE replacement graphics within our XML file
format or to offer SVG content via Clipboard.</P>
<P>Due to the fact, that SVG itself is a very complex format,
offering support for stylesheets, scripting, animations, complex
clipping, (clip) pathes and many more sophisticated features, the
effort to create a full featured SVG import would be way beyond our
current possibilities reagarding development resources. But taking
into account, that such a full blown feature set is not needed for
interchange features, a possible way to go would be to write a SVG
import filter on our own, that offers support for the 'SVG Tiny'
format, that is a subset of the pure SVG specification, concentrating
mostly on graphics primitives, which is exactly what we need in this
case. 
</P>
<P>Taking a look at the export side, we should take care of offering
the possibility to save content only with respect to this special
'Tiny' subset, so that we're able to read our own created SVG files.</P>
<P><I>Required skills/knowledge:</I> good C++, graphics programming</P>
<P><I>Recommendend skills/knowledge:</I> SVG specification, OOo API</P>
<P><I>Contact:</I> <A HREF="mailto:Kai.Ahrens@Sun.COM">Kai.Ahrens@Sun.COM</A></P>
</body>
</HTML>