Re: [Gimp-developer] GIMP for mobile phones

[Chris Mohler]

On Tue, Sep 6, 2011 at 1:56 PM, Alexandre Prokoudine
 wrote:
>> So, is there any progress on the idea of a GIMP ultra-ultra light for
>> smart phones?
>
> In my not so humble opinion there is little to no point making a
> lighter version of GIMP for mobile devices. Simply put, desktop and
> mobile platforms rely on too different types of interaction with
> users.

+1.  Having messed around with GIMP on my n900, it would be a
nightmare to redesign for a touch interface.  Then there's having to
pull in GTK or replace it, battery issues, etc - a long list of
non-fun :)

Now a bare-bones editor based on GEGL/BABL might be interesting.

I'm surprised there's not a basic editor for android already
available.  I'm still on maemo, so I wouldn't know though ;)

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

Re: [Gimp-developer] Fast-painting using the undo stack

[Chris Mohler]

On Mon, Aug 8, 2011 at 2:18 PM, Uri Simchoni  wrote:
> I'd like to know whether I'm inventing something that's already invented, 
> discuss possible implementation strategies, and ask for pointers on how to 
> start

(gtk)recordmydesktop can be configured to record only a certain area
of the screen and ignore the cursor/mouse:
http://recordmydesktop.sourceforge.net/about.php

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

Re: [Gimp-developer] Question about bundled "iBryte" GIMP installer

[Chris Mohler]

2011/7/14 Christopher Curtis :
>> GIMP is licensed under the GNU General Public License, version 2. The
>
> This may not be accurate.  Current GIMP releases are GPLv3:

Oops - guess I need to pay more attention while lurking ;)  I thought
the GPLv3 switch was still in the works...

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

Re: [Gimp-developer] Question about bundled "iBryte" GIMP installer

[Chris Mohler]

On Thu, Jul 14, 2011 at 12:34 PM, Andrew Brandt  wrote:
> -- If this company is distributing this software without your express, 
> written consent, what steps do you plan to take to put an end to this 
> practice?

(I'm not a developer either - I lurk here to keep tabs on the
development version.)

Here is a link to the GPL v2, under which gimp is licensed:
http://www.gnu.org/licenses/gpl-2.0.html

AFAIK, any 3rd party is free to repackage and distribute GIMP as long
as they make the source code available (even if they are bundling it
with crapware, unfortunately).

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

Re: [Gimp-developer] dynamic text plugin

[Chris Mohler]

Try:
sudo apt-get build-dep gimp

Then try running 'make' again.

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

Re: [Gimp-developer] CMYK file export plug-in

[Chris Mohler]

On Mon, Mar 21, 2011 at 5:30 PM, gespert...@gmail.com
 wrote:
> Those operations are:
> - Combining the alpha channel of the pure C, M, Y, K areas with the
> corresponding separated channel via screen blending mode.
> - Converting desired CMYK percentages to grayscale values and fill the
> selection (the alpha of the area that should have a specific CMYK)
> with the resulting values for each layer created by Separate+
>
> The resulting file will be perfectly fine, but reaching that point is
> tedious and several things can go wrong in the process.
> So, what if the ideas of spot layers is applied to Separate+, using
> naming conventions to define what to do with them?

This approach you outline would solve most of the use cases I have for
CMYK (overprint, underlay (for dark substrate), one or more CMYK as
spot/solid color, rich black).

What I really miss from photoshop is the poorly-named "apply image"
command.  It basically allows you to combine any two channels using
the available blending modes (Multiply, Screen, etc.).  Right now, I
have to do a lot of bouncing back and forth between layers, selections
and channels.  But that's probably well beyond the scope of what
you're suggesting so I'll shut up now ;)

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

Re: [Gimp-developer] GIMP vs Photoshop

[Chris Mohler]

On Mon, Mar 7, 2011 at 2:34 PM, Debi Rapson  wrote:
> Can you point me in the direction of where I would go to get GOOD tutorial
> information about GIMP so that I can properly teach it?

I'm a fan of Rolf's tutorials:
http://meetthegimp.org/

HTH,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] GIMP Roadmap - wiki page

[Chris Mohler]

On Wed, Mar 2, 2011 at 1:14 AM, Michael Grosberg
 wrote:
>> > I'm a little uneasy at the moment about the "ban working with numbers for
>> > transformations" comment.
>>
>> It would be nice (IMO) to have a dockable that displays the "numbers"
>> of the transform tool's current selection and transform, and also
>> applies numerical input to the transform tool.
>
> I have a somewhat different solution for this.
>
> When you start messing around with perspective transform and you drag corner
> points every which way, scale and rotate numbers become meaningless. So,
> Precise numbers are not that useful for a free transform tool anyway.
> GIMP could simply keep the existing separate transform tools, but instead of
> displaying them as icons in the toolbox, keep them in their own sub-menu under
> edit-->transform or something.

That would cover the uses I was worried about.

The dockable I was imagining had the following items:
Origin X,Y in pixels
Width in pixels
Height in pixels
Rotation in degrees
X shear in pixels or degrees
Y shear in pixels or degrees

And then some items that would become active only after performing a
perspective transform or clicking on them directly:
Top-Left X,Y in pixels
Top-Right X,Y in pixels
Bottom-Left X,Y in pixels
Bottom-Right X,Y in pixels

I *think* that would cover all of the transformations of the proposed
tool.  And I assume all or most of those values are going to be in
play (and in the undo stack) during use of the transform tool.  But
yeah, just having the one-off dialogs for transforms would work as
well.  I have no real preference either way, but the dockable (or
placing those items in tool options) seems cleaner to me for some
reason.

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

Re: [Gimp-developer] GIMP Roadmap - wiki page

[Chris Mohler]

On Tue, Mar 1, 2011 at 3:46 PM, Kevin Cozens  wrote:
> I'm a little uneasy at the moment about the "ban working with numbers for
> transformations" comment.

It would be nice (IMO) to have a dockable that displays the "numbers"
of the transform tool's current selection and transform, and also
applies numerical input to the transform tool.

Photographers could ignore/hide the dockable entirely and still use
the transform tool by "feeling", and designers would have a method for
performing precise transforms (for example a radial design needing
several exact rotations).

The spec for the tool looks pretty amazing though ;)

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

[Gimp-developer] Fwd: Photoshop “compatibility” mode

[Chris Mohler]

Forgot to reply-all...


-- Forwarded message --
From: Chris Mohler 
Date: Mon, Jan 31, 2011 at 10:10 AM
Subject: Re: [Gimp-developer] Photoshop “compatibility” mode
To: Christopher Curtis 


On Mon, Jan 31, 2011 at 9:33 AM, Christopher Curtis  wrote:
>> I'm actually Ok with this. But we have to agree what we mean by "peer
>> applications" - I'd say gimp and inkscape are, for example, and not gimp
>> and photoshop.
>
> So your argument is that on the "Software Spectrum" GIMP is not a
> graphics application but is first a GNOME application.  For the people
> who want, you know, to create GNOME.  It just happens to create GNOME
> using graphics.

I think the argument is GIMP and Inkscape are peers, while GIMP and
Photoshop are not.  Makes sense to me - I hop between the two quite
often.


> That's sarcasm of course - you say that primary platform trumps
> application domain, and GIMP is GNOME because that's where it's
> hosted; a rather myopic and user-hostile view, IMHO.  Most people
> don't care one whit about GNOME or where GIMP is hosted.  They want
> software that is better than what they currently have, fits the way
> they work, and is relatively familiar ... which is going to lead down
> an ugly road.

Hosting is another straw man, and I believe there are people out there
who are fine with the software they have, people whose workflow is
constantly evolving and people who try new things.  So in other words
that blanket statement cannot possibly be true ;)


> So let me ask you this instead:  Are you going to oppose a patch that
> changes the GIMP shortcut for FG/BG fill to match PhotoShop's on the
> basis that Backspace does something completely different in GEdit?  Or
> on the basis that GIMP is not a PS clone?  Or some other reason?  Or
> would you have no opposition at all?

Personally I would oppose that patch (I'm not a dev).  Why mess with
people who have been using GIMP for years just to mimic some other
application?  There's nothing stopping you from defining your own
shortcuts.

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

Re: [Gimp-developer] Pytho-Fu window not visible

[Chris Mohler]

On Fri, Nov 26, 2010 at 8:10 AM, gnagflow  wrote:
> I installed gimp 2.6.11 on windows7 and Pyton2.6 32-bit with PyCairo, PyGtk, 
> PyGObject.
> I see in gimp under Filters - Python-Fu - Console. But if I click on console, 
> nothing happens but for a short hourglass cursor. the python console doesn't 
> appear.
> What could be the mistake?

Questions about how to install are better suited to the gimp-user
mailing list.  Since you already have a thread going on this same
subject, I'd go back to posting there:
http://gimpusers.com/forums/gimp-user/13080-pytho-fu-window-not-visible

Read the last message in the thread and reply back (there) about what
versions of the python packages you are using.

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

Re: [Gimp-developer] Canvas size, background, and channels

[Chris Mohler]

On Fri, Aug 20, 2010 at 12:29 AM, Martin Nordholts  wrote:
> I would expect it to be filled with what it was filled with when you
> created it, as if it would have no bounds but extend into infinity

Then I wish I could create channels with no fill ;)

(yes, color and opacity but zero fill/solidity - this is not currently
possible AFAICT)

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

Re: [Gimp-developer] Canvas size, background, and channels

[Chris Mohler]

On Thu, Aug 19, 2010 at 10:53 PM,
 wrote:
> Imagine you've made a selection around an object and then saved that
> selection to a channel for later use (for example, a model's face). If
> increasing the canvas size filled the "edges" of the canvas with
> anything but black, then your saved selection would no longer be
> limited to the original object (e.g., the model's face), but would
> also include the edges. It seems more reasonable to me that saved
> selections should not be changed if the canvas size changes.

(forgot to reply-all)

That's pretty much the same (and opposite) problem I'm facing.
Imagine you're storing image data for output in the channels.  100%
solid  = 100% output.  Now, increase the canvas size and there's a
solid border of output.  I must delete it to prevent it from printing.

IMO, storing selections is but a secondary function of spot channels -
their primary function is output to press.  But I'm coming from a
print background, so perhaps I'm biased ;)

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

[Gimp-developer] Canvas size, background, and channels

[Chris Mohler]

Is this a bug? (or a feature ;)

1. Create new RGB image
2. Add channel
3. Increase canvas size
4. Edges of channel are now filled 100% solid, regardless of BG color

I expected:

4. Edges of channel are now filled with % based on BG or possibly FG
color (or 0% fill)

Or am I missing something?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] small Wishlist regarding Guides

[Chris Mohler]

On Wed, Aug 18, 2010 at 5:19 AM,   wrote:
> http://forum.meetthegimp.org/index.php/topic,735.0.html
>
> There are Links to some versions of that script.
> Pick the last one. ;)

There is also a grid of guides script here:
http://registry.gimp.org/node/12003

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

Re: [Gimp-developer] Bug 596066 GIMP/File/Send by Email should use xdg-email

[Chris Mohler]

On Wed, Jul 21, 2010 at 8:10 AM, xianghang liu  wrote:
> Hi,
>
> I think the current implementation is in plug-ins/common/mail.c. A
> dialog box is created to collect information
> about 'from', 'to', 'filename' etc and sendmail command is called to
> send the mail. Now this dialog box only
> needs to collect the filename and after that 'xdg-email --attach
> '  command needs to be called.

Yes - calling 'xdg-email --attach ' should be enough for
most linux setups [0].

I looked at this a long time ago.  See this thread:
http://www.mail-archive.com/gimp-developer@lists.xcf.berkeley.edu/msg18847.html

I was just beginning to study C at that time, so you should probably
ignore any code from me though ;)

Chris

[0] Except that thunderbird has a long-standing bug that causes it to
drop xdg-email attachments, but that is a separate issue.  Evolution
works perfectly the last time I checked.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Gimp UX: Paste

[Chris Mohler]

On Thu, Jun 3, 2010 at 8:47 PM, Sven Neumann  wrote:
>> I bound this to ctrl-v and played for a while and it feels pretty
>> intuitive.  One "feature" is that if you make a selection and go
>> ctrl-x, ctrl-v it pastes the cut out bit exactly where it was cut out
>> from, which makes sense.
>
> That is what GIMP has been doing all the time, right ?

Yes, as long as the selection remains.

Selecting nothing and copy+paste also pastes the layer in place -
unless you select a layer with a different size before pasting.  For
example, copying a 300px wide layer, selecting a 600px wide layer and
pasting centers the floating selection.  I'd prefer it pasted in the
original position in this case - but this is only my opinion.

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

Re: [Gimp-developer] Gimp UX: Paste

[Chris Mohler]

On Thu, Jun 3, 2010 at 4:00 PM, Jason Simanek  wrote:
> It sounds
> like you are saying it should be pasted to the exact location where it
> was copied from. I agree. The pasted pixels should end up exactly
> where I copied them from.

