[openbeos] Re: File format support in Haiku

> From: Ar18@xxxxxxxxxxx
> Date: 2007/04/04 Wed AM 01:25:52 GMT
> To: openbeos@xxxxxxxxxxxxx
> Subject: [openbeos] Re: File format support in Haiku
> 
> Do you guys think there is room for improvement (or the
> need for a total rewrite) on the concepts of how the
> translation kit works? 

The problem with all this file format idealism is that it is impossible to 
define a closed scope for the "standard" formats. Bitmap data is the only thing 
where there are multiple formats for encoding identical data (a 2d collection 
of pixels).

Any attempt to make the conversion too transparent hides the fact that file 
formats are different for a reason. In an ideal world, round-tripping should be 
possible without altering files. However even in the simple bitmap case this is 
not true - saving a JPEG to a GIF and then back to a JPEG would destroy a 
photo. Even JPEG to PNG would not lose image data but would probably lose the 
EXIF attributes from the camera.

> [...]
> 3. To handle native OS support for filetypes, perhaps
> the best way to go about the process is to define a 
> standard filetype within each category. [...] Vector
> might use a modified SVG as the standard (I say
> modified because it would need to include the ability
> to support all the features of all other vector formats).

And there is the problem. The "standard format" that supports everything is 
undefinable - SVG includes support for animation, whereas the Haiku Vector Icon 
Format includes support for different shapes to be drawn when the image is 
rendered at different sizes, and the reuse of path and fill information. Any 
standard vector format would have to support all of these and any other little 
features of other formats we want to convert between. Perhaps even worse, the 
Haiku vector editing application would have to work with this huge 
all-vector-types-combined format.

> 4a. Each Haiku app would be capable of only working
> with certain categories of files (like a Haiku image
> editor may only be able to work with bitmap/raster
> data).
> 4b. As a result, a program would request a file from a
> category that it can handle (like raster/bitmap) and 
> Haiku would simply serve up the file in the standard
> raster/bitmap format that has been agreed on.

It works perfectly for images, which I suspect is why you use that as your 
example. Imagine if Haiku instead serves up a simple text file in the format 
that supports all the combined features of MS Word, OO.org Writer, KOffice and 
Gobe  - I wouldn't want to write the application to deal with that!

The only way anything useful can be done is to stick to a low common 
denominator. The translation kit works so well with images as most of the data 
that we care about in an image file is the colour of the pixels. Thus other 
parts of the file are mainly ignored by the translation kit (EXIF headers for 
example). If an application needs some data like this specific to a particular 
file type it will have to have that support coded into the application. This 
would be necessary for losslessly rotating JPEG images for example.

There is certainly scope for defining other types of translations - vector 
images and image editor data including layers for example - but again, the only 
way it will work is if the common format just supports the most useful subset 
of data stored in the various formats.

The other problem with your huge-mega-standard approach is that it would be 
possible to produce a huge-mega-standard file that combines unique features 
from more than one different original format. The file then becomes unsavable 
in any format other than the huge-mega-standard one.

A simple translation kit framework also has scope to aid reuse in some specific 
situations. For example I was working on an image browser a long time ago and I 
was planning to write a translator to extract the thumbnail stored in JPEG 
images from digital cameras. Then anyone else who wanted similar functionality 
could use the same translator add-on, and the translation kit, to quickly 
retrieve the thumbnail bitmap with very little code. Note this is a different 
approach to having a mega-super-format, where the standard bitmap format 
produced by the translation kit would have to be extended to include support 
for embedded attributes such as the thumbnail.

> 8. [...] There should be code, APIs, or whatever to
> handle the embedding of these formats into an
> application (one for bitmap/raster, one for vector,
> one for video, and on and on for each category.)
> 
> 9. Point 8 easily flows into the concept of also
> building simple viewer applications for each category
> type -- that developers could take and build a special
> Haiku native editor off of later.  These viewers could
> even be tightly integrated with they system in some way.

A low-common denominator approach is also good in these situations when I just 
want to embed an SVG into my about box, or for a general purpose file viewer. 
If I was writing a vector editing application though I would want much more 
control and would probably have to go-it-alone.

In short, my point is file formats are different. Any attempt to hide the fact 
with huge amounts of smoke and mirrors (and gigantic chunks of code too) will 
just lead to user frustration when they try to round-trip with a file and it 
doesn't come out the same. It's nice to have a simple viewing and saving 
approach at the OS-level for simple files but overkill to try and handle all 
possible file importing/exporting needs for all sorts of complex applications 
in the OS itself.

Sorry that got a bit long!

Simon

-----------------------------------------
Email sent from www.virginmedia.com/email
Virus-checked using McAfee(R) Software and scanned for spam

Other related posts: