Impress has two different kinds of export filters. Some of them can be used for „SaveAs“ (like PowerPoint and StarOffice binary filters), some of them are only accessible throuh the „Export“ function. While the first kind of filters can be used via API ( com::sun::star::XStorable::store(To/AsURL) ), the second kind of filters can't. We want to change this, and the most natural way is to use the same API for both. The „Export“ functionality in the user interface will use this API in the same way the „SaveAs“ functionality does it, with some slight differences:
„Export“ uses storeToURL, SaveAs uses storeAsURL. The difference is, that the latter method also changes the URL of the document in memory.
This implies that it's not possible to use a pure export filter in the storeAsURL method, because the generated file would not be importable. Pure export filters can only be used in the storeToURL method. Using a wrong filter will cause throwing of an exception.
To ease the implementation to find out which filters shall be
used in which funtion, „Export“ uses only pure export
filters, while „SaveAs“ only uses filters that can both
import and export. If an Import/Export filter should also be used
for „Exporting“, another filter must be created in the
filter configuration for the same file type, but without the
„Import“ flag set. If new filters are created in the
configuration, they can get the same UI names as the old
import/export filter (because they won't be seen in the same file
dialog), but must get a new internal filter name. Filter names of
import filters must not be changed, because they may have been used
before. If an import filter shall not be used in the „SaveAs“
dialog, they must not have the „Export“ flag set, use a
different filter ony for export.
We will have three kind of
filters then: pure import filter (document can't be stored over the
old file after loading), pure export filters (saved document is not
loadable again, so this filter will be used only in the „Export“
function) and combined import/export filters.
Export filters support an additional property „ExportSelection“ in the media descriptor, that tells the filter to export only the current selection and not the whole document. This will be reflected by a checkbox in the file dialog.
All parameters to configure the export operation will be passed in the „FilterData“ property of the media descriptor that is passed to the filter (implemented as sequence<PropertyValue>). If there is no configuration data given, the filter must use some suitable defaults.
In the user interface it's also possible to provide a UI component that retrieves the needed information and adds it to the media descriptor. If the filter wants, it can also store the input in a configuration file and use it as default in the next operation without given parameters. Here also the „UserData“ parameter of the Typedetection.xml can be used for storing the configuration. This is only possible for data representable as a string, but the advantage is that the default for the filter can be specified in the Typedetection.xml, not in the source code. In this case the filter implementation first must look for „FilterData“, then for „UserData“.
The UI component is identified by an implementation name in the filter configuration (Typedetection.xml). The UI code for the „Export“ function will look into the configuration and instantiate the UI component. The exact interface for this component will be specified in a different proposal, it should use a media descriptor as input/output paremeter and return a boolean value, that will be set to „false“ if the user cancels the operation.
The UI component is not restricted for usage inside the „Export“ functionality. We will also have this new feature for the filters used for loading and storing documents.
At the end we will have one single API for storing or exporting documents, one single set of filters with a common API, only the two UI functions will use it in two different ways. This API also enables other developers to provide export filters for OO.o documents using our filter API, with the additional capabilities of exporting only parts of the document.
Of course this mechanism can be used in other office components also.
ToDo's:
Extend Typedetection.xml for new implementation name for UI component and change filtercache implementation. Make sure that the compatibilty to 6.0 is preserved.
Provide properties „ExportSelection“ and „FilterData“ in media descriptor and SfxItemSet at SfxMedium.
Divide filters into import, export and import/export filters.
Create interface for the UI component.
Implement a UI component for all current export filters and register it for all of them in the configuration.
Move the old „core“ code from the FuExport to the ConvertTo method in Impress.
Offer SID_EXPORT in SFX that will look for the UI component and feed the API call.
Check for pure export filters in storeToURL and for pure import filters in store calls.
Enable the current code for loading and storing documents to use the filters UI components.
Document all parameters of our current export filters.