Internal Filenames AZW/KFX --> Epub

[Jaws]

When converting books from AZW and KFX formats (and, in my recollection, mobi) to Epub, the cover is assigned the filename (inside the epub, visible in the editor) "titlepage.xhtml," which is then marked as the "cover." Usually (sometimes there's a duplicate at the bottom of the epub text\ file list that's marked as the cover).

The W3C documents don't specify a name for the cover, or for the title page, but it's a lot easier if I need to go back later if the "wrapper parts" of a book are named consistently. So I end up manually renaming... which is annoying for a batch conversion... and leads to a two-part question:

(1) Is the postconversion filename for "titlepage.xhtml from Kindle-family files to epub" hardcoded into Calibre?

(2) If it is, instead, somehow available for user choice, how would a user do that (and have that choice persist through version updates)?

If this is just not possible, it's just not possible... but when version 8 gets released, maybemaybemaybe reset anything that's hardcoded in Calibre so it calls the cover "cover.xhtml" (or "coverpage.xhtml" if there's possible confusion with "cover.jpeg"/"cover.jpg") instead?

[jhowell]

Whenever calibre is instructed to replace the cover of a book, either during a conversion or polish operation, it will change the name of the HTML file containing the cover to titlepage.xhtml. That name is hardcoded into calibre. I do not know why that name was chosen but it has long been the case. There is a recent thread somewhat related to this: giude item "cover" displayed as "Title page"

Avoid replacing the original cover in the book to prevent the change of the file name during conversion. In the metadata tab of the conversion options select "Use cover from source file".

[Jaws]

Avoid replacing the original cover in the book to prevent the change of the file name during conversion. In the metadata tab of the conversion options select "Use cover from source file".

This seems to make no difference at all, in my experience — it's always renamed to "titlepage.xhtml".

• On occasion, I will import a new cover file, especially when the publisher has one of its generic text-only or publisher's-uniform-graphic covers. No difference.

• Much more often, I will resize the cover from humungous-artist-and-marketing-department-ego-gratifying to workable-on-screen-in-a-list (nobody needs a cruddy-quality 2500-pixel-tall reduction of a 4500-pixel-tall-as-printed cover that will be further reduced to fit on a part of a 1080-pixel-tall screen in the file listing), and prefer to do that before conversion so I don't then have to go back in the editor into the cover page and redit the width and height of the display by hand. Due to publisher technological impairment and other foolishness, such as that of some software vendors whose products are often misused to produce e-books from print-based files, doing this automatically would be at best error-prone. No difference.

• When the cover isn't touched prior to conversion, it's renamed regardless.

Since I'm not familiar with all of the readers out there, is there perhaps some backward-compatibility issue such that some readers require the "titlepage.xhtml" filename in an epub input, and so that's being maintained? I can at least understand that, even while I disagree with it and stalk off muttering about the insanity of Berners-Lee misnaming the default filename in HTML as "index.htm" without regard to what "index" actually means... (There's a lot of such foolishness in computing. And in publishing. And, well, darned near everywhere.)

[jhowell]

Originally Posted by Jaws

This seems to make no difference at all, in my experience — it's always renamed to "titlepage.xhtml".

There appears to be a misunderstanding. When you convert from KFX to EPUB by default the conversion process will change the name of the file to titlepage.xhtml.

You can avoid that change by selecting "Use cover from source file" in the conversion options. That will leave the original cover file with the original name in place when converting.

[Jaws]

That's not much of an improvement, it's now automatically "part0000.xhtml" and not "titlepage.xhtml." That is, it still needs a name change to reflect its function. (I'm old-school that way. Now get off my lawn, you noisy kids!)

Sigh. But if this is the worst thing I have to deal with, it sure beats getting stuck with a VHS VCR in a cabin full of Beta tapes...

[theducks]

The names inside the book can really be anything. The only reason for otherwise is for HUMAN Editors. The OPF set the order presented on the reader. The cover (HTML) could be called Foo and the image Bar, as long as they are declare as Cover role, it works.

Having chapters sequentially, just makes it easy to put them back in order

OT Why collect JCL cards. is there sill card readers around ?

[Jaws]

I'm not going to get into an argument that parallels "appropriate variable-naming conventions." This is a forum for e-books, not obscure quasireligious arguments that nobody can ever win... although "standards compliance" actually matters in the real world. (Don't get me started on "copyright pages have been at the front of the book for a couple of centuries, and actual scholars depend on it, but us kewl kidz are going to put them at the end of our e-books just to show we're kewl and have the most-up-to-date-and-overpriced dedicated name-brand e-book readers" — I'll resemble the Tasmanian Devil within two or three minutes.)

All seriousness aside, it matters when one needs to go back and debug something later. I am not looking forward to that when some standard/assumption/file format changes down the road — and it will happen; I remember the "WordStar standard file format" all too well (I'm old; I also remember EBCDIC character coding).

Originally Posted by theducks

OT Why collect JCL cards. is there sill card readers around ?

Yes. In museums. That said, I have a working external 5.25" floppy drive I backended into a USB interface with a soldering iron, some ingenuity, and breadboarding skillz from the 70s — if I can find the bloody power cable...

Not to mention the collection of five-pin DIN-connector spare keyboards.

[theducks]

Originally Posted by Jaws

All seriousness aside, it matters when one needs to go back and debug something later. I am not looking forward to that when some standard/assumption/file format changes down the road — and it will happen; I remember the "WordStar standard file format" all too well (I'm old; I also remember EBCDIC character coding).



Yes. In museums. That said, I have a working external 5.25" floppy drive I backended into a USB interface with a soldering iron, some ingenuity, and breadboarding skillz from the 70s — if I can find the bloody power cable...

Not to mention the collection of five-pin DIN-connector spare keyboards.

I have a ton of those 4 pin Molex 'Y', a couple of 5 pin, ps2 keyboards . I did get rid of the 360K and 1.2M 5.25 floppies .
find an old AT class PSU and cut the cables off, but I think Amazon has adapters (for either way )

[DNSB]

Want a couple of 2.88MB floppy drives and ~10 of the matching floppies?

[Quoth]

Originally Posted by Jaws

Not to mention the collection of five-pin DIN-connector spare keyboards.

PC & XT protocol or AT protocol full size DIN?

[theducks]

Originally Posted by Quoth

PC & XT protocol or AT protocol full size DIN?

I forgot about that switch that some after market keyboards offered.

For years, I used to haunt the Electronic Surplus stores for used IBM (brand) or Dell keyboards. They had a solid feel (clickey) to the keys. (The Duck used keyboards in dusty places and they did not last long).

[Quoth]

I've a selection of old good clunky keyboards. Maybe no PC/XT ones.

The best modern one I've used is a Cherry STREAM TKL.

I've standard DIN to mini-DIN adaptors (and some vice versa) and I've mini-DIN Y cables that work on any fully wired mini-DIN PS/2 socket to allow mouse and keyboard.

The USB to mini-DIN adaptors only work with some older Trust, Genius, MS and Logitech mice. And vice-versa.

The PS/2 to Serial mouse adaptors and vice-versa probably don't work with any of my mice. Date from when mice had balls.

I've some PS/2 (mini-DIN) to USB adaptors that mostly work with XP, Win7, Win10, Linux and most mice and keyboards but not always.

If anyone is passing they are welcome to have stuff for free. Boxes of it in the attic.