>From my own (user) perspective, I wholeheartedly agree: if possible,
paste the pixels exactly where they came from.  That saves a lot of
tedious nudging.

0.02,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Could new version of gimp building swf?

[Chris Mohler]

2010/6/1 Hades :
> In linux env,is there any good swf builder project ?

There's also the flex SDK - but there is no GUI:
http://opensource.adobe.com/wiki/display/flexsdk/Download+Flex+4

It is quite capable if you are good with actionscript.

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

Re: [Gimp-developer] Color space support

[Chris Mohler]

On Fri, May 7, 2010 at 8:42 AM, Jason Simanek  wrote:
> The trouble that most contemporary designers have when it comes to
> creating professional graphics with the Gimp (and Inkscape, Scribus,
> etc.) is due to their lack of knowledge.

(Also anecdotal) - personally, the trouble I have is with the vendors
that require CMYK artwork.  If we could convince the entire industry
to accept color-managed RGB, well sure we'd not need to design
anything in CMYK except corner cases like rich black and overprinting.
 However, from what I can tell of the printing industry (at least in
the US), this is just a nice dream.  As long as they insist on CMYK
artwork, CMYK mode is a necessary evil.

I worked for a printing company for a while.  They preferred CMYK
artwork, the rationale being: people tend to send something with a
#FF background and get angry when the final printed item comes out
different (of course a good proofing system helps here).

But this has all been discussed in depth on this list, and once gegl
is fully integrated we'll have all the tools needed for a managed
workflow, and also the necessary evil of CMYK mode :)

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

Re: [Gimp-developer] Trying to Make a Plug-In

[Chris Mohler]

On Thu, Apr 22, 2010 at 3:04 PM, Callie  wrote:
> My first question would be, what language should I be using and how do I set
> it up so that it will work.

I'd recommend python, as it is pretty easy to pick up even for the
non-programmer.

IIRC the OSX version of GIMP includes python support - you can check
by selecting Filters->Python-Fu->Console.  If that opens, you have
python support.  If so, place plugin (.py) files into "[your
home]/Library/Applications Support/Gimp/plug-ins" (create directory if
necessary).

There's this article, which is a bit dated but still useful:
http://www.gimp.org/docs/python/index.html

Then you might check out the plug-in registry for plug-ins tagged
'python' and study how they are coded:
http://registry.gimp.org/taxonomy/term/52

Also - you can interact with the current image (or create a new image)
in the Python-Fu console, which can be useful.  Also see
Help->Procedure Browser.  All of those functions can be called from
python with pdb.finction_name()

Happy hacking,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ceci n'est pas une selection...

[Chris Mohler]

On Mon, Nov 2, 2009 at 11:49 AM, Sven Neumann  wrote:

> I wonder why you need both hands on the tablet. The pros that I have
> seen working with GIMP always had one hand on the keyboard and the other
> hand holding the tablet pen. I don't want to offend you in any way, I
> just would like to understand why using the tablet and the keyboard at
> the same time is not an option for you.

After some of these replies, just wanted to say that this describes
*exactly* how I work.  In addition to the actual drawing/editing I
also need to track email and web pages, so I need to be able to jump
between kb+pad and full kb easily (pretty much just drop the pen into
my lap and start typing).

I'd like to ask the folks who do not keep a hand on the keyboard: how
do you save files?  How do you enter text into GIMP?  Do you not use
modifier keys when selecting/drawing?  I find that just about
everything I do (in any drawing program) requires both hands - but I
would like to hear more about how others work.

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ceci n'est pas une selection...

[Chris Mohler]

On Fri, Oct 30, 2009 at 7:37 PM, David Gowers <00a...@gmail.com> wrote:
> On Sat, Oct 31, 2009 at 10:59 AM, peter sikking  wrote:
>> guys,
>>
>> would like to tap the wisdom of this crowd here.
>>
>> say I have made a selection in GIMP, done what needed to be done to the
>> pixels in the selection and now want to get rid of the selection.
>>
>> the obvious way is Select->None.
>>
>> how many more ways are there?
>
> 1. Use rectangle/ellipse select to select nothing (single click)
> 2. Activate QMask, drop black on the image, exit QMask
> 3. Use the Move tool in Selection mode to throw the selection mask off canvas.

4. (or 0 really), CTRL-SHIFT-A.  This is what I always do - it makes
sense to me.

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

Re: [Gimp-developer] The name "Gimp"

[Chris Mohler]

On Fri, Oct 30, 2009 at 4:53 PM, Scott  wrote:
>
> Way OT, but speaking of getting in trouble with acronyms, I remember
> years ago at law school when someone founded a "Christian Legal
> Association" there, and they would post bulletins on the
> walls. Somebody (hmmm, wonder who?...) started posting bulletins about
> upcoming meetings of the PLO - Pagan Legal Organization.

OK - so I was determined to ignore this thread, but since we're
getting way OT: some years ago a new Christian academy appeared in our
city.  Unfortunately, they named this institution "First Assembly of
God School".  Hilarity ensued, in the form of football uniforms and
school buses emblazoned with the acronym.

The name was promptly changed.

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

Re: [Gimp-developer] The name "Gimp"

[Chris Mohler]

On Wed, Oct 28, 2009 at 1:35 PM, John B  wrote:

> IMO this would be a valid reason for a name change. Has that ever been
> considered?

Search the archives - this has been discussed to death... and there
will be no name change.

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

Re: [Gimp-developer] GIMP T-shirts in our online store

[Chris Mohler]

On Sun, Oct 25, 2009 at 7:18 PM, Ismael Barros²  wrote:
> On Sun, Oct 25, 2009 at 7:04 PM, Chris Mohler  wrote:
>> On Sun, Oct 25, 2009 at 12:54 PM, Omari Stephens  wrote:
>>> Guillermo Espertino wrote:
>>>> Ismael:
>>>> I don't know the official position about this, but I think that the
>>>> Wilber image you used looks pretty dated. I'd use the Tango version or
>>>> the icon for Mac that Jimmac designed.
>>>> They look much better and as far as I could see, the Tango version is
>>>> being used for GIMP since 2.4
>>>>
>>>> http://macin.files.wordpress.com/2008/09/gimp-icon-512x512.png
>>>> http://jimmac.musichall.cz/images/blog/gimp-mac.png
>>>
>>> Gradients are hard and expensive to do on T-shirts.  Most t-shirts are 
>>> screen
>>> printed, which means that distinct colors are layed down one at a time.
>>> Usually, there is no blending.
>>
>> I do t-shirts with gradient/blending all of the time - it's not any
>> more expensive, but it can be trickier to set up and print.  The main
>> thing I see w/those PNGs is that they are too low-res for a full-front
>> print:
>> http://upload.wikimedia.org/wikipedia/commons/4/45/The_GIMP_icon_-_gnome.svg
>
> That's with transfer/sublimation or with screen printing?
> We use this: 
> http://www.freewear.org/images/navigation/compiling/compiling_xr.jpg
> With our technique what Omari Stephens states is true, that's why we
> always try to remove gradients and to minimize the number of colors of
> each design.

Heh - I've pulled a manual halftone screen before, and I assure you
that _with my own eyes_ I have witnessed a woman screening four-color
process *manually*.  Onto sweatshirts.  Now I would never recommend
4CP on a manual press, but it can be done ;-) And a halftone gradient
with 2 or 3 spot colors is really not that hard once you've nailed the
halftone size/shape/angle, screen mesh, and exposure time.

And for the record I dislike DTG (direct to garment) and sublimation
printing - give me screens and good old plastisol any day ;)

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

Re: [Gimp-developer] GIMP T-shirts in our online store

[Chris Mohler]

On Sun, Oct 25, 2009 at 12:54 PM, Omari Stephens  wrote:
> Guillermo Espertino wrote:
>> Ismael:
>> I don't know the official position about this, but I think that the
>> Wilber image you used looks pretty dated. I'd use the Tango version or
>> the icon for Mac that Jimmac designed.
>> They look much better and as far as I could see, the Tango version is
>> being used for GIMP since 2.4
>>
>> http://macin.files.wordpress.com/2008/09/gimp-icon-512x512.png
>> http://jimmac.musichall.cz/images/blog/gimp-mac.png
>
> Gradients are hard and expensive to do on T-shirts.  Most t-shirts are screen
> printed, which means that distinct colors are layed down one at a time.
> Usually, there is no blending.

I do t-shirts with gradient/blending all of the time - it's not any
more expensive, but it can be trickier to set up and print.  The main
thing I see w/those PNGs is that they are too low-res for a full-front
print:
http://upload.wikimedia.org/wikipedia/commons/4/45/The_GIMP_icon_-_gnome.svg

> Additionally, because colors are added one-at-a-time, adding colors directly
> increases the production time and cost of the shirt.

Very true ;)

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

Re: [Gimp-developer] Hacking on the mail plugin

[Chris Mohler]

On Sun, Oct 4, 2009 at 4:59 PM, Chris Mohler  wrote:

> Looking at the new api docs, it seems possible to raise a GimpDialog
> that contains something like a toggle for "Native XCF or Export" and
> also the new 'gimp_export_dialog_new' widget.  Does this sound
> reasonable?

Also - is there some way to grab a list of all of the file types
supported by GIMP automatically?  I've taken a look in the
app/dialogs/file-save-dialog, but I'm beginning to doubt that a call
like 'gimp->plug_in_manager->export_procs' is possible from a
plug-in...

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Hacking on the mail plugin

[Chris Mohler]

On Sun, Oct 4, 2009 at 1:25 PM, Sven Neumann  wrote:

> This should probably read
>
>  gchar *xdgargs[4];

(sorry forgot to reply-all)

Oops (facepalm).  Thanks.

So, I've written a replacement plug-in that works pretty well.
However, the only filetype supported is still .XCF.

Looking at the new api docs, it seems possible to raise a GimpDialog
that contains something like a toggle for "Native XCF or Export" and
also the new 'gimp_export_dialog_new' widget.  Does this sound
reasonable?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Hacking on the mail plugin

[Chris Mohler]

OK, so I thought bug 596066
(https://bugzilla.gnome.org/show_bug.cgi?id=596066) might be easy
enough for me, an admitted novice in C.

However, I can not for the life of me figure out why my call to
g_spawn_async throws a segfault every time.  I would be most grateful
if someone could point out the problem (I'm sure it's a newbie error
on my part).

This patch has known problems.  Due to the new import/export structure
(I think), it will only work on native .XCF files right now., and the
file must be saved.  There is some legacy code from the original
sendmail plugin hanging around that isn't doing much.  And the
segfault of course :)  And finally, xdg-email is broken, and needs to
be patched in order for Evolution or Thunderbird to even accept
attachments.  You can grab the patch for xdg-email from launchpad
(filed upstream also):
https://bugs.launchpad.net/ubuntu/+source/xdg-utils/+bug/408350

The git patch is attached.

Thanks!
Chris

PS - is there any reason to maintain backwards compatibility with the
original mail plugin?  The attached patch was a heavy-handed attack
just to see if I could get it working with xdg-utils - I have not
really settled on the best approach yet.
From 099cf07983d1dbc82510952b2a2bce798b7ef62f Mon Sep 17 00:00:00 2001
From: Chris Mohler 
Date: Sat, 3 Oct 2009 21:10:35 -0500
Subject: [PATCH] Update mail plugin to use xdg-email

This is a work-in-progress patch to use xdg-email instead of sendmail.  There are known problems.
---
 plug-ins/common/mail.c |  501 +++-
 1 files changed, 30 insertions(+), 471 deletions(-)

diff --git a/plug-ins/common/mail.c b/plug-ins/common/mail.c
index 8f5625a..19b8e71 100644
--- a/plug-ins/common/mail.c
+++ b/plug-ins/common/mail.c
@@ -102,8 +102,8 @@ static const guint8 mail_icon[] =
 };
 
 
-#ifndef SENDMAIL
-#define SENDMAIL "/usr/lib/sendmail"
+#ifndef XDGEMAIL
+#define XDGEMAIL "/usr/bin/xdg-email"
 #endif
 
 #define BUFFER_SIZE 256
@@ -114,10 +114,6 @@ static const guint8 mail_icon[] =
 typedef struct
 {
   gchar filename[BUFFER_SIZE];
-  gchar receipt[BUFFER_SIZE];
-  gchar from[BUFFER_SIZE];
-  gchar subject[BUFFER_SIZE];
-  gchar comment[BUFFER_SIZE];
 } m_info;
 
 
@@ -128,26 +124,11 @@ static void   run  (const gchar  *name,
 gint *nreturn_vals,
 GimpParam   **return_vals);
 
