Quote:
Originally Posted by Sweetpea
On my WinCE/WinMobile devices, I use Mobipocket. ... So, I added my OPF files so that the "dc:title" is filled with (let's phrase it with Calibre names):
{author_sort} - {series} {series_index} - {title}
On my BBMini, ... (but show the filename instead).
The Sony does categories a bit more friendly ... So, I'd like to make my title more like
{series} {series_index} - {title}
...Wouldn't it be nice, if I were able to say what fields would be used to fill in those basic OPF fields (author and title, mostly)?
|
There be both dragons and opportunities here.
I think you aren't talking about an OPF that is separate from the book, but instead the metadata that is inside the book. Why do I say that?
If the reader used filesystem information, then you can already do what you want to do with the save template. This is your BBMini example. So you must be talking about something else.
I can't think of a single good reason a reader would look for an OPF file next to a book file. Why would it think it was there, and what would it do with it? So you are probably talking about metadata inside the books, especially epubs that have an OPF built in.
Assuming I have this right, here is a possibility. Calibre already updates the metadata for books when it sends them to devices or saves them to disks (call this
send time). I could provide the notion of a 'metadata plugboard' that calibre could use at send time to 'connect' (semi-)arbitrary source metadata fields to (semi-)arbitrary destination fields. In other words, the metadata that calibre uses at send time to update the book would be what is left after applying the 'connections' in the plugboard.
Regarding your mobipocket example, I assume that it gets metadata from the book, not an OPF on the side. If true, then a plugboard that connects some composite column to title will do what you want. Freda (another reader) would do this, as it gets metadata from the book.
My understanding from reading kindle users' posts is that the kindle gets metadata from inside the .mobi file. If true, a plugboard that changes title and author_sort deals with the issues I know of. The first is the one you raise, getting series info into the title. The second relates to a kindle strangeness where authors must be separated by a ';' to sort properly.
Your sony example brings up a limitation. The plugboard will change the info inside the book, but does not change calibre's metadata for the book (this is a good thing). Devices with accessible databases (Sony, Kobo, and (I think) iDevices) use calibre's metadata to fill in the DB, not the book's, so the plugboards will not affect how calibre builds databases for these devices. Thus, plugboards can't change the displayed title as asked for in your sony example. All is not lost, however, because the file system path is easily seen on a book's info screen.
The reasons for database limitation relate to how metadata is exchanged between these devices and calibre. It goes back and forth several times during the cycle. Changing this to use plugboards both directions would be extremely complex, and isn't something I am willing to attempt.
Comments?
PS: given that I handle the sony driver, I could in fact build plugboard processing into the sony driver's database manipulation code. Two things bother me. The first is that the other DB-driven devices would behave differently, which is probably not a big deal. The second is that it would need to be absolutely right the first time, no corner cases, so that people who do manual management don't lose information.