The GIMP: the GNU Image Manipulation Program
--------------------------------------------

This is version 0.99.11 of the GIMP. For the most part it contains all
of the features that will be in version 1.0 of the GIMP. It does,
however, lack a) documentation, b) robustness and c) some of the
plug-ins found in the 0.54 version.

The main difference between v0.99.11 and much earlier versions is the
use of a tile based memory management for images. This allows the GIMP
to work with images much larger than physical memory in a usable
fashion. Before such memory management, the GIMP was nearly unusable
for large images. (Large being something on the order of
4000x3000). With the tile memory management, image size is effectively
limited by disk space. It is due to the switch to a tile based memory
management system that old plug-ins will not work with this version of
the GIMP.

The GIMP uses GNU libtool in order to build shared libraries on a
variety of systems. While this is very nice for making usable
binaries, it can be a pain when trying to debug a program. For that
reason, compilation of shared libraries can be turned off by
specifying the "--disable-shared" option to "configure". Similarly,
compiling with "-O2" instead of "-g" can be specified by using the
"--disable-debug" option to "configure". We strongly recommend
compiling with the debugging flag as the GIMP appears to be much more
buggy when compiled with optimization turned on.  Your mileage may vary.

The plug-in API has changed drastically from previous versions. The
result is that it is now possible to access much of the GIMP's
internals through a database of procedures aptly named the procedure
database. Plug-ins fit into the procedure database by inserting
themselves into it. The result is that plug-ins can call GIMP internal
procedures and other plug-ins. Most plug-ins now fully support the
procedural database, so that you can call them from scripts and other
places as well.

The procedure database is self-documenting. To add a procedure to the
procedure database the programmer must specify a help string and help
strings for the arguments and return values. This allows us to
automatically create documentation for the procedures in the procedure
database. The documentation resides in "docs" and is provided in
texinfo format.

A new type of plug-in called an extension has been created. Extensions
are similar to plug-ins in that they are external program, but they
differ in when and how they are run. The essential difference is that
plug-ins are associated with a particular image/drawable, while
extensions are not.

A good example of a complex extension is Script-fu, which resides in
the "plug-ins/script-fu" directory.  Script-fu is a simple Scheme
interpreter that provides bindings to the GIMP's procedural database.
This way you can write useful scripts that call the GIMP's functions
and plug-ins, thus allowing automatization of repetitive tasks.  Many
scripts are included for your enjoyment in the
"plug-ins/script-fu/scripts" directory.

Another extension is the "dbbrowser" utility, which lets you
interactively browse through the procedures installed in the
procedural database.  This will mainly be of use to Script-fu
programmers.  Dbbrowser is also nicely integrated in the interactive
Script-fu console.

Lastly, there is new file format (xcf) designed specifically for
saving GIMP images. It handles layers, channels and tiles as well as
saving all of the state information about the image, such as the
active channel, the selection, etc. The format needs testing to make
sure that it really is portable (we think we did it right) as well as
robust. It also will probably change sometime in (near) the future to
implement some form of compression for the tiles.

The GIMP's new home page is at http://www.gimp.org, but this site may
not be ready by the time you read this.  In that case, go to
http://www.xcf.berkeley.edu/~gimp while we finish the new site.

There are two GIMP-related frequently-asked questions (FAQ) lists.
The developer's and user's FAQs can be found here:

	http://www.rru.com/~meo/gimp/faq-dev.html

There is some preliminary GIMP documentation prepared by Adrian Likins
in this URL:

	http://www4.ncsu.edu/~aklikins/gimp/docs

In the meantime, while the final documentation is finished, you can
read the dozens of fine GIMP tutorials people have written.  Most of
these tutorials can be accessed from

	http://abattoir.cc.ndsu.nodak.edu/~nem/gimp/tuts

We have several mailing lists dedicated to GIMP user and development
discussion.  To subscribe, send mail to

	majordomo@scam.xcf.berkeley.edu

and in the body of the message put

	subscribe <list-name> your@email.address

