Return-Path: X-Original-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Delivered-To: apmail-incubator-ooo-commits-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 44DAB7DF9 for ; Tue, 29 Nov 2011 21:31:23 +0000 (UTC) Received: (qmail 13713 invoked by uid 500); 29 Nov 2011 21:31:23 -0000 Delivered-To: apmail-incubator-ooo-commits-archive@incubator.apache.org Received: (qmail 13667 invoked by uid 500); 29 Nov 2011 21:31:23 -0000 Mailing-List: contact ooo-commits-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: ooo-dev@incubator.apache.org Delivered-To: mailing list ooo-commits@incubator.apache.org Received: (qmail 13660 invoked by uid 99); 29 Nov 2011 21:31:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Nov 2011 21:31:23 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=5.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO eris.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 29 Nov 2011 21:31:20 +0000 Received: from eris.apache.org (localhost [127.0.0.1]) by eris.apache.org (Postfix) with ESMTP id 35F1A23888EA; Tue, 29 Nov 2011 21:31:00 +0000 (UTC) Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Subject: svn commit: r1208083 - in /incubator/ooo/ooo-site/trunk/content/xml/filter: ./ index.html sveo1eo2.gif sveo1eo3.gif sveo1eo4.gif sveo1eo5.gif sveo1eo6.gif sveo1eo7.gif Date: Tue, 29 Nov 2011 21:31:00 -0000 To: ooo-commits@incubator.apache.org From: kschenk@apache.org X-Mailer: svnmailer-1.0.8-patched Message-Id: <20111129213100.35F1A23888EA@eris.apache.org> Author: kschenk Date: Tue Nov 29 21:30:57 2011 New Revision: 1208083 URL: http://svn.apache.org/viewvc?rev=1208083&view=rev Log: kls-- added xml/filter Added: incubator/ooo/ooo-site/trunk/content/xml/filter/ incubator/ooo/ooo-site/trunk/content/xml/filter/index.html (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo2.gif (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo3.gif (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo4.gif (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo5.gif (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo6.gif (with props) incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo7.gif (with props) Added: incubator/ooo/ooo-site/trunk/content/xml/filter/index.html URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/index.html?rev=1208083&view=auto ============================================================================== --- incubator/ooo/ooo-site/trunk/content/xml/filter/index.html (added) +++ incubator/ooo/ooo-site/trunk/content/xml/filter/index.html Tue Nov 29 21:30:57 2011 @@ -0,0 +1,685 @@ + + + + + + + + + + + + + +

OpenOffice.org +filters using the XML based file format

+



+

+



+

+

Abstract: This document explains the implementation of +OpenOffice.org import and export filter components, focusing on +filter components based on the OpenOffice.org XML file format. It is +intended as a brief introduction to developers that want to implement +OpenOffice.org filters for foreign file formats.

+



+

+



+

+ +



+

+



+

+

1Preliminaries

+

They are several ways to get information into or out of +OpenOffice.org: You can

+
    +

  1. link against the application core,

    +

  2. use the OpenOffice.org API,

    +

  3. use the XML file format.

    +
+

Each of these ways has unique advantages and disadvantages, that I +will briefly summarize:

+

Using the core data structure and linking against the application +core is the traditional way to implement filters in OpenOffice.org. +The advantages this method offers are efficiency and direct access to +the document. However, the core implementation provides a very +implementation centric view of the applications. Additionally, there +are a number of technical disadvantages: Every change in the core +data structures or objects will have to be followed-up by +corresponding changes in code that use them. Hence filters need to be +recompiled to match the binary layout of the application core +objects. While these things are manageable (albeit cumbersome) for +closed source applications, this method is expected to create a +maintenance nightmare if application and filter are developed +separately, as is customary in open sources applications. +Simultaneous delivery of a new application build and the +corresponding filters developed by outside parties looks challenging.

+

Using the OpenOffice.org API (based on UNO) is a much better way, +since it solves the technical problems indicated in the last +paragraph. The UNO component technology insulates the filter from +binary layout (and other compiler and version dependent issues). +Additionally, the API is expected to be more stable than the core +interfaces, and it even provides a shallow level of abstraction from +the core applications. In fact, the native XML filter implementations +largely make use of this strategy and are based on the OpenOffice.org +API.

