Configuring a Filter in OpenOffice.org

OpenOffice.org Developer's Guide

Office Development

< Previous Section

Next Section >

• OpenOffice.org Application Environment

• Desktop Environment
• Framework API

• Frame-Controller-Model Paradigm in OpenOffice.org
• Frames
• Controllers
• Windows
• Dispatch Framework

• Using the Desktop
• Using the Component Framework

• Getting Frames, Controllers and Models from Each Other
• Frames
• Controllers
• Models
• Window Interfaces

• Creating Frames Manually
• Handling Documents

• Closing Documents
• Storing Documents

• Using the Dispatch Framework

• Command URL
• Processing Chain
• Dispatch Process
• Dispatch Results
• Dispatch Interception

• Java Window Integration

• Common Application Features

• Internationalization

• Overview and Using the API
• Implementing a New Locale

• Linguistics

• Using Spellchecker
• Using Hyphenator
• Using Thesaurus
• Events
• Implementing a Spell Checker
• Implementing a Hyphenator
• Implementing a Thesaurus

• Integrating Import and Export Filters

• Filtering Process
• Filters
• Type Detection and its Configuration
• Properties of a Type
• Properties of a Filter
• Filter Options
• Properties of a FrameLoader
• Document API Filter Development

• XML Based Filter Development

• Writing the Filtering Component
• The Importer
• The Exporter
• XML Filter Detection

• Number Formats

• Managing Number Formats
• Applying Number Formats

• Document Events
• Path Organization

• Path Settings
• Path Variables

• Predefined Variables
• Custom Path Variables
• Resolving Path Variables

• OpenOffice.org Single Sign-On API
• RDF metadata

< Previous Page

Next Page >

As previously discussed, the whole process of loading and saving content works generically in many components and can be adapted to the needs of a user through the addition of custom modules or the removal of others. All this information about services and parameters are organized in a special configuration branch of OpenOffice.org called org.openoffice.Office.TypeDetection. The principal structure is shown below:

Structure of org.openoffice.Office.TypeDetection Configuration Branch

As shown on the left, the file consists of lists called sets. The list items are described by the structures shown on the right to which the arrows point. It works similar to 1:n relations in a database. Every filter, frame loader, detector is registered for one or multiple types. The detection of the proper type is important for the functionality of the whole system. If the right loader or filter cannot be found, the load or save request does not produce the right results.

To extend OpenOffice.org to load or save new content formats, a new type entry is added describing the new content. Furthermore, a filter item is registered for this new type. An optional and recommended change for a detector can be done.

It is not a good idea to edit the configuration branch files directly to make these changes. It is better to use the configuration API to do so, because the format of the file may be changed in the future. The properties describing the components, such as types and filters, are always the same and are not likely to be changed or in an incompatible manner. It is better to add entries by specifying their properties using the API only. To make this easier for external programmers, this manual provides a OpenOffice.org Basic script that is used for that purpose called regfilter.bas. The work to be done by the filter programmer is to provide an ini file that includes the properties and start the basic script inside OpenOffice.org. The script reads the file and uses it to change the configuration package. These changes are done for the user layer of the configuration, so it is possible to restore the original state. There is also an example ini file in the samples folder for this manual that can be used for your own purposes called regfilter.ini.

TypeDetection

Every content to be loaded must be specified, that is, the type of content represented in the OpenOffice.org must be well known in OpenOffice.org. The type is usually document type,.however, the results of active contents, for example, macros, or database contents are also described here.

A special service com.sun.star.document.TypeDetection is used to accomplish this. It provides an API to associate, for example, a URL or a stream with the extensions well known to OpenOffice.org, MIME types or clipboard formats. The resulting value is an internal unique type name used for further operations by using other services, for example, com.sun.star.frame.FrameLoaderFactory. This type name can be a part of the already mentioned MediaDescriptor.

It is not necessary or useful to replace this service by custom implementations.,It works in a generic method on top of a special configuration. Extending the type detection is done by changing the configuration and is described later. It is required to make these changes if new content formats are provided for [OpenOffice.org, because this is the reason to integrate custom filters into the product.

The TypeDetection also employs the com.sun.star.document.ExtendedTypeDetection that examines the given resource and confirms the unique type name determined by TypeDetection. The MediaDescriptor is updated, if necessary, and a unique type name is returned.

ExtendedTypeDetection

Based on the registered types, flat detection is already possible, that is,. the assignment of types, for example, to a URL, on the basis of configuration data only. Tlat detection cannot always get a correct result if you imagine someone modifying the file extension of a text document from .odt to .txt.. To ensure correct results, we need deep detection, that is, the content has to be examined. The com.sun.star.document.ExtendedTypeDetection service performs this task. It is called detector. It gets all the information collected on a document and decides the type to assign it to. In the new modular type detection, the detector is meant as a UNO service that registers itself in the OpenOffice.org and is requested by the generic TypeDetection mechanism, if necessary.

To extend the list of the known content types of OpenOffice.org, we suggest implementing a detector component in addition to a filter. It improves the generic detection of OpenOffice.org and makes the results more secure.

Inside OpenOffice.org, a detector service is called with an already opened stream that is used to find out the content type. In case no stream is given, it indicates that someone else uses this service, for example, outside OpenOffice.org). It is then allowed to open your own stream by using the URL part of the MediaDescriptor. If the resulting stream is seekable, it should be set inside the descriptor after its position is reset to 0. If the stream is not seekable, it is not allowed to set it. Please follow the already mentioned rules for handling streams.

Content on this page is licensed under the Public Documentation License (PDL).

Content on this page is licensed under the Public Documentation License (PDL).