[openbeos] Re: File format support in Haiku
- From: Ar18@xxxxxxxxxxx
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 04 Apr 2007 01:25:52 +0000
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? I obviously know
nothing about how the translation kit currently works; however, there are
certain concepts that I think the future Haiku (not R1) needs.
How could someone get involved in this process? What developers should I talk
to?
I would like to consider the possibility of forming a kind of working group
around this process, but of course would need to rely heavily on the input of
the core Haiku developers, as well as make sure it is all within the vision the
developers have for the future redesign of Haiku (after R1).
Below, I outlined some key concepts. Haiku has some of these things (as you
mentioned). However, I would like to know... how close is Haiku's design of
data translation to these more idealistic goals? Do you think a
rethinking/redesign of the translation kit or the whole translation kit is in
order in order to achieve these goals? I would like to consider any possible
redesign that would be needed (without regards for backwards
compatability).♦
1. Native file format support should apply to nearly everything.
2. File format support would be divided into categories (each category shares
similarities, but is uniquely different from other similar categories). Here's
a kind of list:
bitmap (bmp, gif, jpg, etc...)
vector (svg, etc...)
icon
raw (camera data)
image editor data format (psd, paint shop pro -- include all app specific stuff
like layers, filters, etc...)
dem
cad
compressed files (zip, tar, ace)
video (avi, mov...)
audio (mp3, wav...)
text (txt)
rtf (rtf)
word processor (doc, owd, Gobe -- includes all word processor specific add-ons
and formatting)
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. For
example, bitmap/raster might use raw bitmap data as the standard. 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).
So, when opening a file within a particular category, it converts to the
standard within that category and serves it up to the application; and a
reverse process occurs when saving the file.
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.
5. Complex file types like PSD or DOC files would require the development of a
new standard format for that category that the files can be converted to before
they are served up to the application. Such a process would require
considerable planning. It would also involve things, like allowing the
standard to be extended with extension and updated over time.
6a. Haiku should have built in dialog windows for certain file types that
appear when you open or save certain files (like dealing with the idiosycracies
of compressed images).
6b. In addition to basic options UIs that might be needed; there may also be
the need to develop more complex UIs for saving certain formats (for example,
when saving to a lossy image format it would be useful to have a preview UI.)
6c. Because we are MIT licensed, these default dialogs should be able to be
overwritten by the app developer. The developer can then replace it with their
own UI and just serve the data to Haiku (skipping Haiku's built-in UI). This
would allow the development of special image compression optimization programs,
while maybe still taking advantage of Haiku's built-in format conversion.
7a. Conversion from one format to another format category should also be
possible. For example, getting SVG in some type of bitmap/raster format or
vice versa. This is almost a whole other issue unto itself.
7b. Special built-in dialog UIs would also be needed for this (again with the
ability for app developers to overwrite all or parts of the built-in UI).
8. File format support should extend beyond just dealing with opening,
converting, and saving a file format. There should also be a method for
embedding each type of category (bitmap, vector, video, etc...) into a app; and
I don't mean replicants. 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.
-------------- Original message ----------------------
From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
> Ar18@xxxxxxxxxxx wrote:
> > 1. Can the Translation kit be extended to handle other file
> > categories
> > (vector, bitmap, raw, image editor specific formats, word processor
> > formats, etc...). I assume it already handles a few of those, but
> > not all.
>
> It could, but it always needs a native type format all other can be
> converted to.
> Since there is none for vector images, we would need to specify one
> (like SVG).
>
> > 2a. What does the Translation kit do when a format needs special
> > options in the UI? For example, when you save a gif file, various
> > parameters about the compression must be set. Does the translation
> > kit provide the UI with these options?
>
> It does, every translator can export a settings view.
>
> > 2b. Can the UI be overwritten with a custom UI by the app developer
> > yet still pass the options to the translation kit so the translation
> > kit can
> > be used for the save process?
>
> Yes, configuration works using messages. Unfortunately, there are not
> many commonly defined settings available, so you could only override it
> in a useful way if you know the translator well.
>
> > 3a. Can the translation kit handle complex formats like word
> > processor
> > files?
> > 3b. Can it convert from Word to Open Doc format?
>
> Same as with vector files - the only usable word processor format is
> the one of Gobe Productive, but as far as I can tell, it has never been
> published.
> There is definitely room for improvement concerning the translation
> kit.
>
> > 4. Does the translation kit require including a dll into the program
> > at
> > compile or is it separate from the program (and thus you can add in
> > more file support long after the program has been made)?
>
> Your application only links against libtranslation.so, the file format
> support is delivered by add-ons that you don't have to care about. Much
> like the datatypes library on the Amiga in case you're familiar with
> that.
>
> Bye,
> Axel.
>
>
Other related posts:
