[Gimp-user] Re: Black and White
* Richard [EMAIL PROTECTED] [2004-10-29 00:14]: I was wondering, is there some more plug-ins or scripts, for working with Black and White images? if so, where can I download them? Did you ever get an answer to that Richard? I'm looking for the same thing. Specifically, I need to convert a newspaper that was scanned as a grayscale image to a black and white monochrome 1 bit image. I need a tool that's as intelligent as a scanner in making the background white. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Select by color-- available in version 1.2.3?
* Joao S. O. Bueno Calligaris [EMAIL PROTECTED] [2004-12-06 22:46]: Gah. no..you do not need to update for that..but this stuff is __old__ :-) The select by color is in the Tools menu, or in the Selection menu even. Thanks, it was there in the selection menu. However, it was not in the Tools menu, which was where I was looking originally. As far as upgrading, I'm on an RH9 box, so getting out of date is probably understandable. I really hate to upgrade things in RedHat because of all the problems with RPMs. RPM packages are often buggy, and fail when a other supporting packages don't meet the version criteria, which is often overly conservative and unnecessary. The support packages then often have the same issue, so upgrades tend to snowball into a major project. Sometimes I will -cave in-, and get the latest tarball, but then I end up with two versions in parallel and the RPM system reports the older version. Anyway, I'll switch to gentoo at some point and upgrading problems will be resolved. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Selection woes...
* Carol Spears [EMAIL PROTECTED] [2004-08-11 16:40]: On Thu, Aug 12, 2004 at 02:18:02AM +0400, iwantto keepanon wrote: Did I stump ya? Or confuse ya? Is anyone out there ... I have an image w/ some text in it. I want to move *each* letter over by 2 pixels (to accomodate an outline). So here is what I do: I recently had the exact same problem. I had an email address that I wanted to show as a bitmap (to prevent spam harvesting), and needed to move some of the letters around, all of which I had on the same layer. Move did not work, so I did some cutting and pasting. The cutting and pasting gave me the granularity I needed.. the move suddently works if you cut and then re-paste in place, but (at least in my case) the cut wasn't perfect, and left some specles behind that were well inside the selected area. Anyway, what Carol suggested is probably the best option; that is: best to use texttool to make each letter on a separate layer. you do this by highlighting the background layer and clicking on that for each new letter. It would *really* be nice if the move tool had more power. If the move tool would move only the objects that are selected, that would be great. It would be ideal if the move tool only moved the whole layer in the absense of a selection. (has this been suggested before?) ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: Selection woes...
* Carol Spears [EMAIL PROTECTED] [2004-08-12 17:51]: double click on the move tool. you can move selections, layers or paths (there are buttons at the top of the tool option dialog. Nice! I'll have to update Gimp to a current version and see if I get those options. I'm running version 1.2.3 right now, and the move tool displays the dialog This tool has no options. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Moving objects strictly on the X or Y axis
* Dave Neary [EMAIL PROTECTED] [2004-08-10 16:09]: Using the cursors is how I usually handle this. With the move tool selected, Shift selects the active layer rather than the topmost layer underneath the cursor, Control moves a path, and Alt moves a selection (rather than its contents). Thanks for the suggestions. It's a bit slow, but works. Is there a way to ensure that it stops when the layer boundary crosses the edge of the canvas? ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: So it's a layer border - not a crop frame
* Carol Spears [EMAIL PROTECTED] [2004-08-08 07:23]: and what does this get you? you only need to do this if you need the extra space on the layer. Unfortunately I discovered the float layer option _before_ I discovered the move tool, so I was trying to float everything that I needed to move. Combined with not knowing about the layer boundary, it was a disaster. Now that I've come upon the move command, I actually prefer to have conservative layer borders and use the move tool. I have abandoned the float tool, but that's not to say that I won't find a use for it sometime. i suggest that you want to use Photoshop; a not as complex graphics app that has been built for people who cannot understand (or hope to learn to understand) different sizes of layers. Yes, photoshop from what I understand is much better for users first encountering this type of tool, because it requires very little understanding. They can accomplish layer manipulation w/out needing to study some of the esoteric details. Gimp obviously requires people to grasp this foreign concept. This does not mean they cannot understand, as you put it, but that they will not gain an adequate understanding of this from the gui interface. Until the GUI accommodates, this understanding is acquired via explanation. nothing that a little experience would fix. the gimp is not photoshop so it is a mistake to approach using it as if it is. As far as I'm concerned, Gimp is Photoshop, simply because I'm not doing anything complex enough to go beyond the basic functionality that's offered in both packages. Furthermore, I would hope to see Gimp get to a point where it can replace Photoshop. As it is now, it seems Photoshop is a superset of Gimp. one thing that i do not understand is the need for floating layers. i dont think that this term is being used properly here. is there any reason that there needs to be the extra step to make pasting directly to an existing layer easier? it is so rare that i paste anything to an existing layer. it makes more sense to me to make the extra step for those rare occasions that you do paste right to an existing layer. I can see how floating a layer could be useful in some rare instances, but now that I've switched to moving layers as opposed to objects on layers, I could also live without the floating capability. If a majority of users agree that the floating capability is not very useful, maybe a good approach would be to remove it from the standard builds, and require users to proactively compile that option in if they want it. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Moving objects strictly on the X or Y axis
How do I restrict movement to be either horizontal or vertical? I tried holding shift, control, and alt, and no luck. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: Gimp 2.1.3 Compile fail
* Matthew Daubenspeck [EMAIL PROTECTED] [2004-08-08 09:41]: Here is the error: gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -DG_LOG_DOMAIN=\LibGimpWidgets\ -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -mcpu=athlon-xp -O3 -pipe -Wall -MT gimpwidgets-private.lo -MD -MP -MF .deps/gimpwidgets-private.Tpo -c gimpwidgets-private.c -fPIC -DPIC -o .libs/gimpwidgets-private.o if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -DG_LOG_DOMAIN=\LibGimpWidgets\ -DGIMP_DISABLE_DEPRECATED -DG_DISABLE_DEPRECATED -DGDK_PIXBUF_DISABLE_DEPRECATED -DGDK_DISABLE_DEPRECATED -DPANGO_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE -mcpu=athlon-xp -O3 -pipe -Wall -MT test-preview-area.o -MD -MP -MF .deps/test-preview-area.Tpo \ -c -o test-preview-area.o `test -f 'test-preview-area.c' || echo './'`test-preview-area.c; \ then mv -f .deps/test-preview-area.Tpo .deps/test-preview-area.Po; \ else rm -f .deps/test-preview-area.Tpo; exit 1; \ fi make[2]: *** No rule to make target `../libgimpwidgets/libgimpwidgets-2.0.la', needed by `test-preview-area'. Stop. make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/var/tmp/portage/gimp-2.1.3/work/gimp-2.1.3/libgimpwidgets' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/gimp-2.1.3/work/gimp-2.1.3' make: *** [all] Error 2 Any ideas? I've never compiled gimp before, so this is a SWAG, but it looks like a Makefile problem. Did you run .configure, if there is one? Did you search the makefile for a rule for making libgimpwidgets-2.0.la to see if it's there? That's where I would start. Also, the trailing version number may be specified with a variable, so I would make sure there isn't a mismatch there. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Removing the crop frame
I've been motivated to join this list by a problem that's been driving me nuts. At some point I activated a yellow and black crop frame, and it seems there is no way to turn it off. I would at least expect SELECT::NONE to do it, but that only unmarks regions other than the crop region. I'm about to trash this image and start over just to get rid of the crop box. It cuts off everything that crosses the line. The reset button in the crop tool window does not work. If I set the origin of the crop tool to 0,0 and set the offsets to the image size, it's only temporary for that command, and the old crop region continues to cut things off. It seems there is a different cut-out box for each layer. Any ideas? ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] So it's a layer border - not a crop frame
* Sven Neumann [EMAIL PROTECTED] [2004-08-07 06:59]: Yellow and black crop frame? That's the border of the active layer, not at all related to crop. Thanks for clearing that up - and thanks to those who privately replied. I guess I discovered the layer border at the same time I was playing with crop. And to add to the confusion, floating layers were trimming my image at the border, as if to be cropping. So I've spent a maddening few hours trying to use crop to manipulate what was really a layer border. For the record, the solution is to do a layer to imagesize. As a suggestion to any developers who may be following this thread, it would be really nice if there were a mouse-over that tells the user that the yellow/black line is a layer border. I then guess that would annoy the users who already know what it is. Maybe a novice mode w/ mouse-overs? I know a photoshop user who is an open-source gnu fanatic, and really wants to switch to gimp, but insists that gimp is too difficult to use, and has some missing functionality. There's a good chance that the missing functionality is really a case of him not finding it. Anyway, thanks to all who helped. Besides this issue, I've been quite pleased with gimp. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