substituting <list-name> for "gimp-user" or "gimp-developer" (without
the quotes, of course) depending on the list you want to subscribe
to.  The mailing list archives can be found at

	http://kiwi.cs.berkeley.edu/~gimp

Gimp-user is a mailing list dedicated to user problems, hints and
tips, discussion of cool effects, etc.  Gimp-developer is oriented to
GIMP core and plug-in developers.  Most people will only want to be
subscribed to gimp-user.

And finally, for the real junkies, there are two IRC channels devoted
to the GIMP :-)  On EFNET there is a small #gimp channel.  On Byxnet
(a private mostly-GIMP network) there is #gimp, too.  The Byxnet
servers are:

	irc.mint.net:6666
	irc.canweb.net:6667
	rudolf.canberra.edu.au:6666
	levien.com:6666

More information about Byxnet can be found at 

	http://rudolf.canberra.edu.au/gimp/byxnet.html

We sincerely hope you enjoy the program.  Please report problems to
gimp-developer@scam.xcf.berkeley.edu.  Before reporting a problem, you
may want to see if someone else has already did (check the mailing
list archives for this).

Have fun,

  Spencer Kimball <spencer@xcf.berkeley.edu>
  Peter Mattis <petm@xcf.berkeley.edu>
  Federico Mena <federico@nuclecu.unam.mx>

There are three basic steps to building and installing the
GIMP on unix:

  1. Configure the GIMP by running the `configure' script.
  2. Build the GIMP by running `make'.
  3. Install the GIMP by running `make install'.
  4. Install the gimp-data package.  Be sure to install this, or you
     won't have the GIMP's datafiles installed.

Generic instructions for configuring and compiling auto-configured
packages are included below. Here is an illustration of commands that
might be used to build and install the GIMP. The actual configuration,
compilation and installation output is not shown.

  % tar xvfz gimp-1.0.0.tar.gz   # unpack the sources
  % cd gimp-1.0.0                # change to the toplevel directory
  % ./configure                  # run the `configure' script
  % make                         # build the GIMP
  % make install                 # install the GIMP

The `configure' script examines your system, and adapts the GIMP to
run on it. The script has many options, some of which are described in
the generic instructions included at the end of this file. All of the
options can be listed using the command `./configure --help'. There
are six commands special options the GIMP `configure' script
recognizes. These are:

  1. --enable-shared and --disable-shared. This option affects whether
     shared libraries will be built or not. Shared libraries provide
     for much smaller executables, but they are difficult to debug
     with. If you are interested in doing development, it is probably
     wise to specify `--disable-shared'. The default is to enable
     shared libraries.

  2. --enable-debug and --disable-debug. This option causes the build
     process to compile with debugging enabled. If debugging is
     disabled, the GIMP will instead be compiled with optimizations turned
     on. The default is for debugging to be disabled. NOTE: This
     option is intended primarily as a convenience for developers.

  3. --enable-ansi and --disable-ansi. This options causes stricter
     ANSI C checking to be performed when compiling with GCC. The
     default is for strict checking to be disabled. NOTE: This option
     is intended primarily as a convenience for developers.

  4. --enable-gimpdir=DIR. This option changes the default directory
     the gimp uses to search for its configuration files from ~/.gimp (the
     directory .gimp in the users home directory) to DIR.

  5. --with-libtiff=DIR. This option specifies the location of the
     tiff library and header files. For instance, the libtiff library
     may reside in "/usr/local". This may be specified by
     --with-libtiff="/usr/local". (Note: The compilation process
     should automatically find the tiff library if it resides in
     "/usr/local").

  6. --with-libjpeg=DIR. This option specifies the location of the
     jpeg library and header files. For instance, the libjpeg library
     may reside in "/usr/local". This may be specified by
     --with-libjpeg="/usr/local". (Note: The compilation process
     should automatically find the tiff library if it resides in
     "/usr/local").

