Am 26.11.03, 22:53 +0100 schrieb Sven Neumann:

> Non-gzipped would certainly have been preferred since it allows to
> comment on the code more easily.

It would become ~140kB so I avoided unzipping for the list readers.

> > the patch for 97352 TIFF plugin shows progress bar when run
> That bug was bogus anyway and the "fix" got reverted when be changed
> all plug-ins to do the right thing.

Fine to hear.

> Your plug-in has some interesting parts like where it reads multiple
> TIFF pages and also the use of lcms to do the color conversion should
> be considered for inclusion in the GIMP plug-in. However we probably

Any testimages, which help showing weak points, I would like to see.

> don't want to include a plug-in that will double the amount of #if and
> #ifdef statements in the GIMP source tree.

As I like to continue to develop this tiffreader, what would You think is
appropriate to let the #if / #ifdef macros fall without erasing code?
If You know how to avoid this I would change the code. One thing I imagine
is to bring missed functions in the header and declare them likewise. The
most part of lcms stuff and higher bit modes #if/def s would still remain.
I dont like macros very much as they introduce another language. But I
dont know how to change this.

Please consider I develop for 4 versions of the application (after
gimp-2.0 for three). It is awful to copy the code from on plug-in to the
next and the next and introducing as many bugs as possible. This would
not be my goal.

> Are you or is anyone else interested in merging the interesting parts
> into the tiff plug-in as found in our CVS tree? If noone raises hand,
> I would do it myself. Not sure if the functionality that depends on
> lcms should be included before 2.0. I would suggest we start with
> adding support for multiple pages.

I would help of removing spread comments.
Thanks for going to include it.


Gimp-developer mailing list

Reply via email to