lasm [EMAIL PROTECTED] writes:
Thanks for your explanation. I am not familiar with the
algorithm.. but just curious, would there be any difference
if the Depth takes in negative integer (currently only positive
accepted) ? Can you comment on this ?
It wouldn't make any difference. The
"Steinar H. Gunderson" [EMAIL PROTECTED] writes:
The question is: Does it use 255-bm or just -bm? And would that make any
difference?
It wouldn't change anything. The local differences that are used to
compute the surface normal would be exactly the same.
Dude, follow the math! Read the
[EMAIL PROTECTED] writes:
What he is suggesting is to invert the color value, so white
becomes black, and black areas become white, so that the bumpmap
will take a different height field to achieve the "inverse" effect..
I have tried it before but do not quite like the result..
Nick Lamb [EMAIL PROTECTED] writes:
General purpose compose operations usually include a division by 255 of
a number in the range 0 ... 65025. While fixing up Mozilla's alpha
compositor I disturbed a sleeping hacker who has provided a (tested and
working) macro which computes this operation
Manish Singh [EMAIL PROTECTED] writes:
GIMP 1.1.29 is out there. This is a release candidate for 1.2. So scream
if you see any major brokenness.
Ugh. I haven't got around to fixing the (lack of) premultiplied alpha
in the Blend tool when using custom gradients.
[I downloaded the SRPM with
Nick Lamb [EMAIL PROTECTED] writes:
Probably some UI improvements needed in the gradient editor then,
other packages I've seen use a separate edit bar for alpha. I would
not advocate such a change to Gimp, but it is at least inspiration.
The gradient editor's user interface sucks harder than
Nick Lamb [EMAIL PROTECTED] writes:
If p is a null pointer then "free (p)" may (and should!) crash. You
are incorrect here.
sigh You are completely wrong, see KR's treatment of ANSI C
Sorry, my bad. I just checked the ISO standard and indeed, free(NULL)
is safe.
I guess that makes me
Kevin Turner [EMAIL PROTECTED] writes:
Format issue 1: DocBook or HTML?
DocBook. It is the Right Thing(tm) and GNOME has already assembled a
nice set of tools to handle it.
I'm sure the the GIMP documentation team can use some ideas and
conventions from the GNOME documentation project.
Hello, dudes,
Jens Finke [EMAIL PROTECTED] has sent me an amazing patch to add
support for XCF file loading to gdk-pixbuf. I would really like to
have this sort of functionality so that simple programs like EOG can
view GIMP files.
However, there is the issue of licensing. Gdk-pixbuf is
:set cinoptions={0.5s,^-2,e-2,n-2,p2s,(0
Works most of the case.. (maybe not perfect, but..)
Thanks a lot! I just put it in the programming guidelines.
Federico
Targa files have no magic header, and cannot be reliably identified that way.
[snip]
"New" Targa files have a magic string at the end of the file[1], plus
a bunch of extra information. The Targa specification tells you how
and where to expect it. It does says that for old files you are
Uhm, I use vim and vim uses tabs by default and doesn't indent
the { after an if like GNU suggests. Du you have working settings to
achieve this?
I don't know if this will be useful at all, but the GNOME Programming
Guidelines has a snippet for .vimrc to set the Linux kernel
indentation
If you tweak it a bit it may work for GNU indentation style.
No, unfortunately I couldn't get vim used to GNU indention style.
Please tell me if this works or if you had to change something; I'd
like to keep that part of the programming guidelines as accurate as
possible.
Fill (by default Ctrl-.) has filled using the background colour in the
GIMP for as long as I can remember. I don't think it's a bug
[snip]
I agree. I have grown very accustomed to the existing behavior, and I don't
think it should be changed.
I know it hasn't been customary in
GIMP's a lot lighter than gnome-libs. I would substantially oppose
any serious dependence on gnome-libs in GIMP. Especially since
gnome-libs appears to depend on a library that is only available if
you have RPM installed.
Kelly, please don't spread FUD. People build gnome-libs on
We might also choose to use the upcoming Gnome Print System if it turns
out to fit our needs and appears to be portable to non-Linux systems.
As long as it doesn't require actually running Gnome (works with bare
X, KDE, etc.) and its footprint is reasonably light, that sounds
For the record, I think a plug-in CVS tree independent of Gimp is a good idea.
"Let's focus, people!"
[snip]
The issue is: who has the time? Without people, good ideas remain abstract.
I have no time, but I would nevertheless devote part of on merges between
the two cvs trees. I
- Help us to make a seperate version of GtkXmHtml that compiles on a lot
of setups and fix the Gimp configure script.
Just so you know, GNOME is dropping GtkXmHTML because it is no longer
being maintained and is not very good in general. Anders is working
on a very nice GtkHTML widget,
20 pixels is pretty small (on 300 dpi that means 1.69 millimeters)
Shouldn't these ranges be tied to the resolution setting? ie change the
resolution and the ranges will update (well, maybe not for an open dialog,
but perhaps the next time its opened).
Using sliders for these things
I think this will just give you the LENGTH of the file? So, I don't
know if it matters, but ISTR that Gimp uses files with holes, and
therefore LENGTH != SIZE.
Oh, I didn't know this.
In any case, the program *does* know (or should) know the number of
tiles that it can have (tile cache
20 matches
Mail list logo
