Table of Contents
The main features where Jomic distinguishes itself from many other viewers are:
A two page mode that actually works. It treats mixed single and double page images properly, and levels the size to sensible values even if there are huge differences in two images.
Batch convert multiple comics to CBZ or PDF.
Designed to avoid the "for some reason it doesn't work" syndrome. Jomic has a robust error handling design that should result into some feedback no matter what. Error messages are carefuly crafted to alway tell what cannot be done, and what must be the case the to avoid the error. (The latter is not always true because some error messages are generated by libraries that did not apply the same principles.)
Written in Java and platform independant
Special release for Mac OS X that integrates into Finder (drag and drop comics, filetypes with icons, application bundle)
Ok, you asked for it, so here's the rant:
It's written in Java and uses the infamous Swing user interface. As a result, on most platforms it feels awkward in many little details ("Where did my clipboard go?"), and uses retarted ways to install ("What's that JAR?") and launch the application ("OMG shell scripts?!?!"). And there are some bugs I really don't know how to fix ("The friggin' keyboard stopped working!").
Some popular features are still missing, most notably:
You can take a look at these feature requests to see the current status.
It's bloated. That's mainly because I use Jomic as a toy project to try out new Java libraries even if the same could be accomplished with less code without the library.
It has an absolutely un-slick, brutally functional user interface. Partially because Java Swing applications are unslick by default, partially because I really don't care about slickiness. (Nevertheless I do care a lot about usability, and the user interface is intended to be logical, consistent and efficient. I welcome suggestions for improvement in this area.)
No.
Mac OS Classic 9.x only supports Java 1.3, Mac OS Classic 8.x only Java 1.1. Jomic requires Java 1.4 or later.
You can try Jimic, which is a stripped down version of Jomic satisfied with Java 1.1 and working with Mac OS Classic 8.0 or later. It only supports CBZ/ZIP comics, so you have to convert CBR/RAR comics before you can read them, though.
Most likely not.
Todays Java compatible hand helds and cell phones only support the Java 2 Micro Edition (J2ME), which is a wildly stripped down and simplified version compared to Java 1.4. Think Mac OS X vs. Mac OS 7 or Windows XP vs. Windows 3.1 to get the idea.
Some hand helds seem to support Java 1.1, so you might give Jimic a try.
There are plenty of other viewers. For starters, try one of these:
ComicRack (Windows only)
CDisplayEX (Windows only)
Simple Comic (Mac OS X only)
FFView (Mac OS X only)
Comix (Unix-like only, uses Python and GTK+)
CBView (uses gtk2-perl)
Apart from that, your favourite search engine will reveal serveral others.
This happens when you improperly name landscape images. For
example the image for page 23 and 24 should be named
page_23+24.png instead of
page_2324.png.
Like the Mac OS X Finder or the Windows explorer, Jomic sorts
images "naturally" instead of "asciibetically". This means numbers use
their numeric value, so page_2324.png is treated as
text "page_" and number 2324, while page_25.png is
treated as text "page_" and number 25 and thus sorted before
page_2324.png. If properly named
page_23+24.png, it is treated as text "page_",
number 23, text "+" and number 24 and thus sorted before
page_25.png.
Of course it would be possible to change this, but it would break
all images lacking leading zeros. For example, the current natural
sorting makes sure that an image named page_3 shows
up before an image named page_20.png. Using
"asciibetical" sorting would break this.
To fix a comic that suffers from this problem, perform the following steps:
Extract the comic archive as described in the section called “What are CBZ, CBR and PDF comic book archives?”.
Fix the image names so they comply to the recommendations described in the section called “How can I create comic book archives myself?”.
Recreate the comic archive with the changed images.
In most cases, this means the archive is broken (though the error messages generated by the Java zip library or the unrar command rarely state that clearly). To validate this, just try to manually extract the archive. See the section called “What are CBZ, CBR and PDF comic book archives?” on how to do that.
In most cases, this means the image is broken. To validate this, extract the archive (see above) and try to open the image in an image viewer. If the image viewer also cannot open the image, or warns that it is broken while opening it, or opens an image where obviously some parts are missing, it is broken. As a remidy, try to open and save it with an image editor that has a repair feature, and then create a new comic book archive with the new image.
Otherwise, it probably is a bug in the Java image decoder for that particular format. In that case, try to save the image in JPEG or PNG format, repack the archive, and try again.
The dialog should say "Cannot launch Java application. Uncaught excaption in main method: java.lang.IllegalArgumentException: cannot read image resource: "/.../splash.jpg". If you check the console log, it should contain a stack trace with the same message, and the root cause: "javax.imageio.IIOException: Can't create cache file!" and "java.io.IOException: Not a directory".
This means that for some reason the cache directory for Java ImageIO is screwed up.
Now it would of course help a lot if ImageIO actually would tell
where its cache directory is located. In this early phase of startup
(while attempting to show the splash screen), Jomic does not set the
directory to its own cache but goes with the default. Normally, this is
/tmp. To check this, open Terminal and try to
change to this directory:
cd /tmp
If this yields something like
-bash: cd: /tmp: Not a directory
we found the cause of the problem. To repair it, enter the following commands:
cd / rm tmp ln -s private/tmp tmp
Check /Applications/Utilities/Console, it
should say something like:
crashdump: Unable to determine CPSProcessSerNum pid: 524 name: JavaApplicationStub crashdump: Started writing crash report to: /Users/me/Library/Logs/CrashReporter/JavaApplicationStub.crash.log
Checking JavaApplicationStub.crash.log should
reveal something like:
Command: JavaApplicationStub Path: /Applications/Jomic.app/Contents/MacOS/JavaApplicationStub [...] Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xa7531d54
To fix this, follow the instrunctions at http://docs.info.apple.com/article.html?artnum=301380.
CBZ files are ZIP archives which contain (mostly) image files. If
you change the file extension to .zip, you can
extract them with any ZIP tool.
CBR files are RAR archives which contain (mostly) image files. If
you change the file extension to .rar, you can
extract them with any RAR tool.
PDF stands for "portable document format" and specifies a general format for all kinds of documents. They can also be used to contain comics, in which case every page consists of a singel image.
The easiest way is to copy all images in an new direcory, name
them properly, zip the directory, and rename it to
*.cbz.
The best way to name images is to use a scheme like
01.jpg, 02.jpg,
03+04.jpg, 05.jpg, and so on.
Note that the numbers have leading zeros, and images containing two
pages separate the numbers with a "+" sign (as in
03+04.jpg). Complying to these rules guarantees
that even simple comic viewers will show the images in the order you
intended. Otherwise, they might sort for example
12.jpgbefore 3.jpg because
they compare the name letter by letter and do not interpret "12" as a
number greater than 3.
Your images should use a compressed format such as JFIF/JPEG or PNG. In this case, you can tell the zip tool to not compress them again. This hardly increases the size, but speeds up opening the archive - a lot. If you work at the command line, you can use for example:
zip -0 s00paman-v03-27.cbz s00paman/v03/27/*.jpg
You should prefer ZIP over RAR. See below why.
RAR sucks for at least the following reasons:
Tools to create .rar or
.cbr archives are available for Windows only.
This is not going to change anytime soon because the RAR license
forbids to write other tools by yourself.
Most libraries to extract .rar or
.cbr archives are implemented in C/C++. This
makes them a pain to integrate in interpreted languages such as Java
or Python. Even worse, the compiled libraries depend on a certain
platform, and do not make sense to be included in a platform
independent application like Jomic. Reimplementations using other
languages (such as junrar) have a
much smaller following and consequently fewer eyes to find
bugs.
The freely distributable source code to unrar is a good example for how not to develop software.
RAR does have a few advantages over ZIP, but none of them really matter for comic book archives:
RAR archives can be stored in mutiple files, which unrar automatically joins during extract. That's really useful with 1440K floopy disks, but...
RAR has a repair function. So does ZIP, and althought it's technically inferior, in practice it does not really matter because the result is the same: you can extract the archive short of one or two images. (For details, see the -F and -FF switches of the command line zip tool.
RAR has slightly better compression, which does't really matter as images in are already compressed anyway. Those few bytes saved clearly don't make up for all the trouble RAR causes otherwise.
Summary: For now, use ZIP instead of RAR. On the long run, 7-Zip might become a viable alternative.