I disagree that this should happen for 2.0. And IIRC there is a
bug-report on this already. We can do this in the 2.0 release cycle
just like we did the change to using libgimpprint during 1.2.

Moving to the 2.2 milestone. We can try to make this happen earlier
but it's not a necessity. If there was actual interest in this
upgrade, it could have long happened and it is a little late to push
this now.

Bug #120162 is more or less a duplicate of this bug, and was marked
FIXED when a configure check to ensure that only gimp-print 4.2.x was
valid was added, so I didn't originally find it.

Bug #99526 refers to an eventual migration path, but given that the
bug refers to something completely different, I felt this deserved a
new bug.

I have nothing against doing it in the stable release cycle. But given
that gimp-print 4.3 is now API stable and in beta testing mode (more
or less) I think that this migration could be started now, even if
it's not committed into CVS until after 4.4.0 is released.

Dave.

Excuse me - priority and milestone were changed by accident. Reverting
to the values that Sven put in.

Dave.

[For reference, I'm the Gimp-Print project lead]

Please change the summary to read "Support for Gimp-Print 5.0".

The expected final significant API changes for libgimpprint should be going back
into the Gimp-Print repository shortly (I'm running the final test pass, but
with Valgrind it takes a while).

We either need to work out the proper ownership for libgimpprintui or write a
new plugin.  libgimpprintui isn't particularly clean, so it may make sense for
somebody who's a good UI programmer to write a new plugin based on the 5.0 library.

I agree with 2.2 as a target milestone.  If 2.2 goes out as currently discussed
(3 months from now), Gimp-Print 5.0 will probably be in late beta or thereabouts.

On the Gimp-Print roadmap, all but one of the Mandatory 5.0 changes are now
complete, and all but two of the Critical changes are done.  The one Mandatory
change that isn't done is the GUI reorganization, but that should really be
subsumed by this bug; I see no reason for us to do any more work on the GIMP 1.2
plugin.  The two Critical priority changes are ink limiting (which will have no
effect on the plugin, since it will simply be another option) and piecewise
linear/spline curves (which very definitely will affect the plugin if we get to
them).  None of the Important changes that are not done should affect the plugin.

I'd love to see this for GIMP 2.2 as well, but we can not have a stable release
depend on an unstable release of Gimp-Print.

Yes, gimpprint 5.0 being in late beta doesn't sound too good for GIMP-2.2.

Since noone has been working on this until now, I am afraid we will have to
postpone this. We should consider to do a short development cycle and target for
a quick gimp-2.4 with color management and an updated print plug-in.

Setting the milestone to 2.4 as suggested in the previous comment.

Just FYI, debian sarge does now ship with the new Gutenprint plug-in in a
seperate package and compiles gimp with --disable-print.

I would suggest that we drop the print plug-in from the source tree and only
keep the newly added gnomeprint plug-in (which needs more work). People can then
install the GIMP plug-in from gutenprint if they need more control over the
print process.

I disagree; either we ship with a gutenprint plug-in, or keep the gimp-print one
around.

Having a gnome-print plug-in is a great idea, but gimp-print is ubiquitous, and
importantly it comes with the GIMP (at least the plug-in does). Dropping a
well-tested (albeit old) plug-in for a newer one which needs work isn't a good
idea, IMHO.

The gimp-print plug-in is buggy and a constant source of problems and bug
reports. It is outdated and unmaintained. I don't see a point in shipping with
it any longer. The gutenprint plug-in seems to be best maintained by the
gutenprint people and distributions already started to ship their plug-in in
favor of the one that comes with gimp.

Wouldn't it be a better idea to ship the gutenprint plug-in with the GIMP, then?
Linux distributions aren't the only way people get their software. If someone
installs gutenprint, great. If not, they will have the gimpprint plug-in
available anyway.

We tried that with the gimp-print plug-in and it clearly hasn't worked. The
plug-in wasn't maintained in the GIMP tree and the gimp-print people shipped
their own version leading to a cyclic dependency. I would like not to do the
same mistake again.

I'd like to have Robert's input on this, if you don't mind.

In any case we're agreed that to be useful, gimp-print will have to be shipped
with the GIMP (either by distros or by people building binaries). The question
is whether the plug-in could live with the GIMP or not.

Wasn't the circular dependency partially a problem because we wouldn't depend on
an "unstable" gimp-print, and Robert wouldn't depend on an unstable GIMP (or
move to gtk+ 2)? Is the official gutenprint plug-in gtk+ 2 or 1.2 now?

Gutenprint (which is currently at release candidate status) ships with both GIMP
2.x and GIMP 1.2 plugins.  Both plugins are factored into a small GIMP-specific
portion and a larger UI library based on the appropriate version of GTK.  The
1.2 plugin is deprecated and will be withdrawn (with the UI library perhaps
turned over to Cinepaint) following 5.0 release (i. e. 5.1 will not have a
1.2-based plugin).

The 5.0 API is completely locked down at this point.  We've declared color
freeze (i. e. we won't be changing the colors except to fix really serious
problems).  Unfortunately, the API isn't quite good enough to allow us to
rewrite the Postscript output driver the way we'd like to, but that's going to
have to wait for 5.1 at this point.

We already build Gutenprint for OS X and distribute it.  However, we're only
distributing the core, not the UI library.  I'll need to ask our Mac expert
about that.

My recommendation at this point is to cut over to a Gutenprint 5.0 plugin.  The
major release issue we have at this point is getting the gutenprint.org web site
up -- someone designed us a very nice web site, but it got cracked due to a PHP
bug on sourceforge and he then vanished on us.  If someone wants to volunteer
for that it would help us immensely; otherwise we're going to have to create a
stub web site that redirects to the Gimp-Print site.

The other question is where the plugin should be split for handing it off to
you.  The two options are to give you the GIMP stub or the UI library.  Giving
you the former means that you only need a tiny piece of code (less than 1000
lines, actually), but it also means that we'll need to formalize the UI library
interface and that you folks won't be able to improve the user interface. 
Giving you the whole UI library means that you could improve it, but it would
create an extra dependency for anyone else who wants a direct interface to
Gutenprint.  I think it makes more sense to give you just the GIMP plugin.  That
code has been stable for over a year.  There are a few other clients of the UI
library (PhotoPrint and Cinepaint), and people shouldn't have to install the
GIMP for them (PhotoPrint in particular is intended as a light weight tool for
arranging and printing photos and photo albums).  If someone on the GIMP team
wants to make UI improvements, I'd be happy to give them developer access to our
source.

The dependency problem that we had was an artifact of the extremely long 5.0
release cycle (it's almost 4 years since Gimp-Print 4.2 came out!).  If we had
released on the schedule we originally intended to life would have been a lot
simpler, but 5.0 has proven more complicated than we'd have liked and 4.2 turned
out to meet people's needs for longer than I anticipated.  We didn't want to cut
over to GTK2 until it had been out for a while.  We had agreed to turn the
plugin over to you for the GIMP 2.0 (or maybe it was 2.2) release, but of course
that broke down.

Will the GIMP plug-in coming from gutenprint fix the problems that people have
with the current plug-in? That means will it fix the bugs that this report
depends on and does it give the user a reasonably simple user interface for
printer selection? I don't think we can continue to ask our users to fiddle with
lpr command-lines.

Another question: What advantage does a plug-in using the gutenprint API offer
over a plug-in that uses gnomeprint or another library that abstracts handling
of CUPS printers? Shouldn't CUPS be using the gutenprint drivers anyway and
shouldn't it provide an interface to all parameters of the print process?

The plugin in Gutenprint 5.0 fixes 153012.  It offers a choice of automatically
creating the command line based on the queue you ask it to use, using a manually
created command line, or printing to a file.  Users don't have to fiddle with
lpr command lines.  I'm not certain about 99526, though.

As for the advantages of using the Gutenprint API over any PPD-based printing
system:

1) The Gutenprint API allows adjusting curves to get precise control over color
correction (CUPS has no way to adjust these curves -- including per-channel
linearization, GCR, HSL correction, and so forth).  This is simply something you
can't do with PPD files -- there's no curve data type.

2) Gutenprint can hide options that aren't used, which simplifies the user
interface (this is a change from 4.2).  In particular, if you use one of the
preset quality and image type modes, you don't see the myriad adjustments that
make Gutenprint so notoriously complicated.  You can use "manual control" to see
these other options.

3) Color adjustment is done with 16-bit precision (even though the GIMP
currently supports 8 bits only).  Granted, if you pass the color adjustments
through to CUPS, Gutenprint will still do the corrections in 16 bit precision,
but then you lose the ability to make the preview track the output (so if you
change the cyan gamma, for example, you can see what would happen).  So you
either lose the 16 bit precision or the preview.  This is also an issue if you
want to put external color management into the Print plugin -- if the Print
plugin talks directly to Gutenprint it can send 16-bit data.  This is the
approach PhotoPrint uses.

Created attachment 52940 [details]
Screen snapshot of the Setup Printer dialog

