[openbeos] Re: File format support in Haiku
- From: "Jonas Sundström" <jonas@xxxxxxxxxxx>
- To: openbeos@xxxxxxxxxxxxx
- Date: Wed, 04 Apr 2007 16:45:34 +0200 CEST
Ar18@xxxxxxxxxxx top posted:
Please read
http://wiki.ursine.ca/Best_Online_Quoting_Practices
> 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.
If you want to engage in a truly meaningful discussion about improving
the Translation Kit, or any other part, you need some working knowledge
on it. The essence of what you're asking for is there in Haiku and in
BeOS.
The Annotated BeBook is here
(as long as beunited.org is still around):
http://beunited.org/bebook/The%20Translation%20Kit/index.html
The intro page link is bad, but it's there too:
http://beunited.org/bebook/The%20Translation%20Kit/Translation%20Kit%20Intro.html
This may not be easily understood unless you've got some programming
skills, but it's the only document AFAIK that tells the whole story or
what's possible and what's not possible, for a Haiku application
programmer, and Haiku apps, with the current API.
About a wish list,
I would like to see a simple, explicit X to Y data translation API to
complement or replace the current translation kit. One that doesn't use
crippling, least common denominator, baseline formats. Less convoluted,
more powerful.
This new API would work equally well for offering baseline format
support to apps such as ShowImage and StyledEdit. They would simply ask
for some-file-format-X (e.g. JPEG) to a common format (raw bitmap,
flattened BBitmap) they (or the system) understand. The system would
ship with basically the same set of translators, except there would be
no once-decided-on, limited set of baseline formats, only de facto
standard, available translations.
I would like to see the old Translation Kit API deprecate the use of 4-
character type codes (classic MacOS inherited) and rely only on mime
types. I don't think datatype groups (in mime supertype form or int32
constant form) need to be supported, if the concept of baseline formats
is deprecated.
I would like a translator's two overlapping "quality" and "capability"
estimates replaced by a single variable (float 0-1 or integer 0-100). I
don't think these values are especially useful, but it might be of some
use for choosing the best translation path if you want to try an X to Y
to Z multihop translation and there are many ways to get from X to Z.
It would give you a rudimentary value to compare:
Path 1: X-A, A-Z: 0.5 * 0.5 = 0.25
Path 2: X-B, B-Z: 1.0 * 0.5 = 0.5
Path 2 probably retains the most information, but we can't be 100%
certain. The user knows best how to estimate the loss of information.
I would like a string variable explaining the overall limits of the
format-x-to-format-y translation. It would also be nice to have a post-
translation report available, when desired, in string format, of how
the translation went. What features were stripped, if data was degraded
or altered. Perhaps also a 0-100% success variable. Applications can
then choose to make use of these features if they please, or ignore
them.
...
> 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.)
You can embedd any data in the resource section of the executable file,
or directly in the source code. If the applications takes add-ons,
those can contain additional data in whatever format. There are classes
in the current API that allow displaying images and, I believe, simple
vector graphics, as well as playing sounds (without any visible
controls though, AFAIK), but it's not like embedding files in word
processing documents or in web pages. Replicants -could- be used for
this -- a "fat", contained(?), kind of data insertion -- embedding data
with a rudimentary, possibly standardized set of controls, GUI and/or
non-GUI controls. I'm not a huge fan of that idea myself, for Haiku,
but I suppose it can be done. Applications would have to have support
added, to be able to be hosts to embedded content of the kind I
interpret you as asking for, but I don't think there's a solution that
will instantly open up any given (old) application, without editing its
source and rebuilding it, to arbitrary, safe-ish, content embedding.
But I welcome any experimentation.
/Jonas Sundström.
Other related posts:
