On 13 Jan 2004, "Sven" == Sven Neumann wrote:

Sven> Is there a particular reason you are running such an outdated version?

I see this statement a lot - i.e. users using really old versions of Gimp.

Would it be reasonable/feasible to add a hook into gimp that checks it's age and gives a warning if it is more than x months old?

For development versions, an automatic check seems to be appropriate. For stable versions, this may be a bit annoying - if such a check is implemented, it should probably be disabled by default.

One implementation would be to check the binary timestamp and if > 3 months suggest that the user check http://www.gimp.org for updated

versions?

It should only suggest this if there really is a new version. Note that this may be considered a "phone home" feature, and the last thing The GIMP needs is to be classified as spyware.

HTH, Michael

On Tue, 2004-01-13 at 11:53, Timothy E. Jedlicka - wrk wrote:

On 13 Jan 2004, "Sven" == Sven Neumann wrote:

Sven> Is there a particular reason you are running such an outdated version?

I see this statement a lot - i.e. users using really old versions of Gimp. Would it be reasonable/feasible to add a hook into gimp that checks it's age and gives a warning if it is more than x months old?

Would it possibly be that at gimp.org the latest "stable" version is 1.2.5 and that is what might be included in most distros (not sure what distros all include, but my RH9 I got was 1.2.something)? And maybe other folks would not want to "risk" using an "unstable" yet newer version? FWIW, I'm using 2.0pre1 and keeping up with stuff. But I can imagine some would rather wait for a "stable" release...?

misfit-x wrote:

On Tue, 2004-01-13 at 11:53, Timothy E. Jedlicka - wrk wrote:

On 13 Jan 2004, "Sven" == Sven Neumann wrote:

Sven> Is there a particular reason you are running such an outdated version?

I see this statement a lot - i.e. users using really old versions of Gimp. Would it be reasonable/feasible to add a hook into gimp that checks it's age and gives a warning if it is more than x months old?

Would it possibly be that at gimp.org the latest "stable" version is 1.2.5 and that is what might be included in most distros (not sure what distros all include, but my RH9 I got was 1.2.something)? And maybe other folks would not want to "risk" using an "unstable" yet newer version? FWIW, I'm using 2.0pre1 and keeping up with stuff. But I can imagine some would rather wait for a "stable" release...?

Right on! I just moved to FC1 and 1.2.5 is what's there.

Regards,

Bill Lee

Bill Lee wrote:

Right on! I just moved to FC1 and 1.2.5 is what's there.

SuSE 9.0 Pro, 1.2.5 as well.

Hi,

misfit-x writes:

Would it possibly be that at gimp.org the latest "stable" version is 1.2.5 and that is what might be included in most distros (not sure what distros all include, but my RH9 I got was 1.2.something)? And maybe other folks would not want to "risk" using an "unstable" yet newer version? FWIW, I'm using 2.0pre1 and keeping up with stuff. But I can imagine some would rather wait for a "stable" release...?

Yes, you are perfectly right. The version I called outdated was 1.2.2. 1.2.5 is indeed the latest stable relase and perfectly fine to use until version 2.0 was released and has proven to be stable. Given the few number of bug reports we received so far for 2.0pre1, I am pretty confident that 2.0 will be a good choice from the beginning.

Sven

On Tuesday 13 January 2004 14:52, Sven Neumann wrote:

Hi,

misfit-x writes:

Would it possibly be that at gimp.org the latest "stable" version is 1.2.5 and that is what might be included in most distros (not sure what distros all include, but my RH9 I got was 1.2.something)? And maybe other folks would not want to "risk" using an "unstable" yet newer version? FWIW, I'm using 2.0pre1 and keeping up with stuff. But I can imagine some would rather wait for a "stable" release...?

Yes, you are perfectly right. The version I called outdated was 1.2.2. 1.2.5 is indeed the latest stable relase and perfectly fine to use until version 2.0 was released and has proven to be stable. Given the few number of bug reports we received so far for 2.0pre1, I am pretty confident that 2.0 will be a good choice from the beginning.

Here I would modfiy that because I use the gimp for all my image printing, so the 2.0 release needs to be able to link up with the newer gimp-print too. So far, that hasn't happened. I assume it will by the time gimp-print is out in 5.0 final, and gimp in 2.0 final.

