Re: View shrink factor

2001-02-13 Thread Marc Lehmann

On Tue, Feb 13, 2001 at 04:01:00PM +, Austin Donnelly [EMAIL PROTECTED] wrote:
 I modified the original code to handle non-integer scale factors.  It
 lives in image_render.c

When Daniel and I did our profiling just after the gimpcon we found that
the bottleneck were not really the paint functions but small things like
repeatedly calling methods like drawable_bpp which were just one line and
similar cases. We commited to do a lot of profiling but I don't think anybody
did ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl hang

2001-02-13 Thread Marc Lehmann

On Tue, Feb 13, 2001 at 12:34:18PM -0500, Zachary Beane [EMAIL PROTECTED] wrote:
 I'm using CVS, and it's hanging the build at:

hmm... the only thing I can currently imagine is the regex bug in 5.005_02
and _01. (But that should be chacked). Are you using 5.004? Maybe this bug
is also present in 5.004.

If it is 5.005_03 I have no idea. Could you run the script usign the same
arguments and the -d switch (you will then get a debugger prompt). Just
enter "t" for trace and then "c" for continue. You can then see wether it
runs in circles or just freezes at a specific point.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimp.themes.org ideas

2001-02-05 Thread Marc Lehmann

On Sun, Feb 04, 2001 at 10:17:36PM -0800, "Carl B. Constantine" [EMAIL PROTECTED] 
wrote:
 I think the plug-ins and scripts should also go here, if this site is to be
 created. Otherwise, better organization and keeping things current at
 gimp.org would be appreciated.

We have:

registry.gimp.org - maybe soon to be revamped, web-repository
plugins.gimp.org  - home for plugins, no web-repository

Before adding a third repository (or maybe while adding a third one) we
should first combine efforts, even if this means to just give up one or two,
or totally change their goal.

Distributing scripts over two or more sites, for example, is IMHO bad. IT
might be an evulutionary process, but at first this means users would need to
look at both places.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED]  |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Color calibration in X

2001-01-17 Thread Marc Lehmann

On Tue, Jan 16, 2001 at 01:18:42PM -0500, oliver [EMAIL PROTECTED] wrote:
   Looking at Xcms manpages, I'm not entirely clear on what it's goal in life
 is. It seems to lack any mechanism for converting arbitrary rgb data like a

Well, you can convert rgb to other colourspaces (and vice versa and even
weirder things), so it is certainly possible to do that.

 That is, is it possible to do anything meaningful with
  ICCs under X?

   Windows? Photoshop ;) I don't know what the focus of the gimp is, but color

Windows has been ported to X? Any pointers? ;) (sorry, had to...)

   I wonder what the impact would be on performance, ignoring Xcms stuff, to

Why ignore Xcms? It is a fairl extensive API. under-used, maybe buggy, but
nobody knows.

 do a 3x3 matrix transform on every pixel before displaying it. With luts I
 guess this amounts to three look ups and two adds per component per pixel,
 or something like that, which seems pretty cheap.

Patches welcome (oh yes). Also, "just grabbing icc profiles" is easier
said than done, since there are a lot of patent issues around colour
conversion/calibration/matching.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: retrieving available font list via Gimp-perl

2001-01-14 Thread Marc Lehmann

On Thu, Jan 11, 2001 at 01:25:36AM -0600, Rick Bradley [EMAIL PROTECTED] wrote:
 generate images on the fly.  Currently I am hardcoding the names of
 fonts into a list in the script (or allowing them to be passed as

Just use xlsfonts and pray. That's what everybody uses. Times will get
very bad when gimp supports truetype fonts but the Gtk requestor in
plug-ins doesn't know them ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gauss_rle bad error (indexed image)

2001-01-14 Thread Marc Lehmann

On Thu, Jan 11, 2001 at 10:22:04PM -0600, Rick Bradley [EMAIL PROTECTED] wrote:
 I've run into a problem with gauss_rle and perl-called script-fu's in
 Gimp 1.1.29.

You might try to upgrade. The communication with script-fu from other
plug-ins was broken until very, very recently, and I am not sure it works
correctly now. It is unlikely to be a problem with perl as it proved to
never be the problem so far (and it works with everything else).

  - On those script-fu's which internally use gauss_rle I get the
 following error in the server output log:

Try to call Gimp::set_trace(Gimp::TRACE_TYPE) before the call to script-fu
and check the arguments. If these are correct then you might fail for the
corruption bug in libgimp or something new.

(It could also be a bug directly in the scheme interpreter, but I think
that's unlikely)

However, it might also be a bug in the script-fu script. Sicne there is
no form of type-checking it is very customary for script-fu scripts to
only work directly after starting the gimp, or when certain conditions are
met. For example, it could pass in a layer id instead of an image id.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Color calibration in X

2001-01-14 Thread Marc Lehmann

On Fri, Jan 12, 2001 at 01:30:22PM -0500, oliver [EMAIL PROTECTED] wrote:
   I was curious, how much support does X have for useful color calibration?

A lot. It depends on the server, and xfree does not do much. Basically, the
best you can do is to code it in your application.

However, you can calibrate your card/monitor combination and tell your
X-server about it, after which applications can query all neceessary
parameters (and do calulcations) with Xcms. Gimp does not implement this
yet.

   I know that 4.0 adds gamma adjustment.

Hmm, how is this "added" gamma adjustment different to the gamma
adjustment in 3.x? ;)

 What about the coordiantes of the white point and primaries?

You can set them using properties on the root window, which Xcms
uses. Look for Xcms and XDCCC.

   That is, is it possible to do anything meaningful with ICCs under X?

Poissible, yes, but not in practice (I don't know of any programs that
evaluate icc profiles, and no useful program that evaluates these).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: executing gimp-perl in CGI environment

2001-01-11 Thread Marc Lehmann

On Thu, Jan 11, 2001 at 06:57:55AM -0600, Rick Bradley [EMAIL PROTECTED] wrote:
  wallace.pl: protocol error (1) at
  /usr/lib/perl5/site_perl/5.6.0/i386-linux/Gimp/Net.pm line 66. (ERROR)
 
 The protocol error message makes me think you may not have a recent
 Gimp.  Fix the first problem and see if this error still persists.  If

This might be the case, but most often the problem is that there is no
connection or the connection gets closed immediately. Most often, this is
caused by not making a connection at all, for Apache::Registry, the usual way to do
that would be:

BEGIN { Gimp::init }

(in cgi you can do without the BEGIN {})

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl script in gimp for Windows : is it possible ?

2001-01-05 Thread Marc Lehmann

On Fri, Jan 05, 2001 at 11:13:00AM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
 of people who don't care building GLib or GTK+, but do want to build
 *other* GTK+ applications. They are the the ones that sometimes ask
 "where is gtk-config?".
 
  (c:\gnu\gtk+ required ;)
 
 If it only was so easy... I can easily imagine that a potential GTK+

But wouldn't it be possible to make a gtk-config.bat? Given the
estristcion to use the same compiler as used to build gtk+ this should be
easily doable.

  yes, but msvc isn't and when you pick, e.g. activestate as your perl then
 
 Umm, huh? Gcc-produced code (from C source) is binary compatible with
 MSVC-produced. (As long as you use the -fnative-struct switch to gcc.)

The problem is that the compilers themselves are not compatible:

- msvc lacks good C support (long long), so perl might define I64 as __long or
  something which gcc might glady ignore :(
- gcc uses different commandline syntax, so whatever gtk-config outputs might
  not be soemthing that the compiler likes.
   
 OK, great. I will first try to get Gimp-Perl running without Gtk-Perl
 then.

Just hammer bugs on me and I'll (try to) fix them ;) Thanks!

 configure, and libtool on Win32. At least it's much faster. You can
 imagine how slowly auto* and libtool run on Win98, or cygwin hosted on
 Win98 even.

No, I can't, although I heard that the fork-emulation would be slow.
However, running configure for gimp on unix takes too long, so but
usually my machine is too slow ;)

 (PS. When I considered using a Perl running under cygwin, I was on the
 wrong track. Cygwin is its own operating system in a way, so using
 cygwin-hosted tools to build for Win32 is a cross-compilation. It
 isn't possible to cross-compile Perl modules, is it?)

Well, perl modules use whatever they are told by ExtUtils::MakeMaker,
which could be abused to do cross-compiling. But just like configure, most
modules will want to run the resulting exectables, which is not possible
with a cross compile, so it WILL be easier to not even try it.

But mingw32 + cygwin (for the shell utils only) should work, no?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl script in gimp for Windows : is it possible ?

2001-01-04 Thread Marc Lehmann

[Note: I CC:'ied this as well as tor's original mail to the current gtk
maintainer, which is Paolo Molaro [EMAIL PROTECTED]]

On Fri, Jan 05, 2001 at 01:33:42AM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
 Well, I spent a few hours on it yesterday, and some more again today,
 but it does seem quite hard, or at least tedious. There are several

Certainly there are different grades of difficulty. I'd choose a
cygwin-ported perl, as the makefile that _that_ perl generates can be very
unix-like (gnu-make) and calling the shell is no problem, either.

The most difficult one would indeed be activestate (the dominant perl),
since activestate is ported closely to windows (it is the "better" port in
that sense) and all of the extension problems (e.g.) get real, although
the makefiles that perl itself generates should be fine.

 - Makefile.PL wants to use gtk-config. No such on Win32. (How could
   there be one? On Win32, people typically don't build GTK+
   themselves, but fetch the headers and libraries

The same, of course, is true for the gimp. most people who build gimp
would be able to build gtk as well ;)

In any case, gtk-perl does, indeed, use a lot of unix functionality so
building that one without cygwin will require !CHANGES!.

 - ActiveState's Perl is built with MSVC. Its MakeMaker thus produces a
   Makefile for nmake, that uses cl to compile and link to link. Oh
   well, that is not so bad in itself, I have MSVC available at work,
   and, ehh, I might have a copy at home also.

This is, of course, not solvable in any case. Changing the compiler means
that all the autodetected stuff goes wrong. This also means that the
compiler used to build gtk+, gimp, gtk-perl and gimp-perl must be the
same. We have a lot of problems with this (obvious for me but not others
it seems), e.g. on IRIX where the preinstalled perl is compiled with the
commercial sgi compiler but most people only have access to gcc (which is
not compatible).

   #defines and stuff to hide the GLib versions. Unfortunately there
   are lots of those .xs files that need to have the same stuff
   inserted. Oh well, just manual work.

The better option IMHO would be to make glib (source available!)
compilable against perl, as a compatibility measure on win32. I am not
sure qwether sources for activestate's port are available and even if, it
requires a non-free compiler.

 - Some X11-backend specific stuff present in Gtk-Perl. Have to #ifdef
   those out, but in a way that is still compatible with GTK+ 1.2,
   which didn't have several backends, and doesn't define
   GDK_WINDOWING_X11. Gtk-Perl also uses some GDK functions that don't
   exist any longer.
 
 At this point I bailed out again... I have better things to do, like,
 eh, sleep?

If you have patches, I am quite sure the gtk-perl people will be very
intereste din them, even if they only partially solve the problem by
making it compile for example.

 Maybe it would be better to use a Perl running on cygwin? That would
 help a couple of the issues above.

Certainly. Also not concentrating on gtk-perl but instead on gimp-perl
would also help.

During the run for gimp-1.2 I introduced a lot of unix-things (like
"test2) in gimp-perls makefile, but these are mostly limited to
installation (Especially po, which is not a concern for the gimp
distribution).

OTOH, the main gimp makefile also uses test and a lot of unix-things. Is
gimp not build using autoconf on win32?

 and make sure I am not duplicating somebody else's work in progress,
 and to ask if he has done any more work on Gtk-Perl since 0.6123. (This

There was, however, I am quite sure nobody ever tried to port it to
win32. At least not to a non-unix-like target (mingw32 or msvc).

 (I am not promising that I will hack any more on Gtk-Perl on Win32
 anytime soon...)

This is fine ;) Even trying to build and fail (and you did more) should
be very helpful to them I think. Just as I would expect that somebody who
tried to build gimp-perl on win32 would end up saying "it bails out during
Makefile.PL because it calls ./configure", and I would be happy with that
;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __ ____  __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl script in gimp for Windows : is it possible ?

2001-01-04 Thread Marc Lehmann
ions found in the CPAN sites.  See LUsage
   Hints below for general hints about this.

I think thsi sounds like the right perl to use. IT can also be configured
for different make flavours.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: GIMP 1.2.0 DESTDIR patch

2001-01-01 Thread Marc Lehmann

On Mon, Jan 01, 2001 at 08:59:51AM +0100, Marco Lamberto [EMAIL PROTECTED] wrote:
 not just fix the package manager? ;-
 Eh, eh, I know this old story, not everybody loves RPM but, on my own, I think
 it's extremely useful (if you write a decent specfile) not only for novice

It is (and rpm per se does not require DESTDIR anyway), but I somehow
question the the usefuleness of changing each and every package for .rpm,
.deb, .slp, .tgz, gcc-2.96 variants of ome distributors etc

(So, nothing specific against rpm, jsuta aginst having to modify the
packages, even if it is easier for many packages ;)

 Why do you disable the installation of the perl-translation tables? If
 Yes, I've forgotten to underline this fix. I've modified ONLY this line in the
 perl plug-in dir because the "po" files are installed by the main Makefile, so

This is not good. Can you outline what needs to be changed (since I, in my
endless dumbness, can't find it and gimp does not compile for me at the
moment).

 the main Makefile would have required changes also into the perl/po Makefile,
 while my main goal was to let the perl stuff almost unchanged.

I can understand this, however I am quite in favour of fixing more cruft
and build anomalies, there are a lot of them (o.k., decreasing..) ;)

  +  local_target="PREFIX=$(DESTDIR)$(prefix) 
gimpplugindir=$(DESTDIR)$(gimpplugindir) $$local_target"; \

Oh, now I can see the problem. You use the same prefix as gimp (do
you?). This will produce severely broken rpms unless the gimp prefix
equals the perl prefix, which somehow makes the whole exercise superfluous.

Do not use the gimp's prefix, otherwise your rpm's will only run on
unmodified standard redhat systems where gimp is installed in /usr/bin.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: GIMP 1.2.0 DESTDIR patch

2001-01-01 Thread Marc Lehmann

On Sun, Dec 31, 2000 at 05:31:24PM -0500, Kevin Cozens [EMAIL PROTECTED] wrote:
 should be. I am also trying to decide where scm2scm and scm2perl belong.
 Should they be in gimp and gimp-perl respectively, or gimp-devel for both?

scm2scm should go into gimp-devel, as it only requires perl, not
gimp-perl, scm2perl should go into gimp-perl-devel, so you can choose on
your own (I recommend gimp-perl).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: GIMP 1.2.0 DESTDIR patch

2000-12-31 Thread Marc Lehmann

On Sat, Dec 30, 2000 at 03:32:21PM +0100, Marco Lamberto [EMAIL PROTECTED] wrote:
 Please check the patch and _please_ merge those changes in order to build again
 easily and RPMmed GIMP. ;)

Instead of requiring special rpm support for each and every package, why
not just fix the package manager? ;-

Anyway, I am pleased but astonished that it works without a flaw in the pelr
subtree, however:

 - cd po  \$(MAKE) install
 +#cd po  \$(MAKE) install

Why do you disable the installation of the perl-translation tables? If
there is another makefile doing the make install, do you know which one it
is (so it can be fixed)?

 + if test ! -z "$(DESTDIR)"  test ! -z "$(GIMP_PERL)"  test 
"$$subdir" = "$(GIMP_PERL)"; then \
 + local_target="PREFIX=$(DESTDIR)$(prefix) 
gimpplugindir=$(DESTDIR)$(gimpplugindir) $$local_target"; \

Nifty ;)