-static GimpPDBStatusType  save_image   (const gchar  *filename,
+static GimpPDBStatusType  save_image   (gchar 		 *filename,
 gint32image_ID,
 gint32drawable_ID,
 gint32run_mode);
 
-static gboolean   save_dialog  (void);
-static void   mail_entry_callback  (GtkWidget*widget,
-gchar*data);
-static void   mesg_body_callback   (GtkTextBuffer*buffer,
-gpointer  data);
-
-static gboolean   valid_file   (const gchar  *filename);
-static void   create_headers   (FILE *mailpipe);
-static gchar* find_extension   (const gchar  *filename);
-static gboolean   to64 (const gchar  *filename,
-FILE *outfile,
-GError  **error);
-static FILE * sendmail_pipe(gchar   **cmd,
-GPid *pid);
-
 
 const GimpPlugInInfo PLUG_IN_INFO =
 {
@@ -159,11 +140,9 @@ const GimpPlugInInfo PLUG_IN_INFO =
 
 static m_info mail_info =
 {
-  "", "", "", "", ""
+  ""
 };
 
-static gchar *mesg_body = NULL;
-
 
 MAIN ()
 
@@ -176,16 +155,11 @@ query (void)
 { GIMP_PDB_IMAGE,"image", "Input image" },
 { GIMP_PDB_DRAWABLE, "drawable",  "Drawable to save" },
 { GIMP_PDB_STRING,   "filename",  "The name of the file to save the image in" },
-{ GIMP_PDB_STRING,   "to-address","The email address to send to" },
-{ GIMP_PDB_STRING,   "from-address",  "The email address for the From: field" },
-{ GIMP_PDB_STRING,   "subject",   "The subject" },
-{ GIMP_PDB_STRING,   "comment",   "The Comment" },
-{ GIMP_PDB_INT32,"encapsulation", "ignored" }
   };
 
   gimp_install_procedure (PLUG_IN_PROC,
   N_("Send the image by email&quo

Re: [Gimp-developer] Compiling from git on Ubuntu 9.04

[Chris Mohler]

On Sat, Oct 3, 2009 at 4:27 PM, Alexia Death  wrote:
> On Sat, Oct 3, 2009 at 10:02 PM, Chris Mohler  wrote:
>> On Sat, Oct 3, 2009 at 1:54 PM, Chris Mohler  wrote:
>>> Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to
>>> proceed, and Ubuntu 9.04 is shipping 2.16.1.

>> Compiling 2.16.6 now, sticking in /opt...
>
> you probably should remove any *.la files from your /usr/lib, or you
> will run into a bad dependency/libtool hell. Happened to me after
> installing gtk from git, and I was told this is common.

Well, I installed gtk 2.16.6 into /opt/gtk, then exported my
LD_CONFIG_PATH to there before compiling gimp (and also added to
PKG_CONFIG_PATH), so hopefully I've sidestepped that.  If I'm headed
for trouble with this approach, someone please let me know :)

It seems to be working OK, but it's not picking up the current GTK
settings/devices (like tablet).  I think this method will work well
enough for testing purposes though, and my stock 2.6.6 install seems
to be working just fine.

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Compiling from git on Ubuntu 9.04

[Chris Mohler]

On Sat, Oct 3, 2009 at 1:54 PM, Chris Mohler  wrote:
> Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to
> proceed, and Ubuntu 9.04 is shipping 2.16.1.
>
> Any ideas?

Never mind :)

Compiling 2.16.6 now, sticking in /opt...

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

[Gimp-developer] Compiling from git on Ubuntu 9.04

[Chris Mohler]

Hi,

Not sure how best to proceed - GIMP is requiring libgtk 2.16.6 to
proceed, and Ubuntu 9.04 is shipping 2.16.1.

Any ideas?

Also - the INSTALL file probably needs an update:
  4. You need to have installed GTK+ version 2.16.1 or newer

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

Re: [Gimp-developer] Bug #164774

[Chris Mohler]

On Mon, Sep 14, 2009 at 6:12 PM, Michael J. Hammel
 wrote:
> On Mon, 2009-09-14 at 17:50 -0500, Chris Mohler wrote:
>> I think it's reasonable to pair rulers and guides, and would certainly
>> want to keep the ability to drag a guide from a ruler.
>>
>> However, if there were an alternate method I might use it as well -
>> something like press a key, the mouse is now dragging a guide, click
>> on the window and get a new guide.  Maybe some sort of modifier to
>> toggle/go horizontal/vertical?  Seems like part of the code would
>> already be there in the 'New Guide' menu item, but have not looked...
>
> This is actually the point I'm trying to make.  How is any key/mouse
> combination going to be any more intuitive/less complex than dragging
> from a ruler?  Decoupling adds complexity (at a minimum forcing users to
> learn a new process, but probably worse than that) for the sake of
> cleanliness (re: being able to hide the rulers), but I don't think the
> trade offs are worth it.

Well, I don't think so either.  I find the method of dragging from the
ruler to be quite intuitive already.  Then again, I was trained since
PS 2.0 (or thereabouts) that guides come from rulers - so I might be
biased ;)  But if ui team is determined to find a way to add guides
w/o rulers, then a kb shortcut is the way I'd go - that's all I had to
say :)

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

Re: [Gimp-developer] Bug #164774

[Chris Mohler]

On Mon, Sep 14, 2009 at 5:09 PM, peter sikking  wrote:
> Michael J. Hammel wrote:
>
>> On Mon, 2009-09-14 at 22:21 +0200, peter sikking wrote:
>>> Michael J. Hammel wrote:
 Isn't this already possible with Image->Guides->{New Guide,New Guide
 (by
 Percent)}?  What would this "decoupling" add to this?
>>>
>>> being able to place a new guide with your mouse 'just there'
>>> by feeling using your expert eye.
>>
>> You can already do this with guides - just drag them from the rulers.
>
>
> I was aiming for this without involving rulers...

I think it's reasonable to pair rulers and guides, and would certainly
want to keep the ability to drag a guide from a ruler.

However, if there were an alternate method I might use it as well -
something like press a key, the mouse is now dragging a guide, click
on the window and get a new guide.  Maybe some sort of modifier to
toggle/go horizontal/vertical?  Seems like part of the code would
already be there in the 'New Guide' menu item, but have not looked...

0.02
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Mon, Jul 6, 2009 at 5:45 PM, Sven Neumann wrote:
> Hi,
>
> On Mon, 2009-07-06 at 17:32 -0500, Chris Mohler wrote:
>
>> When using the old, unnamed register() parameters, if you leave
>> 'params' empty, the main plug-in function still receives two
>> parameters - the current image and drawable.  Using the new, named
>> register() parameters does not seem to do this anymore.
>>
>> No big deal really, but I thought it odd that the behavior would be 
>> different.
>
> That is exactly the odd quirks mode for backward compatibility that I
> mentioned. If you use the old register() API, then parameters are added
> for you depending on the menu location your script is registering to. As
> that is hard to understand and frequently leads to automatically added
> parameters that the script does not actually need, this behavior was
> changed. It is still there, for backward compatibility, if you use the
> old API though.

OK - thanks for clarifying that.  I had no idea that the automatic
parameters varied based on menu location.

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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Mon, Jul 6, 2009 at 5:19 PM, Sven Neumann wrote:
> Hi,
>
> On Mon, 2009-07-06 at 16:58 -0500, Chris Mohler wrote:
>
>> I had a little trouble finding docs on the named parameters (I ended
>> up using help(gimpfu.register) in the console).  I've pasted the new
>> register() below - one thing seemed strange: the 'params' parameter
>> seems to require that I add the current image and drawable - is that
>> correct?  Any other big mistakes here?  ;)
>
> Why does it require that? What's required is that you register all the
> parameters that your function actually needs. If you need an image
> parameter, then you should have PF_IMAGE in your input parameters. If
> you also need a drawable, then this should be followed by PF_DRAWABLE.
> But these are by no means obligatory. If you don't need an image nor a
> drawable, then you can safely omit them.

Sorry - I did not phrase that very well.

When using the old, unnamed register() parameters, if you leave
'params' empty, the main plug-in function still receives two
parameters - the current image and drawable.  Using the new, named
register() parameters does not seem to do this anymore.

No big deal really, but I thought it odd that the behavior would be different.

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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Sun, Jul 5, 2009 at 9:42 PM, Alec Burgess wrote:

> Whether paths are Active or not does not appear to change results - it still
> shows the measurement.

I've updated the plug-in at the registry
(http://registry.gimp.org/node/17235).  If in doubt which is which, I
added 'Version 0.2' to the header info of this one.

In linux and XP (both 2.6.6), it reports the length of whichever path
is selected in the Paths dialog.

I also fixed the 'Repeat' and 'Reshow' weirdness, and also disabled
the plug-in when no image is open.

Let me know how it works out...

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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Mon, Jul 6, 2009 at 2:55 PM, Sven Neumann wrote:
> On Sun, 2009-07-05 at 22:42 -0400, Alec Burgess wrote:
>> Bug?: The entry "Filters - Measurement - Path" is always enabled
>> whether or not any path exists (expected) but in Filters-Repeat
>> "Path",  Filters-Reshow "Path" and Filters-Recently Used-Path it
>> always shows as Disabled (grayed out).
>> Is this an easy fix?
>
> This might fix itself if you change your script not to use the
> deprecated register() API. You should instead use the variant that
> passes the menu location as value of the named parameter 'menu'. The way
> your script is using register() triggers an obscure backward
> compatibility quirks mode, which is probably not what you want.

I had a little trouble finding docs on the named parameters (I ended
up using help(gimpfu.register) in the console).  I've pasted the new
register() below - one thing seemed strange: the 'params' parameter
seems to require that I add the current image and drawable - is that
correct?  Any other big mistakes here?  ;)

Thanks,
Chris

register(
proc_name=("python-fu-measure-path"),
blurb=("Measure Path"),
help=("Measure Length of the active path.  Output is directed to
the Status Bar or Error Console."),
author=("Chris Mohler"),
copyright=("Chris Mohler"),
date=("2009"),
label=("Active Path"),
imagetypes=("*"),
params=[
(PF_IMAGE, "img", "Image", None),
(PF_DRAWABLE, "drw", "Drawable", None)
   ],
results=[],
function=(measure_path),
menu=("/Filters/Measure"),
domain=("gimp20-python", gimp.locale_directory)
)
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Mon, Jul 6, 2009 at 12:41 PM, Rob Antonishen wrote:
>>> Bug?: The entry "Filters - Measurement - Path" is always enabled whether or
>>> not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow
>>> "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed
>>> out).
>>> Is this an easy fix?
>>
>> I see the same thing here - I'm not sure what's happening.  I will
>> investigate when I find some time...
>
> I think that if you change the image type to "*" rather than "" it
> will be remembered.

I think you are right - thanks!

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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Sun, Jul 5, 2009 at 9:42 PM, Alec Burgess wrote:

> Works on Windows 2.6.6 but message is displayed in Error console (which I
> have as one of panels in main dock) not on the status bar. Is this somehow
> configurable?
>
> Note: IMO this is a feature not a bug since it allows user to change the
> path and re-measure leaving a "history" record in the Error console.

OK - I don't usually open the error console, but I see the same
behavior in linux with the console open.  I pretty much did just the
bare minimum on the plug-in, but I'm pretty sure it's possible to make
it pop up a message instead, and/or change the message type.


> Whether paths are Active or not does not appear to change results - it still
> shows the measurement.
>
> I created a second much simpler path with Free-Select-Tool then converted to
> path and named it "Path_B". With the two paths it showed: Length of Path_B:
> 383 px.
>
> It appears (based on swapping order of paths with drag+drop) that it always
> shows the length of the lowest path (the one a the bottom of the list)

For me, it gives the length of whatever path is selected in the paths
dialog.  I will install the plugin in Windows at some point and see if
I can reproduce...


> Bug?: The entry "Filters - Measurement - Path" is always enabled whether or
> not any path exists (expected) but in Filters-Repeat "Path",  Filters-Reshow
> "Path" and Filters-Recently Used-Path it always shows as Disabled (grayed
> out).
> Is this an easy fix?

I see the same thing here - I'm not sure what's happening.  I will
investigate when I find some time...


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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Mon, Jul 6, 2009 at 2:57 AM, Dirk
Sohler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Chris Mohler schrieb:
> | What the heck - I added it as a (very) simple plug-in:
> | http://registry.gimp.org/node/17235
>
> I can’t find the menu option „Filters->Measure->Path“. :(

Hmm - did you place the plug-in into ~/.gimp-2.x/plug-ins and is it
executable? (chmod +x)

If so, try starting GIMP from a terminal and see if it throws an error?

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

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Sun, Jul 5, 2009 at 9:51 AM, Dirk
Sohler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi there!
>
> I filed a “bug” with an enhancement request to the GIMP Bugzilla, but
> Martin Nordholts told me, to send a mail to the GIMP developers mailing
> list first, so … here it is :)
>
>
> I had a kind of map opened as image in GIMP. I used the path tool and
> clicked a path alon a route i want to measure. After i did this i tried
> to get the path’s length. But i noticed really soon, that it is not
> possible to output the path’s total length without learning script-fu.

What the heck - I added it as a (very) simple plug-in:
http://registry.gimp.org/node/17235

In 2.6. it returns the length of the path on the status bar.  I used
gimp_message, so IIRC the location of the message is configurable.  It
silently fails if there is no active path - it seems to work OK with
multiple paths, straight lines, and curves.  There is no need to
stroke the path.

