A Pluging that calls a plugin?

[macr0t0r]

So, I'm trying to bend Calibre to my exact and precise will. I have a Sony PRS-500, so it's pretty picky about links (will only reference a division). Since most of my eBook collection is in Non-DRM eReader format, I've created a FileType "on_import" plugin that converts the PDB file to a perfectly formatted HTML file (with link and link-backs to footnotes). However, only the single HTML file gets into the database.

Bottom line: I'd like to pass the resulting HTML file to the "HTML to Zip" feature so that all of the links and images get collected and placed into Calibre.

It appears that the HTML to Zip is not truly a plugin (at least it's not in the Plugin folder of the source code). Is there a way I can call it or refer to it in my plugin? Thanks!

- Jim

[user_none]

Originally Posted by macr0t0r

Since most of my eBook collection is in Non-DRM eReader format, I've created a FileType "on_import" plugin that converts the PDB file to a perfectly formatted HTML file...

I'm assuming you are doing this because of the limitations of the current PML to HTML code. Would you care to share your changes so the current PML to HTML conversion can be improved?

Originally Posted by macr0t0r

It appears that the HTML to Zip is not truly a plugin (at least it's not in the Plugin folder of the source code). Is there a way I can call it or refer to it in my plugin?

HTML2ZIP is a FileTypePlugin and you should be able to call it just like any other plugin. It is located in calibre.customize.builtins. It isn't in the plugins folder because it is a builtin plugin.

[macr0t0r]

Thanks for the response. So, a couple notes:

PML to HTML code
I'm not sure how much you'd want my code. The purpose of my code is to structure the HTML specifically for the Sony PRS-500 so that the HTML2LRF code makes as near perfect reproduction of the eReader file as possible:
1. Every link target creates a new <div> (as required by the LRF).
2. Footnotes are changed into links, and the footnote itself has a link back to the original text.
3. It assumes no inheritance and there are no "layered" span tags. All text is incapsulated with a single-level span tag. Every time the format changes or there is a new division, then the current span is closed and new one is created with all of the styles defined. It makes for some pretty busy-looking HTML code, but it was the only way to get consistent font and format in the resulting LRF format.

I really doubt my HTML CSS code would pass the ePub test. However, I suppose my footnote/sidebar code could be of use. I haven't checked to see if Calibre already handles it.

Calling another FileTypePlugin
Truth be told, I don't know HOW you call a plugin. I know how to MAKE a plugin that Calibre calls. I found the HTML2ZIP class in the builtins.py (thank you), but for some reason I just couldn't get it to work right. I apologize that I don't have the details with me right now.

In any case, I decided to take another route. I discovered that "adding" a file in the MetaData editor executes the same plugins, so my little project made it impossible for me to add the original eReader file to my Library. I want to keep that file as well for reading on my phone.

So, my workflow is this:
1. I add the eReader file.
--a. My plugin generates the folder with the html and images, but returns the path to the original eReader file.
--b. The default PDB plugin then pulls in a minimal amount of metadata and adds the file to the library.
2. I then open the metadata and add the html file.
--a. The default HTML2ZIP program gathers all links and adds the zip file to my library
3. I then use the new "use metadata from this file" to update the metadata from the zip file.
4. I then convert from the zip file to LRF.

Now, each book of mine is in 3 formats: PDB for our phones, ZIP for FBReader on my Nokia tablet, and LRF for my wife's Sony Reader.

A bit laborious, but it's not like I'm getting 5 new books a day. I think the main thing I want to work on is improving the metadata retrieval from PDB and PML files. I could look into your PML2HTML stuff but...man...it's going to take me some time to figure out that whole path. That code really jumps around a lot.

I DO have a question remaining: If a plugin of a high priority returns a file with a different extension, does Calibre re-evaluate that extension and fires off the appropriate plugin and/or builtin function before adding the file to the database? In my original plugin, I converted the PDB to an HTML file (with links to images), but Calibre then just added the individual HTML file to the database. I had to add a book and re-select the html file to get HTML2ZIP to run and generate the zip file. Is that a bug or a feature?

- Jim

[kovidgoyal]

You can just have your plugin create the ZIP file.

If you want to use the HTML2ZIP plugin to create it, have your plugin create the html file and call it like this

from calibre.customize.ui import initialized_plugins
for plugin in initialized_plugins():
    if plugin.name == 'HTML to ZIP':
         plugin.run(path_to_html_file)

Note that the initialized_plugins function will only be available in the next release of calibre.

[macr0t0r]

I did have it creating the Zip file originally, but then the metadata did not import nearly as well as it does with the HTML2ZIP function.

The ability to call other plugins will certainly make things easier. As usual, I'll be looking forward to the next version!

However, I still have the question: after running a custom plugin, does it re-evaluate what type of file is returned and then run the appropriate built-in plugin? For instance, let's say I take a different approach and use my plugin as a preprocessor when converting from PDB to LRF. My plugin would convert the PDB and return the path to the HTML, will calibre then recognize that it needs to finish by using an HTML to LRF builtin plugin? Or would it still attempt a PDB to LRF conversion with the returned HTML file?

- Jim

[kovidgoyal]

No, you can't change the file type in a preprocess plugin.

[macr0t0r]

Eh, I figured as much. If I make my import preprocess plugin return a zipped folder, then it becomes impossible for me to add the original PDB file to my library. For now, I think my workflow is my best option. It creates my specialized HTML folder when I add the PDB file, then I add the HTML file to the Library.

However, I DO think I should make some use of the "calibre-debug" command and see if I can improve the Metadata import of a PDB file. That would at least save me a couple clicks.

- Jim