Re: Gimp-developer Digest, Vol 78, Issue 48

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On Thu, Mar 26, 2009 at 7:40 AM, <gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx> wrote:
Send Gimp-developer mailing list submissions to
       gimp-developer@xxxxxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
       https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
or, via email, send a message with subject or body 'help' to
       gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
       gimp-developer-owner@xxxxxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gimp-developer digest..."


Today's Topics:

  1. Re: Dockable Dialogs Should be Dockable Everywhere
     (Alexandre Prokoudine)
  2. Re: GIMP PDF export plugin (Andrew A. Gill)
  3. Re: GIMP PDF export plugin (Andrew A. Gill)
  4. Re: GIMP PDF export plugin (Graeme Gill)
  5.  a good student UI project... (Nicolas Robidoux)
  6.   a good student UI project... (Nicolas Robidoux)


----------------------------------------------------------------------

Message: 1
Date: Thu, 26 Mar 2009 01:16:04 +0300
From: Alexandre Prokoudine <alexandre.prokoudine@xxxxxxxxx>
Subject: Re: Dockable Dialogs Should be Dockable
       Everywhere
To: GIMP Developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID:
       <733f2c730903251516l180719d6pdb254a6c548d5e2b@xxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1

On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote:

>> A tool should work out of box and help getting the work done right away.
> But if each time you take your tool out of the box, it's behavior has
> changed, you cannot use it. So maybe you are creating a thing new users can
> play with, but please keep in mind that there are people currently using the
> tool !!!

I feel justified to reply only to this one, but it basically covers
all of your email. You seem to be separating users into two groups: 1)
those who like GIMP the way it is now and do not want any other UI and
2) new users who don't care what the previous UI looked like. And you
seem to be in the first group. Too bad, because this distinction is
incorrect. There's plenty of actual GIMP users who desperately want a
better UI , a lot of users who kind of don't mind a new UI and a whole
lot of users who don't know yet how much they will love a new UI.

Now regarding old tool/new tool. Do you know what is one of most
disgusting things in applications like ACD Canvas that are over 20
years old? It's the ugly way their developers never ever refine them.
Just like you say they keep all the old tools, all the old behaviours,
everything they don't feel comfortable to throw away. And it piles up.
How about "A" hotkey that is in use by three (sic!) different tools
depending on tool group? How about 3-level nested toolbox? How about
separate erasers for bitmap and vector objects? These applications
become a horror to use for both old-timers and novices.

Now please give this a lot of thought before replying.

P.S. Shouting is of no help in this list.

Alexandre


------------------------------

Message: 2
Date: Wed, 25 Mar 2009 18:20:46 -0400 (EDT)
From: "Andrew A. Gill" <superluser@xxxxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: peter sikking <peter@xxxxxxxxxxxx>
Cc: GIMP Developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>,
       scribus@xxxxxxxxxxxxxxxxxx
Message-ID: <alpine.LNX.1.00.0903251807280.31469@localhost>
Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII

On Wed, 25 Mar 2009, peter sikking wrote:

> Alexandre Prokoudine wrote:
>
>> There was a somewhat heated discussion of this thread at
>> linuxgraphics.ru forum and here are several examples from people who
>> deal with prepress work on daily basis:
>>
>> 1. Client brings an image for poster in CMYK which needs color
>> correction. Urgent work, not time to ask him to redo it. Double color
>> space conversion is out of question. So he had to use Photoshop from
>> VMWare.
>>
>> 2. You have a newspaper where first page should have a two-color
>> photo: black (C=0%M=0%Y=0%K<=100%) and blue (C<=100%M=0%Y=0%K=0%).
>> separate+ however separates black to 4 channels.
>>
>> 3. Some print houses set limit to overall sum of colors, for example
>> 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a
>> little of K and Y this will result in unnatural colors in a newspaper.
>>
>> 4. Live density control for each CMYK channel is a must (Scribus/SVN
>> has that in preview dialog).
>>
>> To me it's somewhat strange that GIMP's product vision doesn't mention
>> prepress needs explicitly.
>
> A vision is an _expression_ of the project of what they want
> the software to be.
>
> There is choice in there, and the user community cannot demand
> that GIMP does certain things. For instance making web mockups
> (including the required html + css generation) is explicitly not
> supported.
>
> Now what about that prepress. I think it is fairly safe to say
> that scribus' vision is to be prepress-king and GIMP should watch
> it not to want to overlap too much in that department. Everything
> in the above examples that reeks of newspaper, publications or
> multiple pages is a job for scribus. They want to do this.

Scribus is vector-based, not raster based.

I do not believe that Scribus has any intent to be allow
raster-based editing, but I could be wrong.

I have CC'd the Scribus list.  Let us hear their opinions.  Does
Scribus intend to allow people to tackle the problems listed
above?

Or would you be able to trap the following image with Scribus?

<http://www.ets.ru/images/pk000075.jpg>

> The vision does speak about creating original art and I am all for
> it to bring this original art to the printing press. And not via
> the print dialog (I am also mr. openPrinting) but those printing
> presses that have operators. From the description above you can
> see what is should be like: first you create the art, then you
> bring it to the press. Mix master tape (in rgb) and then cut
> the lp (in cmyk).

As someone who works in prepress, I can tell you that when we
take it from original artwork to press, we have to run any raster
artwork through Photoshop or a competing product.

--
| Andrew A. Gill     To ensure continued quality of service,   |
|                    this e-mail is being monitored by the NSA |
| <superluser@xxxxxxxxxxxxxxx> <http://www.needsfoodbadly.com> |
                                                              --


------------------------------

