[Conversion Plugin] KFX Input

[jhowell]

Originally Posted by Birger

I got the following error when converting a book from KFX to ePUB:

ERROR: KFX conversion failed:
Cannot convert The Design Thinking Toolbox
Exception('This book has a layout that is incompatible with calibre conversion. For best results use either the From KFX user interface plugin or the KFX Input plugin CLI for conversion. See the KFX Input plugin documentation for more information.')

That error indicates the book you are trying to convert uses fixed layout. Calibre conversion is designed to handle only reflowable layout books correctly. PDF format is much better suited to books that use fixed layout.

See the section "From KFX" toolbar action in the first post of this thread for information on how you can avoid this error and convert the book to PDF instead of EPUB.

[jhowell]

Version 2.15.0 - 28 Jun 2024

Produce a PDF outline from the book's table of contents when converting fixed layout books to PDF format.

[tomsem]

Originally Posted by jhowell

Version 2.15.0 - 28 Jun 2024

Produce a PDF outline from the book's table of contents when converting fixed layout books to PDF format.

Thank you! Works great.

BTW I'm finding a few more Print Replica books that include Kindle Scribe in supported device lists, and from a large publisher. This one is free:

Measure, Integration & Real Analysis (Graduate Texts in Mathematics Book 282)

SpringerOpen titles are all free. Not all of those in PR format include Scribe in supported devices, and I have not found any paid books from Springer that do (using PR is more the exception rather than the rule for their catalog).

I guess this only proves that Scribe support can be added by any publisher using print replica format. It falls short of explaining why this practice is not a lot more common. I would guess it is just because they would have to update the listing for each of their books, and it's a manual process and not something they are used to doing.

[jhowell]

Originally Posted by tomsem

SpringerOpen titles are all free. Not all of those in PR format include Scribe in supported devices, and I have not found any paid books from Springer that do (using PR is more the exception rather than the rule for their catalog).

It may have something to do with maintaining copy protection for books of value. After all if a print replica book is available on Scribe a user can make an unobtrusive annotation on each page and use that to export the entire book as a DRM-free PDF.

[tomsem]

Originally Posted by tomsem

Thank you! Works great.

BTW I'm finding a few more Print Replica books that include Kindle Scribe in supported device lists, and from a large publisher. This one is free:

Measure, Integration & Real Analysis (Graduate Texts in Mathematics Book 282)

Note these (and write-on books) can be downloaded as AZW4 files using Download & Transfer via USB from Content & Devices for registered Scribes.

The irony is that Scribe ignores AZW4 entirely (with or without DRM removed). It does transfer successfully to a Fire tablet. The PDF in there is easily extracted by calibre or Kindle Unpack.

I wonder if the rest of the data in there provides sufficient 'context' to construct a bona fide print replica KFX? Otherwise AZW4 is kind of useless for side loading to a Scribe.

[tomsem]

Originally Posted by jhowell

It may have something to do with maintaining copy protection for books of value. After all if a print replica book is available on Scribe a user can make an unobtrusive annotation on each page and use that to export the entire book as a DRM-free PDF.

Yes, that has been my thinking as well.

But Amazon controls everything about print replica and what gets exported, so they should be able to offer an option to disable the write-on feature, or degrade the export (e.g. rasterize the page thumbnails instead of including PDF text objects). But maybe not enough volume to justify engineering effort.

[jhowell]

Originally Posted by tomsem

Note these (and write-on books) can be downloaded as AZW4 files using Download & Transfer via USB from Content & Devices for registered Scribes.

The irony is that Scribe ignores AZW4 entirely (with or without DRM removed). It does transfer successfully to a Fire tablet. The PDF in there is easily extracted by calibre or Kindle Unpack.

Allowing AZW4 download targeted to a Scribe when the Scribe ignores that format seems like the sort of mistake Amazon would make. I am more surprised that Download & Transfer via USB is still allowed at all on Kindles.

Originally Posted by tomsem

I wonder if the rest of the data in there provides sufficient 'context' to construct a bona fide print replica KFX? Otherwise AZW4 is kind of useless for side loading to a Scribe.

AZW4 has most of the functionality of KFX print replica. It contains a PDF that is only used to render page images along with a list of words and their locations that is used for text selection and searching. KFX print replica has a few other features such as clickable links and the ability to embed audio/video content that AZW4 lacks.

[Jaws]

Kindle covers, after being imported using KFXInput and converted to epub using Calibre's internal converter, have one weird filenaming quirk when the epub is opened in the editor: The extension for the graphics.

The file for the cover is "cover.jpeg".
Other graphics files, ranging from publisher logos to graphical devices like section marks to actual illustrations, are assigned, in the order encountered in the book, a name like "RS2_54X.jpg".

Is this just a conversion artifact — to assign a different extension to the cover illustration and the cover illustration only — or something buried somewhere in the KFX specification? Is it perhaps related to SVG issues with covers inherited from AZW conversions?