The `make' command builds several things:
 - The libraries `gtk+/glib/libglib.la', `gtk+/gdk/libgdk.la',
   `gtk+/gtk/libgtk.la', `libgimp/libgimp.la', `libgimp/libgimpi.la' and
   `libgimp/libgimpui.la'. The `.la' suffix is used by libtool, the
    program used to ease the compilation of shared libraries on
    different platforms.
 - The test programs `gtk+/glib/testglib' and `gtk+/gtk/testgtk'.
 - The plug-in programs in the `plug-ins' subdirectory.
 - The main GIMP program in `app/gimp'.

The `make install' commands installs the glib, gdk and gtk header
files and libraries, the gimp header files associated with libgimp and
the libgimp library, the plug-ins, and the GIMP executable. After
running `make install' and assuming the build process was successful
you should be able to run `gimp'.


      Generic Instructions for Building Auto-Configured Packages
      ==========================================================


To compile this package:

1.  Configure the package for your system.  In the directory that this
file is in, type `./configure'.  If you're using `csh' on an old
version of System V, you might need to type `sh configure' instead to
prevent `csh' from trying to execute `configure' itself.

The `configure' shell script attempts to guess correct values for
various system-dependent variables used during compilation, and
creates the Makefile(s) (one in each subdirectory of the source
directory).  In some packages it creates a C header file containing
system-dependent definitions.  It also creates a file `config.status'
that you can run in the future to recreate the current configuration.
Running `configure' takes a minute or two.

To compile the package in a different directory from the one
containing the source code, you must use GNU make.  `cd' to the
directory where you want the object files and executables to go and
run `configure' with the option `--srcdir=DIR', where DIR is the
directory that contains the source code.  Using this option is
actually unnecessary if the source code is in the parent directory of
the one in which you are compiling; `configure' automatically checks
for the source code in `..' if it does not find it in the current
directory.

By default, `make install' will install the package's files in
/usr/local/bin, /usr/local/lib, /usr/local/man, etc.  You can specify
an installation prefix other than /usr/local by giving `configure' the
option `--prefix=PATH'.  Alternately, you can do so by changing the
`prefix' variable in the Makefile that `configure' creates (the
Makefile in the top-level directory, if the package contains
subdirectories).

You can specify separate installation prefixes for machine-specific
files and machine-independent files.  If you give `configure' the
option `--exec-prefix=PATH', the package will use PATH as the prefix
for installing programs and libraries.  Normally, all files are
installed using the same prefix.

`configure' ignores any other arguments that you give it.

If your system requires unusual options for compilation or linking
that `configure' doesn't know about, you can give `configure' initial
values for some variables by setting them in the environment.  In
Bourne-compatible shells, you can do that on the command line like
this:
        CC='gcc -traditional' DEFS=-D_POSIX_SOURCE ./configure

The `make' variables that you might want to override with environment
variables when running `configure' are:

(For these variables, any value given in the environment overrides the
value that `configure' would choose:)
CC              C compiler program.
                Default is `cc', or `gcc' if `gcc' is in your PATH.
INSTALL         Program to use to install files.
                Default is `install' if you have it, `cp' otherwise.
INCLUDEDIR      Directory for `configure' to search for include files.
                Default is /usr/include.

(For these variables, any value given in the environment is added to
the value that `configure' chooses:)
DEFS            Configuration options, in the form '-Dfoo -Dbar ...'
LIBS            Libraries to link with, in the form '-lfoo -lbar ...'

If you need to do unusual things to compile the package, we encourage
you to teach `configure' how to do them and mail the diffs to the
address given in the README so we can include them in the next
release.

2.  Type `make' to compile the package.

3.  Type `make install' to install programs, data files, and
documentation.

4.  You can remove the program binaries and object files from the
source directory by typing `make clean'.  To also remove the
Makefile(s), the header file containing system-dependent definitions
(if the package uses one), and `config.status' (all the files that
`configure' created), type `make distclean'.

The file `configure.in' is used as a template to create `configure' by
a program called `autoconf'.  You will only need it if you want to
regenerate `configure' using a newer version of `autoconf'.