Message: 3
Date: Wed, 25 Mar 2009 18:21:09 -0400 (EDT)
From: "Andrew A. Gill" <superluser@xxxxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: Alexandre Prokoudine <alexandre.prokoudine@xxxxxxxxx>
Cc: GIMP Developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <alpine.LNX.1.00.0903251800290.31469@localhost>
Content-Type: text/plain; charset="iso-8859-15"

On Wed, 25 Mar 2009, Alexandre Prokoudine wrote:

> On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote:
>
>> Agreed. ?I don't think anyone here is looking for a Photoshop clone (I know
>> that I personally hate PS for a variety of reasons), but we do realize that
>> it has to compete with Photoshop, and not addressing the issues of large
>> sections of the design market when your competitor does is probably not the
>> best move.
>
> Do we realize that? :)
>
> It is true that GIMP is usually seen as to-be-photoshop-substitution
> and its maturity in various areas in fact is the reason why people
> switch to GIMP. However GIMP doesn't seem to be driven by a will to
> make Photoshop die, die, die :)

<http://www.businessdictionary.com/definition/competitor.html>

It's a product that has similar features.  It's a competing
product.

(Personally, I want to make Photoshop die, die, die, but that's
mainly because of a deep loathing for the UI.)

--
| Andrew A. Gill     To ensure continued quality of service,   |
|                    this e-mail is being monitored by the NSA |
| <superluser@xxxxxxxxxxxxxxx> <http://www.needsfoodbadly.com> |
                                                              --

------------------------------

Message: 4
Date: Thu, 26 Mar 2009 10:19:12 +1100
From: Graeme Gill <graeme2@xxxxxxxxxxxxx>
Subject: Re: GIMP PDF export plugin
To: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
Message-ID: <49CABBF0.9000609@xxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

peter sikking wrote:

> Now what about that prepress. I think it is fairly safe to say
> that scribus' vision is to be prepress-king and GIMP should watch
> it not to want to overlap too much in that department. Everything
> in the above examples that reeks of newspaper, publications or
> multiple pages is a job for scribus. They want to do this.

As I understand it, Scribus is not a pixel editor, it is
a page layout package, rather a different thing altogether.

So you're saying that Scribus should add a pixel editing
package to their application, so that they can support CMYK
and other non-RGB color spaces, duplicating an awful lot
of what's in GIMP ?

> The vision does speak about creating original art and I am all for
> it to bring this original art to the printing press. And not via
> the print dialog (I am also mr. openPrinting) but those printing
> presses that have operators. From the description above you can
> see what is should be like: first you create the art, then you
> bring it to the press. Mix master tape (in rgb) and then cut
> the lp (in cmyk).

I really don't think people working in the graphic
arts are going to want to master two different pixel editing
packages, simply because one of them doesn't support anything
other than RGB. If they're in the Linux sphere, then I guess
they need to go and look at using Krita instead.

[ ie. handling CMYK and other colorspaces is a superset
 capability, with RGB being a subset, and the colorspace is orthogonal
 to the pixel manipulation capabilities ]

Graeme Gill.


------------------------------

Message: 5
Date: Wed, 25 Mar 2009 19:32:24 -0400
From: Nicolas Robidoux <nrobidoux@xxxxxxxxxxxxxxxx>
Subject:  a good student UI project...
To: peter sikking <peter@xxxxxxxxxxxx>
Cc: GIMP Developer <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <18890.48904.286747.696030@xxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii


Peter:

Here is a suggestion UI project for training purpose:

Right now, in GEGL, you have access to the whole 2-parameter family of
cubic splines for resampling, as well as bilinear.

Pick three representatives, say Catmull-Rom ("lots" of halo),
smoothing B-Splines ("lots" of blur) and bilinear ("lots" of jaggies).

(Instead of bilinear you could use nohalo a.k.a. gegl-sampler-sharp.c.)

If you want to stick to what's already in the Gimp you could use
lanczos, cubic and bilinear.

Now: Any location within a triangle defines barycentric coordinates,
which in term define a "blending" of the three methods.

Construct an interface which mimicks

     http://www.cambridgeincolour.com/tutorials/digital-photo-enlargement.htm

except that instead of using it as a descriptive tool, we use it as a
way of "picking your blend of poison."

Now, I don't know how attractive it is to ask people to pick a method
by focusing on their weaknesses, but it certainly is a realistic way.

Also note that this interface would allow one to drive any triad of
resampling methods which can be compared and characterized in terms of
the three common artifacts.

Nicolas Robidoux
Laurentian University







------------------------------

Message: 6
Date: Wed, 25 Mar 2009 19:39:57 -0400
From: Nicolas Robidoux <nrobidoux@xxxxxxxxxxxxxxxx>
Subject:   a good student UI project...
To: peter sikking <peter@xxxxxxxxxxxx>, GIMP Developer
       <gimp-developer@xxxxxxxxxxxxxxxxxxxxxx>
Message-ID: <18890.49357.958733.880641@xxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii


Peter:

Of course, you could also use the interface to choose between three
cubic methods, which makes a lot of sense within GEGL (the "jaggy" one
would be lagrangian bicubic).

Nicolas Robidoux
Universite Laurentienne


------------------------------

_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer


End of Gimp-developer Digest, Vol 78, Issue 48
**********************************************



--
http://www.watch-movies-online-hollywoodkiller.com
_______________________________________________
Gimp-developer mailing list
Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Index of Archives]     [Video For Linux]     [Photo]     [Yosemite News]     [gtk]     [GIMP for Windows]     [KDE]     [GEGL]     [Gimp's Home]     [Gimp on GUI]     [Gimp on Windows]     [Steve's Art]

  Powered by Linux