Date: Mon, 15 Aug 2005 16:12:17 -0700 From: Brian Thomason

Hi,

I am packaging up gimp 2.2.8 for Linspire and have noticed some strange issues in the print dialog that my non-existent C skills have been unable to resolve.

I'm not the best in the world at describing problems, so I have attached a screenshot to help out a bit.

Problem 1:

When the print dialog is open, the orientation is set to "Auto", which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is.

I'm the project lead for Gutenprint. Can you describe for me more specifically what you mean? Why will it "fail as it is"?

Problem 2:

Consequently, as a result of problem 1, the preview pane is "distorted".

Changing the orientation, alignment, or any such settings solves the problem, but I am unable to achieve these same results by manually calling the various callback functions associated with these actions. I either end up with a segfault, or simply nothing being changed.

Any help would be greatly appreciated.

What are you trying to do here?

On 8/15/05, Brian Thomason wrote:

I am packaging up gimp 2.2.8 for Linspire and have noticed some strange

When the print dialog is open, the orientation is set to "Auto", which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is.

Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows?

On 8/15/05, Brian Thomason wrote:

michael chang wrote:

On 8/15/05, Brian Thomason wrote:

I am packaging up gimp 2.2.8 for Linspire and have noticed some strange

When the print dialog is open, the orientation is set to "Auto", which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is.

Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows?

We use CUPS. (No modifications, other than cosmetics)

With or without BSD daemons?

Date: Mon, 15 Aug 2005 16:28:54 -0700 From: Brian Thomason

>I'm the project lead for Gutenprint. Can you describe for me more >specifically what you mean? Why will it "fail as it is"?

Because there are no values automatically filled in to the Left, Right, Left Border, Top, and Right Border fields.

Thanks for sending me the screenshot.

> Problem 2: >
> Consequently, as a result of problem 1, the preview pane is "distorted". >
> Changing the orientation, alignment, or any such settings solves the > problem, but I am unable to achieve these same results by manually > calling the various callback functions associated with these actions. I > either end up with a segfault, or simply nothing being changed. >
> Any help would be greatly appreciated. >
>What are you trying to do here?

I'm simply trying to have these values filled in by default, and have the image vertically aligned, by default.

It would help if I had actually attached the image. (doh!)

Many thanks for the fast response.

I've never seen anything like this, with the dimension/positioning boxes not filled in, even when using the Postscript driver without a PPD file. Which release of Gimp-Print are you using (4.2.7 is the most recent, and last, 4.2 release)? Are you using the unmodified source code? Can you supply a reproducible test case?

Date: Mon, 15 Aug 2005 19:30:54 -0400 From: michael chang

On 8/15/05, Brian Thomason wrote: > I am packaging up gimp 2.2.8 for Linspire and have noticed some strange

> When the print dialog is open, the orientation is set to "Auto", > which is good, but none of the default position indentions are > set. (Left, Right, left Border, etc...) For the common user, he > will just hit print when presented with the dialog, and this will > simply fail as it is.

Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows?

That shouldn't have any effect here. Gimp-Print doesn't really care what the underlying spooling system is.

On 8/15/05, Brian Thomason wrote:

michael chang wrote:

On 8/15/05, Brian Thomason wrote:

I am packaging up gimp 2.2.8 for Linspire and have noticed some strange Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is.