+

The third (and possibly surprising choice) is to import and export +documents using the XML based file format. UNO-based XML import and +export components feature all of the advantages of the previous +method, but additionally provides the filter implementer with a +clean, structured, and fully documented view of the document. As a +significant difficulty in conversion between formats is the +conceptual mapping from the one format to the other, a clean, +well-structured view of the document may turn out to be beneficial.

+

+2The Innards of an OpenOffice.org Filter Component

+

First, we will try to get an overview of the import and export +process using UNO components. Let's first attempt to gain a view +of...

+

2.1The Big Picture

+

An in-memory OpenOffice.org document is represented by it's +document model. On disk, the same document is represented as a file. +An import component must turn the latter into the former as shown by +the diagram (Illustration 1).

+

+


Illustration + 1: a generic import filter

+

If you make use of UNO, this diagram can be +turned into programming reality quite easily. The three entities in +the diagram, (the file, the model, and the filter) all have direct +counterparts in UNO services. The services themselves may consist of +several interfaces that finally map into C++ or Java classes. The +following diagram annotates the entities with their corresponding +services and interfaces: +

+

+


Illustration + 2: services and interfaces used by an import filter

+

In Illustration 2 (and all following +illustrations) the gray part marks the part a filter implementer will +have to program, while the white parts are already built into +OpenOffice.org.

+

If the implementer decides to make use of the OpenOffice.org API +directly, this diagram is the proper starting point: The filter +writer must create a class that implements the ImportFilter +service. To achieve this, the the InputStream must be +obtained from the MediaDescriptor. The incoming data can +then be interpreted, and the OpenOffice.org document can be +constructed by calling the appropriate methods of the document model. +(The available methods of course depend on the kind of document, as +described by the document service.)

+

2.2Where XML Comes +In...

+

If the advantages of an XML based import or export are desired, +the filter implementer may make use of the existing XML import and +export components. This way, the import logic does not need to deal +with the document model itself, but rather generates the document in +its OpenOffice.org XML file format representation. Done in a naive +way, such a filter component would generate the XML, write it to +file, and then call the built-in XML import to read it again. Since +the XML import is based on the SAX API however, a better way exists: +The import logic calls the SAX API. Since the XML reader component +implements the SAX API, the document thus gets translated from the +foreign format into its XML representation and then into the document +model without the need to use temporary files, or even to render and +subsequently parse an XML character stream.

+

+


Illustration + 3: an XML-based import filter

+

The link between the XML based import filter +and the XML reader is the SAX XDocumentHandler +interface. Using this model, the filter implementer has to implement +a class that takes a MediaDescriptor, reads the +corresponding file, and calls the XDocumentHandler +methods to generate the XML representation. Additionally, a filter +component (labelled "Filter Wrapper" in the diagram) needs +to be written that instantiates XML import component and the +self-written import filter.

+

2.3Waiter, the +Export Please!

+

The export into a foreign format may of course be implemented in +the same fashion. Instead of the ImportFilter +service, the component now implements the ExportFilter +service. An XML-based export filter would implement the document +handler interface itself, and write the resulting document in the +proper format into the location indicated by the MediaDescriptor. +For an XML-based export filter, the schematic looks like this:

+

+


Illustration + 4: an XML-based export filter

+


+

+

2.4A +Second Look at the Filter Wrapper

+

How do the built-in XML export or import components cooperate with +the self-programmed filter? As was briefly mentioned above, the +export filter services consist of two major interfaces: XImporter +or XExporter for import and export, respectively, and +XFilter for both filter types. The former interface +passes in the actual document to be imported to or exported from, +while the XFilter interfaces triggers the filtering +process and passes in the MediaDescriptor which +describes the source or target document.

+

