From: Sven Neumann <[EMAIL PROTECTED]>
   Date: 06 Sep 2004 17:52:20 +0200

   a while ago we decided for a feature freeze for GIMP 2.2 that
   should have taken effect last week. I haven't enforced this feature
   freeze yet because there's been some good hacking going on recently
   and I think we definitely wanted to have these features in
   2.2. With the 2.1.4 release, we've reached a point where the new
   stuff (GimpProgress, GimpPreview) seems to be rather well working
   so we could declare a feature freeze right now. I do think however
   that we should give us a little bit more time and try to get the
   following done during the next weeks:

    - add more plug-in previews
    - try to make the previews scale with the dialog
    - implement color management as was discussed earlier
    - fix unit handling and resize / scale dialogs
    - allow for better layer positioning / alignment
    - integrate the metadata editor that Raphael is working on
    - finish and fix whatever is unfinished or broken

   I would suggest we attempt to get a 2.2 prerelease out by the end
   of this month or early in october. Given the fact that the tree is
   fairly stable, we should then be able to deliver 2.2.0 by the end
   of october.

   Please comment on this proposal if you disagree with it or think
   there are important features missing that you are already working

I'd like to get a decision on what to do with the print plugin.

We (Gimp-Print) are in 5.0 beta, and I'd like for the GIMP 2.2 to use
a 5.0-based plugin rather than a 4.2-based one.  The Gimp-Print source
tree has a GIMP 2.x-based plugin.  There has been discussion about
transferring ownership to the GIMP, and if this is going to happen it
should be done soon.  If it's going to stay in the Gimp-Print tree, it
needs a maintainer, since the people who have been doing it aren't
really GIMP experts nor UI programmers in general.

Particularly if there is to be color management in the GIMP, we need
to look at this carefully.  Doing 8 bit->8 bit color transformations
prior to printing will yield quality problems that could be solved
with 8 bit->16 bit transformations, as Gimp-Print can handle 16 bit

Robert Krawitz                                     <[EMAIL PROTECTED]>

Tall Clubs International  -- or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton
Gimp-developer mailing list

Reply via email to