(Anyway, it does look good at least to me ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimp 1.2.0--a few questions

2000-12-28 Thread Marc Lehmann

On Thu, Dec 28, 2000 at 06:42:40PM +0530, Chetan Dhavse [EMAIL PROTECTED] wrote:
 Subroutine gimp_text_get_extents_fontname redefined at 
/opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/Gimp.pm line 539.
 Subroutine gimp_bucket_fill redefined at 
/opt/other/src/perl-5.6.0/lib/site_perl/5.6.0/i686-linux/Gimp.pm line 539.
 
 Sorry but I am lost. The same warnings are for almost all the function

this is very strange but is most probably a problem with your script
(double fork or something similar) - how do you start your script, and can
you send a stripped-down version of your script that shows this error?

 The plug in "plug_in_autocrop" gives the following error if I use
 plug_in_autocrop(1,$img,$layer); (as mentioned in DB browers)

Certainly this is nowhere mentioned in DB browers, where did you get the "1"
from? Hardcoding constants is going to bite you. Either use
RUN_NONINTERACTIVE (or RUN_INTERACTIVE) or, better, just leave our the
unnecessary arguments, e.g.:

plug_in_autocrop($img,$layer);
plug_in_autocrop($layer);

or even

$layer-autocrop;

 but works fine if I use
 
 plug_in_autocrop(1,$layer);

Because 1 happens to be a valid image id. The first agrument is the
run_mode, which must be on the the three symbolic RUN_*-constants. The
second agrument must be an image and the third a layer. It happens thta
you can leave out the first two agruments, since they are redundant (no
runmode == noninteractive and a layer always belongs to some image).

This could also solve your problems above, since 5.6.0 is rather broken
with regards to error handling (this has been fixed in later snapshots, so
best use 5.005_03 or a current perl snapshot if you want sensible error
reporting) so the above could just be the effect of a runtime error that
doers not get reported but instead garbles perl's internal state.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: cmon guys, no patch from 1.1.32 to 1.2??

2000-12-25 Thread Marc Lehmann

On Tue, Dec 26, 2000 at 04:03:42AM +0900, [EMAIL PROTECTED] wrote:
   Why not use CVS and tags? Makes life much easier for both sides. 
 
 
 Because
 a) my bandwidth is limited

You can use -z9 with cvs, which means the transfer size is not larger than
downloadign a normal diff.
 Therefore, downloading a 200k patch is a lot easier than getting a
 cvs-able gimp tree that I can update TODAY.

Why not generate a patch using rdiff -u or something like that?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: divide by 255

2000-12-21 Thread Marc Lehmann

On Wed, Dec 20, 2000 at 08:19:01PM +, Nick Lamb [EMAIL PROTECTED] wrote:
 Eerily similar to your hack and to the one from Marc. For me (PII 300,
 AMD Duron 700) and for the other hackers on that Moz bug who checked
 it _was_ faster than the GCC emitted alternate, but Marc's numbers

Oh, one thing: did you use unsigned integers? signed integers *are* much
slower since they need adjustments all over.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



mail problem

2000-12-21 Thread Marc Lehmann

It seems that I am unable to send mail to gimp.org anymore:

  [EMAIL PROTECTED]|[EMAIL PROTECTED]|[EMAIL PROTECTED]
SMTP error from remote mailer after RCPT TO
host mail.gimp.org [128.32.45.176]: 550-See URL:http://mail-abuse.org/dul/
550 mail from 193.159.127.206 rejected: administrative prohibition


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: divide by 255

2000-12-20 Thread Marc Lehmann

On Wed, Dec 20, 2000 at 02:34:19AM -0600, Federico Mena Quintero 
[EMAIL PROTECTED] wrote:
 Anyways, in libart and gdk-pixbuf we have code like this to composite
 an RGBA image over an RGB pixel:
 
   dest[0] = r2 + ((tmp + (tmp  8) + 0x80)  8);

Warning!

Here is a formula I just came up with (about the same as above, actually,
but without rounding errors):

x = ((n8) + n + 257)16;

It works over the full range (n = 0..65535; x = 0..256) and is always
exact.

However, this optimization is not as important as you might think, as gcc
already uses exactly this technique, however, gcc uses a multiplication
since gcc's formula has to work over the full unsigned int range ;)

For n/255, gcc does this on x86;

   movl %ebx,%eax
   mull .LC0 ; = 0x80808081
   movl %ebx,%eax
   sall $8,%eax

While my formula boils down to:

   shrl $7,%edx
   leal 257(%ebx,%eax),%eax
   shrl $16,%eax

In practise, gcc's code is faster if enough registers are available
(p-ii/iii), and usually not slower. It is also correct over the full
range.

So think twice before starting to "optimize" this division.

(And always remember to use UNSIGNED variables where applicable, since
these are much faster).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: RFC: The future of The GIMP

2000-12-18 Thread Marc Lehmann

On Mon, Dec 18, 2000 at 03:56:55PM +0100, Fernando Herrera [EMAIL PROTECTED] 
wrote:
 Unix vendors as HP-UX, Solaris and AIX are dropping CDE towards GNOME), but
 GNOME optional support will be very interesting. For example:

It will be very easy to make a gnome-frontend for gimp-2.0, as it will be
modular enough to be used in about any environment.

I am also quite sure that the regular gimp hackers will help with the
gnome frontend (as opposed to kde, since most people know gtk and maybe
gnome but not kde).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: suggestion for gimp 1.3 and later

2000-12-12 Thread Marc Lehmann

On Wed, Dec 13, 2000 at 12:27:42AM +0100, "Guillermo S. Romero / Familia Romero" 
[EMAIL PROTECTED] wrote:
 It is one of the things I dislike of GUI: you can not copy info from
 screen lots of times. In the GNOME GUI list there is a proposition to

I think the best way would be to make any gtk label/text widget be
selectable. I don't know why this has not been done so far, but it might be
an interesting experiment.

I, for one, always wondered why there is text that I cannot select. Except
that it might be easier for the programmer to implement I don't think this
serves a purpose (well, maybe less memory, but...)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: repetitive stress . . .

2000-12-12 Thread Marc Lehmann

On Tue, Dec 12, 2000 at 09:46:21PM -0500, Andy Deck [EMAIL PROTECTED] wrote:
 The attached image demonstrates a problem
 that I think ought to be remedied...

Basically, when the disk is full, there is not much one can do. BTW: what,
*exactly*, is your problem?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 2-D Gradients

2000-12-08 Thread Marc Lehmann

On Fri, Dec 08, 2000 at 07:49:38AM -0500, "Garry R. Osgood" [EMAIL PROTECTED] wrote:
  What is the Red Book? Where can I find it? What is its ISBN?
 
 PostScript(r) Language Reference  by Adobe Systems Incorporated
 Paperback - 912 pages 3rd edition Bk  cdr edition (February 26, 1999)
 Addison-Wesley Pub Co; ISBN: 0201379228

Download it here:

http://partners.adobe.com/asn/developer/technotes.html

;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [PATCH] improving on i18n

2000-12-05 Thread Marc Lehmann

On Tue, Dec 05, 2000 at 05:34:18PM +0100, Zbigniew Chyla 
[EMAIL PROTECTED] wrote:
  Probably a good idea, but I doubt we can count this as a bugfix. We 
  should consider integrating a fix like this after the 1.2 release.
 
 This patch _fixes_ GIMP translations. Currently it's _impossible_ to

And givne that a large amount of similar fixes went into the gimp not too
long ago this patch really should be considered.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Problem with perl-plugin (script-fu rip off)

2000-12-05 Thread Marc Lehmann

On Tue, Dec 05, 2000 at 08:54:44PM +0100, "Thomas S. Iversen" [EMAIL PROTECTED] 
wrote:
 ... and on a related note, I can't seem
 to get Gimp-file_png_save($img,-1,) to work
 or   file_gif_save()

