File container / file type translators

[justice]

If you have ever used BeOS you might recall they had a system called translator kits [1][2]. Basically you could add kits to the OS to enable reading / writing to a particular filetype. So you had a GIF translator kit, PNG etc. Any appllication with support for translator kits could then use these file formats.

Seeing how often particular software on Windows does not support a filetype (Try converting SVG files to PNG for instance, fireworks and photoshop don't support them, illustrator doesn't have a batch mode etc), I would have thought the translator kits idea would be a popular way to solve a major computing annoyance? Why is this not the case? How much better would it be if Windows had a centally managed filetype reading writing mechanism with addins provided similar to how they extend the indexing service at the moment (probably the addins would be very similar? a PDF indexing service addin already allows the indexing service to read and make sense of pdfs)

It seems to me (but I am not a programmer) that they already do it for video and music files: both AVI and MOV files for example are just container formats that support codecs. Why couldn't we have an .ADOBE container format with the codecs for all their software, or ultimately just .graphic, .music that can be opened by any program supporting the container (which the codecs doing the read/write to the software)? Or the end of file extensions.

Interesting idea or am I just clueless   ?

[gjehle]

the one-fits-all paradigm sounds nice but fails for non trivial tasks.

just take your svg to png problem
svg is a standard that supports a _lot_ of stuff, there's hardly a svg implementation to date (afaik) that supports all details in the way it was thought out by the w3c. same goes for html, css and all other public standards.

what the translator kit does is build an abstraction layer "file" or "displayable file".
nice idea, but limited.
eg. for svg you have vector information, you can do all kinds of transformations (rotate, skew, resize, ...) without loss of data.
for png you have discrete pixel values, doesn't work that nice :p

there is no parameter-less transformation from one of those domains into the other nor do i know of any superset that could represent both file formats in a way that would be useable and feasible to implement at the same time.

since you lack this superset you can't have that "_any_ program handles _any_ format" thing.

if you only have trivial cases like "load <file> scale to <size> and display <here>" you can use translators, since it's one-way.
that's perfect, and it's nice to have a translator.
the only reason this works is because you already do it _everywhere_. take a file and transform it to a _known_ size with the target format being a bitmap. every program does it do display everything it wants to your screen.

but for everything else, like editing files, forget about it ;-)
since this is a whole different paradigm, it's unlikely that windows will implement this on OS level. (too much work)

the reason you implement a specialized file format is:
you have z specialized data set that has special access functions and supports a special set of operations.
(note the word "special")

[justice]

Ah thank you for that very informative explanation! So I guess at the most something like that could work if all the formats were propretiary to one company, in case they probably have made their software compatbile with one another already.

[gjehle]

Ah thank you for that very informative explanation! So I guess at the most something like that could work if all the formats were propretiary to one company, in case they probably have made their software compatbile with one another already.

no, proprietary formats have nothing to do with that.
it would work if you only have one target domain (display file on screen as color bitmap).
it would not work if you want to translate between several domains back and forth (as in bitmap to vector to text... etc)

[2stepsback]

Hi,
nice idea, but i didn't quite get your problem ...... or is it just an idea that struck you and no problem as such. I mean, what's wrong with your regular *converting* from one format to another?

Programs like IrfanView do a damn good job of converting between so many formats.
To quite an extent OpenOffice as well. We have the Win32 API and these programs that do the conversion, batch mode, cropping, resizing whole hog.

Probably I'm missing the point.... 

Also, IMO, keeping this out of Windows core is *beneficial* considering the so many undocumented things Windoze has and their ability to leave security holes in code and file formats.

This "Software995" thing has all sorts of convertors as well .........

Btw, side note, does anyone know of a program that takes a folder tree (directory, subdriectory, sub sub directory..., files, everything) and makes a single M$ CHM (compiled help manual) file from it?
Assumption: relative links inside the files are correctly in place.

TIA,
2stepsback