misc
found.txt.com
Description: Binary data
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
e from him
below.
Thanks,
Austin
---
Hi Austin,
I have been enjoying your explanations on FM Screening and dithering, They
have helped me understand one of our specs a great deal more, Thanks.
We have recently set up a division (me) to focus excl
you'd like that
to be fast, right?)
Austin
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:gimp-
> [EMAIL PROTECTED] On Behalf Of David Gómez
> Sent: 07 January 2004 22:04
> To: Sven Neumann
> Cc: Gimp-devel
> Subject: Re: [Gimp-developer] Dithering
>
double-click in the rulers should bring up a "change
units" dialog box. It should allow people to change to pixels, since the
most immediately visible effect of changing the image's units is to the
rulers.
Austin
___
Gimp-dev
> "Austin Donnelly" <[EMAIL PROTECTED]> writes:
>
> > > - Add an easy way to change the image's unit. It's quite well hidden
> > > in the Image Scale dialog right now. With the changes proposed
> > > above, changing the image unit
e area should
> become
> black. Anybody a preference?
I'd vote for greying/dimming the image outside the crop area, much like the
QuickMask feature turns stuff red. In fact, you could look at the quickmask
code to see how that does it.
Austin
__
etc). It's the DWIM (Do What I Mean) school of UI design, where you
try and guess what the user is actually trying to do :)
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Or Becky Cierpich's flower & digital background:
http://www.gimp.org/contest/gallery.cgi?display=image&name=20041202094428993
6
The standard of entries is (by and large) very high; I'm impressed.
Austin
___
Gimp-
ft my hands much cleaner than I got it!
There are two areas where it could do with improvement:
- it doesn't handle tile-boundaries (it treats them as edges)
- the point editing interface sucks; I merely made the existing one work
but it might be interesting to see if it could
of files. In my experience
things that go fast on local filesystems can go unexpectedly lots slower on
remote filesystems.
Austin
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Monday, 19 Feb 2001, Roger Leigh wrote:
> I mailed this patch to the list a few weeks ago, but it was ignored.
Your patch sounds useful, and I think it should probably be applied.
However, it seems that everyone is busy right now.
Thanks for persisting!
Aus
tc people.
Distributions like Debian etc can then put the library in its own
package and do their own dependency thing, but we don't have that
luxury, I'm afraid.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Tuesday, 20 Feb 2001, Robert L Krawitz wrote:
>Date: Tue, 20 Feb 2001 10:30:56 +
>From: Austin Donnelly <[EMAIL PROTECTED]>
>
>I think the easiest thing is to have the version in CVS (and gimp
>snapshots) to include the code for the shared library, a
the only
people who will have a statically linked print plugin will be those
who build and install from source - ie those on weird architectures,
or testing non-standard stuff. This seems to cover the cases
correctly, in my view.
Austin
___
Gimp-develo
On , 22 Feb 2001, Sven Neumann wrote:
> But most (all?) window managers scale them down to a tiny 16x16.
Not mine: fvwm 1.24r
> IMO the whole thing should go away, but if people like it, please make a
> preferences option to enable it.
I think it's a good
able
> with all the spaghetti in 1.1.x, but presumably as we wipe out the
> worst of the spaghetti we should be able to bring it back, no?
I thought 1.2.x shipped with COW still enabled?
Austin
___
Gimp-developer mailing list
[
On Sunday, 4 Mar 2001, Raimo Leppanen wrote:
> gimp-1.125-1
Please upgrade to gimp-1.2.1 and see if the problem still happens.
Are you loading a JPEG file? Do other programs display the file correctly?
Austin
___
Gimp-developer mailing list
[EM
ith the
current development head. Thanks!
Austin
--- sobel.c~Tue Aug 22 02:26:56 2000
+++ sobel.c Sun Mar 11 14:08:36 2001
@@ -312,10 +312,10 @@
{
gint b;
- if (y == 0)
-gimp_pixel_rgn_get_row (pixel_rgn, dat
gimp hackery required.
The two scripts xsane-startup and xsane-shutdown can contain whatever
commands are needed to initialise and turn off your scanner etc.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
ands for, but at a first glance
> I'd say, that you try to do something like (car 123324), but car
> is only possible on lists and cons.
At a guess, wta means "wrong type for argument"
I agree the message is pretty useless: you need to know w
hough?
I really don't see what's wrong with using a ruler. The CD idea is
cute, I have to agree.
While there is a standard size from credit cards, some id/membership
cards that claim to be the standard size aren't. I've discovered this
by attempting to stuff them into a card w
Yes: that was always my original idea. Only, I never had the time to
code it up. Thanks are due to Mitch and Sven who actually got their
hands dirty and did something, otherwise we would have nothing. And
what we have is definitely better than nothing.
Austin
__
On Friday, 30 Mar 2001, Nick Lamb wrote:
> On Fri, Mar 30, 2001 at 10:56:32AM +0100, Austin Donnelly wrote:
> > I really don't see what's wrong with using a ruler. The CD idea is
> > cute, I have to agree.
>
> There is a tiny problem. I can hold the ruler _near_
quot;bad"? Are there jaggy edges? Pixelation? Colour casts?
Scaling artefacts? What do you mean by "bad"?
Maybe you could post a (small!) screen shot showing us both gimp and
EE viewing the same image, for comparison purposes?
Austin
_
}
src_row += src_rgn.rowstride;
dest_row += dest_rgn.rowstride;
}
}
}
}
Of course this precise form will only work where there's a one-to-one
correspondence between input and output pixels. I suspect whirl-pinch
has mo
Oops - I missed out some vital pixel region initialisation.
On Friday, 6 Apr 2001, Austin Donnelly wrote:
> gimp_drawable_mask_bounds (drawable->id, &x1, &y1, &x2, &y2);
>
> for (y = y1; y < y2; y += tile_width - (y % tile_width))
> {
> for
l filters where it could potentially be used, so if
> anyone is interested I could try to clean it up.
Actually, the core could do with a tile convolution, since currently
it copies data into a tempbuf before convolving it. This makes some
tools more effificient (or incor
On Sunday, 8 Apr 2001, Ernst Lippe wrote:
> Austin Donnelly wrote:
> > Actually, the core could do with a tile convolution, since currently
> > it copies data into a tempbuf before convolving it. This makes some
> > tools more effificient (or incorrect) eg iscissors.
t time I looked at the code in detail. This is in 1.2.1.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
d assumption, to either crash bizarrely
later or come out with artifacts in the image?
You can argue that maybe it should have been a g_return_if_fail() or
similar, but knowing about bugs early is useful. Besides, aren't
stable releases built with ass
d the comments
at the top of app/iscissors.c
I think I was the last person to go in there. There are still a few
things that could be tidied up, eg getting the convolutions to work
correctly near tile boundaries.
Austin
___
Gimp-developer mai
media selection which
describes how a PostScript interpreter picks the paper
size/color/headed to print on. It might be useful.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Friday, 8 Jun 2001, David Monniaux wrote:
> On Fri, 8 Jun 2001, Austin Donnelly wrote:
>
> > But, we're talking about *paper* here. A4 for me is the same size as
> > A4 for another user, surely? There are only a limited number of paper
> > sizes in exis
is definitely cause for another stable
release, I think. It goes without saying that it should be widely and
thoroughly tested, possibly by a 1.2.2alpha pre-release snapshot or
something.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://li
defaulted to 72 dpi,
maybe they should also have a "gimp-comment" parasite added. File
load plugins would then just override the parasite if the file format
includes a more specific parasite. I believe current file load
plugins than know about par
is 10 * 1000 * 1000 bits per second, not 10 * 1024 * 1024.
1024 is only involved when addresses are, ie for sizes of buffers,
memory, files. Never when talking about bandwidth.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists
ns if the user changes the preferences before saving
then its not entirely obvious what happens, but I think this should be
a rare occurence.
All this discussion means that I don't think anything should be done
to 1.2
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
On Thursday, 21 Jun 2001, Raphael Quinet wrote:
> It is also interesting to see that the number of lines of code has
> doubled from 1.0.4 to 1.2.1.
I think 1.2.1 comes with many more plugins as standard. It would be
interesting to see where all these new lines of code come from!
ror 2
It looks like something involved in making po files isn't present on
my system and the makefiles or configure etc isn't coping.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
page TIFF, + all your examples) the new API
could be offered as well. No too sure of the details here; more
thought required.
The problem might be with existing file loader plugins that no-one
feels like modifying, or that are binary-only.
Austin
___
Gimp-
ram
from crashing plugins. If a plugin crashes and takes out the main
program then we may as well not have bothered.
I repeat: if a plugin crashes and kills the main gimp program,
*please* file a bug report!
Austin
___
Gimp-developer mailing list
[EMAIL P
(lots of
> code commented out, define for "FACEHUGGERS", no real copyright
> notice, etc.) Who is the current maintainer?
It is maintained (and fairly regularly), by Adam Moss.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
an de-select
the Font Types "Bitmap" and "Scaled Bitmap", leaving only "Scalable"
selected. This should then show you only scalable fonts.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
o don't consider its name and menu position as important
> features ;-)
>
> sample of use :
> http://raymond.ostertag.free.fr/html/greffon/test_1.html
>
> plugin, doc, samples :
> http://perso.linuxfr.org/jdumont/gimp
I like it! Pretty cool!
Austin
___
Remember, they are
> hearsay ;)
[observations snipped]
Wow!
Marc Lehmann has written an email that's actually useful and
well-thought out!
His "60% CMYK" makes sense to me. Now all I need is the time to
implement it.
Austin
_
;t always change canvas size
>An odd one, this - another intermittent bug. Actually,
>it's every second time. And only on big images. Go figure.
>(I mean it, go figure :)
These two might be related. See Raphael and my r
rsion (eg because of
slightly different rounding of values combined in layers, etc).
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
to re-code from scratch and failed: Netscape went bust, and MS quietly
canned the Word re-write project.
We should learn from the mistakes of others :)
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
t;live wire" feature mentionned in the paper
would be fairly tough to do in gimp (from a UI point of view).
Can you be more specific about what features described in the paper
you wanted to add to iscissors?
Austin
___
Gimp-developer mailing li
On Tuesday, 15 Jan 2002, Martin Waitz wrote:
> On Mon, Jan 14, 2002 at 10:37:13PM +0000, Austin Donnelly wrote:
> > I think I was the last person to substantially modify the iscissors
> > code. I read the paper you reference above, and indeed it was quite
> > helpful. How
On Tuesday, 15 Jan 2002, Martin Waitz wrote:
> On Tue, Jan 15, 2002 at 11:08:28AM +0000, Austin Donnelly wrote:
> > I did test-implement it. #define USE_LAPLACIAN and recompile to see
> > if it makes much difference. I couldn't see a visual different, only
> > it was
n welcome
to it! I agree with Sven that work should use the latest developer
CVS though.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Tool...
Ah ok - it was a long time since I last looked at the code. You're
right, it wouldn't work. I mis-remembered there being a bit more to
it than that.
> I can put the stuff back so people don't need to compare code
> they have not restructured
d there's no locking (as of 1.2.2)
Do we have locking in 1.3.x?
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
the EXIF data such a usage case?
Uh - it already *is* hierarchical: that's exactly what:
gimp-*
gimp-exif-*
etc are!
It's hierarchical by convention, and this isn't checked, sure. But
it's quick and easy.
Austin
___
Gim
stry) and secondly: if not, would there be any interest in such a
> plugin?
I don't think such a plugin exists already. By all means, go ahead
and code it up - it sounds useful!
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://
> get your hands on GIMP-1.3.3 and add %L to the image-title-format
> or image-status-format strings. There you go.
Since we now have a number of these *-format strings, has someone
taken the time to generalise my code for image-title-format?
ts a good idea from
a UI point of view. Not all plugins will have icons, and it will look
very messy and confusing.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
me severly.
Could someone post a summary of the differences between the current
setup and the proposed new setup?
Austin
(Sorry to dig up old emails, but I've only just got back from a week's
holiday without Internet access - joy!)
___
f now we're expansing different format strings, then perhaps the time
has come to generalise the code.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
I've just heard about Valgrind, a memory debugger much like Purify,
but which works on Linux.
I've given it a quick spin on gimp-1.2.2, and it picked up a couple of
bugs. It's really quite a good tool!
For more information about it, see:
http://developer.kde.org/~s
age for the yellow
tool-tips popping up from the toolbox. And I got another at startup -
perhaps that's the one your talking about.
Using the ink tool showed some problems in the blob code too.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
od idea to investigate this to make sure.
I would trust valgrind :)
Of course, it may have found a bug in glib, gtk, or the X libraries.
Apparently the author found a number of libc bugs, and gcc code
generation errors(!)
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
e rounding errors. Therefore, if you're using it to produce
1-bit output (and hence can't use antialiasing) then you should expect
poor quality output. The newsprint plugin is suitable for producing
(eg) silk-screens for t-shirt designs, or special effects, but not
it the
default format for Gimp curves too?
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
indow, then doing a normal "zoom
centred" is probably best.
Trying to guess that the selection is up to is a recipe for disaster,
as noted in the many special cases in the bug report.
I can't remember the Mac behaviour on zoom out. I don't suppose it
On , 23 Apr 2002, Sven Neumann wrote:
> ack. Who writes the patch?
Sorry, not me - lack of time :(
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
f people don't know about it, which is a shame.
http://bourbon.usc.edu:8001/tgif/
(The GIF in the name has nothing to do with the patent-encumbered
raster graphics format).
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf
I wrote a patch which added a warning, but subsequently it was decide
that not enough people would understand or care what was going on.
Austin
> -Original Message-
> From: [EMAIL PROTECTED]
[mailto:gimp-developer-
> [EMAIL PROTECTED]] On Behalf Of Roland Roberts
> Sent: 14
I wrote some docs about the undo system's operation; try looking around
in the doc/ subdirectory.
I can't vouch for how accurate they are now, but I don't think the
system has changed much since I added the "undo history" feature.
Austin
___
Can someone please look into this patch I've been submitted?
Ta,
Austin
--- Begin Message ---
Title: Patch for wishlist entry 75558
Hi,
I wrote a patch for the bugzilla entry 75558, curve tool does not remember old
values.
I wrote a patch for this a while ago, but it seems
time.
Just a detail to bear in mind...
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
mp application (eg because
you are extending the main UI directly, like the colour selectors do).
Hope this helps,
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
lation of this info is delayed until it is actually needed by the
selection-boundary walking code (we don't know ahead of time where the
boundary is, but we can guess that it's not going to include every tile in
the image).
Austin
___
Gimp-
> (Yes,
> I like the text tool, I etxremely like the undo history.. but that is all
> nothing major).
But the undo history is not a new 1.3 feature, it was introduced by me in
one of the 1.1 testing series and has thus been in all the 1.2 versions
> Conceptually I like this, and the gotchas are toggleable
> via the UI.
I like the idea too. It should be checked in and turned on by default.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/li
So is the current 1.3.x build environment documented in the HACKING file (or
elsewhere)?
I'm guessing that the file is probably out of date, or lacking things.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkele
> > GIMP zooms on Shift-wheel since some early 1.1 version.
>
> Can the gimp be made to zoom in/out on the cursor instead of on the
> centre of the image.
We have a bug open on this:
http://bugzilla.gnome.org/show_bug.cgi?id=79384
Austin
_
IEEE float to your
local weird-ass machine float. Not common, I grant you, but a real pain
when it bites.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
#x27;s a good thing!
If it ain't broke, don't fix it.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
xels as separate members. I think this is roughly what
Leonard was suggesting; we should listen to the voice of experience.
Austin
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
. The bytes
you seeked over are the hole, and will be read as if zeros.
GNU cp uses a bunch of heuristics to discover runs of zeros in the input
file and seek over them in the output file, rather than just writing zeros.
Austin
___
Gimp-developer mai
82 matches
Mail list logo