At odd times, if the user doesn't flatten the image before printing, it will only print the current layer. And he'll wonder why half his image is gone. [I can't remember what version of GIMP/GIMP-Print this is in.] Some who are prompted for auto-flattening-export think it will perminantly flatten their image, and look for a work around.

Are you packing gutenprint/gimpprint also?

On 8/15/05, Robert L Krawitz wrote:

That shouldn't have any effect here. Gimp-Print doesn't really care what the underlying spooling system is.

How does it contact the spooling system? Or does it use specific methods for each printing system?

michael chang writes:

Some who are prompted for auto-flattening-export think it will perminantly flatten their image, and look for a work around.

In CVS GIMP, the export dialog does say, "The export conversion won't modify your original image," so at least users shouldn't be worried about that (if they read the dialog).

But I'm not sure why the dialog exists in the first place. Is there any reason the user needs to be prompted for this? It doesn't modify the current image, it's just a temporary thing for printing. Clicking Ignore seems to do the same thing (at least on Linux and current CVS) as clicking Export, so the user doesn't have any useful choice to make here, just a confusion between two apparently identical choices (or Cancel). Why not just do the conversion without bothering the user about it?

...Akkana

Date: Mon, 15 Aug 2005 19:41:15 -0400 From: michael chang

On 8/15/05, Robert L Krawitz wrote: > That shouldn't have any effect here. Gimp-Print doesn't really care > what the underlying spooling system is.

How does it contact the spooling system? Or does it use specific methods for each printing system?

It just uses the lpr or lp command -- nothing fancy.

Date: Mon, 15 Aug 2005 16:52:33 -0700 From: Brian Thomason
Cc: gimp-developer@lists.xcf.berkeley.edu

michael chang wrote:

>On 8/15/05, Brian Thomason wrote: >
>
>>michael chang wrote:
>>
>>
>>>On 8/15/05, Brian Thomason wrote: >>>
>>>
>>>>I am packaging up gimp 2.2.8 for Linspire and have noticed some strange >>>>Right, left Border, etc...) For the common user, he will just hit print >>>>when presented with the dialog, and this will simply fail as it is. >>>>
>>>>
>
>At odd times, if the user doesn't flatten the image before printing, >it will only print the current layer. And he'll wonder why half his >image is gone. [I can't remember what version of GIMP/GIMP-Print this >is in.] Some who are prompted for auto-flattening-export think it >will perminantly flatten their image, and look for a work around. >
>Are you packing gutenprint/gimpprint also?

Not unless needed. We've been happy with 4.2.7 up to this point.

Are you using the 4.2.7 tarball from gimp-print.sourceforge.net?

Date: Mon, 15 Aug 2005 16:50:14 -0700 From: Brian Thomason

Robert L Krawitz wrote:

>I've never seen anything like this, with the dimension/positioning >boxes not filled in, even when using the Postscript driver without a >PPD file. Which release of Gimp-Print are you using (4.2.7 is the >most recent, and last, 4.2 release)? Are you using the unmodified >source code? Can you supply a reproducible test case?

Yes, I am using 4.2.7, completely unmodified. If you have a spare box to install Linspire 5.0 on, absolutely. (Debian Sarge might also suffice, but I'm not sure.)

I don't have a spare box.

Simply installing gimp 2.2.8, creating an image, of any size, and selecting "Print" from the file menu of that image reproduces this.

I've never seen this kind of problem, and this is the first report I've heard of anything of this sort. I'm cc'ing Roger Leigh, our Debian expert.

Roger, Brian has a rather odd problem whereby when he starts the Print plugin on a fresh image he gets completely empty positioning boxes (nothing filled in for any of the position/sizing boxes). I'll send you a screenshot under separate cover.

Date: Mon, 15 Aug 2005 19:30:35 -0700 From: Brian Thomason

>Roger, Brian has a rather odd problem whereby when he starts the >Print plugin on a fresh image he gets completely empty positioning >boxes (nothing filled in for any of the position/sizing boxes). >I'll send you a screenshot under separate cover.

One thing to note, Roger, is that this is only prevalent in our packaging of gimp 2.2.8, as Debian's package, last I checked, has printing explicitly disabled for some reason. (Perhaps for the same problem, but I doubt it) I'm sure you have far more insight on this than I do, however.

This helps. The GIMP actually includes its own copy of the Print plugin, but I don't know exactly what source that's based on. What you might try is using --disable-print with the GIMP, and configuring Gimp-Print with --enable-gimp (which builds the Print plugin out of the Gimp-Print source).

On Tue, Aug 16, 2005 at 10:33:56AM -0700, Brian Thomason wrote:

We did that, and the plugin works, but the orientation/position fields are all empty upon launching it.

FWIW, I fired up Gimp on my Debian/etch box last night, drew a picture, hit 'Print', and the dialog that appeared also lacked values in the position fields (until I played with the orientation pulldown or the scale slider).

However, if I printed while they were blank, it seemed to print ok, full-page on US letter.

I can't recall what versions of anything I was using, but it's whatever's the latest in Testing (etch) as of a couple days ago.

-bill!

Date: Tue, 16 Aug 2005 11:19:57 -0700 From: Bill Kendrick

On Tue, Aug 16, 2005 at 10:33:56AM -0700, Brian Thomason wrote: > We did that, and the plugin works, but the orientation/position fields > are all empty upon launching it.

FWIW, I fired up Gimp on my Debian/etch box last night, drew a picture, hit 'Print', and the dialog that appeared also lacked values in the position fields (until I played with the orientation pulldown or the scale slider).

However, if I printed while they were blank, it seemed to print ok, full-page on US letter.

I can't recall what versions of anything I was using, but it's whatever's the latest in Testing (etch) as of a couple days ago.

Does this only happen with an unsaved image?

On Tue, Aug 16, 2005 at 08:24:36PM -0400, Robert L Krawitz wrote:

FWIW, I fired up Gimp on my Debian/etch box last night, drew a picture, hit 'Print', and the dialog that appeared also lacked values in the position fields (until I played with the orientation pulldown or the scale slider).

Does this only happen with an unsaved image?

Oh, I didn't think to check with a saved image. It did happen with an unsaved one, though. I can look tonight.

(I've got Gimp on WinXP at work, so that doesn't help me :^) )

-bill!

Date: Tue, 16 Aug 2005 17:42:01 -0700 From: Brian Thomason
Cc: gimp-developer@lists.xcf.berkeley.edu

Robert L Krawitz wrote:

> Date: Tue, 16 Aug 2005 11:19:57 -0700 > From: Bill Kendrick
>
> On Tue, Aug 16, 2005 at 10:33:56AM -0700, Brian Thomason wrote: > > We did that, and the plugin works, but the orientation/position fields > > are all empty upon launching it. >
> FWIW, I fired up Gimp on my Debian/etch box last night, drew a > picture, hit 'Print', and the dialog that appeared also lacked > values in the position fields (until I played with the orientation > pulldown or the scale slider). >
> However, if I printed while they were blank, it seemed to print ok, > full-page on US letter.
>
> I can't recall what versions of anything I was using, but it's > whatever's the latest in Testing (etch) as of a couple days ago. >
>Does this only happen with an unsaved image?

On my Linspire machine, it happens with both saved and unsaved images.

I can't reproduce this at all with 5.0. I'm not able to get 4.2 to run right now for some reason.

Him

Robert L Krawitz writes:

This helps. The GIMP actually includes its own copy of the Print plugin, but I don't know exactly what source that's based on. What you might try is using --disable-print with the GIMP, and configuring Gimp-Print with --enable-gimp (which builds the Print plugin out of the Gimp-Print source).

Which is actually what debian is doing (at least in sid). They recently switched from the included plug-in to the one that comes with gutenprint. I have been very disappointed to find out that none of the user interface improvements that we have done to the Print plug-in over the last years have been incorporated into that version. Basically the Print dialog looks like crap now.

Sven

From: Sven Neumann
Date: Wed, 17 Aug 2005 10:39:39 +0200

Robert L Krawitz writes:

> This helps. The GIMP actually includes its own copy of the Print > plugin, but I don't know exactly what source that's based on. > What you might try is using --disable-print with the GIMP, and > configuring Gimp-Print with --enable-gimp (which builds the Print > plugin out of the Gimp-Print source).

Which is actually what debian is doing (at least in sid). They recently switched from the included plug-in to the one that comes with gutenprint. I have been very disappointed to find out that none of the user interface improvements that we have done to the Print plug-in over the last years have been incorporated into that version. Basically the Print dialog looks like crap now.

1) I don't remember anyone ever feeding them back to us. Mitch did some improvements once, years ago, but no one's ever contacted us since.

2) We're not interested in any changes to the 4.2-based plugin at this point; 5.0 is the wave of the future. They're different enough that changes to one won't port very easily to the other.

3) That's what happens when nobody steps forward to maintain the plugin and I have to do UI stuff. The best way to utilize me for UI programming is to take whatever I do and invert it.

From: Roger Leigh
Date: Wed, 17 Aug 2005 18:58:14 +0100

Sven Neumann writes:

> Robert L Krawitz writes: >
>> This helps. The GIMP actually includes its own copy of the Print >> plugin, but I don't know exactly what source that's based on. What >> you might try is using --disable-print with the GIMP, and configuring >> Gimp-Print with --enable-gimp (which builds the Print plugin out of >> the Gimp-Print source).
>
> Which is actually what debian is doing (at least in sid). They > recently switched from the included plug-in to the one that comes with > gutenprint. I have been very disappointed to find out that none of the > user interface improvements that we have done to the Print plug-in > over the last years have been incorporated into that version. > Basically the Print dialog looks like crap now.

I wanted to do this, but the fact that we have to support both GTK+-1.2 (for Cinepaint) and GTK+-2.0 (for Gimp) versions of the codebase caused serious problems keeping the two versions in sync. It also meant that the 2.0 version was basically restricted to using the 1.2 era features, otherwise syncing changes would become impossible. All I could do was a minimal conversion from 1.2 to 2.0.

