
We Need A Standard Layered Image Format - ingve
http://shapeof.com/archives/2013/4/we_need_a_standard_layered_image_format.html
======
mceachen
TIFF, <http://en.wikipedia.org/wiki/Tagged_Image_File_Format> has been around
since 1993. It supports layers. It supports compression. It supports paged(!)
images. It has well-defined supported image encoding formats. It's already
supported by all the image editing software you've ever used (from this
millennia).

We _have_ a Standard Layered Image Format. HURRAY. NEXT PROBLEM, PLEASE.

~~~
jjcm
Image formats have come a long way. I think the author wants an image format
that can replace .psd in a sensible way. TIFF sadly cannot do that. While it
can contain layered raster data, it lacks a lot of other capabilities. The
author explicitly mentions vector layers, but if you want parity with .PSD
you're looking at also having to support adjustment layers
(hue/curves/levels/etc), blending modes, opacity/fill, raster masks, clipping
masks, vector masks, locks, annotations, guides, grids, gradients, tags, text,
comps, channels, and countless other things I can't even think to list (I wont
even dive into smart objects). Keep in mind that's just the layer data,
there's tons of other metadata in the format as well. It is a behemoth of a
file format, and the years of backwards compatibility inside of it have
multiplied that complexity to levels of insanity. I have .psd files that if I
enable backwards compatibility when saving will increase the file size by half
a gig. Granted those are enormous source files to begin with, but with higher
def screens on the horizon file sizes are increasing dramatically. Having
something more sensible than .PSD is something we're going to have to deal
with sooner or later.

~~~
kruhft
.XCF

~~~
walid
Not really that is still as good/bad as .PSD is because of the nature of what
the file is used for. They are both primarily containers for unfinished works
and are designed to hold a lot of detail without so much regard for size and
portability. Of course the .XCF format is open but not good enough for a
simple viewer or even a web browser. Some file format based on SQLite will
probably be more viable as a cross platform image format that is extensible
beyond any one software developer limiting it. Kind of like HTML.

~~~
kruhft
It meets all of the requirements of the parent post I replied to, plus it even
has a pretty decent open source editor. It's internal structure may not be in
SQLite format, but it is an extensible tag based chunk format. You shouldn't
dismiss it so easily.

------
rogerbinns
FXG could have solved the single file problem by grouping all the files up and
making a zip file, and picking a different extension. For example this is how
Android (.apk) and iOS (.ipa) applications are distributed.

It also has the advantage that if you extract the zip you can now access
whatever pieces are inside as separate files even by tools that don't
understand the containing format. (eg a bunch of jpg/png inside the zip are
perfectly viewable in any image viewer). Trying to do the same with SQLite is
problematic as you have to write queries to grab the blobs and then dump them
to disk.

Where SQLite as a format does shine is if you need to keep historical
information such as an undo/redo log. That makes it good for an application
format, but not for an interchange format.

~~~
kalleboo
Does the zip format let you replace an arbitrary file inside an archive
without rewriting the whole file? It's not uncommon to see Photoshop files
that are 400+ MB, and rewriting the whole file on save would have some pretty
poor performance. The other examples of files that use the zip approach are
either distribution-only (ipa/apk/jar) or generally don't get very big (word
processing).

~~~
masklinn
You can easily add new files at the end, then rewrite the central directory
header (which is at the end of the file for exactly this kind of reason: not
have to rewrite everything to add new files). And because the CDH specifies
offsets to files, you can replace the old entry and put the new one there
(replace old offset by new offset, done). This does however mean the old entry
will still be in the file until you "garbage collect". That's if the new
version of the file is bigger than the old one of course, if it's smaller or
the same size you can just overwrite the old entry and not touch anything.

One could even imagine padding files in the archive so there's some leeway in
growing the compressed files, it'd likely depend on the format expression.

~~~
lucian1900
This is however the sort of thing SQLite already does for you.

------
itafroma
> Last summer, Adobe killed their image exchange format "FXG".

Edit: previously I had balked at this claim, but I'm wrong. While I can't find
any official notice of its death, and it's still in use in Scene7 and somewhat
supported in the open-sourced version of Flex, trawling message boards does
indicate Adobe shying away from it in favor of SVG[1][2] and it's not
supported in CS6 without an extension.

