Hi all!

Here is the 2nd patch (is attached) I produced.

Changes:

* use the file-stream from libc now
* some more cleanups
* added ppm read support
* added bmp (both OS/2 and Windows-format) read and write support


The patch compiles for me, but be beware:

I have nothing tested yet, so there might be some bugs.


I have some comments too:


Adam Scislowicz([EMAIL PROTECTED]) wrote:

> It is more fficient to use libpng, libjpeg, libtiff, etc. Then it would
> be to pipe through conversion programs. As a last ditch effort a call to
> convert could be used(as in imlib), but normally a dlopen of a
> image-loader lib(again, as in imlib) is very efficient. I have a small
> program that dlopens libpng and displays a png image using GGI, but I
> did not implement it as the file-target :(

Send me the source, and I will do it.

Originally I planned to use the libtiff, libjpeg and libpng -libs to
support these file-formats.


Andreas Beck ([EMAIL PROTECTED]) [000203 13:09] wrote:

> 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.

Uhm, I assumed at the beginning, that the RAW-file-format, which is
already implemented by Andrew, is designed for every
program/lib/whatever...

So I thought: OK - implement some read and writing stuff for generel
purposes, and hack support for some file-formats in...


Christoph Egger
E-Mail: [EMAIL PROTECTED]

P.S.: I don't forget to add the patch as attachment. I have yesterday sent
this mail to the ML with the attachment, but it seems that mails with
attachments even in text only, umcompressed are refused by the ML-server.

So, if you want to have a look at it, feel free to mail me.

Reply via email to