ANNOUNCE: GDynText 1.5.4
Now really compiles with GTK_DISABLE_COMPAT_H defined. I can download it at: http://www.geocities.com/marcolamberto/gimp/plugins.html or: http://sourceforge.net/projects/gdyntext Happy GIMPing, Marco -- //\/\ Marco (LM) Lamberto e-mail:lm(.)sunnyspot.org (replace '(.)' - '@') The Sunny Spot - http://the.sunnyspot.org/
Re: ANNOUNCE: GDynText 1.5.4
Hi, Marco Lamberto [EMAIL PROTECTED] writes: Now really compiles with GTK_DISABLE_COMPAT_H defined. I can download it at: http://www.geocities.com/marcolamberto/gimp/plugins.html or: http://sourceforge.net/projects/gdyntext If you think this release containes some important bugfixes with respect to the version we ship with gimp-1.2, please send us a patch, so we can integrate your changes into the 1-2 branch. Salut, Sven
Re: ANNOUNCE: GDynText 1.5.4
On 8 Feb 2001, Sven Neumann wrote: If you think this release containes some important bugfixes with respect to the version we ship with gimp-1.2, please send us a patch, so we can integrate your changes into the 1-2 branch. Well there are no bug fixed, I've mainly merged the CVS stuff. However the most important think for this version (and the previous 1.5.3) is that now avoids renaming any modified layer into "GDynText Layer". This was a quite noisy behaviour. A patch vs gimp 1.2.1 is ok? ;) Regards, Marco -- //\/\ Marco (LM) Lamberto e-mail:lm(.)sunnyspot.org (replace '(.)' - '@') The Sunny Spot - http://the.sunnyspot.org/
Re: Logarithmic histogram
On Monday, 5 Feb 2001, Jay Cox wrote: Linear, Log, and sqrt are all common ways to scale histograms for display. Perhaps we should make it an option in preferences (or in the histogram display itself). sqrt() - I haddn't thought of that. That sounds plausibly like what Photoshop is using. I might have a play with that. Austin
Re: Logarithmic histogram
Linear, Log, and sqrt are all common ways to scale histograms for display. Perhaps we should make it an option in preferences (or in the histogram display itself). sqrt() - I haddn't thought of that. That sounds plausibly like what Photoshop is using. I might have a play with that. To me, it looks like Photoshop uses linear, but if there are some peaks that are very high relative to the rest of the histogram, they don't show these peaks completely (they are clipped off) in order to be able to show some detail in the lower parts. I tried something similar in Gimp, and for a number of images I tried, the histograms of Photoshop and the Gimp were very similar. If you want, I can post the code I used for it. I'm not sure about how to determine the clipping, though; now I have done something like (I don't have my code here with me) after the calculation of max in the function that calculates the heights of all peaks (I forgot the name) avg = ... if (max avg * 4) max = avg * 4; Note: the average is not the average as shown in the histogram widgt; it is the average height of all peaks in the histogram which is something completely different. But perhaps it is better to use the median instead of the average, or maybe the 90% percentile or something. Roel Schroeven
Value in histogram
The value in the gimp histogram is calculated as the maximum of the red, green and blue channels now. Wouldn't it be better to use the average of the three color channels?
Re: Value in histogram
On Thu, Feb 08, 2001 at 01:36:10PM +0100, Roel Schroeven wrote: The value in the gimp histogram is calculated as the maximum of the red, green and blue channels now. Wouldn't it be better to use the average of the three color channels? We discussed this when I was fixing the histogram for 1.2.x BRANCH (btw, did that fix go into 1.2.1, or did it just rot? Maybe I should look for myself) and I can't remember what the arguments were for leaving it as it is, but that's what we decided to do in 1.2 at least. Nick.
fwd: $60 Startup
THANKS FOR SUBSCRIBING. HERE IS THE FIRST RECOMMENDED OPPORTUNITY http://www.geocities.com/newsite2440/
[BUG] font ... not found on some images, works on others
Hi'all,
I noticed some weird behaviour with gimp, particularly the Text Tool. On SOME
images, it fails to add text with an error message like:
"Font '-adobe-times-medium-r-normal-*-*-420-1-1-p-*-iso8859-1' not found."
If I now create a NEW image of the same size and type (say, 1052x835 RGB, as is
the case with my current problematic images), click in the image (the Text Tool
pops up), and then click [OK]m the text is added to the image without any
problems. Since I did not change ANYTHING in the Text Tool, there seems to be
something weird going on.
It does not matter whether I try Type1 or TrueType fonts, the effect stays the
same. Text Tool presents me with all the fonts available to my X server, but
fails to find them when the time comes to render them into the image. On
similar-sized blank images it `just works'. There does not seem to be any
relation between the size of the image and the appearance of this bug.
Changeing the image from RGB to greyscale or indexed does not change the
behaviour. Nor does resizing, scaling or otherwise manipulating the image. Nor
does making a duplicate and trying to add the text to the duplicate (same
effect, `font not found'). Selecting the entire image. copying it and pasting
it as new does not change the effect ('font not found'). In short, NOTHING
works. But the same font, on a different image, JUST WORKS.
The only way to add text to images where Text Tool refuses to work is by adding
to text to another image, selecting `copy', and `paste' in the troublesome
image. This works...
I am puzzled...
Current config:
gimp 1.2.1
linux 2.4.1
glibc 2.2.1
gtk+ 1.2.8
glib 1.2.8
XFree86 4.0.2
uname -a:
Linux behemoth.localnet 2.4.1 #3 SMP Tue Feb 6 17:17:18 CET 2001 i686 unknown
/lib/libc.so.6:
GNU C Library stable release version 2.2.1, by Roland McGrath et al.
Copyright (C) 1992-1999, 2000, 2001 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 2.95.2 19991024 (release).
Compiled on a Linux 2.4.0 system on 2001-01-24.
Available extensions:
GNU libio by Per Bothner
crypt add-on version 2.1 by Michael Glad and others
The C stubs add-on version 2.1.2.
BIND-8.2.3-T5B
NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk
Glibc-2.0 compatibility add-on by Cristian Gafton
linuxthreads-0.9 by Xavier Leroy
libthread_db work sponsored by Alpha Processor Inc
By the way, I am not the only one who has noticed these problems, as can be
seen from this archived posting to the gimp-user list:
http://www.mail-archive.com/gimp-user@xcf.berkeley.edu/msg01408.html
"...The text tool seems to find the fonts OK, but when I type my text and hit
OK, I get something like:
Font '-bitstream-courier-medium-r-normal-*-*-420-1-1-m-*-iso8859-1' not
found"
Cheers//Frank
--
W ___
## o o\/ Frank de Lange \
}# \| / \
##---# _/ Hacker for Hire \
\ +31-320-252965/
\ [EMAIL PROTECTED] /
-
[ "Omnis enim res, quae dando non deficit, dum habetur
et non datur, nondum habetur, quomodo habenda est." ]
Re: [BUG] font ... not found on some images, works on others
On Thursday, 8 Feb 2001, Frank de Lange wrote: [fonts work on some images, but not others] Check both image's resolution: they're probably different. If you ask the text tool for text in a particular "point size", then it needs to scale it so it comes out at the right size for the image's resolution. If you ask for text sized in terms of "pixels", then it won't get scaled, and you'll probably get the results you expected. New images (by default) are close in resolution that of your screen, so the distinction between points or pixels is minor. Maybe the text tool should default to selecting pixel sizes, not point sizes? Too many people get confused. Austin
Re: Value in histogram
Hi, Nick Lamb [EMAIL PROTECTED] writes: On Thu, Feb 08, 2001 at 01:36:10PM +0100, Roel Schroeven wrote: The value in the gimp histogram is calculated as the maximum of the red, green and blue channels now. Wouldn't it be better to use the average of the three color channels? We discussed this when I was fixing the histogram for 1.2.x BRANCH (btw, did that fix go into 1.2.1, or did it just rot? Maybe I should look for myself) and I can't remember what the arguments were for leaving it as it is, but that's what we decided to do in 1.2 at least. Well, max (r,g,b) is the correct formula for calculating the value of a color (assuming that value corresponds to the V in HSV). The average of the three channels is a somewhat useless number, but it might make sense to add intensity (mostly defined as 0.3 r + 0.59 g + 0.11 b) as an option. Salut, Sven
Possible bug in layer preview update
Hi all, I have reproduced this in the 1.3 branch - I think it may be in 1.2 as well but I haven't checked. Basically some of the preview update routines can crash on images with unusual ratios - I haven't entered a bug against this because I was having a look at it, and I wanted to run it through here first. To reproduce, create a new image of dimension 1024x32, and try to run the coffee stain scriptfu on it (Script-fu-Decor-Coffeestain). the GIMP should crash with a seg fault, and a Gimp-CRITICAL message to the effect that in gimp_viewable_get_preview the assertion height0 failed. This can be tracked back to gimp_image_get_new_preview(), which gets height and width from each layer, and multiplies them by a ratio. These values is computed at line 4051/4052 of gimpimage.c. They can end up being less than 1, resulting in the height/width being calculated as 0. Sorry if this report/mail is a bit vague. To be honest I'm not quite sure what the height width variables actually refer to here - can other people reproduce this? If so, is it a bona fide bug? This is on Linux, 2.2.x kernel, X running at 1024x768 :) Cheers, Dave. -- .--. / David Neary, \ | E-Mail [EMAIL PROTECTED] | | Phone +353-1-872-0654 | \ Work +353-1-409-1357 / `--'