It's certainly trivial, but seems just weird and consistent enough that it may reveal something else. (Like a programmer's fatigue and typo-that-luckily-causes-no-harm in one place of thousands of lines of code.)

[DNSB]

Originally Posted by Jaws

Kindle covers, after being imported using KFXInput and converted to epub using Calibre's internal converter, have one weird filenaming quirk when the epub is opened in the editor: The extension for the graphics.

The file for the cover is "cover.jpeg".
Other graphics files, ranging from publisher logos to graphical devices like section marks to actual illustrations, are assigned, in the order encountered in the book, a name like "RS2_54X.jpg".

At a wild eyed guess, that is an artifact of using calibre's cover generation while the other filenames are generated internal to the KFXInput plugin.

[jhowell]

Originally Posted by DNSB

At a wild eyed guess, that is an artifact of using calibre's cover generation while the other filenames are generated internal to the KFXInput plugin.

Yes, that is it. By default calibre's conversion will rename the cover page to titlepage.xhtml and the cover image to cover.jpeg. You can keep the originals as produced by the KFX Input plugin by selecting "Use cover from source file" in the Metadata tab of the conversion dialog.

Added: We have already had this conversation: Internal Filenames AZW/KFX --> Epub

[Jaws]

The previous conversation didn't make clear to me whether the origin point for this particular filenaming issue was Calibre, or farther up the chain. Renaming in Calibre would be less likely to cause later problems on reconversion if the origin was Calibre than if, say, that was a hardcoded-in-the-KFX-spec filename/extension, which is possible since every book has one and Amazon has been known to take advantage of such things.

[DNSB]

Originally Posted by DNSB

At a wild eyed guess, that is an artifact of using calibre's cover generation while the other filenames are generated internal to the KFXInput plugin.

Originally Posted by jhowell

Yes, that is it. By default calibre's conversion will rename the cover page to titlepage.xhtml and the cover image to cover.jpeg. You can keep the originals as produced by the KFX Input plugin by selecting "Use cover from source file" in the Metadata tab of the conversion dialog.

Added: We have already had this conversation: Internal Filenames AZW/KFX --> Epub

Originally Posted by Jaws

The previous conversation didn't make clear to me whether the origin point for this particular filenaming issue was Calibre, or farther up the chain. Renaming in Calibre would be less likely to cause later problems on reconversion if the origin was Calibre than if, say, that was a hardcoded-in-the-KFX-spec filename/extension, which is possible since every book has one and Amazon has been known to take advantage of such things.

Perhaps re-reading the message immediately above your response might help. Heck, @jhowell even gave you the workaround to not have calibre replace the cover image.

Oddly the same advice was given in @jhowell's response to your post in the thread they linked to:

Originally Posted by 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".

Are you hoping to get a different answer by asking the same question multiple times?

[jhowell]

Originally Posted by Jaws

The previous conversation didn't make clear to me whether the origin point for this particular filenaming issue was Calibre, or farther up the chain. Renaming in Calibre would be less likely to cause later problems on reconversion if the origin was Calibre than if, say, that was a hardcoded-in-the-KFX-spec filename/extension, which is possible since every book has one and Amazon has been known to take advantage of such things.

Internally KFX uses mostly automatically generated arbitrary names, such as "a7H", "rsrc95", and "s89", for book components such as images and styles. When developing the KFX Input plugin I decided to retain these names when generating the EPUB output. That was mainly done for my own benefit since it makes it easier to match up the corresponding parts of KFX and EPUB when debugging.

The main exception to that is the naming of XHTML files. Instead of using the arbitrary names used internally for those in KFX ("c0", "c9", "cU", "c1N", "c26", etc.) I chose to name them sequentially ("part0000", "part0001", "part0002", etc.) to match how calibre and KindleUnpack do it when converting KF8/AZW3 files to EPUB. In retrospect perhaps I should have also retained the KFX names for those files.

Calibre's conventions for file names used when replacing a book cover seem odd to me. Personally I avoid conversion whenever possible and when it is necessary I turn off as many options that modify the book's internals as possible.

[Jaws]

Originally Posted by DNSB

Perhaps re-reading the message immediately above your response might help. Heck, @jhowell even gave you the workaround to not have calibre replace the cover image.

Oddly the same advice was given in @jhowell's response to your post in the thread they linked to:



Are you hoping to get a different answer by asking the same question multiple times?

Perhaps I wasn't clear enough, but these were distinct issues and not the same question. The earlier one was about the general choice of filenames in conversion; this one was about internal consistency in the extensions assigned to graphics file almost whatever their names ("cover.jpeg" but all other graphics are ".jpg"), an odd-enough thing with no apparent reason.

[Anonymous Guy]

Greetings, I'd like to report a bug.

It would seem that when converting KFX comics/manga, an error occurs.
Exception('This book has a layout that is incompatible with calibre conversion. For best results use either the From KFX user interface plugin or the KFX Input Plugin CLI for conversion. See the KFX Input Plugin documentation for more information.')"

It likely has something to do with right-to-left image layouts, but not sure.