* Andreas Beck ([EMAIL PROTECTED]) [000203 13:09]:
> > > Hmm - I'd like it better, if it would read only P?M and use ppmtools to
> > > convert any other format as required.
>
> > I want to have reading some different file-formats and not only one.
> > That's why I hack the file-target.
>
> This is a misconception IMHO.
>
> The idea of the ppmtools is to finally put an end to reinventing the picture
> loading and saving wheel for every program/lib/whatever.
>
> As long as you can load/save ppms (which is trivial) you can load/save any
> format by just piping the output through the appropriate ppmtools.
>
> LibGGI is intended to be lightweight, and I'd like to keep it this way.
Compile-time options and existing dynamic libraries can take care of this,
but I think ppms can solve it too (see below).
> So what you should do is to use ppmtools to convert other filetypes to/from
> ppm on the fly.
I almost agree, let me just clarify some points. I think it should be
completely transparent. What I think you're suggesting, and what I would
suggest, is to have this conversion built in the file target: when opening
something that is not a ppm, file-target tries to find the correct ppmtool
and spanws it in the background and gets the ppm through a pipe or whatever.
The user is never aware of the conversion.
My only con to this option is that its not really efficient both in terms of
speed (spawns process, reads file, pipe file...) and memory (at some point
two copies of the translated file have to be in memory, one for each pipe
end --- and that can be a *real* problem in systems with relative with low
memory, since ppms are not really good in saving memory --- swap, swap...).
Ideally, some very common types could be built in. We have libjpeg.so (I
think we even have libtiff.so), so there's almost no overhead in having
jpegs. For GIFs, use the ppmtools scheme above (avoid legal problems). What
I'm really against is implementing a complete jpeg reader from scratch, for
example.
--
Cesar Augusto Rorato Crusius o__ o__ o__ o__ o__
Stanford University ,>/'_ ,>/'_ ,>/'_ ,>/'_ ,>/'_
e-mail:[EMAIL PROTECTED] (_)\(_) (_)\(_) (_)\(_) (_)\(_) (_)\(_)
www.stanford.edu/~crusius
HE WHO SACRIFICES FUNCTIONALITY FOR EASE OF USE
LOSES BOTH AND DESERVES NEITHER
