Jim, can you make heads or tails of this? They're discussing how they might use XML to make "ID3 style tags" to describe the contents of scanned comics same as MP3s offer.

http://www.sketchyorigins.com/comics/sh ... ge=1&pp=15

Sorry to butt in, different Jim here...

They're discussing the structure of an XML-based image file which would provide additional attributes specifically for comic-book images. It looks as though the image file payload would just be inlined inside one tag ( likely base64 encoded ) and the rest of the metadata would be used to describe either the entire book or a given page.

After defining this format, they'd then need to publish the standard so that image-viewers could make use of the new XML-wrapper around the old JPG image formats.

Jim Lawless

Hi Linda.

I don't know what a lot of the lingo means (DCP, *.nfo file, CDisplay), but that doesn't matter as I'm going to just ramble on and think aloud.

I can see the guy's main point and it is a good one; ID3 is to MP3 as ??? is to JPG. (I'm going with JPG because they didn't specify a file format and it seem no better, or worse, than anything else.)

So, I guess the first obvious question is; Is there space in a JPG header to store this type of info?

That it's not being done already leads me to believe the answer is 'No'.

Ok. So how about storing the info in a separate file? (That appears to be the question they're kicking around.)

One guy throws out a text file with a standard structure (see; windows ini file.) Sure. That would work. Another guy says; What about XML? Sure. That would work also. (Functionally, they are the same suggestion.)

Organizationally:
We'd have to settle on fields to record. I'll just throw out a few: Series Name, Series Volume, Start year of series volume (FF, vol. 1, 1961).
Issue number, Date published.
Writer, Artist, Inker...

This would make up the fields of the XML file. (I won't bother with a schema because it'd just look like goobly-gook anyway.)

Physically:
Scan in the pages to a directory. Give each page a unique name. Each directory would be a 'name space'; logical or actual. The primary key of the XML node would be the unique name of the page. The rest of the node would contain the descriptive fields from above.

This alone would be better than just a directory full of JPGs. (Duh) And I imagine that <i>something</i> like this is already being done.

Databases and software (or let the machine find it for you):
Anyone use Music Match? The beauty of it is that you don't need to know the physical layout of your music storage scheme. You drag a directory to mmjb and it recurs the subdirectories, parses the tags and presents the data in a format familiar to you - the user (artist, album, songname...)

Our hypothetical Scan Organizing Application would do the same thing. Except it would read XML files instead of headers. And then display them in a format familiar to you...

But this is me making this up as I go along.

CDisplay - it's a small program for displaying CBZ and CBR files.

What's a CBZ/CBR file? Well it's a Zip or Rar file of jpeg images that had been renamed to work with CDisplay.

CBZ/CBR file contain multiple files?

If so, that would seem like a logical place to store the descriptive text file.

yeah some people have been talking about Nfos but they are as annoying as hell.

Yep. You can store additional application-specific APP0 markers after the initial "JFIF" marker. Readers that don't know what to make of them will ignore the data in this section. It's a null-terminated block, so I don't think it has any limit on size.

They could also do this via custom TIFF tags, since one can embed a JPEG inside a TIFF wrapper, but using XML would allow for more flexible usage by other apps.

Jim Lawless

Sounds like all that's missing is an app to pull it all together.