Digital Comic Museum
Digital Comic Museum => Welcome and Introductions => Topic started by: Whale on January 02, 2012, 12:15:50 PM
-
Hello everyone,
I've already posted this message in goldenagecomics.co.uk forum, but this website looks more alive :-)
I'm working on a XML based comic book format that I named as "Advanced Comic Book Format" or simply ACBF. Widely used Comic Book Archive (CBR, CBZ etc.) has many drawbacks. It's basically just an archive of images. ACBF in contrast will support:
- comic book metadata (title, author(s), genre, annotation, keywords, publisher, publish date, city, ISBN, license etc.)
- definition of comic book structure (pages, frames) - if frames are defined you can zoom in to frame level and read frame by frame (usefull on smaller screens like PDAs, tablets ...)
- it will support a separate semantically enhanced text-layer over the background graphics (like emphasised text, commentary, striked-through text, computer code etc.). Comic book with such separate graphic and text-layer can be more easily readable on smaller screens again because text is drawn by fonts instead of be part of the background image. Besides, more text-layers can be defined for particular comic book, each for different translation.
Everything (included binary data like images and maybe fonts, sounds in the future) will be in a single file, though there's support for having these in separate files outside the ACBF document.
For this project I created project page on Launchpad (https://launchpad.net/acbf). Current specifications you can find in the repository, inside the Docs directory.
Direct link to repository: http://bazaar.launchpad.net/~just-me/acbf/trunk/files
I'm also developing a ACBF Viewer application. So far it is in early stages but is able to load ACBF file and navigate through the whole comic book - also zoomed in to the frame level, view comic book meta-data and table of contents. It is written in python and uses GTK library for drawing user interface. I'm using Linux (on desktop as well as on my PDA) but it is possible to run the viewer under Windows (or even maybe Mac) as well (after installing Python, PyGTK and some libraries). Here you can find ACBF Viewer screenshots (running under Linux): https://plus.google.com/photos/110989843476988874482/albums/5692035097709963025
There's still a lot of work to do. Specifications should be improved, XML schema created afterwards, ACBF viewer improved and also some comic books converted to ACBF. There is a sample comic book in the repository which I converted to ACBF. It's a "Craphound" comic book based on Cory Doctorow's story - I really recommend to read it, it's already a classic and it's free :-). Here's the related ACBF comic file: http://bazaar.launchpad.net/~just-me/acbf/trunk/files/head:/Sample%20Comic%20Book/
Here you can find it in PDF format if you're not able to run the ACBF Viewer on your machine: http://www.archive.org/details/CoryDoctorowsFuturisticTalesOfTheHereAndNow.
ACBF Viewer as well as all ACBF specifications are free.
So any feedback, suggestions or help regarding file format specifications, viewer application or anything project related is appreciated. If you have any questions, just let me know.
Have a nice day.
-
For those who use Windows I managed to run ACBF Viewer under Windows OS, so if anyone with Windows wants to try it, here's the recipe (for 32-bit Windows):
Install python:
http://python.org/ftp/python/2.7.2/python-2.7.2.msi
Install PyGTK:
http://ftp.gnome.org/pub/GNOME/binaries/win32/pygtk/2.24/pygtk-all-in-one-2.24.0.win32-py2.7.msi
Install Python Imaging Library:
http://effbot.org/downloads/PIL-1.1.7.win32-py2.7.exe
Install lxml library:
From http://www.lfd.uci.edu/~gohlke/pythonlibs/#lxml get lxml-2.3.2.win32-py2.7.exe
If you encounter any error messages like "unable to register a library" or something like that, just ignore it.
After you install all 4 packages, download ACBF Viewer from here: http://bazaar.launchpad.net/~just-me/acbf/trunk/view/head:/ACBFViewer.zip
Unzip the file and inside you will find src directory. Navigate to it and double click acbfv.py file.
You will need some comic book in ACBF format as well. So download Craphound comic from http://bazaar.launchpad.net/~just-me/acbf/trunk/view/head:/Sample%20Comic%20Book/Doctorow%2C%20Cory%20-%20Craphound.acbf
In ACBF Viewer the first icon on the toolbar opens "Open File" dialog.
A bit complicated, huh? :-)
You may download easy to use Windows 32 executable. See a couple of posts later.
-
A bit complicated, huh? :-)
And totally unlikely that I'd install that many unknown programs onto my computer to read anything called Craphound. YMMV.
Peace, Jim (|:{>
-
Since little things like this percolate in the back of my mind all the time, here's what little thinking I've actually done, which you can feel free to leverage, work around, or ignore as you see fit, Robert (if you'll pardon the familiarity).
The big problem is overcoming a standard (CBR, CBZ) that's "good enough." For the time being, nobody cares about anything other than seeing pages, so all the extra work is adding points of failure without a significant selling point. Add in thousands of existing comics in that format, requiring enormous time and bandwidth to update them, and a project like this is going to sound like "hey, let's all convert our e-mail to Microsoft Word 2015!" to a lot of people.
You also have a bunch of "secondary formats" waiting for their day in the sun, with PDF being obvious and DjVu having a lot of unrealized potential.
That said, before those issues convinced me that I probably wasn't going to change the world, there are a few things that I thought were of some importance and might make it worth converting ten thousand (public domain) comics...eventually.
- Some unique token, like an MD5 hash, to tell me if two files think they're the same comic and can be compared with the actual contents to determine if the file has been modified and authenticate which is the "official scan." That would also make it easier to build a registry of scans, so that there's no mistaking a file's provenance. It would also make it easy to check if the user has already read a particular file, no matter how many times it's downloaded, copied, moved, or renamed.
- Database support, so that, if the XML file hasn't been created, the data can be populated as well as possible from open-access databases like the GCD.
- SVG support, since I imagine comic publication is eventually (eventually!) going to go vector-based; I mean, raster graphics are insane when you literally can't guess at all the screen resolutions your book is going to be read at and pixels can be anything from near-microscopic to the size of a fist, if you zoom in.
- Likewise, a layered image format would also help future-proofing, allowing a publisher to isolate pencils, inks, colors, and so forth, and allow access to each independently. A similar kind of "swapping" would also be nice when pages are repaired by later editors, so that both can be included without breaking the flow of reading, by only showing the version of the page (original or latest) that the reader wants but storing both.
- For small screens, optional panel transitions would be an excellent addition. DC's (at least) digital viewer does this, and it's a nice idea. The Inkscape presentation plug-in Sozi does something like this for vector art; it's obviously not quite enough to steal code or anything, but shows the sort of direction.
http://sozi.baierouge.fr/wiki/en:welcome
- A step further might be worth supporting a native equivalent to the "motion comics," which right now are full movies that happen to just be showing comics, which is silly.
- Selectable text without requiring it to be rendered apart from the image, like PDF and DjVu do. OCR probably isn't worth pursuing in this respect (in case nobody typed it in), but is an interesting thought.
- When reading scans of microfiche, one thing I can't do without (that's easy to forget) is a gamma adjustment. I'm sure it's useful in other cases, too, but a lot of the old fiche scans are so dark that they're unreadable without being able to change it.
- Most important is a toolchain that helps the scanner or publisher put the books together. As things stand today, the minimal setup is a scanner, scanning software, and a ZIP program that's probably already sitting on your hard drive. With anything more complicated, we're not teaching anybody to edit XML or measure out the panel shapes. To catch on, it has to be trivial, or it won't get done except in the examples.
- I'd also like to see the tools help the scanner/publisher work with the open databases, reading initial content from them and assisting in correcting or uploading the data where needed. After all, if the work's going to be done, it shouldn't be done more frequently than absolutely necessary.
(On that note, one lost-cause wish I have for the future is for archives would start shifting to something like TAR format. Images don't compress well, so there's no gain by using ZIP or RAR, RAR is still proprietary, and ZIP doesn't handle corruption well. Since TAR is just concatenating files, by contrast, it's basically idiot-proof to find all the images that weren't damaged.)
Heh. And I agree with Jim. As the name of an example file, "Craphound" is...inauspicious.
As I said, take what you'd like from that, and where it's too much, just skip past.
-
Thanks for the feedback.
Regarding "Craphound", it's really a nice story and you can download PDF version of it if you wish to read it :-)
The biggest problem with CBR/CBZ standard is that it does not store any meta-data, so I think it's worthy to have comic books in some more advanced format. I created ACBF format and the reader, in the first place for myself - so that I can read comics on my PDA, which has only 600x480px screen resolution and also that I can build a comic books library from comics I have (requires to store meta-data). The ACBF format is a presentation format, I don't expect publishers/creators will use it to store in it the raw comic books. It's a DRM free format, so I don't expect it will be used commercially either.
Optional panel transitions are already defined in the ACBF format and supported by the ACBF Viewer application.
Selectable text is defined in the ACBF format already as a separate text-layer (optional), not supported by the Viewer though yet.
Regarding tool chain, I already created some tools/scripts that help me to convert images into ACBF format as well as extract polygons (used as frames/panel definitions) from SVG file (I use Inkscape to draw polygons over background image to define frames on a comic book page, then convert those polygons from resulting SVG file to XML tags used in ACBF).
Regarding the open comic book databases, it's a good point, I will research into that. Some interface between ACBF meta-data and comic book meta-data from available databases would be nice to have.
I agree that using ZIP/RAR etc does not help in compressing image files, that's the reason why in ACBF you can have those files directly inside the XML (converted to BASE64) and having one single XML file to distribute. ACBF does not define any container to store multiple files in it (though actually you can have a comic book stored in multiple files in ACBF).
Nice thing with ACBF is that you can use from the format capabilities just anything you want. For example you just put inside the images, you don't have to define frames/panels for pages nor text-layers, even meta-data. But it's nice to have them and use the capabilities the ACBF provides. Anyone can take that ACBF file and fill in the meta-data later or define the frames or text-layers.
Regards,
Robert
-
Apart from the mind-blowing techno-banter (and that I fell from my chair laughing after having read Jim’s reply), it sounds like a truly fantastic and worthwhile project.
But I concur that it would be next to impossible to overcome the existing formats and viewers. And no one would spend that much time converting things.
Just a thought what would be fantastic for me – and all those historians who have to permanently jump to and fro between DCM and GCD to check things.
If GCD (www.comics.org) could include a viewer, so that you have all the data AND all the comic book pages COMBINED on your screen. You'd just click on a certain story, and a new window would open with the pages of that story.
This would truly be historian’s heaven!
-
@tilliban:
Converting CBR/CBZ to ACBF is not a problem. It is possible to do it automatically with a simple script as CBR/CBZ archive contains just images.
But filling in the meta-data, frames definition, text-layer definition etc. would indeed require additional human effort. I believe that it is worth the effort and some time in the future library of comic books can be built out of comic books in ACBF format. Even if people will use some other comic book format in the future, comic books created in ACBF will be easily convertable to that new format as ACBF is based on XML standard and specifications are free. Even databases like GCD can extract meta-data information from it, if someone creates a script/interface for it.
Cheers,
Robert
-
Full page comics look great on my ipad. I prefer the panels on my computer.
-
Just my opinion, so feel free to ignore it all you want.
More than a few CBR/CBZ files already include text files that list the publisher, date, etc, and CDisplay lets me set the Height of the page to whatever I want (although I usually just "set to width" to read small print or "set to height" to see the full page). I'm not sure I see the benefit of downloading five programs, with features I don't really find all that important, just to read a comic book. For me, "good enough" is good enough.
-
Robert, I didn't mean to sound discouraging. That was literally just a dump of things that occurred to me when I was kicking around a similar product. More solidarity than anything else.
I do think it's an uphill battle to get traction (there's still a ton of COBOL code, nobody really moved to XHTML, and generally advanced standards get ignored for "good enough") and I certainly wouldn't be up to it. It's not so much whether it would be worth doing so much as it would be to convert and upload the thousands of books here, let alone the thousands out there that aren't public domain (ahem--or so I've heard).
MIME-ing the images could work. Seems like it might bloat things a bit, but there are compressed file systems and servers can do compression, so that might not be relevant anymore.
Bchat, think of it more as proof of concept or demonstration. The other pieces are basically Linux's complete environment. Once the standard is finalized and if people start producing comics in the format, it'll be easy (relatively speaking) to take the existing implementation and write one native for Windows, Mac, phones, or whatever. But until that traction happens, I can say from experience that it's not worth having polished versions for everybody--you just end up rewriting your rewrites and creating a ton of bugs...
-
Bchat, think of it more as proof of concept or demonstration. The other pieces are basically Linux's complete environment. Once the standard is finalized and if people start producing comics in the format, it'll be easy (relatively speaking) to take the existing implementation and write one native for Windows, Mac, phones, or whatever. But until that traction happens, I can say from experience that it's not worth having polished versions for everybody--you just end up rewriting your rewrites and creating a ton of bugs...
I understand what you're saying, I just meant to say (so why didn't I?) that "good enough" is all I need (he asked for feedback and this is mine). Bells & whistles are nice (like those programs that make it look as if you're actually flipping comic pages), but my preference is to simply have the images and decide on my own how I'll view them. Obviously, if the comic files are formatted from the start for this type of application, then there's a need for such a program to exist, but for all the scans available here, it just isn't necessary.
-
Me, too, bchat.
But then you and I are thinking of DCM comics, not 2015 comics. The world is rushing by us, especially fast since we're sort of in reverse (or, at best, stationary). I (and probably you as well) am not all that interested in comics that talk or move. Seems kinda silly, unnecessary, and not really comics as I think of them. Still, times and tastes and definitions change. I say "Let them - but include me out." Robert's comic viewer might be the next big thing, but I'm busy looking at the next big thing of 1942. Different strokes.
Happy New Year to all.
Peace, Jim (|:{>
-
But then you and I are thinking of DCM comics, not 2015 comics. The world is rushing by us, especially fast since we're sort of in reverse (or, at best, stationary). I (and probably you as well) am not all that interested in comics that talk or move.
Speaking for myself, I'm not interested in comics that move. But I'm a fan of a richer comic format from a coupl'a perspectives.
I'd be happy if the native format recognized some basic meta-data about the comic, like title, issue number, publisher, etc. I'd like it if my comic reader could keep track of all my comics so that it organized my comics files, rather than me figuring out the best way to store them in file systems. (By character? By publisher?) If there was machine-readable meta-data, I could easily find other stories with the same characters, or by the same artist (when artist is known). Similarly, if we have good meta-data, we can stop telling people "Make sure the front cover is the first file in the archive!" because the meta-data will indicate which image is the front cover.
If there's good meta-data, then I can more easily tell my reader to skip ahead to the next story in the book -- maybe the current story is boring me, and I want to jump ahead to the next story in the issue.
I kinda view it as the difference between how tape players worked and how iTunes works. Better data; better user experience.
BCing you
-
I (and probably you as well) am not all that interested in comics that talk or move.
Yeah, that kind of stuff just comes across as cheap, low-budget animation to me, which I don't really find all that fun to watch.
-
BC makes some very good points. Those features would be a big help.
But inertia will likely sway people just like it has for jpg/mp3 vs better formats that have never caught on.
I wish Whale the best though.
-
thanks for all the replies. I managed to create a Win32 executable for ACBF Viewer, so if you wanna try it you may get it from project main page (https://launchpad.net/acbf) (green Downloads section on the right side). There's a viewer and sample comic book to download. No need to install Python and all those libraries anymore (at least I think so - tried on 2 different computers with Windows XP installed)
@John C
No problem. I do it in first place for myself. I wanted to have such a comic book reader in Linux with all those capabilities. I'm writing it as a free software, so anyone can take it or leave it or even help with it. If nobody cares and I'll be the only one using it and creating comic books in ACBF that's OK ;-)
-
As far as "transitions" and such things go, keep in mind that there's the emerging audience of people on phones, small tablets, netbooks, or really any setup where the user doesn't want or can't afford an enormous screen. While you can argue that you can always zoom in and scroll around from panel to panel, it's better to let the "publisher" encode the pane ordering into the comic, rather than spoil the reading experience making a bunch of guesswork swishing motions.
So don't think of it as "animation" (though it's happening, so it's probably worth supporting it) so much as having someone point out where to read next, which can be difficult when you're not looking at the whole page.
-
I should clarify what I mean, because I think I might be giving the wrong impression.
Whale - I wish you luck and hope you accomplish your goals with this. I hope you didn't take what I said as being against your project, because I'm not.
I'm not against change, never have been, never will be. I'm fully aware that there is always something "better" just around the corner, especially when it comes to computers & similar technology. I also know that a lot of formats never take-off and some people get stuck with something they get limited enjoyment from (HD DVD or cassette players, for example) because the format is no longer supported.
ACBF sounds interesting, I just don't have any use for it. As JVJ points out, I'm thinking mainly of how this relates to the files available on DCM because they're pretty much the only comic files I read on my computer.
John C - I understand what you're saying. Yes, on a small screen it's better to have the page move in the proper order, but I"m not talking about "everyone else" with their cellphones, tablets, netbooks, hula hoops and thingamajigs. I remember checking-out Marvel's comic reader back when they had free comics online (lousy selection from a company that's older than dirt, by the way), and I found it really annoying that my options were only "full page" (where you can't read anything) or "panel-to-panel" (which handled viewing full page images poorly). It wasn't an enjoyable experience for me and I'm not sure I see what difference there will be between what Marvel's application did and what ACBF will do in regards to handling images.
-
Me, too. Don't want wrong impressions, either.
I see LOTS of uses for all kinds of enhancements in newly created files and formats. As a realist, I see very little chance that anyone is going to go back into the thousands of DCM books and add any new features. Since adding artist or a collection list data would be of little value to me since I no longer collect new comics, this is one of those tools (like a smartphone) that simply wouldn't touch my life in any way.
But as I always try to make clear, I am NOT the target audience for such things, so my opinion represents a minority of one (ok, perhaps ten). I don't have a smartphone. I don't have a tablet. I don't even have a TV. NOBODY is targeting ME for anything. Please keep that in mind when I am commenting.
Peace, (and privacy) Jim (|:{>
-
Yeah, I see the disconnect, bchat. I made the assumption that basic comic reader features would be carried over blindly. I almost always read with "fit width" set, too, and wouldn't touch something without it.
But a project like this is less about the software (except for demonstration purposes) than making sure the format covers everything we'd want IF it became popular.
For example, GAC once had that crash where we lost all the file names; reconstructing that from inside the files themselves would've made life far easier. By the same token, it'd be easy for any of us to automatically save files to the right location in our private libraries, whether we organize by publisher, year, artist, or whatever. If we had unique ID numbers given to the books, we'd be able to distinguish the scanner's original from later-edited versions, automatically filter books we've been asked not to host, and so forth. If it had the text of the comic, someone could copy it out and work with the transcript. Holding the panel geometry would make it possible for the software to allow you to copy specific panels, too, which might be handy.
So there's a ton of potential in just the idea, regardless of the software. The chicken-and-egg part, though, is without really good software (especially for the scanner, who would now have more work), nobody'll do the work, which basically means that it's the worst case scenario: Functionally the same as CBR files, but incompatible. That critical mass is difficult, especially with such a strongly-established format.
-
The chicken-and-egg part, though, is without really good software (especially for the scanner, who would now have more work), nobody'll do the work, which basically means that it's the worst case scenario: Functionally the same as CBR files, but incompatible. That critical mass is difficult, especially with such a strongly-established format.
I totally grok that dilemma. I think that the ideal would be to create additional information about the comics in a way that's compatible with the existing format. I have two ideas about this, just off the top of my head.
One goes back to my own introduction on this board (http://digitalcomicmuseum.com/forum/index.php/topic,2388.0.html). The zip file format (used by cbz, but not cbr) has a mechanism for including limited amounts of metadata with an archive. This site over here (https://code.google.com/p/comicbookinfo/) suggested some ways of populating interesting metadata in the zip notation. If your reader ignores that metadata, fine. Otherwise, hey! Cool extra stuff! Obviously, that has the problem that it doesn't support cbz. Well, that and the "who does the work" problem.
The other idea relates to using Exif data on the images themselves. Increasingly, more and more tools are putting Exif data on your images -- my iPhone puts GPS and date information on my photos, for example. I'm not sure what kind of size limitations there are for Exif data, but assuming that one can put a reasonable size of data on the image, it'd be a great way to store comic metadata. Exif is supported on JPGs (and TIFFs), which is probably what the vast majority of the comics on this site have been scanned as. Again: if your current reader doesn't understand the Exif data, no big deal. The image is still viewable. But, hey, there's still the "who does the work" problem.
I'm sure that there are other solutions.
BC
-
The other idea relates to using Exif data on the images themselves.
After looking at the Google for a bit, I think XMP is a better solution than Exif.
BCing you
-
@bcholmes:
I know about "comicbookinfo" and there's even "comicbook.xml" used sometimes, but meta-data there is quite brief at most, documentation almost non-existing, support by readers limited. Also comicbookinfo is only usable for CBZ files not for CBR/CBT/CB7 etc. CBR is proprietary ...
Expanding those comicbookinfo or comicbook.xml specifications would require more energy and doing many compromises (being careful about not breaking functionality in readers that may support it) than creating a new format.
On the other hand acbf file can be relatively easily created by conversion from existing formats. I plan to write such a convertor that will also support existing meta-data if present. Also backwards conversion from ACBF to CBZ (creating comicbookinfo in the process .. though some meta-data may be lost) is possible if someone writes such a convertor.
I plan to include in the format as much meta-data as possible, therefore asking people for suggestions if I missed something so far. Specifications are still improving. Final version 1.0 is planned for 1st March 2012, beta version on 1st February 2012, if everything goes well. Meanwhile, working on ACBF Viewer as well that will support all those possibilities ACBF provides.
Cheers
Robert
-
If anyone interested, I just released version 1.0 beta of ACBF specifications along with complete XML schema as well as linux installer and Windows executable for ACBF Viewer version 0.4. Five sample comic books are also available to download. Everything can be found on project page (https://launchpad.net/acbf) in the green download section on the right side.
Some major improvements:
- ACBF Viewer is capable of loading CBZ files as well as ZIP files containing images
- comics can be read on "fit width" zoom level
- *.acbf file can be embedded into CBZ archive for improved compatibility with pure CBZ viewers (this is supported by the viewer as well)
- and many other minor fixes and improvements
Final version of specifications is planned for the beginning of next month. Any suggestions and spotted bugs are welcome. If you don't want to install the Viewer you may want to take a look at some screenshots (https://plus.google.com/photos/110989843476988874482/albums/5692035097709963025) perhaps :-)
-
Hi Whale,
while I can see the point of having artists' data et al. in a file, or tags, this all comes down to how we conceive onscreen reading.
Personally, I consider eBooks and generally onscreen reading as a mere tool, because if a book (or a comic book) is worthy it needs to be printed and to be read. Onscreen reading is not reading, for many reasons.
Comics in digital format are great to discover, and for consultation, but as I stumble upon something significant, I immediately see if I can purchase it. In fact, since I use a Mac (and since 1988) I have never kept a CBR or CBZ archive, and I always decompress the archives and keep the JPG files in a folder. As for the artists' credit, I find more convenient to research them, as the need arises, and transcribe them in a separate text file.
I enjoy having high-resolution scans when the comic is too expensive, or when I just wish to have a look at them for comparision, but I see books and eBooks as two specific different things, with specific different aims. There is not the kind of difference there was, say, between a manuscript or a hand-produced book and an inkunabula. An eBook, or an etext, is something which is helpful for study, but it has no physical form, so it can’t be compared to a physical product.
Said all this, I think it would be a worthy effort what you are doing, since CBR and CBZ actually aren’t proper formats at all. From what I get, are just variant formats of a compressed ZIP file. :)
-
Personally, I consider eBooks and generally onscreen reading as a mere tool, because if a book (or a comic book) is worthy it needs to be printed and to be read. Onscreen reading is not reading, for many reasons.
Keep in mind that this isn't a permanent state. Nobody (of relevance) believes that music can only be appreciated when played in person anymore, nor that it must be stored on an analog medium like tracks through vinyl, nor even that it needs to carry the full frequency range that humans can hear. Heck, MP3 is demonstrably worse than any other way of listening to music, and it turns out that nobody actually cares.
Don't get me wrong, I love my smelly, heavy paper books, both the comic and text-based varieties. But the only non-nostalgic difference between them is that my monitor is harder to stare at than paper...but there's a lot of smart people fixing that as we speak.
-
Hi,
thanks for the response vaillant.
As for the artists' credit, I find more convenient to research them, as the need arises, and transcribe them in a separate text file.
In the future I plan to implement a library that will be based on the meta-data present in the comic books. If that meta-data information is present it is then very easy to import those comic books into the library with just a mouse click. You can then view and browse the library, sort and filter the comics based on different criteria, search in the meta-data etc. Depends on how good the implementation and possibilities are. Export of the whole library to a text file can be implemented as well if someone prefers it that way. And, BTW, one of the meta-data tags is "DatabaseRef" which references some open comic book database (e.g. Grand Comics Database) and if program is smart enough it can update the information about particular comic book after querying that database when online.
I enjoy having high-resolution scans when the comic is too expensive, or when I just wish to have a look at them for comparision, but I see books and eBooks as two specific different things, with specific different aims. There is not the kind of difference there was, say, between a manuscript or a hand-produced book and an inkunabula. An eBook, or an etext, is something which is helpful for study, but it has no physical form, so it can’t be compared to a physical product.
Lots have already been written about e-books vs. paper books and everyone has some preferences for one or another. I personally prefer e-books, they are more practical (I can read them in bed at night without having to turn on the light for example). In fact, I have not read a paper book in the last couple of years :-)
Said all this, I think it would be a worthy effort what you are doing, since CBR and CBZ actually aren’t proper formats at all. From what I get, are just variant formats of a compressed ZIP file. :)
Yep, CBR/CBZ are just compressed zip files, but since they are so common and they are so easy to create (people are lazy after all :P) I decided to make ACBF CBZ-compatible which is good thing. I have also a lot of comic books in CBZ and I'm lazy too to fill in the meta-data too (that GCD database reference will be a killer feature ;D).
-
It’s not just a question of preference, but of phisicality.
First, you have to depend on a technology, and an advanced technology. As of now, without a device you have no book: just a set of data.
Secondarily, even when a technology becomes transparent, is not like a physical object.
Without electricity you could still produce a book. Of course, without electricity we wouldn’t be here talking at an ocean's distance, but you’d still be able to read. And there are a lot of other substantial issues, regarding *how* a book is read, and how it affects the way you read.
-
I'm struggling with formats myself. I am totally sold on the iPad as a comic reading device. The new iPad with its retina display is like looking at a printed book... not just a comic book printed on pulp, but high quality printing. I digitized some engravings by Dore from a book from the 1840s and they looked better than the original. I could zoom in and examine details that I could never see without a magnifying glass on the printed page. I want to publish picture books in this format.
The problem is the file formats and distribution networks... The epub format used in Apple's bookstore is designed for text, not images. Amazon uses PDF format, which does everything one would want, but they limit file sizes to 50 MB, which limits the number of full page images considerably. Lulu accepts PDFs up to 500 MB. That seems to be the best I've found so far.
The CBR format just doesn't work for what I want to do. I need blocks of text giving context to the images. Converting all that text to JPEGs at a decent resolution would bloat a 200 page book up too much, and it would slow down switching between pages. It's fine for straight scans of a comic book, but I want to create digital coffee table books.
At this point, I'm experimenting with PDFs and trying to come up with a code of best practices for publishing coffee table e-picture books. I'll probably start by distributing them directly from my own site, but it would be great if some of the e-book stores would take the next logical step.
Has anyone else tried anything like this?
-
Sounds very exciting PP. Sorry I can't help with any personal experience but I wish you the best on this.
If you'd like to share a preview of anything and get opinions please feel free to post a link here.
Good luck!
-Yoc
-
Hi all,
if anyone's interested. Final specifications for ACBF format 1.0 is out. As well as version 0.6 of ACBF Viewer was released. You can find it on project page (https://launchpad.net/acbf). Sample Craphound comic book contains rich metadata, comic book structure definition (pages, panels), page indexing (Table of Contents) and 2 separate text-layers (english and slovak translation between which user can switch). New in ACBF Viewer version 0.6 is that drawing of text-layer for translation over the background image is handled automatically by ACBF Viewer application (best-fitting text into defined bubbles).
This basically concludes my work on ACBF specs. Anyone is invited to study the specs and sample comics, create his own comics, using ACBF to translate comics into different languages and creating his own applications based on ACBF specs (viewers, editors, convertors etc.).
-
just want to bump this one up 8) Since I first started this thread (10 months ago) format and viewer improved considerably. Last release of viewer includes initial version of comic books library. So if anyone's interested, you may try it. There are versions for Linux and Windows. Screenshots are on Google Plus (https://plus.google.com/photos/110989843476988874482/albums/5692035097709963025).
-
Hi everyone,
it's been a while since I posted this topic. Meanwhile, ACBF project has evolved a lot. So, if anyone from this community is interested to try it out, here's what's new:
- ACBF Viewer (Linux and Windows version) almost fully supports 1.0 format specifications, has it's own comic books library, based on comic metadata you can browse it easily
- ACBF Viewer for Android - new application, port of ACBF Viewer to Android, supports smooth panel by panel viewing
- ACBF Editor (Linux and Windows version) - application to help you create ACBF comics (CBZ files with ACBF file inside), edit metadata and you can already create frames/panels definitions there
- Several comics have been converted to ACBF, many of them having panels definitions and text-layers with translations; complete list is available on Wiki page: http://acbf.wikia.com/wiki/ACBF_Comic_Books
Main project page: https://launchpad.net/acbf
Wiki page having a lot of information about the format and available tools: http://acbf.wikia.com/wiki/Advanced_Comic_Book_Format_Wiki
For maintaining a my comic book library I use desktop ACBF Viewer application, for editing metadata ACBF Editor and for actual reading ACBF Viewer for Android. ACBF Viewer for Android is also available from Google Play store for 0.5 EUR, if anyone wants to support the project and receive updates from there, but otherwise everything is open source and free to download from project page on Launchpad.
Enjoy converting some of your comics to ACBF with metadata and panel by panel viewing 8)
-
Impressive - good luck with this Whale!