maybe because -1 is not a valid drawable. Use a layer here (e.g.
"($img-layers)[0]") and it should work.


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Compile error

2000-12-01 Thread Marc Lehmann

On Fri, Dec 01, 2000 at 10:50:19AM -0500, Mathieu Dubé [EMAIL PROTECTED] 
wrote:
 I was using gcc-2.8.1 I switched to 2.95 and I still have the same error when
 it compiles CML_explorer.c
   :gcc: Internal compiler error: program cc1 got fatal signal 6

This is a bug in the compiler and should be reported to [EMAIL PROTECTED]

However, does this happen at the same file and line all the times (does it
output some more messages or just the quoted line)?

[it is safe to rpely in private]

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Gimp-Perl fails to build.

2000-11-18 Thread Marc Lehmann

On Sat, Nov 18, 2000 at 04:54:39PM +0100, Simon Budig 
[EMAIL PROTECTED] wrote:
 checkout of the gimp. Gimp-perl compiled and - after doing a separate
 make install as root in plug-ins/perl it worked.
 (BTW: Why is gimpdoc installed in /usr and not in my PREFIX?)

See README.perl. It's where you told perl to install extensions.

 However, in the desire to keep up to date  :-)  I did an cvs update
 and typed make in the top level source dir.

 Makefile out-of-date with respect to Makefile.PL
 Cleaning current config before rebuilding Makefile...
 make -f Makefile.old clean  /dev/null 21 || /bin/sh -c true

this shouldn't happen. what were the exact commands you entered before the
make?

 configure: warning: ** unable to find gimp
 ./configure: no: command not found
 ./configure: no: command not found
 ./configure: test: -lt: unary operator expected

now *that* is strange ;)

 What is happening here? Why does the second build suddenly depend on an

It tries to build as a standalone perl extension (so it tries to find the
gimp). This should not happen as the top-level configure script tells it
not to do so.

Did you configure the gimp tree without perl? What did you do to enable
gimp?  Did you do make distclean and re-run autogen.sh?

 Marc - could you please fix this behaviour so that people with zero
 knowledge about the Gimp-Perl build process could conveniently build

It works for other people, actually, without any knowledge. The problems
only start when people replace Makefiles in the perl directory, usually ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [gimp-devel] Re: Gimp-Perl fails to build.

2000-11-18 Thread Marc Lehmann

On Sat, Nov 18, 2000 at 07:59:17PM +0100, Simon Budig 
[EMAIL PROTECTED] wrote:
  See README.perl. It's where you told perl to install extensions.
 
 Hmm - IMHO at least for these additional files (not the module itself)
 the option specified at the top level ./configure should be inherited.

configure does not have such an option at the moment.

 From README.perl I learn that I have only the chance to set one prefix.
 Wouldnt this install the Gimp-Perl module in /unstable (in my case)
 and perl would not find the module?

The whole point of ignoring the gimp prefix is that using it will create
a non-working end-result in about 100% of the cases where the prefixes
disagree. So if you want to have gimp-perl installed somewhere else you
should better be prepared to cope with that and most people are not.

 BTW: The Perl installation happily installs the man-pages to
 /usr/local/man/man?   while the scripts gimpdoc and xcftoppm
 reside in /usr/bin. This is inconsistent.

This is strange and probably has nothing to do with perl's idea of the
prefix. Which configure options did you use? I suspect that this relates
to the othewr problems you did encounter (since gimp-perl is utterly
confused on your system at the moment I would expect it to do very strange
things).

 make
 make install
 
 perl was OK at this time.
 
 (today after major changes in app/)
 cvs update
 make

This is very strange. Did configure.in or similar files chgange and you
didn't re-run autogen.sh and make distclean?

 I am not sure, if the make re-invoked the top-level configure script.

that should work (it normally does). the question is what triggered this.

 Checkout. Normally the make re-invokes the autogen.sh script when it
 is necessary.

I've never seen this and I really doubt that autogen.sh will be run
automatically. AFAIK you have to re-run autogen.sh manually after
configuration changes (basically you have to re-run it always, but you get
away with it 99% of the time, otherwise we'd all run autogen.sh for the
whole time).

 Ok, but this time I did not yet mess with the Makefile...

Yeah, I believe you. Tell me if the problems persist after make distclean
and re-running autogen.sh. If they do, we need to fix this ASAP.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [gimp-devel] Re: Gimp-Perl fails to build.

2000-11-18 Thread Marc Lehmann

On Sat, Nov 18, 2000 at 08:12:15PM +0100, Simon Budig 
[EMAIL PROTECTED] wrote:
 I forgot something here: I did this make install as user simon (/unstable
 is mine) and perl of course did not install. I then did an additional
 make install in plug-ins/perl  as root.

The compiletree must of course be accessible during make install - I'll
see wether the additional make install triggered this - however, strange
things can and will happen if a plug-in needs to reconfigure and fails to
do so, and in the case of gimp-perl this is usually catastrophic. Maybe I
can workaround this problem in an easy way, though, this might be really
helpful.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Bug#60647: acknowledged by developer (gimp swap / temp files belong in $TMPDIR or /tmp if $TMPDIR is unset)

2000-11-13 Thread Marc Lehmann

On Sun, Nov 12, 2000 at 09:38:03PM -0500, Brian Ristuccia [EMAIL PROTECTED] wrote:
 To those on gimp-developer:
 
 My gripe is that gimp ignores $TMPDIR, the default location is in my home
 directory which is on a slow NFS mount, and specifying /tmp is unsafe.

Yes, it's almost always better to follow the standard...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: file_gih_save

2000-11-11 Thread Marc Lehmann

On Sat, Nov 11, 2000 at 08:45:09PM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
 Umm, yes ;-) There is a FIXME comment about that... I guess I will

sorry, I somehow totally misinterpreted that comment... hm... ;(

 have to fix it. (You wouldn't happen to have some script-fu around to
 test it with... nah, guess not?)

no, but I have this (this is what I originally used on tehe fair), it
comverts all *tub-files given as arguments to .gih-files.

perl -MGimp -e 'Gimp::init; Gimp::set_trace(-1); for(@ARGV) { \
my $img = Gimp-file_load(($_)x2); s/.tub$/.gih/; \
$img-get_active_layer-file_gih_save(($_)x2, 100, $_); \
$img-delete }' *.tub


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: file_gih_save

2000-11-11 Thread Marc Lehmann

On Sat, Nov 11, 2000 at 11:20:15PM +0200, Tor Lillqvist [EMAIL PROTECTED] wrote:
 file_gih_save. Dunno how it should be called from Perl, but in

About the same, except that you do not need to hardcode values for
constants.

 Obviously, this is not quite what you have in mind. Passing in all the

Yes, it is.

 has been loaded from a .tub file and thus has the
 gimp-brush-pipe-parameters parasite set up already, containing the

Hmm.. in my experience .tub files get loaded as flat images anyway
(saving the files interactively created only very large flat brushes, not
"animations" and I had to edit all the parameters myself), so I wasn't
really aware of the possibility of sensible defaults.

 necessary information. Should the args be ignored in such a case? Or
 should there be a separate PDB function,

good question. gimp really needs a way to specify default arguments. Some
magic value for each argument (e.g. -1 for numbers) would make it possible
to selectively override some arguments.

 file_gih_save_using_parameters_from_parasite or something? I assume
 PDB args can't be optional?

Quite a long time ago I hacked the pdb implementation to allow for
variable number of arguments, so if one left out the checks inside gimp
it should be possible to leave out agruments at the end. Obviously,
most plug-ins would break, though (although perl won't and other
generic-language-interfaces might not, either).

However, this won't help much, as often one wants to leave out something
in the middle, in which case marker values are most useful (NULL for
strings for example, or often -1 for ints).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: strange configure errors with perl in 1.1.29

2000-11-09 Thread Marc Lehmann

On Mon, Nov 06, 2000 at 03:23:32PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
 I suppose that on most other systems, "perl5" is newer or the same as
 "perl", so the current test in configure.in is probably the best
 solution (and it has been like that for more than two years).  You can
 consider this bug report closed.

Well, I wrote that at a time where perl4 was quite common on unix (not
linux), since most vendors ship /usr/bin/perl (4). If anybody has some
data about commercial unixes and their version of pelr shipped (and if
that is perl5) I'd be more than happy to get rid of that uglieness in
favour of the more standard "perl" + "fix your path, pal".

-- 
  -==- |
  ==-- _   |
      ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: GIMP help docs

2000-11-08 Thread Marc Lehmann

On Mon, Nov 06, 2000 at 02:55:39PM +0100, Raphael Quinet [EMAIL PROTECTED] wrote:
   helpbrowser.
 
 Hmmm...  Looks like we need a couple more beta releases before 1.2. ;-)

Simon and me are currently at the Systems'99, and, well, we probably need
a lot of couple of beta-releases ;) gimp seems to have a lot of small
problems like the selection going away after some time and not coming
back, refresh problems (a lot, but difficult to reproduce) on all our
machines, and the return of the "w-src  w-bytes * ..." warning.

I guess most of us just ignore these problems, but just how difficult
would it be to fix this? Are we (simon and me) currently the only ones
having these prblems?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



gimp/gtkrc

2000-11-05 Thread Marc Lehmann

While the .gimp/gtkrc is being used again in the current cvs version, the
plug-ins still don't use it (they used it before).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: build problems from cvs

2000-11-03 Thread Marc Lehmann

On Fri, Nov 03, 2000 at 08:12:07AM +0100, Marc Lehmann [EMAIL PROTECTED] wrote:
 Since quite some time I get spurious errors while building gimp:

sorry, found it (I am not sure that is, I just checked out the build module
in gnome and moved it into the gimp tree. Is that correct??)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Problems with gimp-1.2.28/gtk-1.2.8/perl

2000-10-29 Thread Marc Lehmann

Hi folks... Matthias and me are tracking down severe problems with gimp,
gimp-perl and solaris. While Matthias tracked down a problem with libtool
not working when the locale is != C, the situation became more complicated
now.  It seems that the gimp-libraries (e.g. libgimpui) miss lots of
shared library dependencies and/or the rpath. This explains why this can
be fixed by a "use Gtk" in the main perl script, since this forces libgtk
to be linked into perl.

Any ideas?