In the case of an XML-based filter, this functionality gets +distributed to two components. For the import, the built-in XML +import component implements the XImporter interface as +well as XDocumentHandler. The XML-based filter +component should implement the XFilter interface, and +additionally provide a way to set an XDocumentHandler. +The filter wrapper then needs to instantiate both components and +connect them by setting the built-in XML import as the document +handler of the XML-based filter. The wrapper can then delegate the +XImporter calls to the XML import and the XFilter +calls to the XML-based filter, thereby implementing the filter +ImportFilter service.

+

The export case is slightly more complicated. The additional +problem is that the filter(…) call of the XFilter +interface provides the MediaDescriptor and +simultaneously controls the filter process. However, in the desired +setup for an XML-based export filter, the built-in XML export +controls the filtering process, but the XML-based filter handles the +file output, and hence needs the MediaDescriptor. +Therefore the filter wrapper has to operate as follows: First it has +to instantiate the XML-based export filter. This filter has to +implement the XDocumentHandler interface. Then it has to +instantiate the XML export, which at instantiation time expects the +document handler as a parameter. The filter wrapper delegates calls +to both the XFilter and the XExporter +interface to the XML export. For calls to the filter method of +XFilter, it additionally has to pass the +MediaDescriptor on to the XML-based export filter. +The means by which this should happen is left to the implementer.

+

2.5The Services

+

We should now have a closer look at the involved services:

+

The service com.sun.star.document.ImportFilter +describes a generic import filter. The core of the service is +provided by the interfaces XImporter and XFilter +(see below). XImporter supplies the filter object with +the target document (in form of an XComponent). The +XFilter is used to actually start the filtering process, +supplying the MediaDescriptor for the source file as a +parameter. Additionally, the ImportFilter service +supports XInitialization and XPropertySet +interfaces. The XInitialization interface serves to pass +parameters to the filter at initialization time, while the +XPropertySet can be used to get information from and +about the filter component. It is generally read-only.

+

The twin of the ImportFilter is the service +com.sun.star.document.ExportFilter. +The main interfaces are XExporter and XFilter. +The XExporter supplies the filter with the source +document, whereas the XFilter starts the filter process. +The MediaDescriptor that gets passed into the +XFilter describes the output file. The ExportFilter +supports the XInitialization and +XPropertySet interfaces, just like the ImportFilter.

+

The com.sun.star.document.MediaDescriptor +finally collects all information about a source or target file to be +imported from or exported to. It contains meta information (such as +the file name), as well as an InputStream which can be +used to actually manipulate the file. Caveat: Objects +obtained from the MediaDescriptor may not be referenced +or otherwise held longer beyond the filter(…) +method call. Doing so (e.g., keeping a reference to the InputStream +obtained from the MediaDescriptor prevents the +InputStream from being closed.)

+

The document model cannot be described by a single service, as it +obviously has to vary greatly, depending on the type of document (e.g., +text or spreadsheet.) An example for a document model service is the +com.sun.star.text.AdvancedTextDocument +service. What is important in this context, is that all document model +services support the XComponent interface.

+

2.6Interfaces

+

The com.sun.star.document.XFilter +interface features only two methods: filter(…) and +cancel(). The former starts the filtering process based +for the given MediaDescriptor, while the latter cancels +an ongoing filter process. XFilter must be implemented +for both, import and export filters.

+

The interface com.sun.star.document.XImporter +is used for setting up an import before the filter(…) +method from the XFilter interface is called. The +XImporter supplies the document with its (empty) target +document, i.e., the document whose content is about to be read from +file.

+

The com.sun.star.document.XExporter +is structured identically to the XImporter interface. It +is used to set the target document, i.e., the document whose content +should be written to file.

+

The com.sun.star.xml.sax.XDocumentHandler +is the core interface for handling XML data in OpenOffice.org. It is +part of the SAX interface. It has methods for all parts of XML +documents, like start or end of elements or runs of characters. The +XDocumentHandler interface is used for both, incoming +and outgoing XML data, thus allowing chaining of components handling +XML. A component that processes XML data should implement the +XDocumentHandler interface. A component that will +generate XML data should call the methods of an XDocumentHandler +to output the events. The XExtendedDocumentHandler, +being derived from XDocumentHandler, provides +an extended version that can also handle comments. If the extended +functionality is desired, the XDocumentHandler should be +queried for the XExtendedDocumentHandler at +runtime. However, implementers should make sure their components +never rely on the presence of extended XExtendedDocumentHandler, +but rather make sure they could also work with the plain +XDocumentHandler. Since all vital parts of XML can be +handled through XDocumentHandler, this should not pose +much of a problem.

