![[Way qool image]](http://www.rru.com/Images/blackhole3.gif)
Just the FAQs, please!
Last updated: Monday, 28-Jan-2002 01:00:14 CST
A number of questions related to pre-1.0 releases have been removed. You should really upgrade to the latest release if at all possible. 1.0 is far more stable than any of the developer releases! If you really need an answer to a pre-1.0 question, email the FAQ maintainer at meo@rru.com . If it was in the FAQ, I'll mail it to you.
| Y2K | General | Plug-Ins | Script-Fu | Fonts |
|---|---|---|---|---|
| File Formats | Using | Platforms | IFAQs |
If your question isn't here, it might be more of a Developer FAQ than a user FAQ. Look there before you panic.
The latest version of this FAQ should always be available at http://www.rru.com/~meo/gimp /faq-dev.html .
You may submit material to the maintainer, Miles O'Neal, at meo@rru.com .
Quote of the Something
...birds don't make nifty pencil-tips for sketching...
-Jim Harmon (12 Mar 1998, gimp-developer mailing list)
The ``GNU Image Manipulation Program'' sired by Spencer Kimball & Peter Mattis.
In their own words, ``The GIMP is our answer to the current lack of free (or at least reasonably priced) image manipulation software for Linux and UNIX in general.''
Note: Originally, GIMP stood for ``General Image Manipulation Program''.
One day (I believe it was in 1997) RMS visited Berkeley, and Spencer and Peter met with him. They asked if they could change General to GNU, and it was done.
Not really. It doesn't use the GNOME application framework. The only thing it has in common is GTK.
GTK was developed solely for GIMP, initially. Towards the end of the 0.99 development cycle in 1998, GTK was split from being bundled with GIMP to being a separately available library. See http://www.gimp.org/~sjburges/gimp-history.html for has some interesting tidbits, from the GIMP perspective.
See also http://www.xach.com/gimp/news/, which has an archive going back to 1997.
The best bet is to check out the GIMP home page which includes pointers to the latest source, as well as complete binaries for a variety of platforms, including at least Linux (a.out and ELF), FreeBSD-2.1, HP-UX, SunOS and Solaris 2.4, and SGI. More may be available by now; go check the web page. Go on! Vamoose! You can come back here after you get it!
Version 1.0.0 is out, and very stable. Get the production version, and get rid of all your old developer versions!
Yes. It is available at http://manual.gimp.org/ in HTML form, and ftp://manual.gimp.org/pub/manual/ n Frame, HTML, PDF and PS formats.
Pointers to Windows projects are available on the official About the GIMP page.
A Windoze version was announced on April Fool's Day, and those who missed the opportunity to download it should be sad, indeed; the announcement itself (a work of art!) follows (the URLs are no longer active):
I got a little restless during spring break, so, besides sleeping a lot, and scaring squirrels in the yard, I did mad run of hacking and managed to create a suprising beast: GIMP on Win32. http://www.gimp.org/gimp-win32.gif Yep, it really wasn't too hard, considering the way GTK abstracts out the underlying GUI. It clearly needs work though, but it's for the most part fully functional. Just crashes a lot. But you guys can take a look at it: ftp://ftp.gimp.org/pub/gimp/win32/ -Yosh
As of version 1.0, there is at least one Easter egg.
These are similar to the layers found in tools such as Adobe's PhotoShop[tm]. Think of a stack of slides or filters, such that looking through them you see a sort of composite of their effects. For more information, check out the S&P introduction to layers.
Probably the prime GIMP resource page is maintained by Quartic at http://www.nuclecu.unam.mx/~federico/gimp/el-the-gimp.html .
A list of GIMP tutorials is available at http://abattoir.cc.ndsu.nodak.edu/~nem/gimp/tuts from Nem W Schlecht.
The GIMP Documentation Project, spear-headed by Michael J. Hammel, is the central documentation point for users.
The old, email-based interface is gone. Instead, we use Mailman. You can subscribe, unsubscribe or perform other configuration tasks through the web interface located at http://lists.xcf.berkeley.edu/mailman/listinfo .
There are other gimp-related lists there as well.
I'm not sure who maintains these any more, but the latest list I was provided contains the follownig:
| Hostname | Port | Location |
|---|---|---|
| irc.gimp.org | 6667 | dynamic |
| irc.au.gimp.org | 6667 | Australia |
| irc.su.gimp.org | 6667 | USA |
| irc.acc.umu.se | 6667 | Sweden |
``All the excitement is in channel #GIMP.'' -Zach
Some of the earliest versions needed Motif, but by the 0.60 (development) version, Motif was no longer necessary. S&P developed their own, very slick toolkit for the GIMP, called GTK. More information on GTK is available at http://www.gtk.org/ ..
Probably because it can't find them. 8^)
There are a couple of solutions. The best one, if you have superuser access on your system, or a cooperative system administrator, is to add the GIMP's library directory to the system library configuration. To do this, edit /etc/ld.so.conf to include /usr/local/lib and then type
ldconfig
and things should work from then on.
If you can't do this, add the directory to your LD_LIBRARY_PATH environment variable. Be sure you do this in your shell's startup scripts as well.
If you have old versions of the libraries, you will probably need to remove them first, especially if they are in standard system locations such as /usr/lib . Don't just delete them, though; move them somewhere safe, install the new ones, and try again. Then make sure everything else still works; you may have other programs on your system which require the old versions. The ideal response in such a case is to rebuild all the programs to use the new libraries. Where this isn't possible, you will just have to experiment with trying them in different locations, or statically linking them to one or more programs.
This is caused by attemping to use a pre-1.0 libgimp with gimp 1.0. The gimp_message() was added in 1.0, and is required by 1.0 to operate. Remove old libgimp(s), and try again. (See previous question.)
It's under development. For more information, see Owen Taylor's <otaylor@gtk.org> page about XInput support for GTK and the GIMP.
There is some support, but you have to do a little extra work to compile it in.
See http://www.levien.com/free/linux_intuos.html by Terry Mackintosh, or http://www.gtk.org/~otaylor/xinput/ for details, but here's the quick overview from Juergen Schlag <j.schlag@callisto.fulda.net>:
Yes. You can run xscanimage, the front end to SANE (Scanner Access Now Easy), either as a GIMP extension or in stand-alone mode. This supports Mustek and HP flatbed scanners, as well as the Connectix color QuickCam camera.
Further information is available at http://www.mostang.com/sane/ .
Yes. In either the system-wide gimprc file or your personal gimprc file, uncomment the line that includes ``install-colormap''.
If the GIMP gives you a message similar to either of these when you try to start it:
Xlib: extension "MIT-SHM" missing on display "198.51.29.58:0.0".
or
** WARNING **: XShmAttach failed!
then you need to run it with the --no-xshm option.
This happens for one of two reasons. Either your X display server does not have the shared memory option, or you are running the gimp on a different system than the one on which it is displaying. In the former case, you may wish to look into different X servers, because shared memory can give you MUCH better performance. In the latter case, you will just have to live with it, since different systems can't generally share the same memory space.
For a while, these were provided separately in the developer versions. For some time now a very good, "minimum" set of these has been shipping with the GIMP. More are available as "extra" data bundles from any of the download sites.
Others are available from various places. Adrian "Numerical Excess" Likins has a page with lots of gradients and palettes at http://www4.ncsu.edu/~aklikins/gimp/AG.html .
This error message should say something like "the plug-in (or the main GIMP app) I was talking to has exited before returning any results, so I assume that it has crashed."
This should no longer be a problem, but if you insist on using older versions, read on for help. We recommend you try the latest version, though.
Somewhere around 0.99.16 or 0.99.17 , configure stopped searching /usr/local for include files and libraries, at least for some of the common packages. Also, on some platforms (FreeBSd, for instance), things may get installed under /usr/X11R6/share instead of /usr/local . Running autoconf and automake might solve this, but for the rest of us, just set the following variables before running configure (substituting as neceesary for /usr/local ):
csh, tcsh, etc:
setenv CFLAGS -I/usr/local/include
setenv LDFLAGS -L/usr/local/lib
sh, ksh, bash, etc:
CFLAGS=-I/usr/local/include ; export CFLAGS
LDFLAGS=-L/usr/local/lib ; export LDFLAGS
On Solaris, you may need to set LDFLAGS to
"-L/usr/local/lib -R/usr/local/lib" .
The instructions state that these directories will be searched automatically, but in at least some cases, this is not correct.
Yes, you have to have some form of X server - the GIMP is an X application! It needs an X server for image processing, and for font manipulation. However, if you wish to run in batch mode, you can run with a special, frame-buffer-less X server called Xvfb, which doesn't require a graphics card or mess with your screen:
Xvfb :1 -screen 0 10x10x8 -pixdepths 1 &
gimp --display :1.0 --no-interface --batch "commands" ... &
The first command starts the special X server; the second is an
example of how to invoke the GIMP in batch mode. When you are done
using the GIMP this way for a while, kill off Xvfb so it doesn't
waste system resources. If you expect to use gimp this way a lot,
you might want to leave Xvfb running for better response time.
You should check the man page for Xvfb(1) for other options, such as whether to use shared memory.
http://www.cs.utexas.edu/users/mschaef/gimpicons/index.html
That depends on several factors, but in general, any UNIX-like system (Solaris, Irix, Linux, AIX, HP/UX, BSD, etc) with an X server (preferably X11R5 or later) should work. You probably want at least 32MB of RAM, although a few hardy souls are making do with 32MB. More RAM will help speed things up. I would prefer at least a decent 486 box, but even a 386 should work. And it really screams on higher end workstations, like AIX, Solaris and Irix systems.
Like most graphics applications: the GIMP is resource intensive, which means it directly benefits from more memory, higher end graphics cards, and faster disks. Its the nature of the beast (computer graphics) and not necessarily a problem with the GIMP (although there are probably areas it could use performance work - what program couldn't?).
The main things are to make sure you are running at least version 1.0, and make sure you compiled with optimization on, debugging turned off, and the shared memory and X shared memory options tuned on.
Or, buy a faster system with more memory. 8^)
If it's still too slow for you, the easiest speedup is to invoke the GIMP with the "--no-data" option. This prevents the GIMP from loading patterns, brushes, and similar resources when it starts. You may benefit slightly from the "--no-splash" option as well; you might want to time that one to see if it really helps enough to be worthwhile.
On a Dell 100MHz 486 server box, the GIMP comes up in the following times:
| Command | Time |
|---|---|
| gimp | 18 seconds |
| gimp --no-data | 11 seconds |
| gimp --no-data --no-splash | 8 seconds |
| gimp --no-splash | 16 seconds |
Both users and developers can find a HOWTO report GIMP bugs at http://carol.gimp.org/gimp/howtos/bugzilla/bugzilla2.html for the time being (it should be integrated in the new www.gimp.org later on).
Depends on what you find. If they seem to be plug-in problems, you definitely want to try to tell the plug-in authors (look in the offending plug-in's source or on the Plug-in Registry web page).
For core functionality, you can report them at http://bugzilla.gnome.org.
Finally, if you need to discuss it with a wider developer audience (perhaps because it is really a feature request instead of a bug), send email to the GIMP developer mailing list. It's a good idea to say something like "[bug]" or [patch]" in the subject where applicable.
Always include the system type, OS, window manager, X version, etc, as well as the GIMP version (and GTK version if known), and anything else that might be applicable.
It's OK to send related problems in a single email.
Of course, patches are always welcome. 8^)
Plug-ins are external modules that actually do the nifty graphics transformations. There is a plug-in registry at http://registry.gimp.org/ with the latest plug-ins, maintained by Ingo Lütkebohle. [Special thanks to Adam Moss for the original registry!]
First, copy the plug-in[s] to your plug-in directory (typically /usr/local/lib/gimp/$VERSION/plug-ins/).
After copying the plug-in to its proper directory, just run the GIMP. It should automatically find new plug-ins.
You'll need a copy of the source directories. Build the GIMP. Place the new plug-in in the plug-ins directory. The docs with the new plug-in hopefully identify any special libraries it needs. Look for a plug-in with similar libraries (if all else fails, look at xpm and whirlpinch).
With newer versions, if the plug-in is contained in a single source file, you should just have to run the gimptool in the plug-in's directory :
gimptool --build plugin.c
For older versions, there are several methods. The first two walk you through a number of steps manually; these are the most thorough, but also require more work on your part. The last ones are scripts of one sort or another, and are easier on your part -- if they work with your system. Go ahead and try - you can always fall back on the first methods.
make
and it should build. Install it wherever your other plug-ins
are installed.
whirlpinch
whirlpinch.c
whirlpinch.o
In this case, you would remove the first and last files, leaving
the whirlpinch.c file. Now type
make
to rebuild the old plug-in.
Copy the output (cut and paste it!) into a file. Edit the file and change all occurances of "whirlpinch" (or whatever) to the name of the new plug-in. Execute the file you just edited. For instance, if the file is make_plug-in, just type
make_plugin
and it should work. The copy the plug-in to wherever the others
are installed on your system.
First, load Makefile-pi provided by
Ciccio C. Simon .
Change all occurances of the word sharpen in
Makefile-pi to the name of the new plug-in. Then type
make -f Makefile-pi
and watch it (hopefully) work.
If it doesn't work, try the next method.
First, load the compile-pi script provided by Jeremy Dinsel . Change the permissions on compile-pi as follows:
chmod ugo+rx compile-pi
and type
compile-pi help
for instructions. Follow those instructionms. If this one
also fails, go back to the earlier, manual methods; you
have too picky a configuration for the simple methods to
work.
If you need more help, ask your system administrator or a handy programmer, or get a good book on make (such as O'Reilly's). You may want to join the GIMP developer's list as well (see the Developer FAQ).
The plug-in registry referenced above is the place to check.
Some of the plug-ins have proven unstable. These have been moved into a separate download, which should be available wherever you got the GIMP, in the file gimp-plugins-unstable-VERSION.tar.gz or gimp-plugins-unstable-VERSION.tar.bz2 .
Since this list may change frequently, the unstable plug-ins are no longer listed here.
In the words of S&P:
Script-Fu is the first GIMP scripting extension. Extensions are separate processes that communicate with the GIMP in the same way that plug-ins do. The distinction is that extensions don't require an active image to operate on, instead extending the GIMP's functionality. GIMP internals for version 1.0 have been completely overhauled from version 0.54. In particular, the plug-in API has been made far more general with the advent of the procedural database (PDB). The PDB allows the GIMP and its plug-ins to register procedures which can then be called from anywhere: internally, from extensions, and from plug-ins. There are already over 200 internal GIMP procedures, and more being created all the time. Because all of these procedures can be easily invoked from extensions, the logical next step was to create a scripting facility; thus, Script-Fu was born.
As with plug-ins, web pages, COBOL, or anything else, one of the best things you can do is look at other peoples' code, and play with it. But it helps a lot if you know Scheme.
The trick to calling script-fu-scripts from another script is to just reference the main define for the script and not to try to use the pdb call. All the scripts in script-fu share a common name space; you call other scripts just like a regular function / define / whatever you call those those things in_scheme.
Ie, to call script-fu-predator in a script, just use
(script-fu-predator img drawable 2 TRUE 3 TRUE TRUE)
For examples, see
http://www.gimp.org/~adrian/scripts/test.scm .
From the script-fu console, call a plug-in like this:
(plug-in-name 1 0 0 100.0 1.0 10 0)The first parameter should always be a "1". The next two are the image number and drawable. Anything following these numbers will be plug-in parameters, which depend on the plug-in.
Inside an actual script, call a plug-in like this:
(define (script-fu-fred img drawable)
(plug-in-randomize-hurl 1 img drawable 100.0 1.0 10 0)
(gimp-displays-flush)
)
(script-fu-register "script-fu-fred"
"<Image>/Script-Fu/fred"
"Randomize test"
"Miles O'Neal <meo@rru.com>"
"Miles O'Neal"
"1998/May/1"
"RGB*, GRAY*, INDEXED*"
SF-IMAGE "Image" 0
SF-DRAWABLE "Drawable" 0)
Invoke the script as non-interactive and add a pair of escaped quotes around each string just like you do in (script-fu-register). You DO NOT need to replace '-' with '_' in any names or registrations.
Example script:
(define (script-fu-famhist-link text filename)
;; code ommitted for brevity
(file-gif-save 1 img 0 filename "" FALSE FALSE 0 0))
(script-fu-register "script-fu-famhist-link"
"<Toolbox>/Xtns/Script-Fu/Family Historian/Link"
"Family Historian Link"
"John Johnson"
"John Johnson"
"1998"
""
SF-VALUE "Text String" "\"Family Historian\""
SF-VALUE "Base filename" "\"foo\""
)
Example Invocation:
;; note the '1' as the first argument tell it to run non-interactivly
;; note the \" \" pairs around the strings
gimp -n -b '(script-fu-famhist-link 1 "\"Introduction\"" \
"\"intro.gif\"")' '(gimp-quit 0)'
For a detailed, step by step explanation, check out Adrian's
Gimp Batch Mode how-to at
http://adrian.gimp.org/batch/ .
Normally it means that the script is trying to use a particular font that isn't available on your system - it's either not installed or not in your X server's FONTPATH. The base script-fu package makes extensive use of the freefont package, and at least one font (AlfredDrake) from the sharefont package.
Net-fu is a web-based interface to a script-fu server. The work is done at a remote site. To see Net-fu, point your web browser at ftp://ftp.gimp.org/ or one of the miiror sites, and then go to "gimp/net-fu/". Any web browser can read net-fu pages; the browser must be Java-enabled to actually run Script-fu.
The freefonts and sharefonts packages are both available from ftp://ftp.funet.fi/pub/Linux/mirrors/metalab/X11/fonts/ or other metalab mirrors. If you get the sharefonts package, be sure and read the various licensing agreements, and abide by them.
You need to copy the gtkrc file that comes with the GIMP source (in the top level directory) into $HOME/.gimp/gtkrc . As of 0.99.10, this should be recognized. You then go in and edit the default font style, the one that looks like this:
style "default"
{
font = "-adobe-helvetica-medium-r-normal--*-100-*-*-*-*-*-*"
}
I'm sure ther's a lot of clever stuff that can be done
here, and I'll try to track it down soon, but in the meantime,
just change that "100" to something larger, like "120" or "140".
(The number is points * 10, so 100 is a 10 point font).
Obviously, you could stick in any font you have available.
These are 16 bit fonts, with thouousands and thouousands of characters. And the characters are more complex, which means (usually) more bits per character, which means more memory and more processing time.
This includes fonts such as kana, kanji, song ti, mincho and gothic. (If you look carefully at the fully qualified font name for gothic via xfontsel, you'll see clues. It's a daewoo font. The gothic name is misleading to western minds, but no doubt means something to its author[s].)
Check one of these out in a program that shows a font as pages (such as xfd).. You can keep hitting next page to see a new page of characters, almost forever.
If neither your X server nor your X font server supports you
can try one of the TruType font servers:
xfstt (http://sunsite.unc.edu/pub/Linux/X11/fonts/)
or
xfsft (http://www.dcs.ed.ac.uk/home/jec/programs/xfsft/ .
xfstt supposedly has limitations on the font size.
XCF is the GIMP's "native" format. This will preserve all information about an image, including the layers.
All the common formats, and many more as well, including GIF, TIFF, JPEG, XBM, XPM, PostScript, and BMP. Plug-ins are used to load and save files so adding new file types is very simple, compared to other graphics programs.
As of July 1, 1998, the list of supported types included BMP, CEL, FITS, FLI, GBR, Gicon, GIF, GIcon, HRZ, JPEG, PAT, PCX, PIX, PNG, PNM, PostScript, SGI, Sun Raster, TGA, TIFF, XPM, XWD and XCF. Bzipped, Gzipped and Xdelta'd files are understood, and URL support is provided.
Of course, plug-ins for other types may be available at the plug-in registry .
The two most likely problems are related to image type and layers. For instance, your image type must be "Indexed" for GIF, but "RGB" for TIFF. Try a different image type (look under the "Image" menu). If you have more than 1 layer in your image, you probably need to merge the visible layers, and/or "flatten" the image. Both operations are available under the "Layers" menu or from the "Layers" dialog. Flattening will destroy any background transparency.
Yes; the GIMP has a file format just for this - the XCF format. Don't flatten the image or merge the layers as you would to save to other formats! This will only work with the XCF type.
There are several possibilities.
There's a tutorial on this at http://www.gimp.org/~sjburges/straightline/straightline.html .
Use the elliptical select tool, hold down CTRL key to constrain as circle, fill the selected area with new color, right click on selected area, choose SELECT, SHRINK, shrink selection by whatever number of pixels you want your circle width to be, right click again in selected area, choose EDIT, CUT. Voila, one beautifully antialased circle.
Create a new image large enough to hold the selection. Copy the selection, then paste it into the new image. Crop the new image. Flatten, etc, as necessary. Now save it.
The script-fu-selection-to image can also be used to cut a selection out of an image and create a new image with it.
Before saving the image, select "Layers->Flatten Image". It would be more intuitive if it was called something like "Remove Alpha"...but that's generally not its primary function. It just happens to remove alpha.
Open the additional image via the File->Open
menu. Then Select->Select all. Edit->Copy.
Move the cursor to the edited image. Edit->Paste.
This drops the new image (selection) into the
middle of the edited image. Move it around as
necessary, then anchor it.
In general, small fonts won't ever look quite as nice as large ones. But there are a couple of things to try.
Go to the menu selection you are interested in. Keeping it selected (hold the mouse's menu selection down if necessary), press the key sequence you wish to assign to the menu. It will appear on the right of the menu. The new binding will be saved and used in future GIMP sessions.
0.54 is ancient history - it was an early, developer's release.
The equivalent method in 1.0 or later would be to have two layers, and create an alpha mask (add layer mask from the layer ops menu) and insert the "mask" layer into it.
Not at this time. It's in the works for a future release.
Some servers have no facility for this; you may be able to adjust your monitor to correct somewhat. Later versions of XFree86 allow these server options:
-gamma f set gamma value (0.1 < f < 10.0) Default: 1.0
-rgamma f set gamma value for red phase
-ggamma f set gamma value for green phase
-bgamma f set gamma value for blue phase
If your image doesn't have an alpha channel, add one with
Layers->Add Alpha Channel.
Select the area you want to clear (if not the whole image).
To change everything of a particular color transparent,
pick Select->By Color... and click on the color in the
image you want to replace.
Then select Edit->Clear. That's it.
Any dithering, blurring, or related effects against the color you replace will be against the original color. This usually requires you to do some form of cleanup of the edge pixels. In cases likely to result in this, change the color to transparent as early as reasonably possible to preclude extra "cleanup" work.
At the bottom of the toolbar there is a box with two smaller boxes and an arrow. The uppermost box displays the current foreground color; the lowermost box displays the current background color. You can single-click on the arrow to switch these two. You can also double-click on either of the color boxes (or single-click if that box is already selected) to pop up a color selection tool, with which you can elect any color you like for that box. That color then becomes the new foreground or background color. Subsequent drawing operations (including text and color fill) will now use these colors.
To date, there's no native port for older Macs. Work has been done on OS X and to work with X11 on Macs, with Tenon's X port, etc. For details go to http://www.macgimp.com/ .
You downloaded a non-Windows version. The Windows version is available at http://www.gimp.org/win32/ .
To avoid problems with GIF's patent holder, the GIMP no longer ships with GIF support by default. If you can't find the GIF plug-in wherever you got the GIMP, it's available at http://www.gimp.org/win32/ .
ftp://ftp.uu.net/graphics/jpeg/jpegsrc.v6b.tar.gz
If you are using a 64-bit OS, you need to add the `-o32' option for the compiler, or use gcc. With the SGI compiler, you may also need to play with optimization. Some modules may have exhibit problems unless compiled with `-O1' or even `-O0'.
Script-Fu requires the POSIX-compliant regex functions, which SGI only supports with IRIX 6.2 and later versions. The GNU version of regex should work just fine, though, and is available at:
http://wuarchive.wustl.edu/systems/gnu/regex-0.12.tar.gz
The GIMP is interacting in such a way with your system that it thinks you have XIM extensions when you don't. Run the configure script again, with the `--disable-xim' option, and recompile.
You can also try compiling with `--disable-shared'.
Or you can install a version of X11R6. 8^)
If you just want to use freefonts or sharefonts, you can copy these files into the appropriate directory (such as /usr/openwin/lib/fonts/freefonts/ or /usr/openwin/lib/fonts/sharefonts/), or merge them with the appropriate fonts.dir and fonts.scale files if you mixed in freefonts and sharefonts with existing fonts:
Or just try using fontadmin instead of
mkfontdir .
I've never run into a Solaris system missing this, but according to Neil Corlett:
The 'fontadmin' tool is a openwin demo program and sometimes does not exist. To properly add fonts the finagled directory requires fonts.dir, fonts.scale files to exist. mkfontdir does the first of these OK. For the second I built groff and downloaded type1inst-0.6.1 from an X contrib archive. type1inst (which needs groff) will build the fonts.scale file from the pfb files automatically.Solaris 2.6 is supposed to include better font editor and admin tools.
There may be a number of reasons. Several peoples' answers are here. The most detailed answers, list first, are the best bets with their noted versions.
According to resident Gimp on SOlaris guru Jim Harmon, more recent versions (0.99.25 on) should compile easily, but you may need to make a change in /usr/graphics/gtk-config.in:
OLD:
--libs)
echo -L${exec_prefix}/lib -L/usr/openwin/lib -R/usr/openwin/lib \
-lgtk -lgdk -lglib -lXext -lX11 -lsocket -lnsl -lm
;;
NEW: (subs. your own GTK path for /usr/graphics )
--libs)
echo -L${exec_prefix}/lib -L/usr/openwin/lib -R/usr/openwin/lib \
-L/usr/graphics/gtk+-0.99.10/gtk/.libs \
-R/usr/graphics/gtk+-0.99.10/gtk/.libs -lgtk \
-L/usr/graphics/gtk+-0.99.10/gdk/.libs \
-R/usr/graphics/gtk+-0.99.10/gdk/.libs -lgdk \
-L/usr/graphics/gtk+-0.99.10/glib/.libs \
-R/usr/graphics/gtk+-0.99.10/glib/.libs -lglib \
-lXext -lX11 -lsocket -lnsl -lm
;;
Jim Harmon compiled GIMP 0.99.19 and GTK+ 0.99.5 on Solaris 2.5, SPARC 5. Here are the steps he took:
(*) If you're installing a NEW VERSION, first:
(*) o cd <gtk install path> (/usr/graphics/gtk+<ver>)
(*) o make uninstall clean
(*) o rm -r ~/.gimp
THEN:
o mkdir /usr/graphics
o mv g*.tar.gz /usr/graphics
o tar xvfz gtk+-0.99.5.tar.gz
created /usr/graphics/gtk+-0.99.5
o cd gtk+-0.99.5
o ./configure, make, make install
(executed successfully)
o cd ..
o tar xvfz gimp+-0.99.19.tar.gz
created /usr/graphics/gimp+-0.99.19
o cd gimp+-0.99.18
o ./configure
NOW: *** Edit "config.status" ***
o vi config.status
/LDFLAGS
o change:
(note, the following are SINGLE LINES, remove any "\"
characters and duplicate objects in the string if you
cut/paste these into your config.status file...)
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib \
-lgtk -lgdk -lglib \
-lXext -lX11 -lsocket -lnsl -lm%g
to:
(*) s%@LDFLAGS@% -L/usr/local/lib -R/usr/local/lib \
-L/usr/openwin/lib -R/usr/openwin/lib \
-L/usr/graphics/gtk+-0.99.5/gtk/.libs \
-R/usr/graphics/gtk+-0.99.5/gtk/.libs -lgtk \
-L/usr/graphics/gtk+-0.99.5/gdk/.libs \
-R/usr/graphics/gtk+-0.99.5/gdk/.libs -lgdk \
-L/usr/graphics/gtk+-0.99.5/glib/.libs \
-R/usr/graphics/gtk+-0.99.5/glib/.libs -lglib \
-lXext -lX11 -lsocket -lnsl -lm%g
(*) O To SAVE SPACE in compiling, in the config.status file,
REMOVE the "-g" option from the CFLAGS line:
[was] s%@CFLAGS@% -g -I/usr/openwin/include -O2 -Wall%g
[is] s%@CFLAGS@% -I/usr/openwin/include -O2 -Wall%g
o ./config.status, make, make install
(In other words, where "-lgtk -lgdk -lglib" appear
on the LDFLAGS line, add the GTK+ path to the libs
with the format of "-L/usr/graphics/gtk+-0.99.3//.libs
-R/usr/graphics/gtk+-0.99.3//.libs -l", subsituting
gtk/gdk/glib for )
(*) Also bear in mind that "/usr/local/lib" won't exist if not
added as shown to LDFLAGS.
- - -
CAVEATS:
I'm using the precompiled GCC 2.7.2.3 for Solaris 2.6,
and gmake instead of make. To get GCC and GMAKE working,
I had to set the paths to /usr/xpg4/bin and /usr/ccs/bin
to the PATH variable, so that different compiler tools
could be found. (ar, bison, cpp, etc.)
Jim Harmon compiled GIMP 0.99.18 and GTK+ 0.99.3 on Solaris 2.5, SPARC 5. Here are the steps he took:
o mkdir /usr/graphics
o mv g*.tar.gz /usr/graphics
o tar xvfz gtk+-0.99.3.tar.gz
created /usr/graphics/gtk+-0.99.3
o cd gtk+-0.99.3
o ./configure, make, make install
(executed successfully)
o cd ..
o tar xvfz gimp+-0.99.18.tar.gz
created /usr/graphics/gimp+-0.99.18
o cd gimp+-0.99.18
o ./configure
NOW: *** Edit "config.status" ***
o vi config.status
/LDFLAGS
o change:
(note, the following are SINGLE LINES, remove any
<CR> characters in the string if you cut/paste it into your
config.status file...)
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -lglib
-lXext -lX11 -lsocket -lnsl -lm%g
to:
s%@LDFLAGS@% -L/usr/openwin/lib -R/usr/openwin/lib
-L/usr/graphics/gtk+-0.99.3/gtk/.libs
-R/usr/graphics/gtk+-0.99.3/gtk/.libs -lgtk
-L/usr/graphics/gtk+-0.99.3/gdk/.libs
-R/usr/graphics/gtk+-0.99.3/gdk/.libs -lgdk
-L/usr/graphics/gtk+-0.99.3/glib/.libs
-R/usr/graphics/gtk+-0.99.3/glib/.libs -lglib -lXext -lX11 -lsocket
-lnsl -lm%g
o ./config.status, make, make install
(In other words, where "-lgtk -lgdk -lglib" appear
on the LDFLAGS line, add the GTK+ path to the libs
with the format of "-L/usr/graphics/gtk+-0.99.3/<lib>/.libs
-R/usr/graphics/gtk+-0.99.3/<lib>/.libs -l<lib>", subsituting
gtk/gdk/glib for <lib>)
--------------------------------
CAVEATS:
I'm using the precompiled GCC 2.7.2.3 for Solaris 2.6,
and gmake instead of make. To get GCC and GMAKE working,
I had to set the paths to /usr/xpg4/bin and /usr/ccs/bin
to the PATH variable, so that different compiler tools
could be found. (ar, bison, cpp, etc.)
According to Keyyly Price, here's a major one for 0.99.10 .
``If you do a -lX11, you must also include -lsocket, or it won't compile anything of X on Solaris 2.5. X doesn't have the socket lib.
Which means you'll need to setenv LIBS -lsocket while running configure if you run Solaris 2.5.''
Will Lowe did the following to get the GIMP compiled for Solaris 2.5.1 : (You should replace /usa/lowe/usb_lowe/gimp in each "-L" part with whereever you are compiling gimp, and replace /usa/lowe/gimp/lib in the "-R" parts with whereever you're going to install gimp. -Will)
Get gimp source (duh) (gimp-0.99.9).
uncompress and untar the source.
./configure --without-libtiff
rm docs/pdb.info
gimp/gtk+/gdk/gdkimage.c
Remove these three lines:
#if defined (HAVE_IPC_H) && defined (HAVE_SHM_H) && defined (HAVE_XSHM_H)
#define USE_SHM
#endif
gimp/gtk+/gdk/Makefile:
change the variable "libgdk_la_LDFLAGs" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/glib/.libs -R/usa/lowe/gimp/lib
before "-lglib"
gimp/gtk+/gtk/Makefile:
change the variable "libgtk_la_LDFLAGS" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/gdk/.libs -R/usa/lowe/gimp/lib
before "-lgdk"
gimp/libgimp/Makefile:
change the variable "libgimp_la_LDFLAGS" to include:
-L/usa/lowe/usb_lowe/gimp/gtk+/glib/.libs -R/usa/lowe/gimp/lib
before "-lglib"
change "libgimpui_la_LDFLAGS" to include
-L/usa/lowe/usb_lowe/gimp/gtk+/gtk/.libs -R/usa/lowe/gimp/lib
before "-lgtk"
gimp/plug-ins/dgimp/dgimp.c
move "#include <sys/types.h>" to above "#include <sys/socket.h>"
gimp/plug-ins/dgimp/lpg.c
same as dgimp.c
For 0.99.pre11, Sheldon E. Newhouse suggests the following
change to the libtool files:
#archive_cmds='$LD -G -z text -h $soname -o $lib$libobjs$deplibs' archive_cmds='$LD -G -h $soname -o $lib$libobjs$deplibs'
SunOS ships with an X11R4 server, which does not handle either scaleable fonts or communications with the X font server. If you want to use the freefonts (or any scalable fonts) on SunOS, you need to install your own, newer X server, preferably X11R6.4 (which will be much faster than the server shipped with SunOS).
If you do this, you will no longer have PostScript capability directly in your X server; you will need to use ghostscript. You may well want to keep both servers around, and use each when you need its features.
Of course, you could always try to find a PS version of the font you need and make a bitmap for the size you need and add that to the X11R4 server's font path, but if you need more than one or two font/size combinations over all the time you use GIMP, this is an obnoxious solution.
Yes. Try the following:
ftp://ftp.gimp.org/pub/gimp/binary/RPMS/
ftp://s9412a.steinan.ntnu.no/pub/gimp/
According to Rob Payne...
There are old .src.rpm's on ftp.redhat.com for gimp and gtk that if used to build new gtk+ and gimp will create all kinds of headaches for the builder.
The gtk SPEC file manually moves header files from gtk default installation place, and then the CFLAGS returned by gtk-config are incorrect when it comes time to build/install gimp. I was successful in bringing the gtk+ SPEC file up to date by removing the following lines from (gtk-970925.spec) to build 0.99.7 and 0.99.8:
(cd $RPM_BUILD_ROOT/usr/local/include
mkdir glib
mv glib.h glibconfig.h glib)
Of course, the %files section of that SPEC need to be changed, as well to
include the differences in places for the header files, and to include
gtk-config.
I hope that information is useful to someone. If you have any questions about any of this, please let me know.
Another possibility is for this error (far less common) is that there is an old library compiled with the other hanging around somewhere on the system. Remove old copies of libgimp.
You probably just installed the graphics libraries. You also need to install the development portion as well; it's called the libgr source package. After installing that, GIMP should compile easily.
``Some of the X include files and libraries are not in /usr/include/X11 and /usr/lib/X11 as you may expect. This is because HP allows support for X11R4 and X11R5 on the same machine. You must modify a configuration file so that the Makefile created by imake looks for these files and libraries in an alternate location. See "Motif and Xt" on page A-5 and "Xaw and Xmu" on page A-6 for details on installation of OSF/Motif, Xt, Xaw and Xmu.
...
``HP does not ship or support these widget libraries; however, they are widely used for X public domain software. Binaries and header files are available from the Interworks library. Source is available from public domain archives. The name of the binary package in the Interworks library is x8.0s700.tar.Z. You may also be able to locate these files on another machine and copy them to your machine.''
The ref'd package is at:
ftp://www.interworks.org/pub/comp.hp/
Look for the x8.0s[378]00.tar.Z files.
You are probably not using the GNU make. Most, if not all, non-GNU makes will fail on the GIMP makefiles. Get the GNU make package.
It's a bug in AcceleratedX with shared memory. Turn off shared memory when you start the GIMP (--no-xshm) or pick up the patch to AcceleratedX's X server from ftp://ftp.xinside.com/pub/update/ .
At least one person has found this bug (or another one with the same symptoms) to still be present in 4.1 .
This is a bug in XFree. You need to upgrade to XFree3.3.2 .
Seth Burgess has written A brief history of the GIMP. It's available at http://students.ou.edu/B/Seth.J.Burgess-1/gimp-history.html .
(/usr/local/share/gimp/scripts/beavis.jpg is the
B/W image in question.)
The image (of a kitten playing with Gumby) is used as "sorta random, sorta not" data to generate (for example) the crystal bands, or other texture maps. There are other ways to produce this data as well, but the author stuck with this one, found in a tutorial somewhere.
One of the original GIMP authors, Spencer Kimball or Peter Mattis, we forget which.
Contributors: Spencer Kimball & Peter Mattis, Ross Arnold, Thomas Bahls, Zach Beane, Brandon Beattie, Seth Burgess, Mats H. Carlberg, Keith Christian, Neil Corlett, Christopher Curtis, Jeremy Dinsel, Robert Dinse, Ian Donaldson, Bert Driehuis, Pat Dunn (?), Stephen Eglen, Eugene Filippov, Rial Fletcher, Trond Eivind Glomsrĝd, Michael J. Hammel, Pete Harlan, Jim Harmon, Thimo Jansen, John Johnson, Christoph Kukulies, Philippe Lavoie, Marc Lehmann, Adrian Karstan Likins, Will Lowe, Ingo Lütkebohle, T. Paul McCartney, Wenxin Mao, Adam Moss, Sven Neumann, Sheldon E. Newhouse, Miles O'Neal, netcat, Rob Payne, piranha (alix albert), Kelly Price, Quartic (Federico Mena), Raphael Quinet, Deon Ramsey, Donovan Rebbechi Kai Ruhl, Ken Sallenger, Juergen Schlag, William L. Sebok, Terrelle Shaw, Ciccio C. Simon, Yosh (Manish Singh), Phil Stracchino, Mike Sweet, Owen Taylor, Mike Terry, Tyzen
Last updated: 28 January 2002
Copyright 1996-1998
Miles O'Neal,
<meo@rru.com>
Austin, TX. All rights reserved. You may freely redistribute this
FAQ so long as you redistribute it in its entirety, including this
notice and the web location of the latest version. You are not
required to redistribute the graphics with ths FAQ. It would be
much appreciated if you let the FAQ maintainer (Miles O'Neal)
know if you redistribute this FAQ.
Web service donated by Net Ads
as a community service.