Robert Krawitz wrote:
From: peter sikking pe...@mmiworks.net
this whole pdf/cmyk discussion has been a nice exercise for me
in getting to know the activity as Don Norman calls it.
this is what I digest from all that has been said here:
rule #1: the topic we are talking all the
On Thu, 26 Mar 2009, Robert Krawitz wrote:
I think the case of text black is a partial, qualified exception --
but it's arguable that it has any bearing on RGB vs. CMYK. It really
means the darkest, sharpest black that can be produced regardless of
rendering device. It could just as well be
Andrew A. Gill wrote:
I think I agree with 99% of what you wrote. Clarifications/quibbles:
(wait. Nevermind. Probably about 75%)
I better explain some things before that drops even further ^}
4) tiff or pdf? it is just a transport method. it is a strategic
choice what to do
On Fri, 27 Mar 2009, peter sikking wrote:
I think the case of text black is a partial, qualified exception --
I have a hard time spotting what you mean. this is troubling
because I will have to understand the everything to be able
to drive the Ui side of the solution.
Here, this may help:
Hi all,
my previous posting does not stand a quality test, to put it mildly.
To save the list from multiple nearly indentical follow-ups,
i thinks it's best to bundle my replies here.
My apologies for the noise.
yahvuu schrieb:
Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be
Andrew A. Gill wrote:
On Fri, 27 Mar 2009, peter sikking wrote:
I think the case of text black is a partial, qualified exception
--
I have a hard time spotting what you mean. this is troubling
because I will have to understand the everything to be able
to drive the Ui side of the
On Fri, 27 Mar 2009, peter sikking wrote:
OK, that part I already got before I wrote my digest. But Robert
points this out to show that there is a (minor) spanner in the works.
where's the spanner?
There are two spanners: one in favor of CMYK and one against.
I'm not sure which Robert
Date: Fri, 27 Mar 2009 09:48:04 -0400 (EDT)
From: Andrew A. Gill superlu...@frontiernet.net
On Fri, 27 Mar 2009, peter sikking wrote:
OK, that part I already got before I wrote my digest. But Robert
points this out to show that there is a (minor) spanner in the works.
I am also interesting in this project: GEGL-based file loaders for GIMP.
I'm preparing the proposal, and it says in the introduction that The exact
approach at this is still to be decided but will only require a small set of
discussions and agreements between core developers.
Where can I discuss
On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote:
As for customisability? I think that it's probably underestimated. Take
the example of me spending half an hour or more on google this evening
trying to work out how to enable menu tear-offs in Gnome. As far as I
can tell, the feature just
Robert Krawitz wrote:
where's the spanner?
Against CMYK, regardless of what system you use, text black is
going to be a spot color, so it could just as easily be RGB+K,
CMYK+K, LAB+K, or even YIQ+K.
I meant the latter.
I remember that on some older monitors and graphics devices
On Fri, 27 Mar 2009, peter sikking wrote:
the plan as you can see in my conclusions does not hardwire a
cmyk system, it uses (stolen from pippin) an everything is spot
aka a-plate-is-a-plate system where the separation is free
configurable, and cmyk and cmy+k are standard configurations.
so
On Fri, Mar 27, 2009 at 7:23 PM, Andrew A. Gill wrote:
After all, there's a way to get PMS to work with Scribus (and I
believe you can use this to get approximations in GIMP as well):
http://wiki.scribus.net/index.php/Scribus_and_Pantone_colors
You mean
Dear Nicolas Robidoux
I am Amit Kumar from India,an undergraduate engineering student(Electronics
communication engineering) of IIT Guwahati.
I went through Ideas list of GNU Image Manipulation Program for Gsoc
2009.
I found More Flexible Abyss Policies (including Nearest Neighbour, a.k.a.
Hi,
On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote:
Just think of the most used piece of code on a GNU/Linux system: the Linux
kernel. Didn't you know that the user interface is stable ?
How would you feel if between releases the behavior of interfaces changed,
and when asking the kernel
Hi,
On Thu, 2009-03-26 at 17:03 -0400, Kevin Cozens wrote:
Gary V. Vaughan wrote:
Has anyone been able to find time to look at my patch queue for babl?
One minor thing I noticed is the patch which adds and include of config.h so
it is done in all(?) files. Is it really necessary to
Hi,
On Wed, 2009-03-25 at 23:21 -0400, Louis Desjardins wrote:
At this point in the discussion, it would be great to hear if the
quality of the information provided so far in terms of explanations and
examples is enough to lead someone or a group of developers in the GIMP
team to envision
Alexandre wrote:
On Fri, Mar 27, 2009 at 5:13 AM, David Marrs wrote:
As for customisability? I think that it's probably underestimated. Take
the example of me spending half an hour or more on google this evening
trying to work out how to enable menu tear-offs in Gnome. As far as I
can
Hi,
I'm leaving the Gimp list now as I'm not actively intrested in the
internals of Gimp's development. I just hope that my suggestion from
December of restoring the non-destructive crop functionality (which
sparked quite some discussion) will not be forgotton - this is a simple
feature
On Fri, Mar 27, 2009 at 08:02:13PM +0100, Sven Neumann wrote:
Hi,
On Wed, 2009-03-25 at 14:52 -0700, drizzt wrote:
Just think of the most used piece of code on a GNU/Linux system: the Linux
kernel. Didn't you know that the user interface is stable ?
How would you feel if between
Hi,
On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:
Still that narrow minded? You obviously didn't read the drizzt's post
at all! Drizzt was comparing the linux kernel _user_ interface with the
gimp's _user_ interface.
As far as I know the kernel doesn't have a user interface in the
David Odin wrote:
Drizzt was comparing the linux kernel _user_ interface with the
gimp's _user_ interface.
Comparing a kernel user interface with an image editor user interface
is just plain silly.
[...]
Well, of course, everything could be better if more people would be
even
On Fri, Mar 27, 2009 at 08:51:10PM +0100, Sven Neumann wrote:
Hi,
On Fri, 2009-03-27 at 20:29 +0100, David Odin wrote:
Still that narrow minded? You obviously didn't read the drizzt's post
at all! Drizzt was comparing the linux kernel _user_ interface with the
gimp's _user_
Samp, I didn't look at the archive -- but the functionality you are
seeking appears to be in the rectangle selection tool.
Select a rectangle, move your cursor within the selected rectangle. If
it's close to an edge, you can move the edge. If it's not, you can move
the rectangle.
Actually, if
Hi,
On Fri, 27 Mar 2009, bgw wrote:
Samp, I didn't look at the archive -- but the functionality you are seeking
appears to be in the rectangle selection tool.
Select a rectangle, move your cursor within the selected rectangle. If it's
close to an edge, you can move the edge. If it's not,
Once again, I reply to many posts, and with a long message, but it seems that
people are interested in the discussion, so I wont deceive them.
Martin Nordholts a écrit :
Comparing a kernel user interface with an image editor user interface
is just plain silly.
I don't think so, but maybe some
Sampo Niskanen (spnis...@cc.hut.fi) wrote:
The point is changing the canvas size, but leaving the layers uncropped.
The current crop tool always crops the layers to the selected area, so you
cannot fine-tune the position afterwards - previously there was the option
of cropping only the
27 matches
Mail list logo
