Quote:
Originally Posted by Mackx
If I look at the differences between the image-plugin and pdf-plug and look at the functionality for which mobipocket might be used. Then I suspect the following call:
g_instances_table.add_interface<IPluginDocMarker>( this); in document_impl.cpp.
I am not sure if this interface is also needed for search functionality.
|
I think the PDF plugin also uses the low level interface, and my plugin has exactly the same supported interfaces and behaviour (unless I unknowingly changed something important).
The IPluginDocMarker interface seems to be used for the table of contents and bookmarks and doesn't seem relevant for the decision whether the plugin uses the high or the low level interface.
All interface objects are accessed through an IPluginUnknown query_interface call, implemented in plugin_impl/library_impl.cpp. The only interface actually queried is IPluginLibrary, so I think uds doesn't know about the other interfaces supported by the plugin, at this stage.
The IPluginLibrary interface has three methods: create_document (for the low level interface), create_reader (for the high level interface) and is_supported_document. Of these, only is_supported_document is called by uds before it goes wrong. is_supported_document returns PLUGIN_TRUE if the file has a .djvu extension.
The comments in the IPluginLibrary header file are the only references to the high and low level interfaces I could find, but there isn't any information about when either of them is used. I have tried to set the function pointer of create_reader explicitly to 0 (NULL), but that didn't seem to help.