+

The interface com.sun.star.lang.XComponent +is the parent interface for all document models. Actual documents +derive from this model to provide model specific functionality, such +as XTextDocument. +A filter will have to query at runtime whether it can handle the +supplied XModel.

+

Initialization of components can be supported through the +com.sun.star.lang.XInitialization +interface.

+

Properties of the filters can be queried using the +com.sun.star.beans.XPropertySet +interface. The names of the supported properties are part of the +service description. In general, XPropertySet +implementations support both reading and writing, but the intended +use for filter components is to be read-only.

+



+

+

2.7Built-in +Components

+

All of OpenOffice.org's applications have built-in XML import and +export components. The component names are summarized in the +following table:

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
+

Application

+ 		+

XML import

+ 		+

XML export

+
+

Writer

+ 		+

com.sun.star.comp.Writer.XMLExporter

+ 		+

com.sun.star.comp.Writer.XMLImporter

+
+

Calc

+ 		+

com.sun.star.comp.Calc.XMLExporter

+ 		+

com.sun.star.comp.Calc.XMLImporter

+
+

Chart

+ 		+

com.sun.star.comp.Chart.XMLExporter

+ 		+

com.sun.star.comp.Chart.XMLImporter

+
+

Impress

+ 		+

com.sun.star.comp.Impress.XMLExporter

+ 		+

com.sun.star.comp.Impress.XMLImporter

+
+

Draw

+ 		+

com.sun.star.comp.Draw.XMLExporter

+ 		+

com.sun.star.comp.Draw.XMLImporter

+
+

Additionally, the XML reader and writer components should be +mentioned, even though they have not been discussed in the previous +chapters. These two components implement the XML reader (or parser) +and writer (or unparser) components used by OpenOffice.org for +writing all it's XML files. They implement (XML writer) or use (XML +parser) the XDocumentHandler interface. In some sense +they could be considered XML-based filters, since they read or write +character streams and turn them into SAX function calls. Their names +are com.sun.star.xml.sax.Writer and +com.sun.star.xml.sax.Parser, respectively.

+

+2.8Registering a New Filter With the Application

+

There is a final, crucial step that will not be covered here: +Registering a filter with the application. The registration process +will make sure that the application knows the filter, and also knows +which files the filter can be applied to. The filter registration is +described here. +

+

3Code examples

+

This chapter is intended to give brief code examples for the +crucial steps in creating XML-based import or export filters. We'll +start with the filter wrapper, followed by short examples for +importing into and export from the XML filters.

+

+3.1The Filter Wrapper: Instantiating the XML Filters

+

The filter wrapper needs to instantiate the built-in XML import or +export components. The following code snippet will demonstrate this +for an XML-based export filter.

+
+using namespace ::com::sun::star;
+
+// Instantiate the XML export filter
+
+// Prerequisites: 
+// 1) a service factory, 
+// 2) a document handler, 
+// 3) a string with the service name.
+
+// Obtain the service factory
+uno::Reference< lang::XMultiServiceFactory > xServiceFactory = …;
+
+// Obtain (or create) the XML-based output filter. It has to implement
+// the XDocumentHandler interface, so the export component can write to it.
+uno::Reference< xml::sax::XDocumentHandler > xHandler = … <your filter> …; 
+
+// Prepare arguments passed to the XML export filter:
+// The XML-based filter in form of an XdocumentHandler.
+// Arguments are passed by a sequence of Any. 
+// Our sequence will contain only 1 element.
+uno::Sequence<uno::Any> aArgs(1);
+aArgs[0] <<= xHandler;
+
+// Instantiate the exporter from the factory.
+::rtl::OUString sService =
+    ::rtl::OUString::createFromAscii("com.sun.star.comp.Writer.XMLExporter");
+
+uno::Reference< document::XExporter > xExporter(
+   xServiceFactory->createInstanceWithArguments(sService),	aArgs ),
+   uno::UNO_QUERY );
+ASSERT( xExporter.is(), "can' instantiate XML exporter" );
+
+// Now we have the two components in xHandler and xExporter and can start 
+// calling the XFilter and XExporter methods. Note that the xHandler needs
+// to be informed about its MediaDescriptor.