I don't see why we necessarily have to keep the capabilities of the two in sync. The 1.2 plugin already supports all of the 5.0 capabilities, and keeping them in sync doesn't really reduce the testing burden. It might be a bit late to do it now, but if you want to get started, go ahead.

The only 1.2 clients we need to be concerned with are the GIMP and Cinepaint. The GIMP folks have no interest in 1.2, and if Cinepaint wants to improve it, they can maintain it.

As soon as 5.0.0 is released and stable branched in CVS, I'd like to rip out the 1.2 UI code and do some real work on the 2.0 code, which will include merging the Gimp changes over, as well as splitting it out into discrete GObjects; I'm not too happy with the current slew of global variables.

That code really is rather brutal, isn't it...

Hi,

Robert L Krawitz writes:

1) I don't remember anyone ever feeding them back to us. Mitch did some improvements once, years ago, but no one's ever contacted us since.

You need them fed to you? Are you serious?

2) We're not interested in any changes to the 4.2-based plugin at this point; 5.0 is the wave of the future. They're different enough that changes to one won't port very easily to the other.

The gimp-print plug-in in Debian sid is the 5.0 based plug-in, isn't it?

3) That's what happens when nobody steps forward to maintain the plugin and I have to do UI stuff. The best way to utilize me for UI programming is to take whatever I do and invert it.

Well, I offered my help more than once and asked you to transfer maintainership of the plug-in completely to us. That never happened and at some point I definitely lost interest. At the moment I am more inclined to drop the print plug-in from the GIMP tree entirely. Or perhaps replace it with a simple one that is based on libgnomeprint / libgnomeprintui.

Sven

From: Sven Neumann
Date: Thu, 18 Aug 2005 22:36:22 +0200

Robert L Krawitz writes:

> 1) I don't remember anyone ever feeding them back to us. Mitch did > some improvements once, years ago, but no one's ever contacted us > since.

You need them fed to you? Are you serious?

Personally I had no idea that you ever did anything but port it otherwise unchanged to the GIMP 2.x. At one point, Mitch did make some improvements, which he gave back to us, but I never heard of any further work.

> 2) We're not interested in any changes to the 4.2-based plugin at this > point; 5.0 is the wave of the future. They're different enough > that changes to one won't port very easily to the other.

The gimp-print plug-in in Debian sid is the 5.0 based plug-in, isn't it?

I don't know. The Linspire dialog is definitely 4.2, not 5.0. The one you folks have in the GIMP is based on 4.2.

> 3) That's what happens when nobody steps forward to maintain the > plugin and I have to do UI stuff. The best way to utilize me for > UI programming is to take whatever I do and invert it.

Well, I offered my help more than once and asked you to transfer maintainership of the plug-in completely to us. That never happened and at some point I definitely lost interest. At the moment I am more inclined to drop the print plug-in from the GIMP tree entirely. Or perhaps replace it with a simple one that is based on libgnomeprint / libgnomeprintui.

The idea was that we'd turn it over to you when 5.0 was released. Regardless, we've pretty clearly dropped the ball here, since 5.0 has taken a lot longer than plan. I don't entirely regret that, since we've done some important things, but facts is facts and I don't blame you for losing interest in it.