Images directory in entry' folder

[Perkin]

A possible feature?

To have an Images sub-folder in the entries database folder, which is linked to entry, so when changing author/title, the Images folder is moved with entry, and Check Library is aware of/ignores it?

I'm using Textile txt files and using !/Images/pic01.jpg! would then include the image from the directory when converted.
(I know I can use absolute filename, pointing to own directory, but entry/sub-dir would be handy)

Would be also useful to store some other cover images, I have lots of books where there have been several covers and being able to store them with the entry would be nice. (maybe even automated so when you add a new cover, the old one is stored - if a prefs-setting or tweak is set.)

What do other users think?

[Manichean]

Personally, I don't see the benefit- if I want to have images in a text, I use a format that supports images, e.g. HTML.
As for the "cover storage", there was talk some time ago about including some storage method for formats that eventually lead to a ticket being created, but I don't know if anyone has put it on any todo list It wouldn't make sense, in my opinion, to develop a separate storage system for old covers, if we are to get such a system, it should be one system for all the files associated with a book entry.

[itimpi]

Thinking about this it would be nice to be able to store more than just the front cover as a standard feature of Calibre. For many books being able to have the back cover would be a 'nice to have' feature. However, where it should be stored in a book is not as obvious Should it be at the end like with a real book or just after the Front cover because it is an electronic one?

[ldolse]

Originally Posted by Manichean

Personally, I don't see the benefit- if I want to have images in a text, I use a format that supports images, e.g. HTML.
As for the "cover storage", there was talk some time ago about including some storage method for formats that eventually lead to a ticket being created, but I don't know if anyone has put it on any todo list It wouldn't make sense, in my opinion, to develop a separate storage system for old covers, if we are to get such a system, it should be one system for all the files associated with a book entry.

I think the point is that having something along these lines would allow for easier ebook creation. Using markdown/textile is far more accessible/easier to format than html, and generally quite well suited to basic ebook authoring requirements. I've done one paper book that I had a copy of along with a completely unformatted text file. Markdown, a very small amount of html, along with Calibre's extra_css, and Calibre spit out a book that had 95% of the formatting of the print book.

The implementation in Calibre is the harder part - handling the images during conversion, storing them, etc. Something along the same lines as zipped html might work...

[user_none]

I haven't looked into the internals of the zip format handling... It should be possible to extend it (if it doesn't already have support for this) the zip handling to detect what's inside, unzip and process accodingly. This is essentially what the PDB plugin does.

Would that work for you Perkin?

[kovidgoyal]

I suggest creating a new format called .txtb which like epub is just a zip file and add it to the BOOK_EXTENSIONS as well as the txt input plugin and create a dedicated output plugin for it.

And probably generalize the tweak epub plugin to allow tweaking of txtb files as well. Or (and this is much more work) create an editor program for the txtb format.

txtb could store .txt (in markdown or textile) with associated resource files.

[user_none]

I like the txtb idea and I'll add support for it this weekend. It shouldn't be hard to modify the PMLZ pluging to do this.

@kovid, how set are you on txtb for the extension? I would prefer txtz to keep it consistant with similar plugins.

[Perkin]

Originally Posted by user_none

I haven't looked into the internals of the zip format handling... It should be possible to extend it (if it doesn't already have support for this) the zip handling to detect what's inside, unzip and process accodingly. This is essentially what the PDB plugin does.

Would that work for you Perkin?

That'd be great.

Many thanks.

I use a EditPad Pro,(I've made a Textile syntax file), which allows a much quicker workflow (for me anyway), than editing after the conversion (Sigil or editing html).

Mainly going to use for chapter headings/fancy lettering/scene break images.

[kovidgoyal]

I dont care about the extension, but txtz is likely used already. If you do this, you'd probably want to add some mechanism for storing metadata in the file, probably simplest to just stick an OPF in the top level.

[user_none]

TXTZ input and output support added. It's just a zip archive with TXT files renamed to .txtz. It supports images and they can be top level or in directories. If they are in directories they must be referenced that way in the document. It also stores an OPF file called metadata.opf that stores the metadata.

This is the preferred approach for handling TXT using Markdown or Textile that references images. It is also the preferred method of having TXT documents with metadata.

On my TODO list is making an import plugin to read a TXT file find all Markdown and Textile image references and put everything into a TXTZ file then storing the TXTZ calibre. This would be similar to what happens with PML being pulled in as PMLZ and HTML being pulled in as ZIP.

@Perkin, let me know if you find any issues or any shortcomings of this solution. It will be available in 0.7.45.

[Perkin]

Nice one, thanks.

I'll get .45 when it's released and have a good play.