On Sun, Oct 29, 2000 at 05:56:52PM +0100, Matthias Kurz [EMAIL PROTECTED] wrote:
  I have rebuilt gtk and gimp with LC_ALL=C and LANG=C. Now
  "ldd libgimpui.so" gives:
  ldd ./libgimp/.libs/libgimpui.so
  libgtk-1.2.so.0 =   (file not found)
  libgdk-1.2.so.0 =   (file not found)
  libgmodule-1.2.so.0 =   (file not found)
  
  The "file not found" doesn't matter, because it's not installed and
  LD_LIBRARY_PATH is not set. _What_ matters is, that libgimpui.so
  now depends on libgtk and so on. This wasn't the case before.
 
 I hate to say it, but this is still not the complete solution :-(
 The "file not found" messages above _are_ serious problems. They appear
 because neither LD_RUN_PATH was set nor -R... was given when libgimpui
 was linked.
 
 Now it becomes complicated.
 LD_RUN_PATH was set, when UI.so was built. But it looks like under
 Solaris _this_ search path is only used to locate libraries that UI.so
 depends _directly_ on. It is used to locate libgimpui.so, for example.
 
 But the dependency on libgtk et all comes from libgimpui.so. So the
 system does not use the search path from UI.so, but the one from
 libgimpui.so. And there was no one given, when libgimpui.so was built.
 
 So i see 3 possibilities
 
 1. You have to add -lgtk -lgdk when UI.so is built. Then UI.so depends
_directly_ on the libs and UI.so's library search path is used.
 2. It's a problem with libtool and libtool should set LD_RUN_PATH or
give -R when it builds the library.
 3. It's a bug in the Solaris runtime linker. It should also use the
search paths "above".
 
 I tend to 2.

O.K. AFAIK solaris ignores LD_RUN_PATH when -R is given. It also seems
highly correct to use libgimpui's rpath, and it also seems that the
problem is only libtool not correctly linking libgimpui, which explains
all this.

 
 The command line to libtool is:
 /bin/sh ../libtool --mode=link gcc  -g -O2 -Wall -L/usr/local/lib -R/usr/local/p
 kgs/lib:/usr/local/lib -o libgimpui.la -rpath /usr/local/pkgs/gimp-1.1.28/lib -v
 ersion-info 28:0:0  -release 1.1 gimpmenu.lo gimpbrushmenu.lo gimpgradientme
 nu.lo gimppatternmenu.lo gimpchainbutton.lo gimpcolorbutton.lo gimpdialog.lo gim
 pexport.lo gimpfileselection.lo gimphelpui.lo gimppatheditor.lo gimppixmap.lo gi
 mpquerybox.lo gimpsizeentry.lo gimpui.lo gimpunitmenu.lo gimpwidgets.lo -L/usr/l
 ocal/pkgs/gtk+-1.2.8/lib -L/usr/openwin/lib -R/usr/openwin/lib -lgtk -lgdk -L/us
 r/local/pkgs/glib-1.2.8/lib -lgmodule -lglib -ldl -lXext -lX11 -lsocket -lnsl -l
 m 
 
 Several -R and one -rpath.
 
 The link line is:
 /usr/ccs/bin/ld -G -h libgimpui-1.1.so.28 -o .libs/libgimpui-1.1.so.28.0.0  gimp
 menu.lo gimpbrushmenu.lo gimpgradientmenu.lo gimppatternmenu.lo gimpchainbutton.
 lo gimpcolorbutton.lo gimpdialog.lo gimpexport.lo gimpfileselection.lo gimphelpu
 i.lo gimppatheditor.lo gimppixmap.lo gimpquerybox.lo gimpsizeentry.lo gimpui.lo 
 gimpunitmenu.lo gimpwidgets.lo  -L/usr/local/lib -L/usr/local/pkgs/gtk+-1.2.8/li
 b -L/usr/openwin/lib -lgtk -lgdk -L/usr/local/pkgs/glib-1.2.8/lib -lgmodule -lgl
 ib -ldl -lXext -lX11 -lsocket -lnsl -lm -lc 
 
 No (visible) LD_RUN_PATH, no -R.
 
 What do you think ? Are you still interested in the problem ?

More than ever. I am seeking professional help now ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling Gimp from web pages.

2000-10-25 Thread Marc Lehmann

On Wed, Oct 25, 2000 at 04:55:09PM -0500, Chris Brown [EMAIL PROTECTED] wrote:
 I maybe a bit confused as to the difference betweent Gimp::Net and
 Gimp::Fu.

Gimp::Fu is a convinience interface to gimp-perl, it provides an easy way
to register functions and to create a simple-but-usable user interface for
most plug-ins. Gimp::Net is just an interface module and is loaded
automatically and on demand, so you do not usually need to use it explicitly.

 Can I call Gimp Functions, (the ones in the DB Browser) while
 just using Gimp::Net or do I also have to include Gimp::Fu?

Both are orthogonal to each other. You can call gimp functions without
Gimp::Fu (and also without Gimp::Net, as the mkain gimp module will
automatically load thew appropriate interface module for you).

 Mostly I need to know if there is a way to run the
 Gimp Perl server without running the Gimp

No.

 itself and without running X, as

No.

 the host machine will not have access to the X server.

Many people use Xvfb or Xvnc on their server machines. The next major
version of Gimp (2.0) will be much more modular (and maybe we will soon be
independent of X due to the freetype plug-in).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: How to convert a .jpg file to a RGB format

2000-10-23 Thread Marc Lehmann

On Mon, Oct 23, 2000 at 01:51:20PM -0400, Vinhthuy T Phan [EMAIL PROTECTED] wrote:
 Hello, thanks for your help.
 
 My goal is to extract an array (each entry is a RGB value) out of a .jpg
 file (for my current project).  The only way I can think of is to save a
 .jpg file in gimp as a RGB format, then read the file and 
 store in an array.  Unfortunately, I dont know how to convert a
 .jpg file to a readable RGB format.

use imagemagick:

convert img.jpg test.rgb

(or test.ppm for human-readable format, or ...)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: How to convert a .jpg file to a RGB format

2000-10-23 Thread Marc Lehmann

On Mon, Oct 23, 2000 at 05:17:40PM -0400, James Smaby [EMAIL PROTECTED] 
wrote:
 Here's how I would do it:
 
 convert picture.jpg picture.ppm
 ppmtorgb3 picture.ppm
 for PICTURE in picture.{red,grn,blu}
   do
   pnmnoraw $PICTURE

 There doesn't appear to be either a jpgtoppm program or a
 ppmnoraw program, but doing it in multiple steps seems to work.

no need, you have convert, so you use it (i.e. something like this

convert picture.jpg -interlace plane rgb:-

but you could also save the channels to different files etc... convetr is
*very* versatile).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: I inform the author ;-)

2000-10-21 Thread Marc Lehmann

On Sat, Oct 21, 2000 at 02:13:33PM +0200, regis rampnoux [EMAIL PROTECTED] wrote:
gimp/plug-ins/perl/
 Warning: the following files are missing in your kit:
 po/Makefile.PL
 po/update.sh

strange, both files are part of the repository (now), but at least
Makefile.PL was temporarily absent.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: configure, libtool the install prefix [2]

2000-10-01 Thread Marc Lehmann

On Sun, Oct 01, 2000 at 09:55:33PM +0200, Marco Lamberto [EMAIL PROTECTED] wrote:
 I haven't fixed yet the GIMP Perl plugins installation, please could anyone fix
 it or tell me a workaround?

The README.perl suggests PREFIX= for just this case. Daniel Egger could
probably get more info as he works for suse and suse has quite a few perl
packages in rpm format (includign gimp-perl).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Using Gimp as HB's imaging library.

2000-09-29 Thread Marc Lehmann

On Thu, Sep 28, 2000 at 11:42:08PM -0500, Alejandro Forero Cuervo [EMAIL PROTECTED] 
wrote:
 I used the Lisp bindings to make Lisp programs that generate images
 through Gimp.  I fell in love with that feature.

gimp has lisp bindings? didn't know that ;)

 to be able to have HB generate images on the fly.  Basically, I want
 them to be able to write Lisp (or it could be Perl) scripts inside the
 HB files and have them handled by Gimp to generate images and use them.

At the moment, perl has by far the best interface to communicate with
already running gimp instances (or starting a new one). It is possible
(but requires coding) to use the perl-server for other languages than
perl, but I that's a serious task.

 For example, they can write some simple Lisp code such that given the
 current day time, Gimp generates a nice image displaying that
 information.  Another example is making Lisp code to display an access
 counter.

You might also want to experiment in writing scripts that would be tacked
onto the comamndline of the gimp (I think there is no way to get arbitrary
scheme scripts executed).

 I briefly looked at libgimp's documentation but couldn't find a
 function to do that.  I don't want to have my C code generate the
 images directly (I mean, I do not want to make my own parser) but
 rather use the parser for Lisp code that comes with Gimp.

AFAIK if there is a lisp plug-in/interface, it does not come with
the gimp. scheme comes close to lisp, so I guess you mean scheme
instead? You can easily write your own scheme script, dump it into your
~/.gimp/plug-ins (using gimptool!) and then restart gimp to use it, if
that suffices for you.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: compile gimp-1.1.26 (error)

2000-09-29 Thread Marc Lehmann

On Fri, Sep 29, 2000 at 09:54:50PM +0100, Dominic Knight [EMAIL PROTECTED] 
wrote:
  Could you send me the output of 
  
 I've had a good play around and fixed gimp-1.1.26 by installing zlib and zlib
 development (is it used for PNG compression ?), either this wasn't required
 previously  as 1.1.25 compile still works or (bear with me),  

I am quite sure that this couldn't be the reason for gimp-perl working
again, so either it was some cruft from earlier releases or the big is
still hiding somewhere.

 I just installed Mandrake 7.1 which was given away free on Linux Magazine
 in the United Kingdom. While it was an install I retained /opt/ directory on my
 HD this is where previous gimp tars are installed. I don't think I did a  make
 distclean before  make  so it (gimp-1.1.25) may have been configged slightly
 differently (this box was running mandrake 7.0 + development updates previously)
 but it did build and works so I guess it didn't require zlib.

the gimp configure.in checks for libz and disabled png automatically - you
do not happen to have a configure output from the non-working version? ;)

 As there are going to be a fair number of UK people using this distribution it's
 probably worth a mention on the lists as an answer from a maintainer (after
 testing my answer of course). In the next release is it possible to test for
 zlib if its going to be required ?

It shouldn't be required ;) Anyway, I forwarded your mail to
gimp-developers, maybe someone spots the obvious thing.

Thanks for testing!

 
 Best regards,
 Dominic.
 
 PS. the only other thing I've installed today is MHonArc but I'm fairly certain
 Gimp doesn't require that ;-) 
 

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



gimp-2 already available for windows!!!

2000-09-28 Thread Marc Lehmann

No, this is not a spam, but rather funny... A friend of mine saw a
windows-"freeware"-cd with all sorts of features, including "gimp version
2". He bought it and installed it (it was, of course, a gimp-1.1.2x).

Nevertheless, until we found that out we were *quite* curious ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gradients and pre-multiplied alpha

2000-09-21 Thread Marc Lehmann

On Mon, Sep 18, 2000 at 05:24:20PM -0400, "Garry R. Osgood" [EMAIL PROTECTED] wrote:
 Gimp should do premultiplied alpha. Not because it cures acne or
 extends human life expectancy by an astounding 3000 precent, but
 be helpful to that crowd if  the dear little creature would
 only eat pre-multiplied alpha and composite with it.

One must realise, however, that this only gives a speed improvement
(possibly), and that the visual result is identical (except for rounding
errors, which are only problematic in premultiplied alpha).

Everything that currently results in visible artefacts with
non-preemultiplied alpha will do the same with pre-multiplied alpha, and
would need to be fixed anyway (or is a misconception of the user).

 a slot for an alpha premultiplied flag. And premultiplied pixels are
 otherwise indistinguishable from unmultiplied ones. So it is doubtful
 to me that any paint program any time soon can automagically determine

One could argue that a file format that has no way of specifying wether alpha
is premultiplied or not is hardwired to one alternative - if people use it in
a wrong way (like in the png case) they have incorrect files. For files that
*are* commonly used in both types and cannot distinguish between them (e.g.
raw bytes!) a switch might be helpful.

This, however, is a just an import issue. Gimp happily reads indexed
images with 500 colours, but of course cnanot store them in that way.

In this dicussion, we should draw an exact line between import/export
issues (where premultiplied alpha is a file format feature, and incorrect
handling would be a bug somewhere) and using pre-multiplied alpha for the
internal representatioin (which is *just* a speed hack, if implemented in
a fast way ;).

If Gimp would create different results (modulo rounding errors) when
working in pre-multiplied space this would be a bug.

 a clear statement that Gimp is an unmultiplied compositor (though
 certain tools and plug-ins necessarily have to internally play the
 premultiplied game - blur comes to mind) and (c) If you care about