Still, his problem with FXG (or a format like it) seems superficial. Yes, FXG
defines links to other assets instead of combining them into one file, but to
me, that's a feature, not a problem: I can them programmatically swap out
assets easily by just manipulating the references within the file. It makes it
really useful for generating customized assets on demand. In practice, it's
like HTML for layered documents. We don't complain that HTML is broken because
it links to images instead of including them, do we?

If you don't like that you have to send a folder: zip it up and give it a
custom extension if need be, a la browser extensions and Microsoft Office
formats.

[1]: [http://mail-archives.apache.org/mod_mbox/flex-
dev/201303.mbo...](http://mail-archives.apache.org/mod_mbox/flex-
dev/201303.mbox/%3cCD676E04.4F26E%25aharui@adobe.com%3e) [2]: [http://mail-
archives.apache.org/mod_mbox/flex-dev/201303.mbo...](http://mail-
archives.apache.org/mod_mbox/flex-
dev/201303.mbox/%3cCD677E4B.4F299%25aharui@adobe.com%3e)

~~~
eridius
We also don't typically use HTML as an interchange format between editors.

~~~
justincormack
Well ePub is a zip file of HTML documents. So some people do.

~~~
eridius
Not really. Not only is EPUB not what I would consider an editor interchange
document, but the HTML isn't even the format used for the "core" document
file. An XML file with the .opf extension is the "core" file that describes
how the EPUB works, and the HTML files are actually just content, analogous to
the layer data in Gus's sqlite.

------
groby_b
"I want a filesystem in a single file. I'll pick the one I'm most comfortable
with and pretend that it's much better than separate files".

Meanwhile, we'll ignore all the semantic issues around the data. What exactly
_is_ a layer? Any given image file? What if some tools only handle e.g. alpha-
layers? What if a layer is actually a filter kernel?

How are the layers composited? How are they ordered? Is it a linear order, or
is there actually a tree of layers?