+3.2Exporting +through the XML filter

+

The following code snippet could be located in a filter wrapper +for an XML-based export filter. The following two methods implement +the gist of a filter wrapper for an XML-based export. They are really +simple because the filter wrapper doesn't really do much of its own. +It only delegates to it's two components.

+
using namespace ::com::sun::star;
+
+void SAL_CALL <filter wrapper>::setSourceDocument( 
+	const uno::Reference<lang::XComponent>& xComponent )
+{
+    // delegate to XExporter of the built-in XML export
+    xExporter->setSourceDocument( xComponent );
+}
+
+sal_Bool SAL_CALL <filter wrapper>::filter( 
+    const uno::Sequence<beans::PropertyValue>& aDescriptor )
+    throw(uno::RuntimeException)
+{
+    // set MediaDescriptor at XML-based export filter
+    ...
+
+    // get access to XFilter interface of XML export
+    uno::Reference<document::XFilter> xFilter(xExporter, uno::UNO_QUERY);
+    xFilter->filter(aDescriptor);
+}
+

+3.3Import: +Writing into the XML Filter

+

The next example should detail how an import filter would +communicate with the XML import component. Basically, it only needs +to call the XDocumentHandler methods. The following code +implements the notorious "Hello World!" program as an +OpenOffice.org import filter.