While this might be interesting from a technical perspectibve, since
both compositors must result in the same image, this is not really a
priority.  The only thing one could mention is that gimp's result will be
more correct with unmultiplied alpha.

 Perhaps a later Gimp will know how to consume premultiplied alpha
 (you'll have to throw some switches) the 1.x Gimps of the next
 two years or so won't know how to do it.

But it is probably just a single line in the file load/save functions, so
it should be easy to implement.

If you mean that gimp should have another set of compositing modes,
very much like the dissolve mode which does a kind of "incorrect" alpha
composing (namely dithering) but adds a useful visual effect, then this
might be a worthhwhile addition. However, changing gimp's behaviour in RGB
mode depending on file format features is like saying: well, format xy
saves pixels in the wrong order, so you have to turn your monitor 180", as
gimp is a top-down-compositor.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __ ____  __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gradients and pre-multiplied alpha

2000-09-21 Thread Marc Lehmann

On Thu, Sep 21, 2000 at 02:51:28PM -0700, Kevin Turner 
[EMAIL PROTECTED] wrote:
  While this might be interesting from a technical perspectibve, since
  both compositors must result in the same image, 
 
 In Gary's defense, I am not yet convinced this is true.

Premultiplied alpha is a _representation_ of a colour (including
alpha). Just like you can represent colour using 8 or 16 bits per channel,
or RGB and CMYK. Some representations are equivalent, most aren't.
premultiplied alpha is equivalent to RGBA, _except_ that it's spatial
resolution is lower.

So, if both types of compositing result in different images then they are
simply two different algorithms to do compositing. both ways can work with
both representations, it just happens to be that the current compositing
modes do not include them (just as there are no effect layers). I fail to see
what the internal representation has to do with that.

Now, if somebody came and claimed that fkat RGBA compositing modes make
no sense for premultiplied RGBA comp. modes and vice versa, he'd have a
point, but...

 core, but in my preliminary investigation I found no clean way for the
 blend tool to do premultiplied compositing.

Since you can always convert between the two representations, it
"just" has to convert flat RGBA to premultiplied RGBA. RGBA is all you
need. IF your algorithm works better in premultiplied RGBA, then just
convert. Usually you can reformulate the algorithm to work in RGBA,
preserving the resolution.

(The only exception I can see is layer/channel compositing, but as I
mentioned, if there are two different common ways to compose layers then
you can do both using both representations, and gimp could easily support
both at the same time).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gradients and pre-multiplied alpha

2000-09-18 Thread Marc Lehmann

On Sun, Sep 17, 2000 at 06:33:09PM +0100, Nick Lamb [EMAIL PROTECTED] wrote:
 Pre-multiplying is a performance hack only, please don't let people
 think of it as something that will cure "black fringes" -- it won't.

If at all, it will only create even more visual artifacts due to greatly
reduced colour resolution for nearly-transparent pixels. The point of
not using premultiplied alpha is freedom to change and edit your images,
similar to providing 12, 16 or more bits per colour component. Using 8
bits (or using premulitplied alpha) is simply a performance issue, NOTHING
else.

(Sorry, Nick, when I just re-iterated your point, but I had to provide a
strong "me too" ;-)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling script-fu from perl script

2000-09-11 Thread Marc Lehmann

On Sun, Sep 10, 2000 at 10:39:26PM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:
  Not in the current architecture. The caller is blocked until the called
  plug-in has finished.
 
 That would be the preferred design, but my tests don't seem to bear this
 out.  Again, I could be misinterpreting the results, though I'm fairly
 certain I'm not.

You must, since if this were true we could expect a lot more breakage, but to
the contrary it's only script-fu. Also, the API for plug-ins looks like this:

function run_callback()
{
   ... parse agruments
   ... execute script
   ... create result values
   return;
}

Only when the plug-in returns results values are passed back. There
is currently no way for a plug-in to both return from the call AND do
something.

script_fu_old_photo($drawable, 0, 1, 1, 1, 0);

Ah, now it's clear: script_fu_old_photo _destroys_ the layer that is
passed in. Using the drawable after that was a bug in your (original) code
(this is a very common bug).

## $drawable no longer valid
$drawable = gimp_image_get_active_layer($img);
## $drawable valid again

 If I remove the sleep() call then Gimp crashes

The bug here is that Gimp crashes while it shouldn't, but this is more
a cosmetic problem (it's still easy to crash the gimp using illegal pdb
calls, unfortunately).

 only 1 second, various results occur.  If I don't use the call to
 gimp_image_get_active_layer(), with or without the delay, then Gimp crashes.

The problem seems to be that old_photo calls flatten, and this might
change a lot of internal structures. the right fix would be to make
old-photo return the newly created layer/image/whatever, but AFAIK
script-fu is unable to return anything to the caller (scirpt-fu was never
designed to be called from the outside, obviously).

 tells me that the blocking you mention isn't happening.  In fact, I can
 watch part of the drop shadow actually being performed on the image *before* 
 any visible results from old_photo happen - all before Gimp crashes.  Weird,
 but that's what I'm seeing.

I doubt that this has something to do with the plug-in API. Most probably
some pdb function only starts the rendering (AFAIK there was some
semi-recent change to push some long-running-ops into the background, so I
guess some locking there is missing).

 True. Still, my misuse of a valid drawable was unexpected for the Gimp.  There
 may be some error checking that could be done to prevent the crash,

Well, it's not as if a the developers didn't put a lot of effort into
argument checking. It is definitely much more difficult to crash the gimp
now than half a year ago ;)

 this can't be addressed before 1.2 is released) to make a note that
 serializing of calls to plug-ins from plug-ins is not guaranteed.

This is highly unlikely. the current set of perl plug-ins call a lot of
other plug-ins (including pelr ones) without a problem. I am quite certain
it's either an uncommon operation or yet another script-fu-breakage, for
example, script-fu is the only plug-in that stays in memory all the time,
even if not used, and uses temporary pdb functions instead of normally
registered calls (that's why it's so slow on startup). This could be the
key...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: TGA plug-in patch

2000-09-11 Thread Marc Lehmann

On Mon, Sep 11, 2000 at 01:15:18AM +0100, Nick Lamb [EMAIL PROTECTED] wrote:
  If the abovce is true and the file format indeed supports this (in the
  spec, if any), then this is not an "error" but "valid but uncommon".
 
 Ah no, writing images to TGA with "flip-vertical" flag set is both valid
 and common, almost universal in fact. But not being willing or able to
 load top-down images like Gimps would be an uncommon error,

Ah! ;) Still gimp would not support uncommon errors by giving the user more
freedom.

 wacky things you legally _can_ write to a TGA file, I am offering the
 opinion that we should generally shield users from the dozens of valid
 yet unimportant TGA options, and set them for our convenience, as we
 do with TIFF.

This is windows thinking a lot. Not implementing something because it is
costing a lot of time would be understandable, but not offering features
because the user might be too dumb is never a good idea (IMHO).

 [x] Top-left start [ ] Top-right start [ ] Bottom-right start [ ] ...
 [x] R-G-B [ ] B-R-G [ ] R-B-G [ ] B-R-A-G

Make sa lot of sense to me. TGA images are a common format for programs
that have special requirements (like a special layout).

 [ ] Mysteriously allocate but don't use colourmap
 [ ] Make alternate scanlines inverted for some reason
 [ ] Write four channels, but then only use three

These are of a something different quality, though.

 working image app... I want to have a genuine REASON to add any
 options like this before I risk confusing users further.

Well, we could also always write png's with compression=9, for example, as
the resulting image is the same in all cases ;)

 Still, a good reason may be forthcoming and if it is I'll happily
 integrate this patch or one like it.

A very good reason _not_ to is that it might be pretty unimportant, so
coding these features might be a waste of time...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: TGA plug-in patch

2000-09-11 Thread Marc Lehmann

On Mon, Sep 11, 2000 at 04:33:13PM +0200, "Guillermo S. Romero / Familia Romero" 
[EMAIL PROTECTED] wrote:
 can not be a bug (varies with personal opinion, and even if you say it
 is a bug, a new release would be cool anyway). But I would like to see
 the options in future versions.

This is a wonderful case for "he who needs it sends a patch2 ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Compilation and installation instructions

2000-09-11 Thread Marc Lehmann

On Mon, Sep 11, 2000 at 05:20:13PM +0200, Raphael Quinet [EMAIL PROTECTED] wrote:
 of June), because all Perl scripts crashed with a dynamic linking
 error (missing symbol) due to the changes in libgimp.

This had been caused by the upgrade to the newer API, not by changes in
the header files (or at leats not the usual changes ;)

 the new version over the old one.  Do you know if the bug was fixed
 between 1.1.24 and 1.1.25?

no, it was fixed a much longer time ago. Look at the compiler switches (here
I get):

gcc -c -I/localvol2/cvs/gnome/gimp/plug-ins/perl -I../../..
-I/localvol2/cvs/gnome/gimp/plug-ins/perl/../.. -I/usr/app/lib/glib/include
-I/usr/app/include -I/usr/app/lib/glib/include -I/usr/app/include
-I/usr/X11R6/include -I/usr/app/include -DGTK_DISABLE_COMPAT_H
-I/usr/app/lib/perl5/PDL/Core -g -Os -g -pipe -mpentium -mcpu=pentium
-I/usr/local/include -I/usr/app/include -fstrict-aliasing -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -Os -funroll-all-loops -mpentium
-DVERSION=\"1.201\" -DXS_VERSION=\"1.201\" -fpic -I/usr/app/lib/perl5/CORE
-Ddatadir="\"/usr/app/share\"" -DHAVE_PDL=1  Lib.c

the second -I points directly to topdir. A common mistake is to configure
plug-ins/perl seperately, in which case the perl module will assume
a standalone build, which makes it seem work, but with the described
symptoms.

 bugs, but I currently do not understand what problems the libgimpi.a
 hacks are trying to solve.  Is there any reason for that or is it just
 because it worked once and nobody dared touching it later?

I think the problem is getting the overall dependency right with automake.
the hack doesn't seem to be necessary on linux, but maybe on some other
systems(?) and was therefore never taken out.

 Well, it's a pity to break one of the two options, but I think that it
 is better to get the compilation inside the Gimp tree working properly
 even if it means that the upgrade would be a bit more difficult.

Well, there was only a single outstanding issue with the Makefile.PL, but
the new way has the definite advantage that I am no longer directly liable
for it ;-

-- 
  -==- |
  ==-- _   |
      ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



building things twice

2000-09-11 Thread Marc Lehmann
 gimage.o gimage_mask.o gimpbrush.o 
gimpbrushgenerated.o gimpbrushlist.o gimpbrushpipe.o gimpcontext.o 
gimpcontextpreview.o gimpdnd.o gimphelp.o gimphistogram.o gimplist.o gimplut.o 
gimpparasite.o gimpprogress.o gimprc.o gimprc_cmds.o gimpui.o gimpunit.o global_edit.o 
gradient.o gradient_select.o gradient_select_cmds.o gradients_cmds.o gtkwrapbox.o 
gtkhwrapbox.o gtkvwrapbox.o guides_cmds.o gximage.o help_cmds.o histogramwidget.o 
histogram_tool.o hue_saturation.o image_cmds.o image_map.o image_new.o image_render.o 
indicator_area.o info_dialog.o info_window.o ink.o interface.o internal_procs.o 
invert.o iscissors.o layer.o layer_cmds.o layer_select.o layers_dialog.o lc_dialog.o 
levels.o lut_funcs.o magnify.o main.o measure.o menus.o message_cmds.o misc_cmds.o 
module_db.o move.o nav_window.o ops_buttons.o palette.o palette_cmds.o 
palette_select.o paint_core.o paint_funcs.o paintbrush.o parasite_cmds.o 
parasitelist.o path.o paths_cmds.o paths_dialog.o pattern_select.o 
pattern_select_cmds.o patterns.o patterns_cmds.o pencil.o perspective_tool.o 
pixel_processor.o pixel_region.o plug_in.o plug_in_cmds.o posterize.o 
preferences_dialog.o procedural_db.o procedural_db_cmds.o qmask.o rect_select.o 
regex.o resize.o rotate_tool.o scale.o scale_tool.o scan_convert.o scroll.o 
selection.o selection_cmds.o session.o shear_tool.o smudge.o temp_buf.o text_tool.o 
text_tool_cmds.o threshold.o tile.o tile_cache.o tile_manager.o tile_swap.o 
tips_dialog.o tool_options.o tools.o tools_cmds.o transform_core.o transform_tool.o 
undo.o undo_cmds.o undo_history.o unit_cmds.o user_install.o xcf.o libgimpim.a 
../libgimp/libgimpi.a -L/usr/app/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule 
-lglib -ldl -lXi -lXext -lX11 -lm -lpthread -L/usr/app/lib -Wl,--export-dynamic

