To my way of thinking, Java is a natural for building a comic book reader. It's just viewing images and lots of people are going to want to do the same thing and use the same viewer on multiple platforms. So I started working on one a while back called FourColor. I got it to a point where you can actually read .CBZ and .CBR comic book files with it and in some ways (but only some) I like it better than CDisplay or Comical but I never released the code. I think it's definitely time to do so even if I don't do much more work on it for a while. Three other Java based readers have appeared in as many weeks and maybe someone so inspired can put bits and pieces of the four available together to come up with one really great reader.
Asparagino's Comic Viewer | java-gnome viewer for zipped comic scans is a little different because it uses GNOME for its UI. Apparently Swing wasn't good enough for something that only has a handful of controls on the screen, it was much better to pick a GUI that had limited availability.
Jomic is neat and despite the suggestion that you need Mac OS X on the front page (another person apparently missing the whole "cross platform" part of Java) I was able to run it successfully on Linux. I've not yet tried it on Windows though. It's nice that it handles two pages at once, it's not so nice that you have to do the installation by hand and that you have to install Java Advanced Imaging (JAI) just to run it.
CBViewer tries to outdo Jomic in strange requirements by requiring the not yet released Java 5 rather than the plain old mainstream Java everybody is likely to have on their machines. It supposedly works with Java 2 as well but after downloading it and trying it, it seems clear to me that you would have to recompile it to get it to work with Java 2. The provided binaries were compiled under Java 5.
I have no idea why you need either JAI or Java 5 for simply loading some JPG images and displaying them. FourColor seems to do just fine now without that. What all of these readers suffer from is a common problem that pretty much any Java program is going to face. The stupid, proprietary .RAR format has been used to compress many many comics. That's where the R comes from in .CBR files, .CBZ files use .ZIP compression. Because there is no library to handle .RAR files directly under Java, you have to have the UNRAR command installed in your path whether you run Linux, Windows, or Mac OS X for FourColor to work. How Jomic avoids the need for UNRAR on Mac OS X is something I haven't looked into yet. It's this requirement that keeps FourColor from being all it can be. Otherwise, it's simple Java Web Start installation would make it one of the simplest ways to get read a comic book file.
Anyway, since I haven't filled in anything on my project page for FourColor yet, here is a plain old .ZIP file with the source code for FourColor. Don't imagine that just because I have criticisms of the other three Java comic readers that that means I think mine is perfect. Far from it, just click the "more" link to read about what I think is wrong with FourColor and a multitude of features I think it needs to become a better reader. If you'd like to give it a quick try here is a Java Web Start link to try out the latest version.
OK, what is wrong with FourColor:
- One of the most common ways to read a comic is with it set to page width. So the comic is scaled to as wide as the window and it is most likely too tall for the window so you end up having to scroll to read the whole page. FourColor does page width but it recalculates how big the page has to be with scroll bars after the scrollbars appear and it does it after you switch to each page even if this page's scan is exactly the same size as the last scanned page. Ugh. It looks like it's doing a little resizing dance as you view each page when you are set for page width.
- Rather than using PageDown to move down each page and then Ctrl+N to move to the top of the next page, there needs to be a single key like space that does that automatically. It pages down until you've hit the bottom and cannot scroll any more and then it automatically moves to the next page.
- The list of pages on the left was meant to use a list cell renderer so it would show a thumbnail of each page. It doesn't do that yet and I think it would be an excellent feature to have.
- No ability to display facing pages. If you have a large high resolution display or a dual monitor system, facing pages works quite well. Also you sometimes want it just to see big two page panoramic spreads that the artist may have used to show something.
- FourColor remembers the last position and size of its window. It also remembers the last directory from which you opened a comic. What it doesn't remember is the position of the splitter window, the view you want of the comic (i.e. page width, size to fit, etc.), or the last comic you had loaded and its page. I think all of that would make for a nicer startup if remembered.
- I had started a refactoring where the underlying model had a Comic interface and there were separate classes for ZippedComic and RaredComic which would implement the nasty details of each one. That refactoring was never completed and I've really got more pressing stuff to work on. But it should be done.
- It's not "cool". No, I know none of these comic readers are really "cool", but I think there's an idea for something which could be tried out that would make a comic reader which was both cool and more functional at the same time. By hacking together something with the Piccolo library you could try starting out showing the user all the pages in a comic at the beginning and zoom in on the cover. Then as they turn to each page (or layout of two pages) you could zoom out a little and back in to the relevant page(s). Then going to a specific page is just zooming out all the way and letting them pick the page to go to. The whole UI becomes much more consistent. Issues like showing dual pages aren't hard at all because all the pages sit beside each other in one long line. It could work and work well but it would take some work even to try out.
- Accomodate a XML file within the comics which would not be required but which if there could be used to pair up pages in sensible fashions. Some comics have extra pages (like a small and large scan of the cover, or multiple cover scans for comics that came with several covers), others have different page orders like Japanese Manga which really need to start at the end and work backward. If there were a XML file in the comic then it could be used to hold that kind of information. For comics that don't have it, you'd have to continue to assume everything (i.e. all pages shown in alphabetical order will display the comic).