To CBZ, or not to CBZ: that is the question

[tomsem]

I recently got the Pocketbook InkPad Color 3. Naturally I would like to read color content on it.

Most of my comics/graphics novels were purchased from Amazon. Except for those in Print Replica format, I have added these to my calibre library, and they are ready to convert (some have been converted to ePub3).

The PIC3 supports AZW3 in some fashion, but also ePub3, PDF, and CBZ/CBR. For maximum portability I prefer the latter 3.

My experience with CBZ up to this point has been very limited. Calibre does not offer a direct conversion to it (is there no demand for a plugin for this?). None of my present content is in that format.

So the question is 'what are the merits of it' vs ePub or PDF? Is it worth taking the time to do so?

My conversion workflow currently is:

• Run Kindle Unpack plugin to produce a folder of images
• Use Finder Compress to generate a ZIP of the images
• Open that with ComicTagger to add metadata and save to CBZ file
• Add CBZ to calibre and merge with the original AZW3/ePub record.

One thing that is missing from CBZ is ability to navigate directly to Issues within a CB collection. I assume Pocketbook does not support CBC (collection) format or they would mention it, but I guess I can try that to make sure.

I have yet to see an AZW3 comic collection that has a ToC, so said navigation would need to be added manually as well: you need to preview the content from start to finish to determine where the issue boundaries are.

In this regard, PDF seems preferred as it is easy to add page links and bookmarks relative to ePub with any PDF editing tool. Can you save PDF content for right to left language (and page order), e.g. for manga? (I tried creating one with 'Right binding', but it didn't behave as I would expect.)

I have tried all 3 formats on my PIC3. It's not yet clear any is superior to any other.

In closing, is there any good reason to prefer CBZ to ePub or PDF? Especially given the need to manually convert to it, and add it to calibre.

[gweeks]

A cbz is just a zip file of the images. If you are converting from paper it's great. There's no search ability and you can't create an index.

I use cbz a lot, but not so much to read from on a hand held device.

Greg

[Quoth]

If it's not reflowable usefully anyway, and comics mostly are not, then a PDF with custom paper size and no margins is the most universal. The Kindle and epub3 Fixed layout are mostly only less compatible versions of PDFs anyway.
Unlike a cbz, a PDF can have a searchable text layer and and TOC, depending on how much effort you want to put in. No need to use Adobe or InDesign either, especially for personal use.

[jackm8]

Originally Posted by tomsem

In this regard, PDF seems preferred as it is easy to add page links and bookmarks relative to ePub with any PDF editing tool. Can you save PDF content for right to left language (and page order), e.g. for manga? (I tried creating one with 'Right binding', but it didn't behave as I would expect.)

You can manually inverse the order of images for both pdf and cbz. When you have images extracted, they'll usually be named something like 001-002-003... in order. Select all files in a program that allows multi renaming of files, and you'll usually have options to add a custom counter to them. Example is Total Commander.

Pocketbook also has it's own image viewer, so you could view comics using it by uploading your comics into their own folders into the device. That was my preferred method, as I was never a fan of using multiple programs to mangle image files.

As far as quality is concerned, it's got pretty good downsampling codecs, so if source files resolution is greater than your device's screen, you shouldn't have to do anything. In fact it's better to have them in larger resolution, if you're used to zooming in. But if resolution is smaller, then it's best to upscale them first on computer to the resolution of the device.

[tomsem]

Thanks for the suggestions. PDF seems like a better target overall.

I'm still curious about how the various formats encode for 'right binding', i.e. Japanese texts.

Sure, you can reverse page order, but that does not work correctly with two page spreads, where you read the right hand page first and page numbers should likewise increment from right to left. Surely PDF can do this? I must be missing something.

I think ComicTagger lets you set a manga property for CBZ, and CBZ readers are supposed to know what to do with that.

[Aleron Ives]

I thought the whole point of CBZ was manga; I didn't realise people used it for anything else.

[Quoth]

Hebrew has RTL PDFs.


It's mixing RTL and LTR on one line that seems to be an issue with many programs.

[tomsem]

Originally Posted by Aleron Ives

I thought the whole point of CBZ was manga; I didn't realise people used it for anything else.

It's not just for manga, though I have no idea what people are using CBZ for and who publishes things in that format.

[tomsem]

Originally Posted by tomsem

I'm still curious about how the various formats encode for 'right binding', i.e. Japanese texts.

.

ePub has a spine property, page-progression-direction, that sets reading order to 'rtl'. Probably same with Kindle formats.

Also changing Binding to 'Right Edge' in Acrobat indeed changes the two-page display so you read the right page first. But (at least when system language is English) you still use right cursor to advance through the document. There is also a way to change the default for all documents and override this property. I assume you also get print ready PDF that arranges the pages correctly for printing out signatures for book binding.

Of course some PDF editors will not let you do either of these things, particularly if they aren't designed to product PDF for print production.

macOS Preview doesn't do two page display correctly, for example. Nor does PDF Expert. I think FoxIt does, as a document came up when I was doing web search about this.

[Freeshadow]

if you want to use CBZ you can use advzip from advanceComp package to recompress the cbz with Zopfli zip compression; still zip but smaller.

[DNSB]

Originally Posted by Freeshadow

if you want to use CBZ you can use advzip from advanceComp package to recompress the cbz with Zopfli zip compression; still zip but smaller.

And check that your ereader will be able to use that algorithm. I've found several times that the more advanced .zip compression algorithms are not usable on Kobo or Kindle ereaders. Zopfli made that list even using it's deflate algorithm.

[DrChiper]

For what its worth:
CBR are compressed with the RAR-method, while CBZ are compressed with a ZIP-method. Kobo is very picky about the fact that the used compression method is expressed by using the according file-extension, otherwise the file won't show.
I've seen RAR compressed files faulty using the CBZ extension and ZIP compressed files faulty using the CBR extension. That won't matter on Windows system as Windows don't really use the file extensions, but it does matter for *nix systems.

You can check this by opening the zipped files with for instance notepad++ and look at the very first characters of that file:

• RAR indicates a RAR-method compressed file, so must have extension CBR
• PK indicates a ZIP-method compressend file, so must have extension CBZ

[j.p.s]

Originally Posted by DrChiper

That won't matter on Windows system as Windows don't really use the file extensions, but it does matter for *nix systems.

For the most part, my experience has been the opposite.

[Quoth]

Originally Posted by j.p.s

For the most part, my experience has been the opposite.

Mostly I'm with j.p.s. on this, though my default Linux image viewer gets confused if a .png is ending in .jpg. Windows does pretty much use file endings which is why the Explorer default of hiding them is really stupid. That's one of the first things I change after installing windows since Explorer ever existed. So sometimes on Linux having really no file ending on a downloaded file can work better. Default MS Wwindows installs only pretend to have no endings on all filles, but it's a stupid Explorer setting.

MacOS, Linux, BDS, Solaris, UNIX, Xenix etc don't depend on suffix and indeed don't have default like .exe (except for WINE).
See https://en.wikipedia.org/wiki/File_format#Magic_number
(Unrelated to a magic number in programming source code)

Malware in attachments is famously 'something.doc< loads of spaces >.exe' so even if file endings are visible it is not.

[Aleron Ives]

Windows uses the extension to determine which program should open the file, but any compression program on Windows will be smart enough to look at the file header when deciding how to decompress it, rather than blindly relying on the extension.