The overriding warnings are probably not relevent (I get them in a couple
of directories).

This is indeed unrelated to the parallel build problem. And indeed also
happens on my machine ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling script-fu from perl script

2000-09-10 Thread Marc Lehmann

On Sun, Sep 10, 2000 at 01:23:31PM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:

Hmm, a serialization issue is unlikely, since all the other plug-ins seem
to work, and script-fu never could be called reliably. If this, however,
is indeed the case than this change is probably quite new (maybe somebody
hacked locking lately?)

  drawable instead of both image and drawable) is this:
 
 Is there a way to pass in the image id?

Just pass it in at the usual position.

 I tried, but I get error messages

Did you pass in a valid image, or did you try to pass in a number? The latter
might not work reliably. You can also try to use the all-explicit syntax,
i.e.

(RUN_INTERACTIVE, $image, $drawable, ...

 when I try to pass the image id as the first parameter.  Do you pass the
 image id and drawable id's as a list?

No, you pass them "as usual".

 
  i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id
  etc..) to get the image, which in turn calls the the pdb function
  gimp_drawable_image without any caches. This means that, temporarily, gimp
  returns "-1" as the image id and later the correct one.
 
 Ick.  If this is true then there is a timing issue here where plug-ins
 can't call other plug-ins. 

you could check this hypothesis by doing something like this:

for (0..29) {
   print "IMAGE ID: ", ${$drawable-image}, "\n";
   select undef, undef, undef, 0.1;
}

this (untested) snippet prints out the image id of your drawable ten times
a second. Just insert it after the call to drop_shadow (i.e. where you
formerly added the delay).

When the image id changes from -1 to something else we have found the
problem.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling script-fu from perl script

2000-09-10 Thread Marc Lehmann

On Sun, Sep 10, 2000 at 02:56:07PM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:
 plug-ins from another plug-in.  Since the plug-ins run as separate
 processes, the calling plug-in continues running after each call to another
 plug-in.

Not in the current architecture. The caller is blocked until the called
plug-in has finished.

However, are you sure that the layer you used to calldrop-shadow is still
valid after drop-shadow returns? If not, then this would explain why the
example above works (and this would be the right fix).

 I don't see how you can "fix" this problem with the Gimp and maintain the

Could it be that the whole problem was just your script re-uzsing a drawable
id that didn't exist after drop-shadow returns? i.e. does drop-shadow really
lave the layer alone or does it create a new one?

(Iny case, gimp shouldn't crash)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: TGA plug-in patch

2000-09-10 Thread Marc Lehmann

On Sun, Sep 10, 2000 at 07:16:22PM +0100, Nick Lamb [EMAIL PROTECTED] wrote:
  strange to do, it is a supported feature of the file format and OpenGL
 
 apply the patch and (b) I don't think Gimp should offer too many
 features that work around uncommon errors in other systems at a cost of

If the abovce is true and the file format indeed supports this (in the
spec, if any), then this is not an "error" but "valid but uncommon".

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling script-fu from perl script

2000-09-09 Thread Marc Lehmann

On Fri, Sep 08, 2000 at 07:04:04PM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:
 $drawable-script_fu_drop_shadow("8", "8", "15", [0, 0, 0], "0", 1);

AFAICS, this should work.

 interactively.  I've also tried without the quotes (those are supposed to
 be STRINGS according to the PDB)

Which shouldn't matter, either (all the same for perl).

 gets resized) but immediately after making a selection around the current
 layer Gimp crashes.

gimp or script-fu? script-fu could never be called via the pdb, despite a lot
of effort to fix that, so script-fu breaking is not unexpected - gimp should
however, not really crash.

Could you add the following call before the call to drop_shadow:

Gimp::set_trace(-1);

and post the resulting trace output? This will help us find out what,
actually, is getting passed to script-fu (this is helpful in any case as
it shows wether you passed the arguments in correctly).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Newbie: LIBGD or GIMP?

2000-09-09 Thread Marc Lehmann

On Fri, Sep 08, 2000 at 04:08:16PM -, [EMAIL PROTECTED] wrote:
 1. One of the major requirements the solution should run as batch 
 process on AIX.

libgd - easy, gimp - difficult (you need an x display all the time, even
if only virtual).

 2. It should be able to create images from text in Helvetica Neue 
 font. 

gimp - easy, libgd - difficult (newer versions might support truetype
fonts).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: calling script-fu from perl script

2000-09-09 Thread Marc Lehmann

On Sat, Sep 09, 2000 at 11:18:49AM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:

Thanks for the reply ;) I posted it to gimp-developer because i seems this
is a generic gimp bug and hope somebody else can add more.

 gimp.  I suspect (but it's a guess) that the second one causes a change to the
 drawable id's for the image (which starts with a single layer when
 old_photo gets to it).

If the script-fu-drop-sahdow does change the darwable id (creates a new
one and deleted the old one) then your code is buggy: you simply mustn't
call gimp functiosn on drawables that do not exist. In this case this
would also be a gimp-bug, however, since gimp is not supposed to crash
when you feed it nonexistant drawable id's.

 If this is the problem, perhaps setting a delay of some kind between the
 two would work. 

No, it wouldn't. A delay wouldn't change the drawable id. A delay would
help if script-fu would return to the gimp before it finished its work
(unlikely, but definitely not impossible), or gimp would do something
after it has forwared the results to perl.

 script_fu_drop_shadow(
 INT32 run_mode=1"Interactive, non-interactive"
 IMAGE image=-1  "Image"
 DRAWABLE drawable=2 "Drawable"
 
 Without the sleep() call, the last entry looks like this:
 
 script_fu_drop_shadow(
 INT32 run_mode=1"Interactive, non-interactive"
 IMAGE image=0   "Image"
 DRAWABLE drawable=2 "Drawable"

 Looks like the image id gets changed somehow.  Ideas?

Highly interesting indeed. Now, what gimp-perl does (when you pass in a
drawable instead of both image and drawable) is this:

if (sv_derived_from (sv, PKG_DRAWABLE))
  arg-data.d_image = gimp_drawable_image_id(unbless(sv, PKG_DRAWABLE, 
croak_str));

i.e. it calls gimp_drawable_image_id (or gimp_layer_get_image_id
etc..) to get the image, which in turn calls the the pdb function
gimp_drawable_image without any caches. This means that, temporarily, gimp
returns "-1" as the image id and later the correct one.

Here I have to give up and hope this rings a bell for somebody more tied
to the internals of gimp id management.

-- 
  -==- |
  ==-- _       |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: New text metric procedure

2000-09-09 Thread Marc Lehmann

On Wed, Sep 06, 2000 at 07:58:13PM -0400, Nick Marden [EMAIL PROTECTED] wrote:
 I was looking through the PDB for a good procedure to return the
 metrics of a text string a la gdk_string_extents() but all I could
 find was gimp-text-get-extents. Unfortunately it returns the ascent
 and descent of the font, not of the characters in the current string.

Isn't the first what you want, anyway? I can only guess that the real
problem is that gimp-text clips away part of the bounding box. Try using
-1 as border size, this should leave the standard ascent and descent space
around the charatcers, allowing you to align everything correctly.


-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: configure script missing

2000-09-06 Thread Marc Lehmann

On Wed, Sep 06, 2000 at 12:14:50PM +0530, Vikas [EMAIL PROTECTED] wrote:
 I downloaded entire CVS'ed sources of GIMP and to start I could not find
 configure script. Can anybody send me that file or tell me where can I
 find it other that doing CVS again (It is a long job).

Run autogen.sh as if it were configure.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Code cleanup

2000-08-31 Thread Marc Lehmann

On Thu, Aug 31, 2000 at 09:22:56PM +0200, Mail Delivery System 
[EMAIL PROTECTED] wrote:
  if (p)
 free(p);
  
 I would not assume that it is safe to free() a NULL pointer in _all_

True. OTOH, this has been an internationally accepted standard since 11
years. The question is sometimes as to wether each and every programmer
must be hurt by non-C-ism's in some vendors os's, rather than hurting the
user of gimp(!) on a ten year old machine.

;- (I am not advocating to change g_free to free everywhere ;)

  2) we might break things that work
 
 This is the biggest danger right now.   A freeze is a freeze!

a freeze? a freeze? where is a freeze? ;()

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl script question

2000-08-31 Thread Marc Lehmann

On Wed, Aug 30, 2000 at 05:16:48PM -0500, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:
 Is there a way to open an image in Gimp Perl and run filters on it without 
 opening a Canvas window?

Funny question ;) Yes - just don't create a view. In gimp, loading a file
or creating an image will not result in an image window.

 e script will run interactively, but process

I guess your problem is starting the script on the image when it isn't
visible. There are a lot of wazs to accomplish this, for example, yoz could
change the type of the script from Image to Toolbox and trhe script will
then show a image/drawable secltor. Just starting the script (via the
perl-server) from the commandline will result in the same behaviour.

You could also modify the script to load the image for you, of course.

Or did I misunderstand your question?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Direction sought for scripting

2000-08-28 Thread Marc Lehmann

On Mon, Aug 28, 2000 at 04:03:30PM +1000, Mark Hessling [EMAIL PROTECTED] wrote:
 Gimp, and it is the Gimp that controls the execution of the plug-in, not the
 other way around. This is where I'm confused :-(

you call gimp. gimp calls the plug-in. the plug-in might be implemented in
any language you want.

The normal way to code a plug-in is to initialize the plug-in (global vars
etc..) and then call gimp_main(), which uses the plug-in-info structure to
make callbacks into your program.

In rexx you have to

a) create an interface for gimp_main
b) create a way to initialize callbacks in the global PLUG_IN_INFO
   structure.

One way to do that would be to write glue functions (in C) that would call
predefined rexx functions ("GimpInit", "GimpRun" etc..)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Direction sought for scripting

2000-08-28 Thread Marc Lehmann

On Mon, Aug 28, 2000 at 08:19:27PM +1000, Mark Hessling [EMAIL PROTECTED] wrote:

[lots of unnecessary quoting removed, please do that yourself next time]

  predefined rexx functions ("GimpInit", "GimpRun" etc..)
 
 And then in GimpRun() one can call all of the libgimp functions ?

Yes.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: PDL 2.1.1

2000-08-27 Thread Marc Lehmann

On Sat, Aug 26, 2000 at 07:52:50PM -0800, sayao [EMAIL PROTECTED] wrote:
 Lib.xs: In function `need_pdl':
 Lib.xs:97: warning: passing arg 1 of `Perl_croak' from incompatible pointer

Do you have, by any chance, compiled perl with experimental threading
enabled?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: api break before release

2000-08-25 Thread Marc Lehmann

On Fri, Aug 25, 2000 at 10:03:43AM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
  although not all that much so.
 
 I was referring to the version of gimp-print that is included in gimp 
 CVS. It was left unchanged by me despite the inclusion of the line 
 #define GIMP_ENABLE_COMPAT_CRUFT in print_gimp.h. This seemed to work
 very well. I'm happy however that you've decided to switch to the new
 API. 