+
+using namespace ::com::sun::star;
+
+// instantiate the XML import component 
+::rtl::OUString sService =
+    ::rtl::OUString::createFromAscii("com.sun.star.comp.Writer.XMLImporter")
+uno::Reference<xml::sax::XDocumentHandler> xImport(
+    xServiceFactory->createInstance(sService), uno::UNO_QUERY );
+ASSERT( xImport.is(), "can't instantiate XML import" );
+
+// OK. Now we have the import. Let's make a real simple document.
+
+// a few comments:
+// 1. We will use string constants from xmloff/xmlkywd.hxx
+// 2. For convenience, we'll use a globally shared attribute list from the 
+//    xmloff project (xmloff/attrlist.hxx)
+// 3. In a real project, we would pre-construct our OUString, rather than use
+//    the slow createFromAscii(…) method every time.
+
+// We will write the following document: (the unavoidable 'Hello World!')
+// <office:document 
+//      office:class="text" 
+//      xmlns:office="http://openoffice.org/2000/office" 
+//      xmlns:text="http://openoffice.org/2000/text" >
+//   <office:body>
+//     <text:p>Hello World!</text:p>
+//   </office:body>
+// </office:document>
+
+SvXMLAttributeList aAttrList;
+
+xHandler->startDocument();
+
+// our first element: first build up the attribute list, then start the element
+// DON'T FORGET TO ADD THE NAMESPACES!
+aAttrList.AddAttribute(
+    ::rtl::OUString::createFromAscii("xmlns:office"), 
+    ::rtl::OUString::createFromAscii("CDATA"), 
+    ::rtl::OUString::createFromAscii("http://openoffice.org/2000/office") );
+aAttrList.AddAttribute(
+    ::rtl::OUString::createFromAscii("xmlns:text"), 
+    ::rtl::OUString::createFromAscii("CDATA"), 
+    ::rtl::OUString::createFromAscii("http://openoffice.org/2000/text") );
+aAttrList.AddAttribute(
+    ::rtl::OUString::createFromAscii("office:class"), 
+    ::rtl::OUString::createFromAscii("CDATA"), 
+        ::rtl::OUString::createFromAscii("text") );
+xHandler->startElement(
+    ::rtl::OUString::createFromAscii("office:document"),
+    aAttrList );
+
+// body element (no attributes)
+aAttrList.clear();
+xHandler->startElement(
+    ::rtl::OUString::createFromAscii("office:body"),
+    aAtrList );
+
+// paragraph element (no attributes)
+aAttrList.clear();
+xHandler->startElement(
+    ::rtl::OUString::createFromAscii("text:p"),
+    aAtrList );
+
+// write text
+xHandler->characters(
+    ::rtl::OUString::createFromAscii("Hello World!") );
+
+// close paragraph
+xHandler->startElement(
+    ::rtl::OUString::createFromAscii("text:p"),
+
+// close body
+xHandler->endElement(
+    ::rtl::OUString::createFromAscii("office:body") );
+
+// close document element
+xHandler->endElement(
+    ::rtl::OUString::createFromAscii("office:document") );
+
+// close document
+xHandler->endDocument();
+

+4Appendix

+

4.1 Other Uses

+

This chapter briefly mentions a few other uses of XML-based filter +components that provide additional value and versatility.

+

In some circumstances, it may be desirable to have standalone +format conversion tools. This would, for example, enable batch +conversion of legacy documents. The XML-based filter components allow +us to do that with little extra effort. Let us recall that an +XML-based import filter uses OpenOffice.org's built-in XML import to +generate the document. It calls the (generic) XDocumentHandler +interface after it has been supplied with the XDocumentHandler +implementation by the filter wrapper. Now if the filter wrapper +instead supplies the XML-based import filter with the XML writer +component (which implements the XDocumentHandler +interface as well), then the XML writer component will output the XML +as a character stream to disk. Thus we have created the desired +standalone conversion utility by only implementing a new filter +wrapper!

+

+


Illustration + 5: a standalone file format conversion utility

+

A different possible use is the chaining of +XML-based filters. Suppose the foreign file format in question is +also based on XML. Now it doesn't make sense to re-implement the XML +parser inside that component, so it seems natural to use the existing +parser (or unparser) component. This way, our import (or export) +filter would have to implement the XDocumentHandler +interface for its input, and also use an XDocumentHandler +interface for its output. The resulting implementation is sketched in +Illustration 6. Note that such XML to XML filters could be chained +arbitrarily.

+

+


Illustration + 6: a filter chain with one element

+

Note that, if the other application is also an +OpenSource application, it could use UNO component technology as +well, and thus use the very same filter components for its own import +and export. A filter converting from the foreign XML into +OpenOffice.org XML would be an import filter for OpenOffice.org, and +simultaneously an export filter for the other application. +

+

As OpenOffice.org is being developed further, it becomes likely +that eventually changes to the file format will have to be made. It +is mandatory to supply users with the ability to read and write the +old formats of course. This could indeed be handled by an XML to XML +transformation, with one format being the old OpenOffice.org XML +format, and the other being the new format.

+

Note that such a filter could also be used by users of the older +versions to read and write documents in the new format! Additionally, +it could be chained between other XML-based import or export filters, +allowing users to utilize import and export filters for versions +other than their own. Essentially, this would achieve a decoupling of +application, filter, and file format version. The opportunities this +opens up are quite amazing: If a new file format is implemented, +users would not be forced to upgrade their application to make use of +the new filter. Also, users of newer application versions could still +use filters developed for the older format. +

+

4.2Resources

+

The following resources may provide additional information:

+ +
+

The xmloff development +team
Summarized by dvo

+ + Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/index.html ------------------------------------------------------------------------------ svn:eol-style = native Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo2.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo2.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo2.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo3.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo3.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo3.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo4.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo4.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo4.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo5.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo5.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo5.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo6.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo6.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo6.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif Added: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo7.gif URL: http://svn.apache.org/viewvc/incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo7.gif?rev=1208083&view=auto ============================================================================== Binary file - no diff available. Propchange: incubator/ooo/ooo-site/trunk/content/xml/filter/sveo1eo7.gif ------------------------------------------------------------------------------ svn:mime-type = image/gif