You will need to have Python installed though...

HTH,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Improvement for measurement tool

[Chris Mohler]

On Sun, Jul 5, 2009 at 9:51 AM, Dirk
Sohler wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi there!
>
> I filed a “bug” with an enhancement request to the GIMP Bugzilla, but
> Martin Nordholts told me, to send a mail to the GIMP developers mailing
> list first, so … here it is :)
>
>
> I had a kind of map opened as image in GIMP. I used the path tool and
> clicked a path alon a route i want to measure. After i did this i tried
> to get the path’s length. But i noticed really soon, that it is not
> possible to output the path’s total length without learning script-fu.

Hmm - it would probably not be too hard to write a plugin for this.

As a quick test, I created a new image, drew a path, and stroked it.

Then I opened the python console and did:

>>> img = gimp.image_list()[0]
>>> path = pdb.gimp_image_get_active_vectors(img)
>>> len = pdb.gimp_vectors_stroke_get_length(path, 1, 1)
>>> print len
644.628491517

That might choke if you have more than one path - I have not tested.

Is this enough to get you going?

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

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sun, Jun 21, 2009 at 11:22 AM, peter sikking wrote:


>> Imagine I'm designing a black t-shirt with say five spot colors,
>> including white.  After completing the artistic design, I enable the
>> 'projection screen'.  This theoretically would result in my five
>> "plates".  However, the white plate will need special attention.
>>
>> Here's my workflow for this in PS: I would use the (badly named)
>> 'Apply Image' command to take the contents of each color plate and
>> combine them into the white plate using the mode 'multiply'.
>
> this looks analogue to me to black generation in cmyk, but now
> inverted because we are on a black background. interesting concept,
> the media color (makes note). since it is going to work for black,
> it can be made to wok for any other color, with reversed logic also.

Yes, I think media color should be taken into account when designing
this system - even though I suspect the vast majority of media will be
white or very light.

>>  I would
>> also manually "choke" the white plate - this means making the white
>> areas a point or two smaller than the colored areas, thereby
>> preventing the white from poking out at the edges of the colored
>> areas.
>
> this looks like trapping to me. is there a difference?
> trapping set-up for each plate would be in the projection set-up.

A "choke" is a trap of negative amount.  This is probably just jargon
-  I suspect that it should in fact be called a negative trap.
Automatic trapping (and overprinting) has never lived up to my
expectations - I would love to hear from anyone who has used
auto-trapping software with acceptable results though.

>> Now, I am quite interested in learning new workflows - so I am not
>> bound to the "how" of the method above, but I hope I have explained
>> the "why" well enough.  In addition to being able to interact with
>> each plate as a grayscale drawable, it would be useful to create
>> temporary areas for doing work - be they layers, channels, plates,
>> whatever - on which to create paths, selections, etc to in turn use to
>> modify the plates manually.
>
> everything of that will work on plates like working on layers today.
> I am sure that global concepts like paths and selection will be
> applicable to layers and plates without limits. a selection created
> on a layer and applied to a plate: sure.

OK - thanks for clarifying.

>>  Icing on the cake would be a mechanism to
>> combine/subtract plates using the available blending modes.
>
> to generate plates from channels/layers that is needed, but
> generating plates from plates? sounds like a creative kind
> of workflow to me.

I remember one specific instance:  printing two blue colors - one
light, one medium - on very dark blue.  We originally placed the light
blue color behind the medium blue color (overprint).  The client
changed their mind,  and I needed to remove the overprint.  Merging
the (inverted) contents of med blue into the contents of lt blue
removed the overprint in one step.  I basically masked one plate with
another and applied the mask.

While I doubt that function is necessary, it would certainly be very
useful on occasion.

>>  During
>> the process, it is fairly critical to have an ink density/opacity
>> setting for each plate, to simulate (roughly) how the final print is
>> going to look.  EG, set the white plate at approx 90%, the colors at
>> approx 70% - and you can see which portions of the colors are falling
>> on the white underlay, and which portions are falling on the black
>> shirt.
>
> hmmm, tricky that one. it is natural for the plate stack to work
> sort-of like the layer stack. eye symbols to switch plates on/off.
> then there is the opacity slider of the layer stack. coverage slider
> for the plates? ay be does the dual purpose of previewing like you
> need and absolute print balancing.

Indeed - the stack of plates should function more or less like the
layer stack.  Yes - I envision a visibility toggle for each layer, and
also an opacity slider.  But here's another murky area  (as if we
needed more ;) - if I set a plate's opacity to 50%, does 100% black on
that plate print out at 50% or 100%?  I would expect 100% - but that's
from past experience, and not very intuitive.  Perhaps you are right
that we need both a opacity and coverage control - that makes more
sense to me,  but I have never seen it implemented and may well prove
confusing.


>> After re-reading the notes on the talk, if we have a Layer->Plate
>> mapping, I think that will cover most situations.  I would prefer a
>> way to "mix" the plates,
>
> "mixing" channels + layers -> plates is a starting point for the
> development of the design of the plate set-up.

OK - thanks.

>> and to be able to add new layers that could
>> later be applied to new or existing plates, but this could be worked
>> around.
>
> add layers where, image side or press projection side?

My guess is image-side.  One possible scenario:

1. Design artwork in GIMP - RGB, 3 colo

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sat, Jun 20, 2009 at 12:07 PM, yahvuu wrote:
> hi,
>
> Chris Mohler schrieb:
>> On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
>>> i assume the temporary layers are mostly grayscale?
>>
>> Usually RGB layers, or grayscale channels.
>
> sorry, imprecise question. I mean, if you use a temporary RGB layer,
> it's content will still usually be just grayscale, effectively used
> as a mask. Assumed correctly?

Not necessarily - consider another scenario: mixing two spot colors to
create a third color.  More accurately, consider an image (RGB) that
is primarily three colors, and then attempting to print that image in
two colors, getting as close to the original RGB artwork as possible
(the number of spot colors is a major factor in printing cost).

In that scenario, I may end up duplicating the original RGB artwork
several times before getting the selection that I want - then
ultimately filling or erasing that selection on the spot channel(s).
The process can be very non-intuitive at times, and sometimes you just
have to dive in and do some trial and error - esp. if the original RGB
image is something flat that was not originally intended to be printed
in such a way or is "damaged" (eg, not on layers, suffers from JPEG
compression, etc.).

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

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Sat, Jun 20, 2009 at 11:27 AM, yahvuu wrote:
> hi,
>
> Chris Mohler schrieb:
>> Imagine I'm designing a black t-shirt with say five spot colors,
>> including white.
> [..]
>> Whew ;)
>
> Whew, too ;) Makes me wonder if it has to be that hard or if
> it points to some missing software improvements. Trying to understand
> the example, i hope you don't mind some uninformed questions (and also
> some out-of-sequence quoting).
>
> Besides anticipating printing press idiosyncrasies ('choke'),
> it seems to me you're manually creating kind of a color separation.
> Quite naively: doesn't photoshop know you're printing on black?

Yes - I end up doing a lot of it manually, and no it does not know -
having a 'target' or 'base' would be a step forward.

>> Here's my workflow for this in PS: I would use the (badly named)
>> 'Apply Image' command to take the contents of each color plate and
>> combine them into the white plate using the mode 'multiply'.
>
> this is to create the white underpinning, resp. the beginning thereof.
> 'Apply Image' is short-hand for 'blend anything with anything',
> but doesn't do any tricks that could not be achieved with layer stacks
> in combination with proper channel masking. On track?

Yes.

>
>> I would
>> also manually "choke" the white plate - this means making the white
>> areas a point or two smaller than the colored areas, thereby
>> preventing the white from poking out at the edges of the colored
>> areas.  This process can get a bit tricky, especially if the original
>> artwork is very complex.
>
> if the artwork was fully vectorized, say a pure inkscape job,
> would that make things easier?

Of course, but when photographic-type artwork comes into play, it's
usually easier/faster to do the whole thing in a raster editor.

>
>> Often, create temporary layers (or plates),
>> perform selection/drawing functions, then combine the result back into
>> a plate in one of two ways - either making a selection on the temp
>> layer and going to the plate and filling or erasing, or using the
>> 'Apply Image' command to take the RGB channel of the current layer and
>> combine it with a plate using a mode such as Multiply, Screen, or Add.
>
> i assume the temporary layers are mostly grayscale?

Usually RGB layers, or grayscale channels.

> the temporary layers serve as 'mixing stage' because it takes
> several steps to create a desired mask, or is it more
> to keep selections/drawings for reuse?

A little of both.  Sometimes I just need a very complex selection, but
I need to do some work to create the selection.  Other times I need to
store a selection for later use  (that's generally when I make an
extra channel).


After re-reading the notes on the talk, if we have a Layer->Plate
mapping, I think that will cover most situations.  I would prefer a
way to "mix" the plates, and to be able to add new layers that could
later be applied to new or existing plates, but this could be worked
around.

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

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Fri, Jun 19, 2009 at 12:41 PM, peter sikking wrote:
> Chris Mohler wrote:
>
>>>
>>> <http://www.mmiworks.net/eng/publications/2009/06/gimp-squaring-cmyk-circle.html
>>
>> I like this approach.
>>
>> I have a few questions:
>>
>> Will each plate have a density or opacity attribute?  (some inks are
>> more opaque than others)
>
> I guess that the complexities of ink simulation start showing here.

Yes - although transparency/opacity would be enough for me to use GIMP
for professional separation work.  I'm reasonably sure that PS uses a
variant of the blending mode Multiply for spot channels, and this
works fairly well.

>> Will it be possible to edit an individual plate in grayscale?
>
> well, as pippin said: the individual plates _are_ grayscale/monochrome
> drawables. they will be editable just like layer masks or selections.

Excellent.

>> And finally, will it be possible to perform operations on the RGB
>> portion of the image that do not take (immediate) effect on the
>> projection?  For example, if I want to go back and add a portion of my
>> RGB artwork to a plate, I might want to clone and existing RGB layer,
>> perform some modifications, then apply the contents of that new layer
>> to one of the plates.
>
>
> I am curious why you want to do something like that, because you
> are then going against the grain of the whole plan: freedom to develop
> the artistic concept further without (much) rework on the plates.

Imagine I'm designing a black t-shirt with say five spot colors,
including white.  After completing the artistic design, I enable the
'projection screen'.  This theoretically would result in my five
"plates".  However, the white plate will need special attention.

Here's my workflow for this in PS: I would use the (badly named)
'Apply Image' command to take the contents of each color plate and
combine them into the white plate using the mode 'multiply'.  I would
also manually "choke" the white plate - this means making the white
areas a point or two smaller than the colored areas, thereby
preventing the white from poking out at the edges of the colored
areas.  This process can get a bit tricky, especially if the original
artwork is very complex.  Often, create temporary layers (or plates),
perform selection/drawing functions, then combine the result back into
a plate in one of two ways - either making a selection on the temp
layer and going to the plate and filling or erasing, or using the
'Apply Image' command to take the RGB channel of the current layer and
combine it with a plate using a mode such as Multiply, Screen, or Add.

Now, I am quite interested in learning new workflows - so I am not
bound to the "how" of the method above, but I hope I have explained
the "why" well enough.  In addition to being able to interact with
each plate as a grayscale drawable, it would be useful to create
temporary areas for doing work - be they layers, channels, plates,
whatever - on which to create paths, selections, etc to in turn use to
modify the plates manually.  Icing on the cake would be a mechanism to
combine/subtract plates using the available blending modes.  During
the process, it is fairly critical to have an ink density/opacity
setting for each plate, to simulate (roughly) how the final print is
going to look.  EG, set the white plate at approx 90%, the colors at
approx 70% - and you can see which portions of the colors are falling
on the white underlay, and which portions are falling on the black
shirt.

I realize that this is just one corner case, but if you visualize each
plate being printed separately, in order, you may be able to recognize
some of the many 'gotchas' inherent in separating the artistic artwork
into something suitable to send to the press.  That's why (in my
opinion) it is important to have as much control as possible over each
plate.

Whew ;)

If I explained any of this poorly, I am sorry and will happily try to do better.

All in all, I am very pleased with the direction that this is taking
and I would certainly like to use GIMP for even more of my production
work. :)

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] lgm talk, part 2...

[Chris Mohler]

On Fri, Jun 19, 2009 at 10:37 AM, peter sikking wrote:
> guys,
>
> the second part of my lgm talk is blogged now:
>
> 

Re: [Gimp-developer] Procedural call to undo?

[Chris Mohler]

On Mon, May 11, 2009 at 12:31 PM, gg  wrote:
> peter sikking wrote:
>> David Hodson wrote:
>>
>>> That's true, but how does that make undo different from many other
>>> functions?
>>
>> undo involves user having a change of heart.
>>
>> a script cannot have a change of heart.
>>
> No but it can have a conditional execution path dependant on the result
> of a previous command.
>
> resize image
> save test.png
> if (size of file) > 4GB undo resize.