Maybe it's just gimp-perl then. Maybe it's the fact that gimp-perl simply
relies on all symbols, while gimp-print probably only relies on the most
common (small) subset. In that case, most probably only gimp-perl is hurt...
Which might also be the only plug-in where the community has considerable
need to be convinced that a new version of some tool is as stable as the old
one (because people's income depends on working servers) before they switch.

Anyway, I *did* switch to the new API before writing my lament. I wrote
that mail because I *do* think such an under-the-hood-change deep *within*
the feature freeze is highly unconventional.

So backwards compatibility is not just not my problem anymore.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: api break before release

2000-08-25 Thread Marc Lehmann

On Fri, Aug 25, 2000 at 06:02:30PM +0200, Sven Neumann [EMAIL PROTECTED] 
wrote:
 Maybe your problems to get gimp-perl going with GIMP_ENABLE_COMPAT_CRUFT 
 defined were related to the fact that gimp-perl seems to prefer to use 
 installed libgimp header files over the current ones in the source tree.

There is no evidence that this is the case.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



api break before release

2000-08-24 Thread Marc Lehmann

While, in theory, I agree that having compatibility cruft inside a
software package is bad, I think breaking compatibility deep within a
feature freeze was a very bad idea.

I thought different this afternoon when I could just enable
GIMP_COMPAT_CRUFT_STH, but it just turned out that this define only
catches very few of the API changes.

So, in effect, the recent undiscussed changes completely break the API and
make it impossible to maintain a plug-in for both 1.0 and 1.2 versions.

This I consider a very very bad move so close before a release, and so
deep after the feature freeze was declared.

Usually, you do something like that just after starting a new development
track, not shortly before a release.

Just my 0.00 cents.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: resource management...

2000-08-24 Thread Marc Lehmann

On Thu, Aug 24, 2000 at 03:06:10PM -0700, christopher baus [EMAIL PROTECTED] 
wrote:
 something like perl, but that's IMHO.  I know a lot of people aren't down 
 with functional programming languages.

(... like perl ;)

Anyway, it seems nobody has the time and energy to really work on the
needed changes in script-fu to make it a viable programming environment.

 More generally is it possible for script-fu scripts to introduce memory 
 leaks even tough scheme in itself is a garbage collected language?

In script-fu it shouldn't be possible to enerate memory leaks, but a
plug-in (like script-fu) can easily create memory lekas within the main
gimp application. This is not easy to solve, and the question is wether
it should be "solved" for all cases (I can think of a lot of cases where
holding images inside the gimp for cahcing reasions makes a lot of sense,
without them being actively referenced).

 I need to pass an image and a drawable?  If I load an image, do some image 
 level manipulations on it, and then want to save it with gimp-image-save, 
 do I need to create a layer?

If your image doesn not already have a layer you have nothing to save,
so just use the existing layer. If you are sure your save plug-in
does not depend on the layer (most don't) you can also pass in -1 or
gimp_image_layer_active (or whatever its called).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Command Line Options

2000-08-22 Thread Marc Lehmann

On Tue, Aug 22, 2000 at 01:37:58AM +0200, "Steinar H. Gunderson" 
[EMAIL PROTECTED] wrote:
 But then, most other GNU programs use -V for --version and -v for --verbose,
 right? I completely agree that we should strive not to break anything, but the
 question is what (if anything) we'll break, vs. the need for consistency.

I doubt there is any software testing the gimp version using the gimp
itself currently. After all, there is gimptool and it seems to get used
(it is more interesting to check for the library version anyway).

So unless there is some really important piece of software we should go for
-v = verbose.

(BTW, this is not universal, many programs do use -v for version and
--verbose or -V for verboseness (some even use -x or -e or somethign
weird), and, yes, I always swear at them...)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: install issue over NFS

2000-08-22 Thread Marc Lehmann

On Tue, Aug 22, 2000 at 01:00:05PM -0600, "Michael J. Hammel" 
[EMAIL PROTECTED] wrote:
 `/home/mjhammel/src/graphics/gimp/gimp-1.1/gimp-1.1.25/plug-ins/perl/po'
 /usr/bin/perl ../pxgettext `find .. -type f -print | grep
 '\.pm$\|\.xs$\|examples/\|Perl-Server'`  gimp-perl.pot~
 /bin/sh: gimp-perl.pot~: Permission denied

It's problematic, since the makefile does not have dependency information,
so the rule runs everytime gimp-perl.pot~ is being generated.

 (making gimp-perl.pot~) be part of the build process or does it have to be
 done during the install step?

No, it needs only be done during make all. (it should run during make all as
well).

An easy fix would be to remove the dependency to update-gmo during make
install, which however means that a user has to do "make all", which is
probably not acceptable.

Do we depend on gnu-make?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Getting the image size

2000-08-21 Thread Marc Lehmann

On Mon, Aug 21, 2000 at 10:50:34AM -0500, [EMAIL PROTECTED] wrote:
 I am trying to develop a script for scaling images and I cant seem to
 find out how to get the size (pixels x and y) of the image once I load
 it.
 
 my $img2 = Gimp-file_load($file,$file);
 
 How do I get the height and width of this image??

$img2-width

Now transfer this knowledge to "height" ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Scaling bitmaps

2000-08-17 Thread Marc Lehmann

On Thu, Aug 17, 2000 at 12:14:08PM +0200, Martin Weber [EMAIL PROTECTED] wrote:
 Would be very interesting for GIMP, because it is much better then cubic
 bisplines

Hmm, the example images they give get really distorted a lot by their
process (see, for example, the letter-shape which changes *drastically*).

It would, nevertheless, be interesting, and the name (and output) looks as
if they were doing some vectorization here. OTOH, the warp-sharp script
for Gimp could result in quite similar results.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Bluesky ideas of the week

2000-08-13 Thread Marc Lehmann

On Sun, Aug 13, 2000 at 01:16:39PM -0400, Tom Rathborne [EMAIL PROTECTED] wrote:
 At SIGGRAPH I saw "Corel Network Painter" or something like that in
 action.  Basically there were a bunch of people all painting on the

Something like emacs' opening multiple views on different DISPLAY's?

Can gtk+ do that?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: UTF-8 vs. current locale charset mess...

2000-08-11 Thread Marc Lehmann

On Fri, Aug 11, 2000 at 12:50:12PM +0100, Nick Lamb [EMAIL PROTECTED] wrote:
 For Linux at least the filesystems speak UTF8.

While this is the proposed standard, there exist about zero systems in
practise that follow it, and the kernel does neither check nor enforce it.

 around that without needing to consult us) how about *BSD, Solaris etc?

"unix", in general, only supports characters from the portable filename
character set, so "in theory" there is no problem at all, as characters
127 do not exist in that set.

So there is no way around supporting native character sets.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimptool using --prefix for install?

2000-08-02 Thread Marc Lehmann

On Wed, Aug 02, 2000 at 01:26:00AM +0200, "\"Jürgen A. Erhard\"" [EMAIL PROTECTED] wrote:
 automake-using apps per default, usually) can do it.  It's just Perl
 that doesn't seem to be able to honor that (according to older posts
 from you Marc), which is a shame (for Perl).

Perl can do it very well. Have you read my posts? Or README.perl, which
explains that it's PREFIX not --prefix?

What perl cannot do is automagically find installed modules in that way,
and that is only natural.

The shame is really underinformed people (like you) who keep talking about
things they lack essential information on :(

I also don't know why perl is the primary target, most probably because
its used much more often than python, which has the same problems,
just like any other extension which uses an independently installed
interpreter.

 basis...  (and I hope that the rumored complete Perl rewrite will be
 helping here).

It's impossible. How could gimp find plug-ins that are installed in
/some/where/else unless you tell it?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimptool using --prefix for install?

2000-08-02 Thread Marc Lehmann

On Wed, Aug 02, 2000 at 12:08:18AM +0200, Alexander Skwar [EMAIL PROTECTED] 
wrote:
 ? Did I miss something?  Why is it such a bad thing that programs should be
 installable in a user specified place?  And why is RPM broken because of

What you miss is that it's not "installing in a user-specified place" but
"installing it in /usr/bin" but physically copying files somewhere else,
which only rpm needs.

You choose the installation location while configuring the program.

 wouldn't be a problem.  But that is *BAD* as far as creating the rpm file is
 concerned.

At least under linux, you don't need such fragile solutions (any ELF
system provides better measures). You could also use chroot to work on any
unix, although that would be difficult.

  ;)
 Ah! :-)

Sure!

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimptool using --prefix for install?

2000-08-02 Thread Marc Lehmann

On Wed, Aug 02, 2000 at 07:56:35AM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote:
 be a way to install (and deinstall) auxiliary files.  We (gimp-print)
 don't have any as of yet, but that's largely because we have no handy
 way of installing them.

What support are you missing? I'd think that every plug-in should know best
how to manage it's library space, and gimptool provides a lot of information,
e.g. where to put architecture dependnet and/or independent library files,

The only thing that I miss (from a cursory look) would be the
user-dependent gimp directory.

 hope to release in a few months), we'll probably want to ship printer
 definitions, color profiles, possibly dither matrices, and such as
 separate files rather than compiled in to the binary.

I think it's not a good idea to put knowledge about printer files (or
any plug-in-specific data) into gimptool. What's wrong about just using
$gimpdatadir/gimp-print?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Gimptool in Gimp 1.0.4

2000-08-01 Thread Marc Lehmann

On Mon, Jul 31, 2000 at 09:29:01PM -0400, Robert L Krawitz [EMAIL PROTECTED] wrote:
 Any suggestions?  Is Red Hat broken, or is it our configure script?

Obviously, if gimptool is missing the rpm source (e.g. the distro) is
broken, as is the usual case.

You might want to find out where the rpms come from. There are myriads of
gimp rpms, all with different contents, so the users with missing gimptool
might have a (broken) redhat while the users with gimptool might have
installed a third-party rpm. Or vice versa.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [gimp-devel] Gimptool in Gimp 1.0.4

2000-08-01 Thread Marc Lehmann

On Tue, Aug 01, 2000 at 11:49:26AM +0200, Simon Budig 
[EMAIL PROTECTED] wrote:
 IIRC gimptool is in the gimp-devel package, which makes sense, because
 all uses (except determining the Gimp Version) are developer-related.

So, adding scripts you downloaded from the registry is developer-related?

(it's definitely not _that_ clear).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: [gimp-devel] Gimptool in Gimp 1.0.4

2000-08-01 Thread Marc Lehmann

On Tue, Aug 01, 2000 at 02:26:49PM +0200, Simon Budig 
[EMAIL PROTECTED] wrote:
 impossible w/o gimp-devel, because the libgimp header files are
 unavailable.

Also, gimptool is very useful for other programs, to find out where gimp
was installed, even at runtime.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: gimptool using --prefix for install?

2000-08-01 Thread Marc Lehmann

On Tue, Aug 01, 2000 at 10:59:50PM +0200, Alexander Skwar [EMAIL PROTECTED] 
wrote:
 RPM it is very much desirable to have the install not go to the "real"
 directory, but to prefix the install dir with some other dir.

rant again
Why is that every program has to be "fixed" to be usable with rpm, and
everbody even agrees with that, instead of just fixing rpm???
/

;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Docbook (Help files)

2000-07-31 Thread Marc Lehmann

On Mon, Jul 31, 2000 at 07:40:12PM +0100, Austin Donnelly [EMAIL PROTECTED] wrote:
 The problem with this is that it suggests actually using "-"
 literally in the HTML, rather than the more correct "-gt;".

There is nothing wrong with using "-" in html, except for some *very*
outdated and *very* broken user agents.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Perl Scripting

2000-07-30 Thread Marc Lehmann

On Sun, Jul 30, 2000 at 04:54:55PM +0200, [EMAIL PROTECTED] wrote:
 On 30 Jul, Marc Lehmann wrote:
 
  i would really appreciate if you would finally start thinking, as this
  is not the first time you claim things that are sooo obviously broken
  :(
 
  No need to get insulting.

It's pure fact. You keep claiming all sorts of funny things that you
yourself should have known long before you started posting about it.

 Spend your time fixing the plugin instead.

This also has nothing to do with any plugin. What I said is in no way
limited to this week. It is your general behaviour.

  This would be more helpful for you and me.

It would indeed be most helpful if you try thinking a bit before you
post. I just mean that.

  BTW: You told me to just close all bugreports reporting gimpperl on
  the bugtracker, but I really think there could be serious problems
  which would need the time of an expert (i.e. you) to have a closer

And I think otherwise. Don't ask me if you are going to ignore me.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Perl Scripting

2000-07-30 Thread Marc Lehmann

On Sun, Jul 30, 2000 at 06:02:04PM +0200, [EMAIL PROTECTED] wrote:
  It's pure fact. You keep claiming all sorts of funny things that you
  yourself should have known long before you started posting about it.
 
  Ok Marc, it's enough. I will not continue this useless flamewar!
  In real life you sometimes play the nice guy but back on the computer
  you're pretty unproffesional!

It's you who is unprof(f)essional. You were and are totally wrong with
your today's claim about gcc -- claiming some not-yet-existant version of
gcc causes problems on your machine.

This is distracting time and other resources from real problems.

  And I think otherwise. Don't ask me if you are going to ignore me.
 
  I wouldn't answer if I had ignored you.

Well, you sound like that ;)

 The perl plugin is broken
  on several configurations and you're ignoring it.

I am not. However, unless you tell me about it I will have no way of
finding out.

  I for my part offered help to remove the problems but am pretty

Then start doing what you say you are offering. Claims about problems with
nonexistant programs is _not_ helping anybody.

And please stop picking on your problems with perl. I am _not_ talking
about perl, but about your general attitude of posting, well, garbage to
this list unrelated to me, but related to gimp and often (fortunately
not always) totally wrong. Wrong in a way that you, yourself, could have
avoided with minmal effort.

For example, when I told you that your latest patch uses mempcpy, a
function not available on most systems, you just replied with a quote from
the libc info pages(!), claiming the function _does_ exist. When I told
you that your usage of mempcpy is wrong anyway (you used it like memcpy)
you told me to read the manpage. Fact is, either you didn't read the
manpage or you simply didn't understand it. Honestly, I suspect it was a
typing error and you just wanted a way to save your face, wether it breaks
gimp or not.

It's your willingness to break the gimp sources without blinking,
and without willing to fix things later, combined with your immense
willingness of stealing other people's time if it saves you looking up a
manpage that cost you my support now, which, I guess was the only person
supporting you anymore.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: perl 5.6? or on openbsd 2.7

2000-07-30 Thread Marc Lehmann

On Sat, Jul 29, 2000 at 05:27:19PM -0700, pixel fairy [EMAIL PROTECTED] wrote:
 does gimp perl work with perl 5.6? this is what ships with openbsd 2.7
 or, has anyone gotten the gimp perl stuff to work with it?

I have gotten it to work with. As a matter of fact, gimp-perl is being
developed with perl5.6.

However, the current 5.6.0 release have a lot of bugs. If you experience
problems with error-reporting in your own scripts then you either have to
upgrade or to downgrade. Most everything else should work with vanilla
5.6.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Perl Scripting

2000-07-30 Thread Marc Lehmann

On Sun, Jul 30, 2000 at 12:09:25AM +0200, [EMAIL PROTECTED] wrote:
  The most frequent bug I'm stumbling over is the uncompilability with
  gcc compilers more rencent than version 2.95.2.  

then you must come from the future. more recent gcc versions than 2.95.2
DO NOT EXIST. it would save us gcc people a lot of time if you could
import, say, gcc-3.0 from the future back to now ;)

i would really appreciate if you would finally start thinking, as this is
not the first time you claim things that are sooo obviously broken :(

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: The Gimp is wasting a lot of memory

2000-07-23 Thread Marc Lehmann

On Sun, Jul 23, 2000 at 04:01:37PM -0500, [EMAIL PROTECTED] wrote:
 I'm not sure if the projection buffer is constructed conservatively or
 not.  As I recall projection is done bottom-up instead of top-down,
 which makes conservative construction difficult.  I planned a top-down

No matter what, gimp-2.0 _will_ be conservative about allocating tiles. I
know, this doesn't help much yet ;)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: The Gimp is wasting a lot of memory

2000-07-23 Thread Marc Lehmann

On Mon, Jul 24, 2000 at 12:16:30AM +0200, Tomas Ogren [EMAIL PROTECTED] wrote:
  operations (rectangular select, crop, flip, and I'll write the
  striping thing) on huge images? That would save the reputation of
  Linux in front of those guys.
 
 ImageMagick? Available on just about every Unix, Windows etc.

Ehrm, his problem was memory consumption ;) ImageMagick is quite a hog, as
it opzimizes for quality much more than even gimp (which IMHO also favours
quality over speed).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-19 Thread Marc Lehmann

On Wed, Jul 19, 2000 at 11:53:30PM +1000, David Hodson [EMAIL PROTECTED] wrote:
  No:
 
 No? If I render an object, and the edge of that object only covers
 half of a pixel, why does it need more than half the colour range?

I was talking about precision and not resolution.

 is that I could load an image file containing pre-multiplied alpha
 without being asked if the alpha should be un-multiplied. (Although
 I still think there's a useful distinction between pre-mult alpha
 and non-mult masks, and I would like to load an rgba image into
 Gimp and then add a mask layer.)

Pre-mulitplied alpha is a data representation which contains as much or less
information than the un-multiplied version.

The only reason to use pre-multiplied alpha is for speed, or ease-of-use.
(unless you argue that out-of-gamut values make sense). Since pre-multiplying
rgba images looses information (maybe a lot) there should be very good
reasons to switch the representation used to store the data.

As opposed to pre-multiplying image data to speed up display.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



another good reason to get rid of the %% default signal handler

2000-07-19 Thread Marc Lehmann

Since, at the moment, it is very easy to crash the gimp while drawing (at
leats it happens all the time to me), I am really annoyed by the signal
handler: Gimp keeps a grab on the screen, which means that i have to
log-in via the network (unless I am on linux an lucky enough to be able to
switch consoles) and kill the gimp, to get rid of the grab.

Of course, somebody might say "ah, let's just call XUngrab* (or the gtk
equivalent) after the SIGSEGV occured...

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: 32-bit images in gimp - Alpha handling wrong?

2000-07-18 Thread Marc Lehmann

On Wed, Jul 19, 2000 at 12:53:31AM +1000, David Hodson [EMAIL PROTECTED] wrote:
 A hack? I thought it was a mathematically elegant representation of
 an image layer, which is why I see a reason to support it. I'm trying

AFAICS premultiplied alpha is a speed hakc and nothing more, for cases where
sacrificing precision for speed makes sense.

 And even if you consider it a hack, don't people use pre-mult alpha?

Gimp tries to convert pre-multiplied alpha back to normal alpha, as Nick
said, so it is supported (or should be). This really sounds like a load
(and maybe save) issue (most image formats do not support pre-multiplied
alpha).

Can you state any reason why premultiplied alpha should be directly
supported as data representation?

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Fw: Logo for Linux Magazine

2000-07-14 Thread Marc Lehmann

On Fri, Jul 14, 2000 at 02:16:19PM -0700, Peter Mattis [EMAIL PROTECTED] wrote:

 Apache 1.3.12 has made the Linux Magazine Editors Choice Award for Best Graphics 
Tools. At

Uh-oh, there goes our monopoly on painting programs, when even Apache is
getting an award as a graphics tool ,)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: script executes fine at command line but not as a cgi

2000-07-12 Thread Marc Lehmann

On Wed, Jul 12, 2000 at 04:20:00PM -0400, [EMAIL PROTECTED] wrote:
 The script below, called wallace.pl, executes fine when I execute it at
 the command line, but dies when I try to call it from my web browser.

make sure gimp can be started when run from the web-server (valid DISPLAY,
valid permissions etc,..)

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: SOLVED::Installing gimp-1.1.24 (Gimp-perl) Problems - (--disable-shared BUG??)

2000-07-03 Thread Marc Lehmann

On Thu, Jun 29, 2000 at 10:55:23AM -0500, Jeff Sheffield [EMAIL PROTECTED] 
wrote:
 I.E. I was using the flag --disable-shared
 My thinking was that I could run multi-versioned gimps @ the same time
 without conflicts.

This does unfortunately not work in general with gimp, gtk+ or any other
package.

It works best if you use completely seperate prefixes for the gimps which
are not shared with other packaged (libtiff, perl...), since you cannot
portably link against a specific library and the linker will use the first
"libgimp" it finds.

 The only remaining problem I have is with the Fu modual.

It's actually the logulator. The CVS version has that one fixed.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: CorelPhotopaint for Linux

2000-07-03 Thread Marc Lehmann

On Mon, Jul 03, 2000 at 11:18:37AM -0400, Kevin Cozens [EMAIL PROTECTED] wrote:
 There has to be something to explain the installation stating that you need
 170Meg of disk space which is about twice the space needed for the GIMP.

170 = 2 * 17? The factor for a standard gimp (current cvs) is 10, not 2!

$ du -sk bin/gimp lib/libgimp* lib/gimp/1.1 share/gimp/1.1
1992bin/gimp
148 lib/libgimp-1.1.so.24.0.0
180 lib/libgimpui-1.1.so.24.0.0
7563lib/gimp/1.1
7153share/gimp/1.1

You could easily incldue a full X+basic linux installation into the remaining
53 Megs.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: XCF code in Imlib2

2000-06-25 Thread Marc Lehmann

On Sun, Jun 25, 2000 at 05:05:18PM +0200, [EMAIL PROTECTED] wrote:
  He and Raster are going to meet next week and then they'll think about
  possible solutions for this conflict.

Don't they think this is demanding some _action_ (like reverting that
patch)? "meet next week" and "possible solutions" sounds, well, not very
serious.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: Gimp and Perl 5.6

2000-06-09 Thread Marc Lehmann

On Fri, Jun 09, 2000 at 02:01:49AM -0400, "Marc D. Spencer" [EMAIL PROTECTED] wrote:
 Has anyone successfully run non Perl::Fu command-line scripts under Perl 5.6?

Yes, me ;)

 Gimp $img = gimp_image_new(100,100,RGB)
 Segmentation fault (core dumped)
 
 gdb reveals that it's seemingly a perl problem, but my experiance is 

Which version of gimp-perl (or gimp) did you use, and how did you
compile it (and on what architecture)? Although I don't remember any
perl5.6-specific problems it might be caused by some old version.

Also, perl5.6 is not production-ready, if you want bleeding edge perl
(highly recommended, it's got new cool features ;) better get it from the
repository.

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



Re: compression parameters on re-save jpeg

2000-06-09 Thread Marc Lehmann

On Fri, Jun 09, 2000 at 12:24:35PM +0200, Andreas Haack [EMAIL PROTECTED] wrote:
 it saved with using save (Ctrl-S). I assume the original once are not recorded
 in the image,
 so how could I be shure that the quality is perserved.

Just do not use JPEG ;) In general it is impossible to do what you want,
especially if some other program wrote the JPEG.

In practise you should save the JPEG in a quality very near the original
quality. It is also possible to guess the quality (my "judge" program does
something similar to this, for example), but it is very difficult. (Also,
one might not want to "judge" the quality of the image, but the quality of
the quantization factor instead).

-- 
  -==- |
  ==-- _   |
  ---==---(_)__  __   __   Marc Lehmann  +--
  --==---/ / _ \/ // /\ \/ /   [EMAIL PROTECTED] |e|
  -=/_/_//_/\_,_/ /_/\_\   XX11-RIPE --+
The choice of a GNU generation   |
 |



  1   2   3   4   >