And because I've not run into anything that my limited gfx knowledge says needs fixed, I'm still at a self-compiled 1.2.3 here.

Hi,

Gene Heskett writes:

Here I would modfiy that because I use the gimp for all my image printing, so the 2.0 release needs to be able to link up with the newer gimp-print too. So far, that hasn't happened. I assume it will by the time gimp-print is out in 5.0 final, and gimp in 2.0 final.

Support for the newer gimp-print API will be added. If it doesn't make it into 2.0.0, there's nothing that keeps it from being done for the 2.0.1 release.

Sven

On Tuesday 13 January 2004 15:26, Sven Neumann wrote:

Hi,

Gene Heskett writes:

Here I would modfiy that because I use the gimp for all my image printing, so the 2.0 release needs to be able to link up with the newer gimp-print too. So far, that hasn't happened. I assume it will by the time gimp-print is out in 5.0 final, and gimp in 2.0 final.

Support for the newer gimp-print API will be added. If it doesn't make it into 2.0.0, there's nothing that keeps it from being done for the 2.0.1 release.

Chuckle, that old adage about never downloading version x.0.0 of anything comes to mind. :)

Hi,

Gene Heskett wrote:

Support for the newer gimp-print API will be added. If it doesn't make it into 2.0.0, there's nothing that keeps it from being done for the 2.0.1 release.

Chuckle, that old adage about never downloading version x.0.0 of anything comes to mind. :)

The only reason that we aren't already on gimp-print 5.0 pre is because we expected to have a 2.0 release some time ago, and didn't want to force people to use unstable packages as dependencies. Now that 5.0 is in pre-release, it is entirely possible that the print plug-in will be upgraded (by the way, the same logic (in reverse) is why the plug-in shipped with gimp-print is for the 1.2 GIMP series).

Cheers, Dave.

Hi,

Timothy E. Jedlicka - wrk wrote:

Sorry to quote Sven out of context, this was regarding a user on 1.2.2 - two years out of date. My point was that I've noticed several notes from users on really old versions - 1. is this a problem? 2. is it worth fixing?

Not really a problem. If he were reporting bugs against 1.0.4 (as one person recently did), he would politely be told that we're not fixing bugs in that any more, and that upgrading to 1.2.5 might be an idea.

But being on a stable version isn't a problem in itself. However, it is helpful if the person verifies that the problem they're reporting is still present in the latest stable release.

Also, it should be said that all the developer resources are (and have been for at least 6 months) being exclusively put into getting a stable 2.0 release out. So the chances of another stable release (given that there are only about 6 or 7 bug fixes that have gone in since 1.2.5) are extremely unlikely.
Cheers,
Dave.

Sven Neumann wrote:

Steve Litt writes:

By the way -- I use select by color a lot when I scan yellow receipts. I use select by color to turn the yellow to white, then save it as grayscale and save mucho megabytes.

The classic method to make the paper on a scan to appear as white is to use the Levels tool. Use the white-point color picker and click on an empty spot of the scan. Or, even better, define the white-point before doing the actual scan. Most scan software (including XSane) supports this operation.

That has a quite different effect from what Steve mentioned.

Adjusting the white point will scale all the colours in the image. For example if you had green writing on yellow paper, adjusting the white point like this would change the green to cyan (and red to magenta, but not affect any blue writing). Mind you, for Steve's receipts and his use of them, the final result in B&W might be OK.

Adjusting the white point is a very useful technique for colours _within_ an image, but it's a bit flawed as a general method for rendering the surrounding paper as white (unless the ink is pure black).

Cheers
__
David

Hi,

David Burren writes:

Adjusting the white point will scale all the colours in the image. For example if you had green writing on yellow paper, adjusting the white point like this would change the green to cyan (and red to magenta, but not affect any blue writing). Mind you, for Steve's receipts and his use of them, the final result in B&W might be OK.

Adjusting the white point is a very useful technique for colours _within_ an image, but it's a bit flawed as a general method for rendering the surrounding paper as white (unless the ink is pure black).

Right, unless the ink is pure black, which is very common for scanned documents. With a scanned document, what you usually want to achieve is to have black text on white background. Unless the scan is perfectly adjusted, you usually have dark gray text on light gray background. Picking the white and black points fixes this very conveniently. If there are photos on the same page, the photo should be handled separately from the text anyway. It's best put on a separate layer and treated independently from the text.

Sven