The reason PSD works so well is only partially that things are all in one
file. It's also that the semantics of its contents are extremely well defined.
(OK, if you're willing to consider PSD documentation "extremely well defined")

And Gus is almost completely punting on that part - define _that_ well enough,
and it might make sense. Until then, it's just another VFS with a blob of
assets that the receipient probably can't parse exactly as intended.

~~~
robbles
Couldn't someone come up with a relatively sane schema for storing the same
information that a PSD would contain in a SQLite database?

That way, you could standardize on the semantics that are already documented
and familiar to other developers, but avoid the difficulties of the file
_format_ , which seem to be the issue here.

* disclaimer: I've never had to write a PSD-parser, I'm just going on hearsay.

~~~
cachvico
How about just strip PSD of all its crud, Adobe specifies it openly and gives
it to the commons. I have a dream..

~~~
sneak
Keep dreaming: PSD is not a single file format, but two decades of cruft upon
cruft:

<http://www.jwz.org/blog/2012/11/psd/>

~~~
chaz
I found this article, linked in the comments, to be insightful:
<http://www.joelonsoftware.com/items/2008/02/19.html>

------
greggman
It's not going to happen for the same reason a standard 3D format will never
happen. (and no neither FBX nor Collada fit).

The problem is, at least in the case of image editors (and 3d editors),
standard formats arguably stifle innovation because you have to break the
standard to add anything.

Maybe you decide it would be be better if all vector colors were stored as
HSVA instead of RGBA except now no one can read your files. Maybe you'd prefer
to store floating point colors with values greater than 1.0 to represent light
emission. Maybe the standard only defines circles but you want eclipses. Maybe
the standard says circles are defined based on rounded rect with the maximum
roundness but you'd like them to be based on a center point and radius. Maybe
the standard doesn't support text on a path but you want text on path. Maybe
the standard doesn't support linking paths so that if the text doesn't fit on
one path it bleeds into another. Maybe you'd like to justify text across
multiple paths but that's not in the standard. Maybe you like columns but
that's in the standard. Or you want to be able to define areas to be cut into
pngs, each area with a specifiable filename. Or you want some of the settings
to be per animation frame but the spec never thought about animation so your
SOL. Or you want layer fx. Or you want to add a new layer effect. Or you want
to be able to embed a PDF as a layer. etc.. etc.. etc..

Photoshop's basic chucky format is well known. It's not that hard to write
some code to read all the chunks you care about. Putting those chunks in an
SQLite format will not make it any easier to deal with new chunks your code
does not understand.

~~~
itafroma
> The problem is, at least in the case of image editors (and 3d editors),
> standard formats arguably stifle innovation because you have to break the
> standard to add anything.

Indeed: that's exactly why Adobe created FXG instead of adopting SVG in the
first place[1] (though they are now circling back to SVG).

[1]: [http://www.mikechambers.com/blog/2008/09/30/why-adobe-
chose-...](http://www.mikechambers.com/blog/2008/09/30/why-adobe-chose-fxg-
over-svg/)

------
spartango
Interestingly, in the GIS/Mapping space Mapbox has faced a similar kind of
problem, albeit with image tiles rather than just layers. Their solution was
to come up with an image format called mbtiles
(<http://mapbox.com/developers/mbtiles>), which actually uses SQLite. It's not
the same problem, but perhaps it throws some credibility to the use of SQLite
as an on disk format for structured images.

~~~
saraid216
ESRI Shapefile formats include a DBF file, which is a Foxpro database.

~~~
peatmoss
And I still dream of spatialite becoming the one interchange format to rule
them all.

~~~
blacksqr
I just used Spatialite to create a tool for managing large stacks of images on
the pixel level; i.e., each image gets its own database file, each pixel is
stored as an XYZ coordinate and an RGB value.

I can use Spatialite's built-in functions to rotate, translate, scale, etc.
images; and use SQL to pull out sub-volumes of the stack, edit and composite
them.

My biggest stack is almost 2000 images, over 90GB uncompressed data. Working
with subvolumes is pretty snappy up to a few hundred megabytes, which is good
enough for my purposes. For bigger jobs it should be possible to parallelize
some tasks for better performance.

Not entirely on-topic, but the takeaway is I'm thumbs-up for using SQLite to
process image data.

~~~
peatmoss
Do you do anything in particular to improve access speed to that image data?
I've been working with big matrices that get spit out of traffic assignment
software that we use in travel modeling. Every vendor seems to have their own
proprietary format. We ended up using HDF5 as a container due to its somewhat
awesome speed characteristics. I'd initially tried SQLite for that matrix
data, but couldn't squeeze the same kinds of performance out of it. That could
have just been my own brain fail though.

~~~
blacksqr
Nothing beyond the standard advice for SQLite performance. I found that
keeping the data in individual per-image database files worked a lot better
than trying to create one big database for the whole stack. With that done, I
expect the big performance win to come with parallelization of the image
transformation tasks.

------
aidos
This whole idea seems totally mad from a distance but as a developer I'd love
to be able to open complex files as DBs.

What would be the downfalls of passing around a DB as an image file? Does the
compression suck? Does the performance suck? What makes this a terrible idea?

EDIT: to clarify, by compression I'm referring to the non-lossy type - I'm
assuming that within the db you'd have already processed assets.

~~~
thristian
One downside would be that tools like file(1) that try to guess a file's
format by examining its contents would return "SQLite database" for every
image file, which isn't the most helpful result.

Since SQLite aims to be a generic way for applications to store data, it'd be
nice if its "open database" and "create database" functions allowed you to
supply, say, a 4- or 8-byte magic value that would be stored at a fixed
location in the file's header so tools could distinguish _your_ SQLite-based
file-format from everybody else's, without having to load the thing up and
examine the schema.

~~~
SQLite
There are currently 24 contiguous bytes of unused space in the SQLite header.
If need be, and if SQLite catches on for use as a portable image format, I
will be willing to allocate some or all of those 24 bytes to an identifier
string for file(1).

~~~
aidos
This is surely one of the greatest responses I've ever seen on the internet.
What was the intention with the unused space originally? Did you foresee this
moment coming?

~~~
SQLite
When designing a file format, it is always a good idea to plan for
enhancements. There were originally 36 bytes of unused space in the 100-byte
header of the SQLite 3.0.0 file format, back in 2004 - bytes set aside
specifically to deal with unforeseen needs. Over the years, 12 of those bytes
have been allocated to various improvements. 24 bytes remain. (I'd prefer not
to use them up all at once or on a whim, obviously.)

~~~
sneak
Thank heaven for people like you.

------
hoov
> and Adobe, if you are listening you should really give SQLite a serious look

I'm not in the Photoshop group, but I do make liberal use of SQLite in the
projects that I'm involved in at Adobe.

------
seanalltogether
I'm interested in why Acorn ties the concept of a layer so tightly to a bmp or
shape blob rather then segregating the two. It seems that having a library
table that the layer table links to would allow for better reuse of images.

Library table <\- pixel data

Layer table <\- heirarchy/duplication of library items

Attributes table <\- attributes of layers

Also, are the concept of Pages accounted for by the ordering of parentless
layers, or does Acorn not support the notion of pages? Would that be its own
table or a modification on the Layer table.

------
hiker
OpenEXR solved that problem years ago and it's supported by virtually all
content creation tools. An open source implementation with a well designed C++
api and bindings to several other languages.

For reasons that I don't understand, it's adoption is weak outside of the VFX
industry.

~~~
jbarham
Yeah, OpenEXR (<http://www.openexr.com/>) is a very nice format, well designed
and documented, and with an open-source implementation.

Apart from VFX and post-production, OpenEXR has also become the standard file
format in HDR applications.

IMHO it isn't mainstream yet because most people don't know what HDR imaging
is and why current image formats are inadequate for HDR. For still image
editing Photoshop is overwhelming dominant, whereas in VFX pipelines there's a
lot of custom tools so you need an open format.

------
rlpb
Won't this format leave behind traces of what was in the file before? I'm not
sure that this is something that we want in a standard interchange format.
Users will assume what they are sending is only what they see in an
application. This is reasonable. I am concerned that using this format will
lead to data leaks.

~~~
angersock
That ship has pretty much sailed with EXIF and embedded metadata anyways,
right?

This would seem to be more targeted at digital content creation (and toolchain
application interop) than a normal-use file format.

~~~
rlpb
It's up to your editor what metadata it chooses to save. It is not up to your
editor what data was in the sqlite row that it just modified or deleted but
may still be forensically available. There is a fundamental difference here.

It is possible to clean it up of course - perhaps by vacuuming, or definitely
by copying to a new file at database level. But it seems dangerous to me to
start with a native format with this behavior and attempt to clean it up
later.

~~~
eurleif
>But it seems dangerous to me to start with a native format with this behavior
and attempt to clean it up later.

File formats don't have behaviors. Programs do.

Lots of binary formats, including PNG, will ignore any extra junk after the
end of the file. So if a change makes a PNG file smaller, there's nothing
stopping a program from leaving data from the old version at the end. But
that's not normal behavior for programs that write PNG, so it's not an issue.

As long as programs adopted the behavior of VACUUMing the database, this
wouldn't be an issue either.

------
aceofspades19
Whats wrong with SVG? Doesn't it accomplish what the OP wants to do already
and is already a standard supported by a lot of applications? I must be
missing something here

~~~
arielpts
XML is a really bad format for containing large chunks of binary data (bitmap)

~~~
aceofspades19
And why are we storing binary data? The whole point of SVG is everything is in
XML unless I'm very mistaken

~~~
supercoder
How else would you propose to store a bitmap.

~~~
modarts
<points> <point x='2px' y='3px' color='rgba(255,255,255,0)' /> <point x='2px'
y='4px' color='rgba(100,255,255,0)' />

    
    
        <!--...-->
    

</points>

heh

------
flutty
Zip archive containing an SVG file embedding multiple png/jpg/jpeg2000 images.

------
angersock
I would like to suggest this minor change:

    
    
      create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob);
    

become (Vec2 used for notation's sake to make the declaration simpler--just
two reals):

    
    
      create table layers (id text, parent_id text, sequence integer, uti text, name text, data blob, offset Vec2, bounds Vec2, rotation real);
    

This would make it really easy to ignore layers which have no component in the
view space, or to compactly represent raster subimages.

"bounds" is the size of the axis-aligned bounding-box of the image. "offset" i
a translation from the center of the axis-aligned bounding-box of the layer
image data to the origin, and "rotation" is the rotation (in radians, CCW) of
the layer. Order of application is rotation, then translation.

EDIT: Fixed missing def for "bounds".

~~~
eridius
I think you're missing something in your comment. There's no change between
the two lines, and no reference to offset or rotation.

~~~
aeontech
mouse over the declaration line and scroll left.

~~~
eridius
Oh, wow. HN really truncates that early. Those code blocks were narrower than
the surrounding text, with no indication whatsoever that they were
independently scrolling divs.

I get that HN is awfully bare-bones in its appearance, but this I think is a
bit too far.

~~~
chc
That is a problem with _your browser_ not clearly indicating scrollable areas.
Hacker News doesn't do anything special to prevent browsers from showing
scrollbars.

~~~
eridius
But it doesn't do anything to force the scrollbars either, or to provide a
visual treatment that indicates that this is an independent scrollable area.
We've had iOS around for 6 years now, with its hidden-scrollbars approach, and
OS X has followed the hidden-scrollbars approach for some time now as well. It
is no longer acceptable to assume that scrollbars are necessarily going to be
visible.

~~~
chc
Hacker News does everything it is supposed to according to the CSS standard to
indicate to your browser that the area is scrollable. In fact, it is obvious
that the site is doing enough because the browser does in fact render the area
as scrollable. The fact that your browser doesn't do anything to visually
indicate when a region is an independent scrollable area is _entirely Apple's
fault_.

You can argue that websites should be written to conform to the standards-
violating behavior in Apple's browser rather than actual Web standards, but we
already went through that with Microsoft in the '90s and early 2000s, and I
don't think you'll find a lot of people who are eager to return to those days.
Browser-makers are expected to conform to the standard, not vice-versa.

I am sympathetic to the fact that this is inconvenient, because I use Apple's
software too. But it's Apple that's responsible for the inconvenience, not all
the web designers who are correctly following the standard.

~~~
crgt
Huh. So do we build sites for users or to satisfy specs?

~~~
PavlovsCat
Do "we" make browsers to be usable, or to be pretty? If any random hack came
up with that idea, it would be a random, hackish idea. But because it's Apple
we have to abide? I dare say nahhhh...

------
darkstalker
What about OpenRaster? It's used in open source apps like MyPaint and Gimp.

<http://www.freedesktop.org/wiki/Specifications/OpenRaster>

~~~
eridius
> OpenRaster is an open exchange format for layered raster based graphics.

How's that going to work for vector images?

~~~
franksalim
You can have SVG layers in OpenRaster. See:
[http://freedesktop.org/wiki/Specifications/OpenRaster/Draft/...](http://freedesktop.org/wiki/Specifications/OpenRaster/Draft/LayersStack)

------
bane
One nice thing about using SQLite is that various compressed versions of the
flattened image could just be stored as blobs in another table in the same
file. For example, my camera shoots with a RAW+JPG mode that produces two
files, why not store the RAW data as described here and the JPG as an easy to
grab/display item for quick image viewers etc. Hell store various common
versions of thumbnails and icons in there as well.

------
Groxx
This is kind of like saying "We don't need PNG/JPEG/ETC, we just need to put
image data in an XML file! It can do everything! Standardization at last!"

Which is true. Except for that little "implementation" detail.

I like the idea of using SQLite as a complex-data-in-single-file format.
Hadn't really thought of that for cases like this. But it does _nothing_ to
solve the problem of _standardization_.

------
VoxPelli
Standardizing a format/API upon a tool like SQLite was something that was
proposed in the web world as WebSQL but scrapped due to not wanting an entire
standard to rely on a specific code base but rather wanting to have the
standard be possible to reimplementable by others and thus creating the
IndexedDB standard instead.

I'm not proposing that an image format like this one should use IndexedDB, but
if relying on SQLite means being reliant on a specific code base that has to
be used by anyone that wants to read the file - then it's probably not such a
good idea.

When discussing this I think one should also have in mind eg the move to web
apps as well - a reliance on SQLite will make it hard for them to read the
format. A standardized simple base format that can easily be supported in new
languages would be preferable as I see it - but I'm no expert in the image
processing area.

------
aaronblohowiak
> When you want to send someone an image you want to pass them a single file,
> not an XML file with a folder of assets. While there are technical benefits
> to this, it's an incredible burden on the customer.

Or, you could just zip that whole thing up and everyone who doesn't have to
care thinks it is "just one file", like .war's.

~~~
arielpts
Other common examples: .app .docx

------
zellyn
Some of your blobs seem to contain a lot of structured data: I would further
specify a format for them somehow: perhaps as further tables that join to the
main ones, perhaps as JSON, perhaps as protobufs. Burying application- or
format-specific blobs in SQL fields just pushes the problem down a level.

------
benatkin
The author didn't put the punchline in the title. Why did you put it in the
title, HN submitter or editor?

~~~
comex
On the contrary, in my opinion, this isn't a joke, and since the "punchline"
was likely to draw attention to the article from people that might be more
interested in a debate over the wisdom of using SQLite "trivially" like this
than a generic discussion of image formats, it was useful and shouldn't have
been removed from the title.

------
jared314
Whatever happened to the debate around how in/efficient the blob storage
format in SQLite was? Did that get changed in v3?

EDIT:

Found the official examination[0] on the performance of blob storage.

[0] <http://www.sqlite.org/intern-v-extern-blob.html>

------
nanoscopic
Correct me if I am wrong, but FXG files are an archive with an XML file and
assets, just as xlsx files are.

How is this a problem? How could is possibly be easier to open a file in
sqlite than it is to just extract the file into it's folder structure with any
standard decompression software?

I don't know about you, but last time checked there is no easy way to open a
file contained in a sqlite database in my editor directly. I for one would
much prefer the archive method than using a sqlite database.

Also, I would rather edit xml, than edit a sqlite database. XML can be edited
by any text editor. I'd say text editors are a bit more universal and
widespread than sqlite editors.

------
malkia
And why not TIFF?

~~~
splicer
According to Wikipedia, Adobe Systems holds the copyright to and has control
over the TIFF specification.

------
mkr-hn
Why not XCF?

<https://en.wikipedia.org/wiki/XCF_%28file_format%29>

~~~
takluyver
That page says: "The use of XCF as a data interchange format is not
recommended by the GIMP developers, since the format reflects the GIMP's
internal data structures, and there may be minor format changes in future
versions."

~~~
mkr-hn
It still seems like a better basis to fork for a format than something new and
untested.

~~~
rosser
Something you don't control — and which the people who do control it say
"don't use this because we'll probably change it often" — is somehow better
than something you _do_ control?

~~~
mkr-hn
> _fork_

------
Semiapies
This is an interesting idea, though I cringe a little at using a relational
database as a key/value store (as in the case of layer_attributes).

I wonder whether it would be more useful to just represent the whole thing as
a big JSON structure with base64 blobs. Each layer can be an object in the
"layers" array with the attributes as keys.

~~~
gilgoomesh
Layered images can easily grow to gigabytes in size. You do _not_ want to
store that much information in a format like JSON that must be opened into
memory, parsed and stored in native objects. SQLite is RAM efficient and quick
to open, even at large file sizes.

~~~
Semiapies
Fair enough - I rarely work much with images, so didn't even think of size.

------
pbhjpbhj
What I'd like is the ability for two editors to work on a file at the same
time, so layer locks might need to be built in. A db seems to me, a novice in
everything relevant(!), to be a good way to allow multiple applications access
whilst controlling for collisions.

------
schrijver
Don‘t think the discussion is complete without
<http://en.wikipedia.org/wiki/OpenRaster> which is already supported in a
number of programs.

------
est
IMHO SQLite is horrible format. using Matroska (.mkv) would be suitable for
anything, vectors, bitmaps, audios and so on. It's essentially a container
format like XML but for binary

WebM is based on mkv as well.

~~~
shuzchen
Could you elaborate on what specific benefits using Matroska would have? One
downside I can think of is that there are no programming environments (that I
can think of) that ship a Matroska parser, whereas sqlite readers/writers are
found in many standard libraries.

------
hardwaresofton
not a huge conspiracy theorist, but isn't this the kind of thing that would
make us not rely on purchasing Adobe CS7 exclusively (for fear of
incompatability) in the future?

Standards wise, open-source wise, and generally it's a good move (who wouldn't
want to get a standard complex image format that would make sense to the
common programmer?), but I don't think the finance department over at Adobe is
going to like it very much?

------
aoloe
.ora? (OpenRaster)

<http://en.wikipedia.org/wiki/OpenRaster>

gimp (plugin), krita, and mypaint

------
fnordfnordfnord
If someone does this right, it should go over pretty well for EDA (Electronics
Design) file formats. EDA is a wasteland.

------
jbverschoor
Good luck opening and modifying that 150MB psd file.

------
xiesx
xkcd.com/927 :)

------
7952
A limited subset of HTML would be nice.

------
Zikes
How about an additional frames table?

------
notatoad
this is like saying "i've invented a standard file format for all types of
files. i call it binary. it's made up of zeroes and ones. i've solved
interoperability forever".

------
nvk
Amen!

