Another idea is to just apply the current operation on the
x+Tx*i,y+Tx*i position too, and skip the tiled view. This might be
easier.
I think it's harder, since all ops have to be replicated that way, including
filters etc
On the other hand, having brushes work modulo the image size might be
1. Draw first attempt at tile
2. Image-Transforms-Offset
2a. Hit Offset by x/2 y/2 etc.
3. Fiddle with any edges revealed by this
It is frequently useful to see how the tile looks when tiled many
times, to reveal any disturbing salient patterns. The above procedure
can only help with the local
Heavens, there's no need to edit the gradient file manually. You can
easily use the colorselector the gradient editor supplies to set the RGB
values independant of the alpha value, to make RGBA 1.0, 1.0, 1.0, 0.
This is embarrassing, I had actually not found that colour editor before.
Thank
Below is a patch to add support for saving TGA files upside down.
Although it sounds strange to do, it is a supported feature of the
file format and OpenGL expects its textures to be upside down. Support
already exists for reading such files but it was impossible to save
them.
As far as I know
o is it legal to save an xpm image in not-indexed format?
XPM is an indexed file format that happens to supports very large palettes,
so you can save any RGB image as XPM. It is impossible to know whether an
XPM image was saved as an RGB image or an indexed one (or even greyscale),
but a
GIMP cannot read 16 bit TGA files. Has anyone a patch?
I just wrote a TGA reader for the SDL library, including 16-bit reading.
The only hard part was finding valid 16-bit images for testing it; after
some searching I found some kind of budget Windows program (I think it
was called paint pro
While we are on it, could someone please check that all Perl scripts
register menu names with trailing dots if, and only if, they open a
dialog.
Not a Perl script, but the About... menu entry shouldn't have the ellipsis,
according to most GUI standards, since in this case opening a dialog is an
The Indexed Color Conversion dialog is far too wide (~1200 pixels) because of
the warning at the bottom. For some reason the label doesn't wrap properly
despite the call to gtk_label_set_line_wrap in convert.c, perhaps because
the width is not limited. Hard-coding a width is tempting but hardly
But there seems to be no way to do it from a script. I had to resort to
duplicating the entire image and delete the unwanted layers, which seemed
slightly wasteful.
I don't understand, scripts are supposed to ALWAYS work this way, and
you say that there's no way to do it? If you save a layer
TGA and XCF both have INDEXED modes, so you can save TGA or XCF from
an INDEXED image, you *should* be able to save INDEXED PNGs with an
alpha channel, but I only recently checked in the functionality to
do that, and doubtless you have an older version of Gimp.
This is 1.1.19. From png.c:
TGA and XCF both have INDEXED modes, so you can save TGA or XCF from
an INDEXED image, you *should* be able to save INDEXED PNGs with an
alpha channel, but I only recently checked in the functionality to
do that, and doubtless you have an older version of Gimp.
Sorry for my earlier message; I
IMHO using X makes much more sense than abusing the filesystem.
Both ways of doing it (that were discussed so far) won't work on non-UNIX
platforms anyway, so I guess we can safely rely on X for this feature.
The problem with using X is that the xterm where "gimp filename" is invoked
is not
Most SysV shm applications (XFree86, Gnome, SDL) work fine without any
modification, but gimp pukes and gives the error :
** ERROR **: could not attach to gimp shared memory segment
shm IDs are removed immediately at IPC_RMID instead of when the last user
detaches the segment. This is how most
17/plug-ins/common/xwd.c.orig Sun Feb 27 17:32:13 2000
+++ gimp-1.1.17/plug-ins/common/xwd.c Sun Feb 27 18:36:29 2000
@@ -1,7 +1,7 @@
/* The GIMP -- an image manipulation program
* Copyright (C) 1995 Spencer Kimball and Peter Mattis
* XWD reading and writing code Copyright (C) 1996 Peter Kirch
[ correct description of the patch ]
The only problem I see with this patch are badly written file_plug_ins
that don't provide a magic header but a bunch of extensions since the
patch would significantly enhance the possibility that the wrong loader
is used.
Grepping for
Anyway, if the user finds that an application doesn't try to load a file
whose name ends in .tga as a Targa file (or worse, attempts to load it as
a Group 3 fax file), then the same user will assume that the application,
or its programmers, or both, are stupid beyond belief. And rightly so
"New" Targa files have a magic string at the end of the file[1], plus
a bunch of extra information. The Targa specification tells you how
and where to expect it. It does says that for old files you are
basically screwed :-(
I know that, but since a) the Gimp magic pattern language doesn't seem
Targa files have no magic header, and cannot be reliably identified that way.
The TGA plugin tried to register some nonsense magic string which didn't work
anyway, and any attempt to load a TGA file without explicitly selecting the
load format will usually cause gimp to handle it as a group 3 fax
18 matches
Mail list logo