Note that the second line of text (lp -s -d 'c80_usb' -oraw) is generated based
on the printer queue and the autodetected printing system, and cannot be edited
by the user.  The "-oraw" is not inserted if Postscript is generated.  The user
can also select a custom command or a file.

Created attachment 52941 [details]
Setup Printer dialog for a Postscript printer

This is what the Setup Printer dialog looks like if the user has selected a
Postscript printer.  Note that the "-oraw" option is no longer set in the print
command, and that the user is requested to specify a PPD file.

Looking at these screenshots, I am afraid that the UI will need major surgery
before it can be shipped as a GIMP plug-in. It simply doesn't hold up to our
standards. So we would need a volunteer who can do these modifications to the UI
library. But since you are already in release candidate status, it is probably
too late for these changes anyway?!

No, it's not necessarily too late to make changes to this.  If it really needs
changes, it's better to do it sooner than later.

This is only a small part of the whole UI, obviously.  I would suggest that if
you would like to see improvements that someone step forward quickly.

We will have to ask for a volunteer on the mailing-list then. We don't have a
queue of user interface designers waiting that we can assign such jobs to. I
wish we had.

Here's another idea, since I don't think that changing the UI library in a short
time frame is realistic. You said that you aren't happy with the API of the UI
library anyway. Why don't you drop it from the 5.0 release then and just offer
the code as an example implementation? Projects can then base their UI code on
this. You can then look into integrating the UI library with a later release
when it has evolved.

Then what do we do for the GIMP plugin and for PhotoPaint?

Sorry, I don't understand your question.

I'm not sure I understood all of this discussion, but if what is needed is to
mung around some Gtk code so as to make the UI for some dialogs look like the UI
for the plug-ins that ship with GIMP, then that's the sort of thing I can do,
and I volunteer for it.  My understanding of printing is not very strong, but I
am reasonably skilled in the art of widgetry.

Sven, my question was in response to your suggestion to drop the UI library from
the 5.0 release -- the UI library is used both by the GIMP plugin and by PhotoPrint.

Weskaggs, send me an email (rlk@alum.mit.edu) and we can discuss this.

Robert, the point was that you said you aren't happy with the UI library yet. So
in order to not delay the 5.0 release further, you could decide not to include
it with the release. Photoprint would then have to include a copy of the UI code
and the GIMP plug-in would also do that. We would then have enough time to
improve the UI library to a point where it can be included with a later
gutenprint release.

But perhaps it is sufficient to make sure that the API doesn't expose any
internals that might have to be changed later. On the other hand it still needs
to expose enough internals to allow us to make a GIMP plug-in from it. That does
for example require access to the main dialog window, which would preferably be
a GtkDialog.

Raising priority on this to Urgent because it is necessary to decide what to do about this for the 2.4 release.

We're locking down for Gutenprint 5.0 release.  We've just cut -rc3, which should be the final release candidate.

There's going to have to be one API change (which I think can be done compatibly) at some point in the future to support a full-featured Postscript driver.  The compatible way to do it would be for the application (in this case, the Print plugin) to regenerate the list of options when the PPD file is changed.  However, in all other regards the 5.0 API is locked down.

*** Bug 99526 has been marked as a duplicate of this bug. ***

Robert, what is the state of the GIMP plug-in included with Gutenprint 5.0? Is there such a plug-in? Is it supposed to be bundled with Gutenprint? Do we need to ship a gutenprint plug-in in the GIMP source tree or not?

Marker as a blocker because it is essential to deal with this somehow for 2.4.

Hi, sorry I wasn't able to respond; I've been on vacation for the past two weeks and had only very limited network access.

The plugin in the 5.0 tree (and 5.0 itself, except for critical bug fixes) is essentially frozen at this point.  I do not expect any further changes prior to 5.0 release.  I do expect one significant (but most likely very localized) change after 5.0 to better handle Postscript printers, and there may be additional changes for better CUPS integration, but that isn't going to happen right away.

We can either hand the plugin off to you at this point, or continue to maintain it in the Gutenprint tree and give you bug fixes and other changes.

I just downloaded and tested the RC3 release (on a Fedora Core 4 system, with cvs GIMP), and it seems to work nicely.  Since apparently the GIMP plug-in gets installed automatically in a properly set up system, it seems to make the most sense to keep it in the Gutenprint tree, where you will be able to maintain it.  

Agreed. Closing as WONTFIX.

We have removed the old gimp-print plug-in from the tree and we plan to have a new print plug-in based on the GtkPrint API for GIMP 2.4.

Please use Milestone + Priority==Urgent instead of Severity==Blocker.