[Gimp-developer] CVS doesnt compile
Hi, I got the following error: Making all in tips make[2]: Entering directory `/usr/local/src/gimp-1.3.cvs/tips' INTLTOOL_EXTRACT=../intltool-extract ../intltool-update --gettext- package gimp20-tips --pot can't open Makefile.in.in: Aucun fichier ou répertoire de ce type at ../intltool-update line 952. make[2]: *** [gimp20-tips.pot] Erreur 2 make[2]: Leaving directory `/usr/local/src/gimp-1.3.cvs/tips' make[1]: *** [all-recursive] Erreur 1 make[1]: Leaving directory `/usr/local/src/gimp-1.3.cvs' make: *** [all] Erreur 2 -- Regards - Jean-Luc pgp0.pgp Description: PGP signature
[Gimp-developer] Anti-counterfeit software: implications for Open Source
Hi, I'd like to draw the GIMP developer's attention on this Advogato article. It has some interesting comments and links and somehow I get the feeling that it would be unwise to ignore this subject: http://advogato.org/article/742.html What is especially worrying me is that there seems to exist a proposal for EU legislation to require devices and software to include counterfeit deterrence technology: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Alternative zoom algorithm
Hello. More in-between steps in the logaritmic zoom (...,2:1,1:1,1:2, 1:4,...) would be nice, but nothing fancy like more steps around 1:1 is not needed here. There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing. This gives an idea that GIMP could have a tool which computes the scale ratio required for matching the scanned pencil size with the size of the selected pencil. The tool could work this way: (1) select the pencil, (2) start the tool, (3) zoom the image until the selected pencil size matches the scanned pencil size, (4) start scale operation which takes the zoom ratio as scale ratio. That would require that GIMP can draw the outline circle (say) of the pencils. Does not solve the underlying problems of GIMP, but is better than nothing. Regards, Juhana ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source
On Wednesday 21 January 2004 13:07, Sven Neumann wrote: Hi, I'd like to draw the GIMP developer's attention on this Advogato article. It has some interesting comments and links and somehow I get the feeling that it would be unwise to ignore this subject: http://advogato.org/article/742.html What is especially worrying me is that there seems to exist a proposal for EU legislation to require devices and software to include counterfeit deterrence technology: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. Sven A good point to focus this discussion seens to be pointing the Central Bank to the direction of including non-printable add-ons to currency, like holograms or other things. Our (Brazil's) latest bank note already have got an holographic strip on it, and ...it would be quite hard to reproduce that in the GIMP. :-) The idea of installing anti-counterfeit protection in any imaging device is similar to the one discussed for some time about the so called analog hole - in which the movie and audio industries try to address anti-copying tecnologies even on analog devices such as VCRs. Perfect nonsense, since the ones most interested in counterfeiting would just have to make a deal with a manufacturer in China, or other country with similar capabilities to get his hardware without such protection. In the case of software, it is even easier: all a conterfeiter would have to do would be to develop his own, in house software - which could be a little harder if all existing Open Source libraries related to graphics were forbidden, but not impossible. Spammers already do that. On the other hand, this very same idea threatens the very soul of Free Software, or Open Source. It is just not feasible., as it is plain obvious. The pdf pointed to by Sven however asks for a comment that could be well constructed together with FSF Europe, showing these and other facts. JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
Hi, Juhana Sadeharju [EMAIL PROTECTED] writes: There are more important problems relating to the zoom and resolution: I scanned a drawing and wanted to complete it with GIMP. After I had zoomed the large image, largest pencil was too tiny for drawing. Any particular reason you did not press the New button in the brush dialog to obtain a larger brush? Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
Joao S. O. Bueno ([EMAIL PROTECTED]) wrote: I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice. There are two things I'd like to know. As you know Gimp avoids opening too big image windows when loading an image. Right now the size of the image area is restricted to 0.75 * screen dimensions. This of course is perfectly Ok. However, I'd like to know which of the two following behaviours is preferrable in case of an image being too big for the screen: a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS. b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...) Also I'd like to know if the zoom steps around 100% are fine grained enough. Homogenous zooming right now is implemented with a factor of 2^(1/2) (from 100% to 200% in two steps), but 2^(1/3), 2^(1/4) would work as well (three, resp. four steps from 100% to 200%) and give finer grained steps. Opinions? Thanks, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP on Mac OS X
Hi, I'm picking up on an older thread here since there's some good news on the MacOS X subject that should be shared. Since this topic was brought up last, Yosh added a POSIX shared memory implementation that is used on Darwin. Recently GIMP-2.0pre packages appeared for fink (http://mirror.student.iastate.edu/) and today I've been told that GIMP-2.0pre2 has found its way into darwinports (http://darwinports.opendarwin.org/). What I heard so far these packages work flawlessly and this means that we can say that MacOS X is a fully supported platform for GIMP-2.0. Thanks to everyone who helped to make this happen. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
Simon Budig ([EMAIL PROTECTED]) wrote: a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS. b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...) Oops, sorry I mixed that up. Right now Gimp-CVS uses the old zoom steps when opening a new image (kind of behaviour b). My patch implements a) here and I got confused with the two different GIMPs... :-) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
On Wednesday 21 January 2004 12:27, Simon Budig wrote: Joao S. O. Bueno ([EMAIL PROTECTED]) wrote: I've tried Simons Patch, and it seemed very nice for me. Of course I am innoi position to word out what should and should not be commited, but from a user point of view, it is nice. There are two things I'd like to know. As you know Gimp avoids opening too big image windows when loading an image. Right now the size of the image area is restricted to 0.75 * screen dimensions. This of course is perfectly Ok. However, I'd like to know which of the two following behaviours is preferrable in case of an image being too big for the screen: a) open the image as big as possible (zoom-to-fit to a window about 0.75 * screen dimensions), this roughly is the behavior of current CVS. b) open the image in the next smaller zoom preset (which would result in image windows smaller than the 0.75 * screen dimensions, but would have nice ratios) (since CVS does not yet really have any zoom presets its hard to compare...) Hmm... Actually, 0.75 is sometimes boring, when the whole image would fit in, say, 90% of the screen, and it shows up zoomed out. regarding your specific question, it would not be nice if the GIMP openned an image in a zoom factor that once changed could not get easily reproduced. So the answer is (b).However, if you could make it in a way that if the next bigger zoom ratio (in the 2^(1/2) steps you use) would be no larger than 80% or maybe 85% of the screen it would be the one used. On the other hand, I was not around when the choice for 75% was made, and there may be strong motives for that. Also I'd like to know if the zoom steps around 100% are fine grained enough. Homogenous zooming right now is implemented with a factor of 2^(1/2) (from 100% to 200% in two steps), but 2^(1/3), 2^(1/4) would work as well (three, resp. four steps from 100% to 200%) and give finer grained steps. Yes, it seens just ok. I would not like to have to hit '+' four times to get a image twice as large. Now let's see what others have to say. Opinions? Thanks, Simon Regards, JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-user] Re: [Gimp-developer] Re: Re: Re: Alternative zoom algorithm
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: Actually, 0.75 is sometimes boring, when the whole image would fit in, say, 90% of the screen, and it shows up zoomed out. regarding your specific question, it would not be nice if the GIMP openned an image in a zoom factor that once changed could not get easily reproduced. So the answer is (b).However, if you could make it in a way that if the next bigger zoom ratio (in the 2^(1/2) steps you use) would be no larger than 80% or maybe 85% of the screen it would be the one used. On the other hand, I was not around when the choice for 75% was made, and there may be strong motives for that. IIRC, 75% was choosen rather arbitrarily and I agree that it would make sense to use 85% or even 90% instead and choose the closest sane display ratio below. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote: Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2? In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while. - - -- Servus, Daniel - -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQA46CTBkNMiD99JrAQIGRQf/UWfxv7S9lxgybUrvm1U2CTUAGvSQLC2w uK6iUhZqirtQaBuzDTH23BEz5L/tzCoCf+7vJl11j1vZOpRZqE6H7kK8wmAb1i8T HKUthgScPGASocRHPevpF+u5cD3xBcbT2C6F6OXg/BEOOAFEm06gVIjaF7AOvEW3 x1L/zksyCxfZsAf2CYX845OnUAvXZZOZABaeXsUEqkQRJ7aXFQlcyMznMEx0w3U8 thp6VWtA2SlgcJmKk4nbTd06UHyoJY1XxSGR+OyRnICxS6grWC9UoBx2gXxMUmOG 9ib4yHKwD1EIUzNl4Cq18MQPUgh7UZ9/t1rWDcuVOBBeYtOGYamFTw== =KwxL - -END PGP SIGNATURE- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iQEVAwUBQA7OnzBkNMiD99JrAQKWyAgAouLPJ0cYHWBEySFPkRrnyXxVeVvJJsU1 kSe+WmD9d1a6aZyMZbqo2XkQb3+SP4aTYwBBv1oX9ZrKT02EkzRvGoxX1wvGmYBG Tp+l36e4YdVht3369Xl9qWrOvIvrX+3GcL0jXpY4M7B93FSwaeQr95Qy16k3g/mv 065AxzmR+d6d+rZQvmb271/JNFxDuc3GptuILgPueDsq3oakovq2cPkZBYcf+qcq bn92bkJiPgTVsT7TGBljP2+Zra586f57+i/96A0n1MntGUHkGfvs3IfvDNhz7Gua /nf2u2xlBNMaTynccIsvFI73C2rrDAsk/YeMEbgV/+adTPL+Y0Fmzg== =hOY/ -END PGP SIGNATURE- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dithering
Daniel Egger wrote: On Jan 20, 2004, at 5:48 pm, Sven Neumann wrote: Well, actually we'd like to add interpolation to the GIMP canvas as well. At least optionally. Modern computer hardware seems fast enough to do this, especially when one takes advantages of CPU acceleration features (MMX, SSE, ...). Perhaps someone wants to tackle this task for GIMP-2.2? In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while. Hee hee... it's interesting how things can come full-circle. GIMP 0.5[34] did something very similar to provide a quick-render for interactive operations, re-rendering the results more nicely on the idle thread (undithered vs. dithered rather than aliased vs. interpolated, but for the same reasons). --Adam -- Adam D. Moss . ,,^^ [EMAIL PROTECTED] http://www.foxbox.org/ co:3 At this point the rocket becomes engorged with astronauts. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source
On 21 Jan 2004, at 16:07, Sven Neumann wrote: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. To be precise, it says: + Comments in English or in the relevant Community language + are invited from all interested parties by 19 December 2003 Does that not mean the deadline was 19 December last year? -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Anti-counterfeit software: implications for Open Source
On 21 Jan 2004, Sven Neumann wrote: What is especially worrying me is that there seems to exist a proposal for EU legislation to require devices and software to include counterfeit deterrence technology: http://www.ecb.int/pub/legal/c_25520031024en00080008.pdf This document explicitely asks for comments and IMO it would be a good idea to prepare such a comment. We could do this as the GIMP developers or try to corporate with the FSF Europe. Yes, I think it would be best to do it as a joint GIMP/FSF Europe comment. I would include something akin to the following: * GIMP is a popular image-manipulation program that is used in many different applications, such as web design. * Should legislation be enacted requiring currency detection, GIMP would effectively be outlawed from the European Union, since, due to its open source nature, it is trivial to modify it to skip the currency detection step. * The legislation would not have its desired effect anyway, since it is not significantly more difficult for a dedicated individual to modify a closed-source program to skip the currency detection. Once a program is modified once, it is trivial for instructions on how to modify the program to be spread to others. * There are many legitimate and legal uses for images of currency. FSF Europe and the GIMP developers are greatly opposed to any measure that would restrict the freedom of expression of the citizens of European Union member nations. It would then of course be signed by all the GIMPers who are members of the EU. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re : [Gimp-developer] CVS doesnt compile
Le 21.01.2004 14:35, Sven Neumann a crit: Hi, Jean-Luc Coulon (f5ibh) [EMAIL PROTECTED] writes: I got the following error: Making all in tips make[2]: Entering directory `/usr/local/src/gimp-1.3.cvs/tips' INTLTOOL_EXTRACT=../intltool-extract ../intltool-update --gettext- package gimp20-tips --pot can't open Makefile.in.in: Aucun fichier ou rpertoire de ce type at ../intltool-update line 952. You are using intltool-0.29, a version that is unfortunately broken. Right guess .. Version 0.28 will work but it's know to produce a broken gimp-tips.xml file. If you want a working version of intltool, please downgrade to intltool-0.27.2. Well I've reinstalled 0.28 because I had a backup package for my Debian sid but I've not 0.27 anymore ... And it seems to work, at least to compile. -- Thanks and regards - Jean-Luc Sven pgp0.pgp Description: PGP signature
Re: [Gimp-developer] Dithering
Am Mit, den 21.01.2004 schrieb Adam D. Moss um 20:28: In OSX many applications tend to provide a quick redraw for pannings but start a timer which will refine the display once it was static for a while. Hee hee... it's interesting how things can come full-circle. GIMP 0.5[34] did something very similar to provide a quick-render for interactive operations, re-rendering the results more nicely on the idle thread (undithered vs. dithered rather than aliased vs. interpolated, but for the same reasons). This would be my favourite solution rather than hope that the CPU is fast enough and someone wrote optimized code just to render a view that a human eye won't be able to trace in real-time anyway. -- Servus, Daniel signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
[Gimp-developer] Re: Alternative zoom algorithm
This is my first post here. Is the proper protocol to
1) post here to the mail lists?
2) put on the bug list?
3) both?
In reference to the earlier discussion about uniform
zooming scale factors, why not let the user choose his
own (reasonable) scale factor in preferences? It
could be set to sqrt(2) by default. The code
below rounds to the nearest multiple of the factor. I
think it is an elegant solution which gives a lot of
power to the user.
gdouble
gimp_display_shell_scale_zoom_step (GimpZoomType
zoom_type,
gdouble
scale,
gdouble factor)
{
/* scale is scaled by factor which is nominally =
sqrt(2) */
/* the user enters factor in preferences */
/* need enough significant digits in factor to get
nice scales */
/* e.g. factor = sqrt(2) = 1.414213562373 */
switch (zoom_type)
{
case GIMP_ZOOM_IN:
factor = CLAMP (factor, 1.1, 4.0);
scale = CLAMP (scale, 1.0/256.0, 256.0);
scale =
pow(factor,floor(log(scale)/log(factor)+0.5)-1.0);
break;
case GIMP_ZOOM_OUT:
factor = CLAMP (factor, 1.1, 4.0);
scale = CLAMP (scale, 1.0/256.0, 256.0);
scale =
pow(factor,floor(log(scale)/log(factor)+0.5)+1.0);
break;
case GIMP_ZOOM_TO:
break;
}
return CLAMP (scale, 1.0/256.0, 256.0);
}
Regards,
Harold
__
Do you Yahoo!?
Yahoo! Hotjobs: Enter the Signing Bonus Sweepstakes
http://hotjobs.sweepstakes.yahoo.com/signingbonus
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Alternative zoom algorithm
top flight ([EMAIL PROTECTED]) wrote: This is my first post here.? Is the proper protocol to 1) post here to the mail lists? 2) put on the bug list? 3) both? ? Well, since we are in a discussion here a post on the bug list might be a bit too early. But yes, a enhancement request in bugzilla will definitely get a response, but on the zooming behaviour there are enough open bugs right now :) In reference to the earlier discussion about uniform zooming scale factors, why not let the user choose his own (reasonable) scale factor in preferences? It could be set to sqrt(2) by default. The code below?rounds to the nearest multiple of the?factor.? I think it is an elegant solution which gives a lot of power to the user. Well, we have a lot of preferences already and one can have too much degrees of freedom. When I brought up different sets of zoom presets available in the preferences, some people were complaining, that preferences are just a sign of a lack of descision competence :-) [ code snipped for arbitrary factors ] As you might have seen in the earlier discussion, for some people it is very important, to get sane ratios like 1:x as magnification factors. Your approach of course would work, but usually result in ugly fractions. The list of fractions from the earlier Mails were the result of a compromise, a move back to real floats is not an option. Personally I believe that only factors based on the n'th roots of two are reasonable choices, since we usually want to have the double, quadruple etc. sizes of the images in the list of zoom factors. For a short time we had something based on the golden mean in CVS, and it really felt clumsy, because it was so hard to hit the powers of two as magnification factors... sqrt(2) gives us two steps between each doubling of the size, and it seems to be fine enough. I might experiment later with 2**(1/3), but that isn't really urgent now. Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] layer effects
Hi all, I'm just wondering is it being planed by anyone to include some feature like the layer effects in photoshop in any gimp release (soon)? If not, if someone has time to just write some tutorials on how to achieve some of the layer effects (e.g. emboss, inner shadow,etc.) I would really appreciate it. As far as I'm concerned I'm not the only person looking for this feature. I thank you for contributing to the GIMP to all of you. Gezim __ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
