Internal filenames (mobi/azw --> epub) cover named as title page

[Jaws]

I'm not sure where this is coming from; there could well be some deep, dark, barely-documented directive that's outside of Calibre regarding internal filenaming conventions, it could be a pure accident, it could be inside of Calibre.

When I convert files that originated as mobi, azw, and kfx to epub, about 90% of the time the assigned filename in the /text folder for the cover is "titlepage.xhtml." (The other 10% of the time it's completely unpredictable.) The actual title page, however, is given an index_splitxxx.xhtml name.

Do. Not. Want. That is, don't call it a variable if it's a constant sort of thing. But it might not be Calibre, which is why I'm asking this as a question, all the while muttering as I manually correct internal filenames to satisfy that OCD-like impulse to comply with several hundred years of naming conventions for parts of "books" (at least in Europe, and if India's conventions are/have been different and that's what Kovid is following I just don't know that).

So:

(1) Is this something that's being imposed at the source level and Calibre is just silently (and properly) not changing it?

(2) Is this a default naming convention in Calibre — and if so, is there a setting that can be changed so it doesn't do it?

What's annoying about this is that it's not completely consistent, so I can't seem to automate a "correction" at this end. Perhaps the hobgoblins of foolish consistency are taking over my brain, but persistent misnaming of parts makes later updates and analyses more difficult. (And admittedly, this is as much an aesthetic impulse in favor of "neatly-formatted code" as anything else, because the actual filename doesn't ordinarily affect any display or function of the ebook. For my conception of "neatly-formatted code," which to some people probably verges on "Are indents in source code two spaces or four?")

[Quoth]

No-one reading sees any of the internal filenames.

[Jaws]

Originally Posted by Quoth

No-one reading sees any of the internal filenames.

Agreed. Known; it's why I specifically mentioned that I am seeing this when I edit a book, not when I read it. It's still annoying to me, especially when it comes time to remove all the advertising crap (some of which exceeds the size of the rest of the book. slows down readers on legacy devices, and includes dead/nonverifiable links) before transferring it to my library.

It's entirely possible that it's either an external sloppy or a "the programmer who set this up has a different tradition than I do" silent assumption. That's why I'm asking it as a question first.

[DNSB]

The file names with split in the file name can happen when a file matches calibre's file splitting rules. See Structure detection in the calibre FAQ section for e-book conversion.

[Karellen]

Originally Posted by Jaws

however, is given an index_splitxxx.xhtml name.

Where do you see that? Is it in the opf file?
I've not noticed the actual xhtml file having a different name to what is listed in the opf file. (but I've never actively looked for it either)

The titlepage/cover naming issue has been briefly discussed here... https://www.mobileread.com/forums/sh...d.php?t=342830

[kovidgoyal]

There are no filenames in amazon ebook formats. The filenames you see are generated. And whether something gets named cover or titlepage depends on the metadata in the book about that file.

[Jaws]

It's the filenames assigned in the upper-left-hand panel of the editor. Remember, the .opf was generated from the source, non-epub-formatted book, and unless it was a highly unusual mobi-family book (by inference although there's really no way to test this, a well-formed-and-named epub at the publisher, which the publisher then converted to azw/mobi/kfx instead of allowing the 'zon to do it) those well-formed filenames are not preserved when converting back to epub in Calibre.

But I have no way to test this, which is why I'm asking here.

[Jaws]

Which metadata? If I could edit the metadata prior to conversion so that this is consistent, that would work. But if I can't, I guess I'm stuck with the existing annoyances...

[kovidgoyal]

This is not user visible metadata, and again there are no filenames in amazon formats. So roundtripping an epub through an amazon format will always use the filenames.