Re: [Gimp-user] help with compilation
On Thu, 2004-01-15 at 22:04, Sven Neumann wrote: You should consider to rename the package to gimp2.0 or gimp2 so that the full package name becomes gimp2.0-2.0pre1 or gimp2-2.0pre1. Then it could coexist with the gimp package (that should have been called gimp1.2 to begin with). I renamed it to gimp2.0 and installed it. rpm -i -v gimp2.0-2.0pre1-1mdk.i586.rpm It is installed as gimp-1.3. Is this correct ? It does not seem to have the help files...I'd like to have some tips about the new user interface. TIA -- josenildo marques icq #289971493 homepage http://cyb.ezdir.net registered linux user #341648 * I knew it. He's the One. -- Tank, The Matrix ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Help a novice...
Hi, Matt wrote: At 09:33 AM 1/14/04 -0700, SCOTT ANDERSON wrote: I'm running Win 98, and have downloaded the 2.0 to my program files. I don't know what to do from here. _I'll be watching for your post. The WinGIMP page has files and instructions for 1.2.4 but not for 2.0. I would like to know how to install 2.0 also. Your choices are to use the installer (which was still at 1.3.23 when I last looked, although Jernej may have updated it since) or the .zips. If you choose to use the .zips, then you need to download lots of packages, and basically unzip them all in the same place (create a directory c:\GIMP-2.0 and unzip everything) - for some .zips you may have to copy files from $PACKAGE_NAME/bin to bin (same thing for lib). Once everything is unzipped, you should set the path to include the gtk+ files (if you installed them separately), and just run gimp-1.3.exe. The installer is easier - just run gimp-installer.exe and it will install the program The Windows Way (TM). Cheers, Dave. -- Dave Neary [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] help with compilation
Hi, Josenildo Marques [EMAIL PROTECTED] writes: I renamed it to gimp2.0 and installed it. rpm -i -v gimp2.0-2.0pre1-1mdk.i586.rpm It is installed as gimp-1.3. Is this correct ? Yes, the executable and the libraries will continue to be called 1.3 until the first release candidates for 2.0 are released. It does not seem to have the help files...I'd like to have some tips about the new user interface. Help files will be packaged and distributed separately for gimp-2.0. There's also still lots of content missing and we could need your help with that. Sven ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Suggestion for non-tablet users...
I apologize to Sven N. for accidentally emailing him last night. Goofed up in the mail program. ;) I usually try to be sure everything is replied only to the list. Yesterday I noticed some stuff was replied in private email and thought I caught them all. Anyway, I wonder if they would somehow make the features that are available for pen-tablets in Gimp useable for the mouse too. Like for instance, the brush size (in 2.0pre1), etc. or have a regular feature added to manually add the size to what you like. (Same idea for all the normally-pen tablet features). I also wondered if the rpm versions of Gimp have tablet enabled or do we have to compile Gimp with the suggested flag to get that? (Thinking of future here.) I find RPMs easier because with something like Gimp, I have too hard a time compiling it (can't even get past ./configure) due to dependancies. I can't run Freetype 2 apparently or it messes up my Xwindows causing me to have to fix my XF86Config's font settings. :( Being on dial-up, also getting new packages/updates takes a lng time. So if Gimp runs from RPMs, the better. :) -- .:: misfit-x ::. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Select contiguous regions tool (Z) Problems
On Fri, Jan 16, 2004 at 10:30:39AM +0100, Dave Neary wrote: Hi, Jeffrey Brent McBeth wrote: I have a layer with many disjoint shapes surrounded by transparency. To move the rectangles, I would select the tool (Z), make sure the threshold was at 255, and select transparent areas was off. Then I could click on the shape (which selected everything up to the transparency) and move it where I needed it. I'm afraid I haven't been able to reproduce this in the HEAD. There has been one change since 2.0 pre1 in the contiguous region selection, but that should only affect indexed mode. That may be it. I forgot to mention that the images I'm working on are in indexed mode. Could you open a bug against this and attach an example image which shows this behaviour? Will do. I'll come up with a smaller version than the image I'm using now Are you sure that the completely transparent areas are really completely transparent? Absolutely positive. I just rolled my install back to 1.3.23 and it works as expected. Jeff -- Computer Science is as much about computers as astronomy is about telescopes -- Edsger Wybe Dijkstra (1930-2002) ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Suggestion for non-tablet users...
Hi, misfit-x [EMAIL PROTECTED] writes: Anyway, I wonder if they would somehow make the features that are available for pen-tablets in Gimp useable for the mouse too. Like for instance, the brush size (in 2.0pre1), etc. or have a regular feature added to manually add the size to what you like. (Same idea for all the normally-pen tablet features). I think there's an enhancement request for that already. Opacity is already controllable using the cursor keys even for mouse users. I also wondered if the rpm versions of Gimp have tablet enabled or do we have to compile Gimp with the suggested flag to get that? It's a GTK+ configure option, not a GIMP configure option. Most distributors seem to have it enabled by default. Sven ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] xsane Gimp 2.0pre1
Hi, Xsane doesn't appear to work with the devel. release of Gimp? Searched the net for clues, but it seems I only found out that they don't work together. Anyhow, I guess you're familiar with the problem and I don't have to explain it further? I'm assuming it will be made to work though, so does anybody know anything about this? Somewhere (on the net) I read that xscanimage worked with 2.0pre1 -- that doesn't seem to be the case for me though, Gimp just shows me the same complaints ... So ... Just looking for news about the topic really. I don't dare to hope for solutions yet. ;) h: Krisse ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] CMYK support
In one of the recent reviews of the upcoming Gimp 2 it has been advertised that it will fully support CMYK. There was actually a statement in the review like, if you have problems with the Photoshop license throw it away and use The Gimp. Or why spend $600 if you can use the Gimp and open these Photoshop files and edit them! We have heard from this mailing list that this is not the case. What is the reason that CMYK does not make it into Gimp. Is it very difficult to program or is there a patent issue? Lot's of other budget priced (Windows and Linux) graphic programs do not have it built in either. Don't get me wrong. I love The Gimp and I compiled Gimp2-pre1 and I am actually using it. -- Best Regards Thomas J Spuhler All Tusonix outgoing e-mail has been scanned for viruses signature.asc Description: This is a digitally signed message part
Re: [Gimp-user] CMYK support
On Jan 16, 2004, at 10:13 AM, Thomas Spuhler wrote: In one of the recent reviews of the upcoming Gimp 2 it has been advertised that it will fully support CMYK. (Which recent review?) yes, this has been an irritating problem. Some time ago (3 years) it was decided that the gimp would need to go though some major changes to add things like CMYK. It was thought, then, that CMYK would be added and that version would be called 2.0. Things have changed since then. CMYK is still planned, but not in version 2.0. There was actually a statement in the review like, if you have problems with the Photoshop license throw it away and use The Gimp. Or why spend $600 if you can use the Gimp and open these Photoshop files and edit them! Well, there are some things in psd files that the gimp clearly doesn't support yet. So if you have lots of work in psd's getting rid of photoshop might be a bit hasty. We have heard from this mailing list that this is not the case. What is the reason that CMYK does not make it into Gimp. Is it very difficult to program or is there a patent issue? Lot's of other budget priced (Windows and Linux) graphic programs do not have it built in either. No, there is no patent issue that we know of. It is just that doing it right takes either a lot of time, or a lot of money. We don't have the latter, so the former is the answer. The answer is the CYMK support and a lot of other features are a direct focus for some of us. Just when we finally do it, it will be the best way we know how. We are well on our way to this goal. -- Dan ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] CMYK support
On Fri, 2004-01-16 at 11:56, Daniel Rogers wrote: On Jan 16, 2004, at 10:13 AM, Thomas Spuhler wrote: In one of the recent reviews of the upcoming Gimp 2 it has been advertised that it will fully support CMYK. (Which recent review?) Cannot find it anymore. Maybe it's pulled off the WEB since it was kind of unreal, just highlighting features that such as full CMYK support and being able to open all psd files w/o problems. yes, this has been an irritating problem. Some time ago (3 years) it was decided that the gimp would need to go though some major changes to add things like CMYK. It was thought, then, that CMYK would be added and that version would be called 2.0. Things have changed since then. CMYK is still planned, but not in version 2.0. There was actually a statement in the review like, if you have problems with the Photoshop license throw it away and use The Gimp. Or why spend $600 if you can use the Gimp and open these Photoshop files and edit them! Well, there are some things in psd files that the gimp clearly doesn't support yet. So if you have lots of work in psd's getting rid of photoshop might be a bit hasty. We have heard from this mailing list that this is not the case. What is the reason that CMYK does not make it into Gimp. Is it very difficult to program or is there a patent issue? Lot's of other budget priced (Windows and Linux) graphic programs do not have it built in either. No, there is no patent issue that we know of. It is just that doing it right takes either a lot of time, or a lot of money. We don't have the latter, so the former is the answer. The answer is the CYMK support and a lot of other features are a direct focus for some of us. Just when we finally do it, it will be the best way we know how. We are well on our way to this goal. This seems to be a good answer! -- Dan -- Best Regards Thomas J Spuhler All Tusonix outgoing e-mail has been scanned for viruses signature.asc Description: This is a digitally signed message part
[Gimp-user] Re: [Gimp-developer] Alternative zoom algorithm
Hi, GSR / FR wrote: I saw that zoom has been changed following bug 124073. After trying it, I did not liked it. Personally I think it gives too much importance to extreme zooms, forgeting most people work around 100%. 4000 to 20 pix images in a reasonable size monitor is what I normally see, not 4 pix or people with one pixel painted as 128*128 screen pixels. I also did not liked that it quickly went to fractional numbers in which one of X:Y is not 1, cos it does not look very pleasing due the fast way Gimp interpolates when displaying. I like the idea of special-casing near-100% ratios (and so does Alan Horkan, from what I can tell from the bug he submitted recently). A LUT is a good way to go for them too, I think. There are some issues with the patch, though. I don't really get what's happenning in the if (src == 1 dest == 1) clause, and I'm not sure completely reverting the old change is the way to go. Perhaps it might be an idea to have some smallish set of presets which are favoured as is suggested in bug 124073 - something from say 8:1 to 1:8, which would cover most common usages, but with zooming allowed outside that range, using the new continued fractions algorithm and a sqrt(2) zoom factor. Help welcomed about how to make it work with typical optimization level. Comments about the presets also welcomed, I just made a list of the ones that seemed interesting while working always around some given factor. I would go for 12.5% 18% 20% 25% 33% 50% 75% 100% 150% 200% 300% 400% 600% That gives you a smallish set of presets, with extra focus around 100%, and outside that you let her fly with the newer algorithm. Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Alternative zoom algorithm
[EMAIL PROTECTED] (2004-01-16 at 2215.53 +0100): There are some issues with the patch, though. I don't really get what's happenning in the if (src == 1 dest == 1) clause, and I'm not sure completely reverting the old change is the way to go. It is the flip point, and I found the sequence is buggy (100 - 150 - 200 - 100, missing the 150 step when going back). It is special cos 1.0 == (1.0 / 1.0). You are sitting in the middle of the roof, so to speak. Once you are in the sequence, you can use the normal look up. I would go for 12.5% 18% 20% 25% 33% 50% 75% 100% 150% 200% 300% 400% 600% That gives you a smallish set of presets, with extra focus around 100%, and outside that you let her fly with the newer algorithm. The sqrt algorithm seems to have problems with rounding, btw. I could do a different set, with a first 8 at +1 to last 8 at +32 (first group would be 8, not 16). Or even scaling the factors and playing with the other part of the fraction (I think that would fix the buggy case above). The adventage is that all would be handled with the same code (I am not happy with so many if and switch). GSR ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Alternative zoom algorithm
Hi, I don't think it makes sense to discuss patches here. We should concentrate on the behaviour we'd like to see and do the implementation later. In my opinion it is important that the series of zoom ratios is linear. The current implementation fulfills this requirement, it favors zoom ratios such as 1:1, 1:2, 1:4, ... and still provides the linearity and the intermediate steps that the 1.2 implementation was missing. I don't see a reason to change it. Sven ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Alternative zoom algorithm
Simon Budig ([EMAIL PROTECTED]) wrote: With this approach it is trivial to implement different approaches for the zooming strategy: homogenous zooming would multiply/divide by sqrt(2), preset zooming would have a lookup table with percentages for the different zoom steps and move back/forward [1] in it (this also easily adresses the nice looking zoom levels problem, simply select the percentages so that they result in the desired fractions). The user then could e.g. select the strategy in the preferences. To explain what I mean by homogenous zooming: when viewing an image at 100% zoom in would result in 100% * sqrt(2) = 141% 100% * sqrt(2)^2 = 200% 100% * sqrt(2)^3 = 283% 100% * sqrt(2)^4 = 400% etc. Zoom out would result in 100% / sqrt(2) = 71% 100% / sqrt(2)^2 = 50% 100% / sqrt(2)^3 = 35% 100% / sqrt(2)^4 = 25% etc. This has the advantage that the behaviour is exactly predictable in every zoom level, since always exactly the same rectangle of the viewable area gets magnified. This also would work for other starting zoom levels. It seems that some people are scared away by the weird percentage numbers (huh? 283%?) and seem to prefer nice ratios instead. Ok, this makes things a bit more complicated. I tried to figure out a set of ratios that tries to emulate the behaviour described above while using more or less nice fractions. These presets could be used for preset zooming, i.e. zoom in/out would jump to the next bigger/smaller preset. Of course this is not as predictable, since you have to know your current zoom level to know in advance what area will be magnified. This table tries to minimize this effect. sqrt(2)- percentage used based preset ratio 0.39 - 0.39 = 1:255 0.55 - 0.56 = 1:180 0.78 - 0.78 = 1:128 1.10 - 1.11 = 1:90 1.56 - 1.56 = 1:64 2.21 - 2.22 = 1:45 3.12 - 3.12 = 1:32 4.42 - 4.44 = 2:45 6.25 - 6.25 = 1:16 8.84 - 9.09 = 1:11 12.50 - 12.50 = 1:8 17.68 - 16.67 = 1:6 25.00 - 25.00 = 1:4 35.36 - 33.33 = 1:3 50.00 - 50.00 = 1:2 70.71 - 66.67 = 2:3 100.00 -100.00 = 1:1 141.42 -150.00 = 3:2 200.00 -200.00 = 2:1 282.84 -300.00 = 3:1 400.00 -400.00 = 4:1 565.69 -600.00 = 6:1 800.00 -800.00 = 8:1 1131.37 - 1100.00 = 11:1 1600.00 - 1600.00 = 16:1 2262.74 - 2250.00 = 45:2 3200.00 - 3200.00 = 32:1 4525.48 - 4500.00 = 45:1 6400.00 - 6400.00 = 64:1 9050.97 - 9000.00 = 90:1 12800.00 - 12800.00 = 128:1 18101.93 - 18000.00 = 180:1 25600.00 - 25500.00 = 255:1 Of course it always is possible to choose other zoom levels interactively with the lens tool etc. This leaves the question what should happen when the user zooms in/out from an arbitrary zoom level. IMHO Zoom in/out always should result in a zoom level from the list above. But - as briefly mentioned in an earlier mail - it would not make very much sense to jump from 102 % to 100% when the user wants to zoom out. I'd suggest to guarantee a minimum zoom out, e.g. by a factor of 0.9. Examples: (Zoom out) 102 % * 0.9 = 91.8 % --- next smaller zoom preset is 66.67 % so we pick this one. 2 % * 0.9 = 1.8% -- next smaller zoom preset is 1.56% (Zoom in) 1500 % / 0.9 = 1666.66 % --- next bigger zoom preset is 2250.00 % I hope you get the idea. Ideas? Suggestions? (But please do not complain about the lack of your favourite zoom level, trying to insert specific missing zoom levels in the table above would completely break the advantages of nearly homogenous zooming...) Bye, Simon -- [EMAIL PROTECTED] http://www.home.unix-ag.org/simon/ ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Compile problems and GTK
On Fri, 2004-01-16 at 18:38, Brad Kligerman wrote: checking for GTK+ - version = 2.2.2... *** 'pkg-config --modversion gtk+-2.0' returned 2.2.4, but GTK+ (2.2.1) *** was found! When I tried to uninstall GTK+ (2.2.1) as you suggested, it said 2.2.1 was not installed. # rpm -qa | grep gtk+ If it shows 2.2.1 then: # rpm -e --force gtk+-2.2.1 If that didn't work, then there's a config somewhere that's still saying there's a GTK+-2.2.1 somewhere. I have another idea... REinstall GTK+2.2.1, then uninstall it. Then reinstall (just make install in the source tree you compiled GTK+-2.2.4 in, if you still have the sources compiled (ie. didn't delete the dirs or run make clean yet)). And see if that helps. Before I throw in the towel and go back to Photoshop, I just want to understand what my _/etc/ld.so.conf_ should look like. Mine has the following... /opt/lib/gtk+-2.2.4/lib/pkgconfig I would think it should be in /opt/lib/gtk+-2.2.4/lib instead? /usr/X11R6/lib /usr/kerberos/lib /usr/lib/qt-3.1/lib /usr/lib/sane Rest of this looks good to me. If you really really want to run PhotoShop, you can in linux using WINE (www.winehq.org). Runs slower but works - at least PS LE 5 worked for me. However, I would rather use Gimp, personally. You can still use Gimp 1.2.x but the new 2.0pre1 is really nice. :) -- .:: misfit-x ::. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