Bit shouldn't that really be:

get image size/depth
calculate target image size
if (target size < 4GB) resize image
?

I agree that Undo should be reserved for human use...

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

[Gimp-developer] Pop-up message

[Chris Mohler]

Hello list,

I've written a python plug-in that uses this function:
pdb.gimp_message($message)

One user in particular is having problems with it, and someone has
advised me that "You just can't expect gimp_message to raise a popup
message window. The error console dockable dialog is there to get rid
of these. ".  Is this true, and if so what methods exist for giving
the user a message upon completion of the plug-in?  The info in the
message is pretty much the whole point of the plug-in...

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] New features that should be nice

[Chris Mohler]

On Sun, Mar 29, 2009 at 2:22 PM, Eduardo Barijan
 wrote:
> Hello Gimp coders!
> I was thinking about 2 new features that would help a lot.
>
> 1 - the auto-save job. When you`re working and gimp crashes, your work is
> lost =x. If not a auto-save, a .bak file that you can save as xcf for
> recover work should be fine too.

Save early, save often - and if in doubt, save a copy ;)  Personally,
I would turn off the auto-save feature if it was an option: I don't
want to automatically save a huge image every X minutes - just my
opinion.

> 2 - An option to save custom collor palettes. Yes, sometimes you are working
> on a big draw. Then when you finish a bit of the work and closes gimp, the
> color pallete you were working is lost. And it is very boring to keep note
> of any hexa code for colors.

I just tested adding colors to a palette and closing GIMP (current
SVN)  - it saved them for me, and the new colors were available when I
restarted GIMP.  What version/OS are you using?

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

Re: [Gimp-developer] New features that should be nice

[Chris Mohler]

On Sun, Mar 29, 2009 at 2:57 PM, Eduardo Barijan
 wrote:
>
> 2009/3/29, Chris Mohler :
>>
>> > Save early, save often - and if in doubt, save a copy ;)  Personally,
>> > I would turn off the auto-save feature if it was an option: I don't
>> > want to automatically save a huge image every X minutes - just my
>> > opinion.
>
> Hm... yes, auto-save huge images isnt so nice. But it would help cause the
> crashes I experience here.

I don't use GIMP on windows very much at all, but I do use it often on
linux - either way it does not crash very often...

>> > I just tested adding colors to a palette and closing GIMP (current
>> > SVN)  - it saved them for me, and the new colors were available when I
>> > restarted GIMP.  What version/OS are you using?
>
> I am using Windows and gimp version 2.6.3 final version. So how to add and
> save palletes then?

I just tested again with XP and GIMP 2.6.6 - there have been some bug
fixes between 2.6.3 and 2.6.6, so you should probably upgrade and see
if it fixes your crashing problems and also saves your palettes...

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

On Wed, Mar 25, 2009 at 2:44 PM, yahvuu  wrote:
> Hi,
>
> Chris Mohler schrieb:
>> I can express any CMYK color in RGB - but not the other way around.
>
> now i'm confused :)
>
> Is CMYK->RGB->CMYK roundtrip safe?

Not really.  What I was trying to say is that I send RGB proof images
to my customers, even though the artwork is in CMYK - and they get a
fairly honest representation of the final print.  I do not actually
convert from CMYK->RGB->CMYK  though - just export RGB from the CMYK
image.

> >From past examples (trapping, rich black) i've come to think that
> hand-optimized CMYK separations can't be transformed back
> to RGB losslessly (quite opposite to gamut issues).

Yeah - that will lead to problems.

> Can some RGB color space be tricked to accommodate overprinting uses?

On that I have no idea...

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

On Wed, Mar 25, 2009 at 1:58 PM, peter sikking  wrote:
> Alexandre Prokoudine wrote:

>> Which means in fact that the team does not wish to meet *real*
>> prepress users needs on product vision level.
>
>
> I would like to have this answered answer first: why can't they
> do it with scribus? are we the last piece of (free) software
> in the world that can help them?

Ah, but Scribus is a layout program, not an image editor.  Ideally,
one would prepare images for printing with GIMP, then embed them in a
page with Scribus.  Having control over the CMYK (or spot color)
makeup of the image in GIMP should make things smoother when setting
the image in Scribus.

As to the projection screen, that approach sounds complicated.  But if
it can give a fairly honest CMYK projection and allow for manually
adjusting the channels, then it would go a long way toward solving
some of these problems.

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

On Wed, Mar 25, 2009 at 12:44 PM, peter sikking  wrote:
> Mix master tape (in rgb) and then cut
> the lp (in cmyk).

I can express any CMYK color in RGB - but not the other way around.
Therefore, I "master" all of my print jobs in CMYK, and if I "cut"
something like a preview for a client then I use RGB space.  So you
see, it's actually quite the opposite in my world.  This is why GIMP
is only a small portion of my day to day work flow - it is not
printer-friendly (yes, friendly to the device sitting on your desk,
but not a person who is a printer).

And I agree that Scribus is coming along nicely and will (hopefully)
become a robust page layout program - but I think where GIMP comes
into the arena is creating a single image that will be printed (in a
magazine, screen printed, newspaper, whatever).  Something like
PDF+CMYK export is a good first step, but ultimately CMYK editing and
channel operations are needed to make GIMP suitable for preparing an
image for print.

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

On Mon, Mar 23, 2009 at 2:57 PM, Sven Neumann  wrote:
> Hi,
>
> On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote:
>
>> The product vision states that "GIMP is a high-end photo manipulation
>> application" and that certainly includes support for editing images in
>> the CMYK color space.
>
> It certainly doesn't. Photos are taken in an RGB color space. It makes
> sense to do some processing in other color spaces such as LAB. But CMYK
> is totally inadequate for manipulating photos.
>
> Being able to do a color separation to CMYK is sometimes required in
> order to prepare an image for print (even though the printer can almost
> always do this much better). Editing an image in CMYK is not required
> though.

It is helpful to see an approximation of CMYK on the screen before you
go to print - many colors available in the RGB color space fall
outside of the CMYK gamut.  RGB blue is likely the worst offender -
fill an image with solid #FF and print it to a color printer and
you will see quite a shift in color.

Take a simple case: annotating a photo with some text (for print use)
- working in CMYK space would prevent the user from using #FF as
the text color (or actually convert it from #FF to its CMYK equiv
on the fly) - giving a reasonably accurate representation of the final
printed output on the screen.

A more complicated case: removing small black text from the CMY
channels manually (to improve legibility) - or more realistically only
applying the small text to the K channel.  Editing the channels in
CMYK would be more comfortable than running through the separation
process first and then making changes - and the ability to use CMYK
swatches (in this case C=0, M=0, Y=0, K=100) could also speed things
up dramatically.

Of course this is not a trivial task, and I'm not holding my breath.
Although it might not be hard to throw up a projection of the current
image with a generic CMYK profile applied to it - that would be enough
to satisfy the simple use-case above.  Oh, and I guess we're rapidly
drifting off-topic in re to PDF export ;)

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

2009/3/22 peter sikking :
> Sven wrote:
>
>>> bummer about the non-standard, but would industrial-strength TIFF
>>> in and export not be significantly more in line with our product
>>> vision than industrial-strength pdf in and export?
>>
>> Depends on what gets used nowadays. If professionals are turning away
>> from TIFF and start to adopt PDF instead, then PDF support would be
>> more
>> in line with our product vision.
>
>
> when I wrote the previous message I already knew that this is the
> only counter-argument that I was going to accept.
>
> so now we really need some trend spotting from those in our community
> who deal with serious printing jobs.

I often use GIMP as a part of my work flow - but almost never for
preparing the final artwork for submission to the printing company -
mainly due to the aforementioned lack of CMYK color space.

Only ~1% of my PDF files submitted to printing companies are 100%
raster.  PDF seems (to me) to be gaining ground against formats like
TIFF, but it's not a "standard" yet (for raster images anyway).  On
one hand, TIFF is still more widely accepted than PDF.  On the other
hand, PDF is well documented.  On the gripping hand, neither format is
useful for print jobs without the CMYK color space - which I know is
somewhat arbitrary, but many printing companies expect files in CMYK.
If I have a choice, I use TIFF or PNG for raster pre-press images -
but it might be wise to look to the future: PDF format has options
(like crop area and bleed) that are useful to printers and the format
seems to be slowly catching up to the "standards" (at least in my
experience over the past few years in the US).

> and when then moving forward with pdf, we should keep in mind
> what a GIMP document actually is: a single canvas/image
> (please do not mention the animation hacks we have...)

You and I are in 100% agreement on this point ;)

So to recap, I would welcome a printer-friendly PDF export if someone
wants to work on it, though without CMYK support built-in it's not
very useful just yet.  From what I understand though, once GEGL
integration is complete, any plugin could be refactored or rewritten
to use higher bit depth and other color spaces.

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

Re: [Gimp-developer] GIMP PDF export plugin

[Chris Mohler]

On Sun, Mar 22, 2009 at 6:19 AM, Sven Neumann  wrote:
[...]
> I don't understand why that is needed. What is our goal here? To create
> PDF files as small as possible? IMO the goal for PDF export should be to
> improve support for professional printing. File size is not important
> for that. Paths are also not important for that. If people need vector
> art, then they should use a vector editor. What matters is color
> profiles, CMYK color separation in the export process, support for spot
> colors, crop marks, ...
>
> As I said already, we can't discuss the details unless we know what the
> goals are. So we need to have one or more user stories for PDF export
> first. And we need to check these against our product vision to see if
> they are worth supporting.

I see two possible use cases:

1. Proofing artwork - you need to prepare a proof before going to
press.  You send that proof to a client and they print it out and get
a reasonable hard proof.

2. Submission to a printing company - you need to submit hi-res
artwork to a printing company.

For either case to be useful, the PDF export needs to at least
support: CMYK color mode, ICC profiles, spot colors, trim marks, crop
area, and bleed area.  Embedding or outlining (vector) fonts,
registration marks, encryption, and downsampling of image/photo layers
could possibly be useful.

That being said, both use cases would only come about when setting up
a full-color job (CMYK, etc.) - and it is very likely that the
printing company would accept (and perhaps prefer) a hi-res raster
format like TIFF, PNG, or JPEG.  I submit PDFs all of the time for
proofing and printing but 90% are pure vector, 9% are vector with
embedded bitmap images, and only the remaining 1% are completely
raster (I've used at least one printing company that accepts pdf
*only*).

IMHO: Attempting to redraw solid colors as vector would not be a good
idea .  File size is not really a concern - creating PDFs that print
in a reliable manner and are as accurate as possible would be the main
challenge.  If GIMP comes to support vector layers at some point, then
an option to rasterize those layers or keep them as vector should be
presented at the time of PDF export.  Multi-page is not something that
GIMP should worry about at all - there are plenty of tools to join
PDFs already, and multi-page documents are more the domain of page
layout software.

PDF export might be a nice feature, but as a designer I would not use
it very often.  If I did use it, I would expect it to be *extremely*
reliable, and quite verbose about any errors before or during export.

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

Re: [Gimp-developer] Behavior when saving a selection to channel

[Chris Mohler]

On Wed, Mar 11, 2009 at 10:33 AM, Rob Antonishen
 wrote:

> Sven mentioned other uses, like spot colour and halftoning.  I can't
> find any references on using gimp channels for spot colour, in fact
> google only finds me claims that a weakness of gimp is that it does
> NOT support spot colours.

GIMP does offer spot channels, but there is no (easy) way to output
the spot channels directly to a printer in grayscale.   Nor does the
channel mixer operate on the spot channels.

I use spot channels to create separations for printing.  Each spot
channel corresponds to a positive that will be used to create a screen
(plus one channel to represent the substrate).  In PS, one can turn
off the RGB channel and use the visibility of the spot channels to
simulate the final output on the printing press.  Turning off
everything except one spot channel renders that spot channel in
grayscale (which makes printing the single channel very easy).
Turning on two or more spot channels renders them in RGB.  This is
incredibly useful when setting up multicolor prints (think of a white
underbase for printing a bright color on a dark substrate).

I can work around most of these things in GIMP by doing things like
reloading the channel as a selection, creating a new layer and filling
it with black and printing just that layer - but it can be quite
cumbersome.  Also, PS supplies a very badly-named function called
"Apply Image" that allows you to take the contents of any given
channel and apply it to the contents of any other channel using the
available blending modes (multiply, screen, etc.).  This is the real
power behind channels.

99% of people will likely not need spot channels, but to the reaming
1% they are quite useful.  Hopefully with the coming of GEGL it will
become easier to do some of this pre-press separation and channel
mixing.

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

Re: [Gimp-developer] save + export...

[Chris Mohler]

I know this thread is already getting long, but I'd prefer to see
Export behave similar to:

1. Create a new, multilayer XCF
2. File->Export
3. Name it something.png, click Next
4. Set options, click Save

At no point do I want to be nagged about layers, masks, or anything
else.  If there were a small warning icon (with maybe a turn-down
triangle to display the actual warnings) on the bottom of the option
dialog in step 4, that would be nice - but not necessary.  I know PNG
does not support layers - I do not need the reminder every time.

5. Close the XCF file

At this point I should be prompted to save the XCF "master" file,
since I've only done an export and never saved the original.

I based this on PNG, but I'd like to see this workflow on all
non-natives.  GIF for instance should have the choice to save as
animation displayed on the GIF option dialog - not in the warning
dialog.  IMO, the warning dialog should die ;)

Just $0.02

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

[Gimp-developer] Possible feature for Clone Tool?

[Chris Mohler]

Hi,

I just finished a bunch of cloning (dates inserted into digital pics)
and thought of something:

When cloning, would it be possible to display the source pixels inside
of the clone tool's brush outline?  I think that would be quite useful
for dealing with cloning when straight edges are involved, esp at odd
angles.  I envision a checkbox on the clone tool options for "display
source" or similar, and possibly an opacity slider.

On the other hand, I'm not sure if the brush/tool implementation can
handle something like this.  What do you guys think?

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

Re: [Gimp-developer] Gimp on a Commercial CD-Rom ?

[Chris Mohler]

On Wed, Feb 11, 2009 at 4:44 PM, Jackson Tam  wrote:
> Hi Tobias,
>
>
>
> Yep, we are planning on making a donation J. Thanks for the reply and I hope
> you could help me with a few more questions. It would be greatly
> appreciated.

You might find this page (and the entire site, actually) useful:
http://www.gnu.org/licenses/licenses.html

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

Re: [Gimp-developer] Gimp's name

[Chris Mohler]

On Thu, Jan 22, 2009 at 2:41 PM, Viktor Kojouharov
 wrote:
> I'm not trying to beat a dead horse here or anything like that. I'm just
> wondering whether during the great discussions of old about changing the
> name of the program, the name 'Wilber' was considered? Wilber sounds
> like a good name not just for a mascot, but for gimp as well. No
> acronyms, no play on words, no hidden meanings (that I know of).

Not this again... :(

Anyone who is offended by the acronym GIMP (or words in general) ought
to step back and take a long look at atrocities commited every day:
humans killing each other (often in the name of religion), humans
allowing others to starve, and the list goes on...  This world faces
far larger problems than a bit of wordplay.  So many people suffered
horribly at the hands of the Spanish Inquisition that I am offended by
any symbol depicting the Roman Catholic Church - but I hardly go
around asking every church to take down their crucifixes - life's too
short ;)

Here we have humans working together for free to deliver a free - as
in freedom - photo editor.  I believe nothing short of a fork is going
to change the name, and I respect that decision.  Those who are
"offended" should lighten up a bit - they'll live longer ;)

These are only my own opinions of course, and do not reflect the
positions of GIMP or Gnome in any way...

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

Re: [Gimp-developer] Guides in templates

[Chris Mohler]

On Mon, Dec 29, 2008 at 3:53 PM, Sven Neumann  wrote:
> Hi,
>
> On Sun, 2008-12-28 at 19:25 +0000, Chris Mohler wrote:
>
>> With a recent SVN I created a new image, added guides, and saved it as
>> a template.  However when I create a new image and select the
>> template, the guides are no longer there.  Is this intended behavior?
>> I can't think of any reason not to keep the guides, but thought I'd
>> ask...
>
> No good reason except that no one has implemented this yet.

OK - I took a look at the template code and after a (quick) review I
have some more questions.

It seems that the current implementation writes  parameters to the
~/.gimp-2.x/templaterc file, which are used to create a new image.  Is
there a technical (or other?) reason to not use the XCF format for
templates?

One one hand, adding the guides to the current template system looks
somewhat straightforward (like something I might be able to
accomplish), but on the other hand I wonder if would be easier in the
long run to handle templates as native XCF files.

David's message just came to me - thanks for clarifying:
> No one has implemented [image-based templates] yet; 'Save as template'
> does not fully work in this sense, it doesn't save image content; It
> just saves all the properties that you can see in the 'New image'
> dialog, like size, units, dpi, and fill color.

So it sounds like 'image-based templates' is a good idea, but one that
has not been implemented yet?

If that's the general consensus, I will investigate the image-based
approach a bit more.  No promises though - I am still not extremely
good at C...

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] Guides in templates

[Chris Mohler]

Hi gimp-dev list,

With a recent SVN I created a new image, added guides, and saved it as
a template.  However when I create a new image and select the
template, the guides are no longer there.  Is this intended behavior?
I can't think of any reason not to keep the guides, but thought I'd
ask...

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] new feature request - gimp

[Chris Mohler]

On Wed, Oct 22, 2008 at 4:06 PM, Jim Michaels <[EMAIL PROTECTED]> wrote:
[...]
> sorry, my primary email is html (yahoo) email. yahoo mail has no options to
> send as text (no yahoo there).

From: http://email.about.com/od/yahoomailtips/qt/et_plain_text.htm

To compose a text-only message in Yahoo! Mail:

* Click Plain Text at the end of the Subject: line while composing
the message.
* Click OK.

You can switch back to rich-text formatting by following the Rich Text
link in the same spot.

HTH,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 3:31 PM, paul taney <[EMAIL PROTECTED]> wrote:
>> >
>> > Maybe a pallette or something is passed by default and
>> you have to have a placeholder for it -- as with (image,
>> drawable) when it lives at .
>> >
>> > def test_attach(p, this_file):
>> >print "Test type(p): " + type(p)
>> >print "Test file: " + this_file
>>
>> D'oh! - you are correct.  I had to add a parameter when
>> registering:
>> [
>> (PF_PALETTE, "palette",
>> _("Palette"), ""),
>> (PF_FILE, "this_file",
>> _("File"), ""),
>> ]
>>
>> That seems odd to me - is this behavior documented
>> somewhere?
>
> I guessed :-)
>
> Not on  http://www.gimp.org/docs/python/index.html
> Use the Aussie spelling to look for "palette".
> 2 occurances.
>
> Is there other gimpfu documentation?  This is dated July 1999.

That's what I've been using.  The procedure browser and python-fu
console are also very handy.

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

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 2:56 PM, paul taney <[EMAIL PROTECTED]> wrote:
>
>> Instead of
>> getting a GUI file chooser, the main plug-in function is
>> executed, and
>> the the name of the currently selected palette is passed
>> instead of
>> "this_file"
>>
>> Attaching to another menu (/Xtns/, for
>> example) works as expected.
>
> I didnt find it (where is this menu?)...
>
> Maybe a pallette or something is passed by default and you have to have a 
> placeholder for it -- as with (image, drawable) when it lives at .
>
> def test_attach(p, this_file):
>print "Test type(p): " + type(p)
>print "Test file: " + this_file

D'oh! - you are correct.  I had to add a parameter when registering:
[
(PF_PALETTE, "palette",  _("Palette"), ""),
(PF_FILE, "this_file", _("File"), ""),
]

That seems odd to me - is this behavior documented somewhere?

>
>
> BTW, I have noticed that this fails "trying to convert to Unicode".
>
>(PF_FILENAME, "filename", "Output file:", \
>os.path.expanduser("~/tmp.svg")),  # fails

Not sure about that - would something like this work (does on linux):
print os.path.join((os.getenv('HOME')), 'tmp')

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

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 11:57 AM, paul taney <[EMAIL PROTECTED]> wrote:
>
>
>
> --- On Fri, 10/10/08, Chris Mohler <[EMAIL PROTECTED]> wrote:
>
>> From: Chris Mohler <[EMAIL PROTECTED]>
>> Subject: Re: [Gimp-developer] A question about python gimpfu - "home folder"
>> To: [EMAIL PROTECTED]
>> Cc: "gimp" 
>> Date: Friday, October 10, 2008, 12:08 PM
>> On Fri, Oct 10, 2008 at 10:11 AM, paul taney
>> <[EMAIL PROTECTED]> wrote:
>> > Hi,
>> >
>> >> >> Is there a method to discover the GIMP
>> version
>> >> and/or ~/.gimp folder
>> >> >> that works across platform (from python)?
>> >> gimp.directory
>> >
>> >
>> > On a Mac running gimp2.4.5
>> >
>> >   print "gimp.directory = %s" %
>> gimp.directory
>> > prints
>> >gimp.directory =
>> /Users/paultaney/Library/Application Support/Gimp
>> >
>> > ...but my plugin fails to run from there.  It does not
>> appear in the menus.
>> >
>> > Nor will it run from ~/.gimp-2.4/plug-ins  or
>> ~/.gimp-2.4/scripts
>> >
>> > I have only managed to make it run from one location:
>> >
>> > % cat push.sh
>> > cp stroke_to_vector.py
>> /Applications/Gimp.app//Contents/Resources/lib/gimp/2.0/plug-ins/
>> > chmod +x
>> /Applications/Gimp.app//Contents/Resources/lib/gimp/2.0/plug-ins/stroke_to_vector.py
>>
>> That's interesting.  if you create a custom palette on
>> a Mac, does it
>> end up in ~/.gimp or
>> /Applications/Gimp.app//Contents/ ?
>>
>
> Not knowing what file to look for I cant be sure, but I did create a new tmp 
> file and then ran Gimp and "custom pallette".
>
>   % find ~ -newer tmp
>
> ...didnt get any hits in the ~/.gimp-2.4 dir but made about ten files in
>
>~/Library/Application Support/Gimp
>
>
> Tell me the name of the expected file and I can do a better test.

It's no big deal - I was just wondering if you created a new palette
(not image) if it's stored in your home gimp folder. The more I think
about it,  I doubt that it *could* be saved anywhere else - so don't
worry about it.  Thanks anyway :)

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

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 2:28 AM, David Gowers <[EMAIL PROTECTED]> wrote:
[...]
>>
>> And (in the interest of being a pest) a follow-up:
>>
>> Can I attach a plug-in to the Palettes sub-menu?
> Other python plugins, like the 'Sort palette' plugin, certainly do.

Hmm - I can't seem to figure this out.  When I register a plug-in on
the Palettes menu, the 'PF_FILE' parameter seems to be ignored.  Can
someone please take a look at the attached test script?  Instead of
getting a GUI file chooser, the main plug-in function is executed, and
the the name of the currently selected palette is passed instead of
"this_file"

Attaching to another menu (/Xtns/, for example) works as expected.

Thanks,
Chris
#!/usr/bin/env python

from gimpfu import *

gettext.install("gimp20-python", gimp.locale_directory, unicode=True)

def test_attach(this_file):
print "Test file: " + this_file

register(
"python-fu-test-attach-menu",
    "Test of PF_FILE from palettes menu",
"Test of PF_FILE from palettes menu",
"Chris Mohler",
"Chris Mohler",
"2008",
"/TEST...", 
"",
[
(PF_FILE, "this_file", _("File"), ""),
],
[],
test_attach, 
domain=("gimp20-python", gimp.locale_directory)
)

main()
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 10:11 AM, paul taney <[EMAIL PROTECTED]> wrote:
> Hi,
>
>> >> Is there a method to discover the GIMP version
>> and/or ~/.gimp folder
>> >> that works across platform (from python)?
>> gimp.directory
>
>
> On a Mac running gimp2.4.5
>
>   print "gimp.directory = %s" % gimp.directory
> prints
>gimp.directory = /Users/paultaney/Library/Application Support/Gimp
>
> ...but my plugin fails to run from there.  It does not appear in the menus.
>
> Nor will it run from ~/.gimp-2.4/plug-ins  or ~/.gimp-2.4/scripts
>
> I have only managed to make it run from one location:
>
> % cat push.sh
> cp stroke_to_vector.py  
> /Applications/Gimp.app//Contents/Resources/lib/gimp/2.0/plug-ins/
> chmod +x  
> /Applications/Gimp.app//Contents/Resources/lib/gimp/2.0/plug-ins/stroke_to_vector.py

That's interesting.  if you create a custom palette on a Mac, does it
end up in ~/.gimp or /Applications/Gimp.app//Contents/ ?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

On Fri, Oct 10, 2008 at 12:24 AM, Chris Mohler <[EMAIL PROTECTED]> wrote:
> Hi list,
>
> I've been mucking around with a GIMP plugin a la python, and I have a 
> question:
>
> Is there a method to discover the GIMP version and/or ~/.gimp folder
> that works across platform (from python)?

And (in the interest of being a pest) a follow-up:

Can I attach a plug-in to the Palettes sub-menu?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Gimp-developer] A question about python gimpfu - "home folder"

[Chris Mohler]

Hi list,

I've been mucking around with a GIMP plugin a la python, and I have a question:

Is there a method to discover the GIMP version and/or ~/.gimp folder
that works across platform (from python)?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Debug level

[Chris Mohler]

On Tue, Oct 7, 2008 at 2:47 PM, Martin Nordholts <[EMAIL PROTECTED]> wrote:
> Chris Mohler wrote:
>> Sorry if this is a dumb question - I did search the gimp-dev site but
>> did not see an answer.
>>
>> I see many statements like this in the source:
>> IFDBG(3) g_debug ("Compression mode: %d", comp_mode);
>>
>> I built GIMP (2.6) with --enable-debug=yes, and then set
>> G_LOG_LEVEL_DEBUG to 3.  Running GIMP from command line with " -c
>> --debug-handlers" would (so I thought) show messages from a statement
>> such as the above, but it does not.  What have I missed?
>>
>
> Hi!
>
> If you grep for IFDBG you will see that that macro is only for the PSD
> and PSP file plugins (i.e. not GIMP-global). It's definition is in both
> cases:
>
>  #define IFDBG(level) if (PSD_DEBUG >= level)
>
> so you it should be enough to simply make sure PSD_DEBUG is defined to
> whatever level you want to debug for. Should be as easy as changing
>
>  #define PSD_DEBUG 0
>
> in
>
>  plug-ins/file-psd/psd.h

Thanks Martin - that cleared things up for me...

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

[Gimp-developer] Debug level

[Chris Mohler]

Sorry if this is a dumb question - I did search the gimp-dev site but
did not see an answer.

I see many statements like this in the source:
IFDBG(3) g_debug ("Compression mode: %d", comp_mode);

I built GIMP (2.6) with --enable-debug=yes, and then set
G_LOG_LEVEL_DEBUG to 3.  Running GIMP from command line with " -c
--debug-handlers" would (so I thought) show messages from a statement
such as the above, but it does not.  What have I missed?

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Python back-up files

[Chris Mohler]

On Sat, Sep 27, 2008 at 6:16 PM, Samuel <[EMAIL PROTECTED]> wrote:
> Another question from me:
>
> When I write a plugin, my text editor (kwrite or kate) creates a backup
> file named plugin.py~. When I start now the plugin in GIMP, it is
> executing the backup instead the original.

Hi,

I think you should file a bug against kwrite and kate - while it's a
good idea to create backup files, I see no reason why they should have
the execute bit turned on (even if the file you are editing is
executable).

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

Re: [Gimp-developer] newb questions re python-fu

[Chris Mohler]

On Mon, Sep 22, 2008 at 5:41 PM, paul taney <[EMAIL PROTECTED]> wrote:
>
>> >
>> > Thanks very much, Chris.
>> >
>> > I am using your file now and made a coupla repairs,
>> afaict.
>> > But it still doesnt install.  Now I may know why, as
>> running
>> > it straight up gives  No module named gimpfu!
>>
>> AFAIK, you can't run gimp-fu scripts outside of GIMP.
>> There is a
>> python-fu console (XTNS->Python-Fu->Console) that
>> will allow you to type/paste code in.
>>
>> When it doesn't register, is there any console output
>> from GIMP?
>>
>
> No, but if I try to import it in the console I get something revealing:
 import python-fu-vanderwalt
>  File "", line 1
>import python-fu-vanderwalt
> ^
> SyntaxError: invalid syntax

>
> I would not be suprised if python objects to minus signs in module names,
> so I have fixed that in my push script:
>
> % cat push.sh
>  cp python-fu-vanderwalt.py ~/.gimp-2.4/plug-ins/python_fu_vanderwalt.py
>  chmod +x ~/.gimp-2.4/plug-ins/python_fu_vanderwalt.py
>  cp python-fu-vanderwalt.py 
> ~/gimp/gimp-2.4.7/plug-ins/pygimp/plug-ins/python_fu_vanderwalt.py
>  chmod +x ~/gimp/gimp-2.4.7/plug-ins/pygimp/plug-ins/python_fu_vanderwalt.py
>
> Still, it does not appear in the Xtns browser or /Filters/Render.
>
> Maybe it has to be Capitalized , as in the script...
>
> Nope.  That"s not it; I just tested for that, but it is something
> REALLY STUPID.  Je garantir.

Hi Paul,

I did not look at it very carefully, but there are still indentation
errors.  I recommend opening it in Eric - it will literally show a
"bug" on the line(s) in question.  You're also missing a comma on line
92...

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

Re: [Gimp-developer] newb questions re python-fu

[Chris Mohler]

On Mon, Sep 22, 2008 at 12:37 PM, paul taney <[EMAIL PROTECTED]> wrote:
>
> Thanks very much, Chris.
>
> I am using your file now and made a coupla repairs, afaict.
> But it still doesnt install.  Now I may know why, as running
> it straight up gives  No module named gimpfu!

AFAIK, you can't run gimp-fu scripts outside of GIMP.  There is a
python-fu console (XTNS->Python-Fu->Console) that will allow you to
type/paste code in.

When it doesn't register, is there any console output from GIMP?

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

Re: [Gimp-developer] newb questions re python-fu

[Chris Mohler]

On Mon, Sep 22, 2008 at 10:29 AM, paul taney <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> A coupla questions from the newb...
>
> I am trying to write my first python-fu plug-in and I cannot get it to 
> install.  Here"s how I am pushing it to the plugins dir:
>
>  cp VanDerWalt.py ~/.gimp-2.4/plug-ins/python-fu-vanderwalt.py
>  chmod +x ~/.gimp-2.4/plug-ins/python-fu-vanderwalt.py
>
> Then I look for it under /Filters/Render/  and it is not there.
>
>
> It"s a color filter that attempts to extract the bluest pixels,
> like this:
>
> 
>
>  RED, GRN, BLU = 0, 1, 2
>  bluemask = (image[...,BLU] > 1.4*image[...,GRN]) & \
> (image[...,BLU] > 1.4*image[...,RED])
>
>  blue_layer = gimp.layer(bluemask, width, height, RGBA_IMAGE, 100, 
> NORMAL_MODE)
>  image.addlayer(blue_layer, 0)
>
> 
>
> Q1) Is this even close?
> Q2) can I continue to use numpy (as I was with wx.Python) or do these images 
> have to be treated with scipy?

Hi Paul,

I found a few mistakes here and there.  The main one is that Python is
very strict about indentation.  After that, the "import Interpolate"
line I changed to "from scipy import interpolate as ma" - I'm not sure
if that is correct or not.  Lastly, there were some items like
"PF_ITEM("foo", _("foo"), "foo")" that I changed to "PF_ITEM("foo",
"foo", "foo")" and also I added "Vanderwalt" to the end on the plug-in
resgistration.  Oh yeah - I also added an 'except' in somewhere befor
a "finally"...

So... now it still does not run correctly, but at least it registers
with GIMP :|

BTW - starting GIMP from the command line will show syntax errors in
py-fu scripts  Also editors like scite and eric (among others)
show indentation problems in Python by default - these are probably in
your repositories.

HTH,
Chris
#!/usr/bin/env python
###
#
## van der Walt color filter
## python gimp plugin
## by paul taney
## [EMAIL PROTECTED]
#
## Licensed under GPLv3
## see www.fsf.org for details
#
# installation:  put this file in
#$HOME/.gimp-2.n/plug-ins
# then look for it under /Filters/Render/
###

		
import numpy as np

from gimpfu import *  # imports the symbols gimp, pdb, register and main
import os, sys, string
import datetime
#import Interpolate as ma
from scipy import interpolate as ma


def getXML(dictionary):
line2 = transformLine(dictionary["line"])
form = string.Template("""\


 
$operator  
  
 
$location 
$lat   
$long  
   
 
$timestamp  
$datestamp
$chartdate

 
$workingdirectory
$imagepath
$datfilename
$xmlfilename

 
$width
$height

$time_units   
$world_units
$time_coord_min
$time_coord_max
$world_coord_min
$world_coord_max


$bluemask_factor


""")

s = form.substitute(dictionary)
s += '\n%r\n' % (dictionary["line"])
if dictionary["line2"]:
s += '\n%r\n' % (line2)
s += ""
if 0: print s
return s


def python_fu_vanderwalt(image, drawable, operator, location, lat, long,
			thisdate, chartdate, imagefile, xmlfilename, phenomena,
			time_units, world_units, time_min, time_max, world_min,
			world_max, bluemask_factor):
	
	[ width, height, channels ] = image.shape
	
	dictionary = {
		"operator":operator,
		"location":location,
		"lat":lat,
		"long":long,
		"thisdate":thisdate,
		"chartdate":chartdate,
		"imagefile":imagefile,
		"xmlfilename":xmlfilename,
		"phenomena":phenomena,
		"time_units":time_units,
		"world_units":world_units,
		"time_min":time_min,
		"time_max":time_max,
		"world_min":world_min,
		"world_max":world_max,
		"bluemask_factor":bluemask_factor,
		"line":[],
		"line2":[],
		"width": width,
		"height":height,
		"channels":channels,
		}
	
	image.undo_group_start()
	try:
		"""Stefan van der Walt gave me this filter on the numpy mailing list"""
		f = bluemask_factor
		#pdb.gimp_message("calling vanderWalt with factor=%f" % f)
		RED, GRN, BLU = 0, 1, 2
		bluemask = (image[...,BLU] > f*image[...,GRN]) & \
		(image[...,BLU] > f*image[...,RED])
	
		# post it as a new_layer  xxx
		blue_layer = gimp.layer(bluemask, width, height, RGBA_IMAGE, 100, NORMAL_MODE)
		image.addlayer(blue_layer, 0)  # from python_fu_template_image
		gimp.delete(blue_layer)
		
		# Create a new display window for the given image.
		gimp.display(image)
		gimp.displays_flush()
	except:
		pass
		
	finally:
		img.undo_group_end()

	line = np.array(bluemask.nonzero()).swapaxes(0,1).tolist()
	
	if line:
		try:
			line = ma.flip_Y(line)
			line = ma.interpolate(line)
			#line = ma.uniqify(line)
			line = ma.scale(line, image.width, image.height,
			time_coord_min, time_coord_max,
			world_coord_min, world_coord_max)
			di

Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6

[Chris Mohler]

On Tue, Aug 5, 2008 at 3:31 PM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, 2008-08-05 at 15:10 -0500, Chris Mohler wrote:
>
>> It's a dialog, that lets you blend channels from one or two images.
>>
>> Here's one tutorial in which two images are blended (at the
>> beginning):
>> http://www.digitalscrapbookplace.com/university/tutorials/ps_beginnercollage2.shtml
>>
>> Here's a general description of the dialog with screenshots:
>> http://www.graphics.com/modules.php?name=Sections&op=viewarticle&artid=381
>
> Thanks for the pointers. I had a look at this and some other tutorials
> and to me this looks like going back to GIMP version 0.54 where you had
> to use a dialog to blend images together simply because GIMP at that
> point did not yet have layers.
>
> I might be wrong, but it appears to me that everything that "Apply
> Image" does can be done using layers. It's just another way of using
> layer modes and it seems quite akward to use an extra dialog for that.

Except for one thing: layers don't print out as solid.  For example on
a spot red channel if the channel is 100% opaque red it will print out
solid black.  100% opaque red on a layer will print out as some % of
gray.

I'm not suggesting that this be implemented anytime soon - but it
would be nice to have better channel mixing abilities once GIMP is
using GEGL for composition...

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

Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6

[Chris Mohler]

On Tue, Aug 5, 2008 at 2:29 PM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, 2008-08-05 at 14:10 -0500, Chris Mohler wrote:
>
>> > It would help a lot if you guys would not assume that everyone knows all
>> > Photoshop features. If you are missing a particular feature, then please
>> > take the time to explain exactly what it does and how this is useful for
>> > you.
>>
>> Sorry if my explanation wasn't very clear.
>>
>> Here's an example of in-image use of "Apply Image":
> [...]
>
> Thanks. Now I have a nice example of how "Apply Image" can be used. I
> still have no clue though what this "Apply Image" thing is. Is it a
> tool, a dialog, a plug-in? What exactly does it do? Perhaps you can
> point us to them online documentation or a tutorial or illustrate this
> with some screenshots?

It's a dialog, that lets you blend channels from one or two images.

Here's one tutorial in which two images are blended (at the beginning):
http://www.digitalscrapbookplace.com/university/tutorials/ps_beginnercollage2.shtml

Here's a general description of the dialog with screenshots:
http://www.graphics.com/modules.php?name=Sections&op=viewarticle&artid=381


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

Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6

[Chris Mohler]

On Tue, Aug 5, 2008 at 12:45 PM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Tue, 2008-08-05 at 11:41 -0500, Chris Mohler wrote:
>
>> I do miss 'Apply Image', which allows you to either:
>
> It would help a lot if you guys would not assume that everyone knows all
> Photoshop features. If you are missing a particular feature, then please
> take the time to explain exactly what it does and how this is useful for
> you.

Sorry if my explanation wasn't very clear.

Here's an example of in-image use of "Apply Image":

You're printing a red and white design on a black garment.  Create
three channels named "spot red", "white", and "white base" - set the
opacity on each to around 70%.  Go back to RGB channels and select red
parts of your image, select the spot red channel again and fill with
black.  Repeat for white portions - add them to the white channel.
Now 'Image->Apply Image', select "spot red" as the source, "white
base" as the target, and "Multiply" as the blending mode.  Repeat the
last step, but choose "white" as the source channel.  Now you have
combined "white" and "spot red" to form a white base that you can then
choke down - and see the result on the screen before going to press by
hiding the RGB channels.

That's a pretty simple case - sometimes you want to subtract all of a
channel that overlaps another (blending mode "Add", "Invert" checked),
or selectively mix portions of channels.

The idea is similar to the Channel Mixer dialog in GIMP - but the
different blending modes makes it very powerful.

Does that make sense?

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

Re: [Gimp-developer] Script proposed for inclusion in gimp 2.6

[Chris Mohler]

On Tue, Aug 5, 2008 at 11:10 AM,
<[EMAIL PROTECTED]> wrote:
> In my opinion, a better solution to the "copy visible to new layer"
> functionality would be to add an option to Merge Visible Layers which
> would retain the original visible layers. This approach would seem
> more intuitive and would not entail an additional menu command. It
> would also be more flexible because the newly created layer wouldn't
> need to be the image size (the user would have available the
> expansion/clipping options of Merge Visible).

I do miss 'Apply Image', which allows you to either:

1. Apply any RGB/CMYK/spot channel or all RGB/CMYK channels from one
image to another (if they are the same size) using any of the blending
modes available (multiply, screen, etc).  Selections remain active
during the procedure.

2. Apply any channel to any other channel within the image using
available blending modes. Selections remain active.

It's a nice feature that opens up a lot of possibilities, esp if you
are working with spot channels.

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

Re: [Gimp-developer] international chars in Gimp

[Chris Mohler]

On Thu, Jun 26, 2008 at 11:29 AM, Andrei Simion <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Does Gimp support German characters. I work on Mac and I want to add
> text on an image. I cannot copy/paste the character Ü because Gimp uses
> its own clipboard, so I have to somehow type it in. What I can do?

On a mac, just press option-u or option-shift-u...

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

Re: [Gimp-developer] More intelligent user protection from information loss

[Chris Mohler]

On Sat, Jun 7, 2008 at 12:46 PM, Alexia Death <[EMAIL PROTECTED]> wrote:
[..]
> Exactly... Witch has bitten me in the ass a few times...

That evil witch has bitten me a few times as well - even with the
pentagram drawn under my workstation ;)

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

Re: [Gimp-developer] functions in wacom

[Chris Mohler]

On Tue, May 13, 2008 at 12:07 PM, Dani Perez <[EMAIL PROTECTED]> wrote:
> Hi,
>
>  I need to get some features of the wacom like coordinates X and Y, pressure 
> of
>  pencil, etc in each instant of time.
>  Does Gimp save this information in any file?
>  Are there functions to obtain it?

Have you looked at the wacdump program (linux - usually in a package
called 'wacom-tools') or the utilities on the driver CD (windows)?

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

Re: [Gimp-developer] ‘no image’ window: prog ress...

[Chris Mohler]

On Sun, Mar 16, 2008 at 8:31 AM, peter sikking <[EMAIL PROTECTED]> wrote:
> GIMPsters,
>
>  some good news on this front, I have spent a couple of man-days
>  rethinking and re-specifying the 'no image' window situation.
>  It is now roughly complete:
>
>  
>
>  If wrinkles need to be ironed out, let me know.

I think some of the "gimmicks" could be useful (and remain professional):

# any splash-screen-like graphics or interaction, or GIMP contributor credits;
A fairly small, horizontal graphic that is very similar to the initial
start-up splash screen is not only more interesting, but also ties the
window to the application.  If for example the window becomes
partially obscured while a user is opening their file manager to begin
dragging a file, they can readily identify the portion that is still
visible.

# any 'what would you like to do today' type of interaction, including
'recently open images';
I consider a list of recent images and a list of templates to be
functional.  As long as these can be configured easily or disabled I
see no reason to rule it out completely.  Something for "Paste as New"
would be handy - any of these would cut down on the number of
clicks/menus needed to perform the most common tasks.

The spec seems well thought out but I think that this window could do
more for the user.  Perhaps not right now, but I wouldn't rule those
two out for all time.

My 0.02,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] tagged resources such as brushes, gradients, etc

[Chris Mohler]

On Jan 18, 2008 5:03 AM, Tobias Jakobs <[EMAIL PROTECTED]> wrote:
> On Jan 18, 2008 8:55 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> >
> > My current favorite approach is to put the tags into files in the
> > ~/.gimp-2.x directory, one file per resource type. So there would be a
> > brushrc, gradientrc, patternrc and so on. These files will contain
> > metadata from the actual resource files.
>
> One think I'm missing here is a way to share brushes with tags.
> The user scenarios I'm thinking about is:
> - Download package (ZIP-File) with a lot of brushes
> - Install them (btw. Finding the right folder and copying them into it
> looks like a problem for some users. At least it's an FAQ in the
> German gimpforum.de.)
> - Now I'd like to have this brushes tagged in Gimp and start working
> with this brushes and I don't want to tag them myself.

What about a function to "export" brushes that dumps selected brushes
to a new dir with a local version of brushrc, and a matching "import"
that reads them in - file, MD5, and tags?

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

Re: [Gimp-developer] improving QMask mode

[Chris Mohler]

On Dec 1, 2007 5:07 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sat, 2007-12-01 at 18:05 +1030, David Gowers wrote:
>
> > > > b) Push the context before entering qmask mode, and pop it when
> > > > exiting qmask mode.
> > For Chris's benefit : it means that the context that was being used is
> > stored, and restored after qmask. so the FG and BG that you were
> > previously using return.

@David: Thanks for explaining.

> It would mean a lot more than that. Also any changes to the current
> brush, pattern, gradient, paint-mode, ... would be undone when the
> context is popped.

A power user might benefit from having a QMask option in preferences
for "keep separate context for QMask".  I can think of a couple of
scenarios where using separate settings in QMask could prove useful.

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

Re: [Gimp-developer] improving QMask mode

[Chris Mohler]

On Nov 30, 2007 6:15 AM, David Gowers <[EMAIL PROTECTED]> wrote:
> I believe that QMask mode could be made quicker to use, by providing
> an option to:
> a) Reset the FG/BG colors to black and white upon entering qmask mode
> and
> b) Push the context before entering qmask mode, and pop it when
> exiting qmask mode.
>
> With the sum effect that you needn't destroy the colors that you were
> using in order to paint on the QMask (I myself always find myself
> resetting the colors to default before I draw on the QMask), and you
> start out with the two most useful 'colors' set as FG+BG.
>
> What do you think of this? If I get the go ahead I'll implement this.

I like "a" - I switch to black and white in QMask very often.  Not
sure exactly what you mean by "b", so no opinion...

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

On Nov 26, 2007 8:48 AM, Chris Mohler <[EMAIL PROTECTED]> wrote:
> > Eeek, no! I thought I had tried to make the purpose of this list clear.
> > We already have Bugzilla and its milestones for the purpose of reminding
> > us what needs to be done for 2.6. The task list is supposed to list a
> > few tasks that we consider important and that show where GIMP
> > development is heading. Your list now has about five times too many
> > items. It will be rather difficult to get to the final list from there.
>
> OK - I thought it was too long also.  Ignore the third version.   I'm
> beginning to see the light - we need a short list of the most
> important items, with a nice description for each...  I'll try again
> tonight.


This is likely too long also and could use some more organization and
detail.   It's Alexandre's email to the gimp-dev list, plus a couple
of items later mentioned.  I followed the convention of adding a
(name) after each task and a (?) if that isn't certain.  Things inside
brackets are just my notes.

http://cr33dog.fedorapeople.org/misc/gimp_task_list_04.txt

Is this enough of a starting point to finalize what should and should
not be on the map?

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

On Nov 26, 2007 1:58 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Sun, 2007-11-25 at 18:52 -0600, Chris Mohler wrote:
> > On Nov 22, 2007 1:03 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> > > This is a nice start, but I think we need a lot more information in the
> > > short description. So one row per task is certainly not going to be
> > > sufficient. But it's probably a good idea to finalize the structure and
> > > layout before we go into filling in all the details.
> >
> > I trolled through Bugzilla and added anything with a 2.6 milestone.  I
> > *think* this is now a list of all possible tasks for 2.6.
>
> Eeek, no! I thought I had tried to make the purpose of this list clear.
> We already have Bugzilla and its milestones for the purpose of reminding
> us what needs to be done for 2.6. The task list is supposed to list a
> few tasks that we consider important and that show where GIMP
> development is heading. Your list now has about five times too many
> items. It will be rather difficult to get to the final list from there.

OK - I thought it was too long also.  Ignore the third version.   I'm
beginning to see the light - we need a short list of the most
important items, with a nice description for each...  I'll try again
tonight.

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

On Nov 22, 2007 1:03 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> This is a nice start, but I think we need a lot more information in the
> short description. So one row per task is certainly not going to be
> sufficient. But it's probably a good idea to finalize the structure and
> layout before we go into filling in all the details.

I trolled through Bugzilla and added anything with a 2.6 milestone.  I
*think* this is now a list of all possible tasks for 2.6.  So now I
need some feedback on what ought to be bumped to Future or 2.8, and
also how this could be better organized.  The "meta" tasks at the
bottom are pretty much useless: if someone wants to propose specific
areas to move forward with Cairo/GEGL I'm more than happy to
add/outline them.

http://cr33dog.fedorapeople.org/misc/gimp_task_list_03.html
http://cr33dog.fedorapeople.org/misc/gimp_task_list_03.ods

I will add a longer description for each task later (hopefully after
shortening the list :)

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

On Nov 22, 2007 1:03 AM, Sven Neumann <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On Wed, 2007-11-21 at 18:32 -0600, Chris Mohler wrote:
> > On Nov 20, 2007 7:26 PM, Chris Mohler <[EMAIL PROTECTED]> wrote:
> > > > Does this sound reasonable? Is there anything I missed? Any volunteers
> > > > to work on this list?
> > >
> >
> > Formatted it a bit better:
> > http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.html
> > http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.ods
>
> This is a nice start, but I think we need a lot more information in the
> short description. So one row per task is certainly not going to be
> sufficient. But it's probably a good idea to finalize the structure and
> layout before we go into filling in all the details.

OK.  Should these tasks be added perhaps?
http://wiki.gimp.org/gimp/ToDo

I won't have much time to work on the list today, but I can make
changes tomorrow or over the weekend.

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

On Nov 20, 2007 7:26 PM, Chris Mohler <[EMAIL PROTECTED]> wrote:
> > Does this sound reasonable? Is there anything I missed? Any volunteers
> > to work on this list?
>

Formatted it a bit better:
http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.html
http://cr33dog.fedorapeople.org/misc/gimp_task_list_02.ods

I will try to make time to hunt for BZ numbers and look at the UI spec
this weekend.  I may also go through the list again and see what I
missed.

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

Re: [Gimp-developer] finalizing the task list

[Chris Mohler]

> Does this sound reasonable? Is there anything I missed? Any volunteers
> to work on this list?

Sounds reasonable to me.  Since I never get around to contributing
anything, I took a few minutes to copy-paste some items from the
mailing list that came up this past month.  It needs work - I haven't
searched BZ or the UI spec yet to match up items either.   Hopefully
it can be a start at least.

http://cr33dog.fedorapeople.org/misc/gimp_task_list.html
http://cr33dog.fedorapeople.org/misc/gimp_task_list.ods

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

Re: [Gimp-developer] Selection moving - is this a bug?

[Chris Mohler]

On Nov 3, 2007 1:19 AM, Martin Nordholts <[EMAIL PROTECTED]> wrote:

> Works fine fore me. Are you sure you are not just using weird Move Tool
> Options? If not, please provide more details, like size of selection
> before and after scaling and so on.


Odd - after a few days, I can't reproduce it either.  It works now -
sorry for the noise...

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

[Gimp-developer] Selection moving - is this a bug?

[Chris Mohler]

Not sure if this is a bug or not.  Using 2.4.1 on ubuntu 7.10.

1. Create a new image
2. paint a couple of areas (just for reference)
3. select a painted area
4. float the selection
5. move it around
6. shift-T and scale it
7. try to move it again

At step 7 I expect to be able to move the floating selection, but it
won't budge.  Is this intended behavior or did I just miss a step?
I'm going back to the manual, but this seems odd...

Thanks,
Chris
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] a first step towards Cairo drawing

[Chris Mohler]

On 10/27/07, Sven Neumann <[EMAIL PROTECTED]> wrote:
[...]
> Currently we are drawing the rectangle using XOR. When we switch to
> Cairo this should probably change. But I am not entirely sure how to
> best draw a nice-looking outline that is visible on all images. Perhaps
> some of the artists out there could draw me some nice mockups?

How about darkening the outside-of-the-view area and then adding a
simple white border?
http://cr33dog.fedorapeople.org/misc/gimp/nav.png

My only concern is that very dark images may become black in the
outside view.  On the upside, I'm pretty sure the visible area will be
clearly defined on all image types - light images will benefit most
from the darkened transparency, and dark images will benefit most from
the white box.  Both ways, the rectangle is clearly visible.

Just a thought...

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