On 11/15/06, Sven Neumann wrote:

I would also like to
further improve the color management preferences. In this case it seems like a good idea to try to get something that resembles the Photoshop color management configuration in terms of terminology and policies.

Sven,

I would strongly recommend work out common terminology with developers of other open source projects instead. Having uniform terminology is one of the reasons the OpenIcc project [1] exists: commercial applications fail to provide uniform terminology, even within one product line. Same advice for policies.

[1] http://www.freedesktop.org/wiki/OpenIcc

Alexandre

On 11/15/06, Sven Neumann wrote:

I know about the OpenICC project and I am subscribed to the mailing-list. But I don't think they can provide me with a decent proposal for color management policies and what terms to use.

If by "them" you are referring to developers of Scribus, ICC-Examin, LProf etc. and technical specialists of Lexmark, HP and Adobe, then, most likely, yes -- "they" can. If you are referring to somebody else from that list, then it could be both yes and no ;)

Following pages are of interest:

http://www.oyranos.org/wiki/index.php?title=What_the_users_want http://www.oyranos.org/wiki/index.php?title=Concepts

Alexandre

On Wed, 15 Nov 2006 18:51:10 +0100, Sven Neumann wrote:

Hi,

On Wed, 2006-11-15 at 11:14 +0100, peter@piments.com wrote:

There is still drift on rotation tool using interpolation=NONE

How pointless to tell me. Please make sure that there's a bug report about it and that it has the 2.4 milestone set.

Sven

I thought it was the responsability and privelege of those with cvs commit rights to determine development milestones for not just anyone.

when you said your list of stoppers was open for discussion I though you meant is was open for discussion.

If it is not then you are right my post was pointless. sorry.

On Wednesday 15 November 2006 10:05, Alexandre Prokoudine wrote:

On 11/15/06, Sven Neumann wrote:

I know about the OpenICC project and I am subscribed to the mailing-list. But I don't think they can provide me with a decent proposal for color management policies and what terms to use.

If by "them" you are referring to developers of Scribus, ICC-Examin, LProf etc. and technical specialists of Lexmark, HP and Adobe, then, most likely, yes -- "they" can. If you are referring to somebody else from that list, then it could be both yes and no ;)

Following pages are of interest:

http://www.oyranos.org/wiki/index.php?title=What_the_users_want http://www.oyranos.org/wiki/index.php?title=Concepts

Alexandre

For the most part the existing OSS applications that are color management aware more or less use terminology and policy settings that are similar to Photoshop. Some only implement a subset and others have a much more complete implementation. So in a way Sven is correct and if this approach were followed (IE. model this after photoshop) that at the very least would be a good starting place and most CM savvy users would feel comfortable with the result.

But I am also sure that if the OpenICC list were queried for some expertise to help with finalizing the design of the CM UI that you would in fact get someone (perhaps even a small group) who would provide the needed expertise. In addition to virtually every OSS project that has an interest in CM having someone from their development team subscribed to the OpenICC list there is a wide range of CM experts and professionals including authors of books on the subject and as Alexander points out representatives from various manufacturers and the ICC itself. Making the OpenICC list a valuable resource for any OSS project that is involved in implementing CM awareness. In addition you might find that these experts have places were they feel the photoshop way of doing things has problems and issues and that you might see some proposals that would result in the CM support actually being better than it is in photoshop.

Also some time ago I put together a fairly detailed description of what was needed and where this should be located in the GIMP menu structure that I submitted to this list. There have been similar proposals from others as well. For the most part these are similar to photoshop's implementation. With the exception of printer CM support there is not that much work that needs to be done to GIMP to finish off the CM implementation.

One area were many on the OpenICC list agree is that the photoshop/proprietary OS approach to CM could be substantially improved in the area of printing. My GIMP proposal did not deal with color managed printing since my vision for how this should be handled would require significant changes to the gimp-print/guten-print plugin that I think are beyond the scope of 2.3/2.4 and are in fact significantly different from how this is handled in photoshop. Besides at this time there is PhotoPrint which will fill this gap, at least for Linux users, until such time as guten-print can implement CM support. So I don't view CM printing support as necessary for the 2.3/2.4 release cycle. But I would be willing to help design this if someone though that this was in the scope of the current release cycle. My printer proposal is in the OpenICC archives and if anyone here is interested I am sure I can dig it out and clean it up.

Hal Engel

LProf Project

On 11/15/06, Sven Neumann wrote:

That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet.

What requirements should be met by this plug-in to consider it ready for release?

Alexandre

On Wednesday 15 November 2006 18:50, gimp-developer-request@lists.xcf.berkeley.edu wrote:

Send Gimp-developer mailing list submissions to gimp-developer@lists.XCF.Berkeley.EDU

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

You can reach the person managing the list at gimp-developer-owner@lists.XCF.Berkeley.EDU

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

Today's Topics:

1. GIMP 2 book, your opinion is...? (Leon Brooks) 2. 2.4 showstoppers (Sven Neumann) 3. Re: 2.4 showstoppers (Alexandre Prokoudine) 4. Re: 2.4 showstoppers (Sven Neumann) 5. gimprc confusion (gg@catking.net) 6. Re: gimprc confusion (gg@catking.net) 7. Re: gimprc confusion (Michael Schumacher) 8. Re: gimprc confusion (Sven Neumann)

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

Message: 1
Date: Wed, 15 Nov 2006 14:40:09 +0800 From: Leon Brooks
Subject: [Gimp-developer] GIMP 2 book, your opinion is...? To: gimp-developer@lists.xcf.berkeley.edu, gimp-user@lists.xcf.berkeley.edu
Message-ID:
Content-Type: text/plain; charset="iso-8859-1"

Has anyone read /GIMP 2 for Photographers/ yet?

There's a review up at:

http://www.desktoplinux.com/news/NS5105451578.html

I'd value your opinion, if you've formed one. Particularly if you're a photographer of any sort.

Cheers; Leon

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

Message: 2 Date: Wed, 15 Nov 2006 09:40:46 +0100 From: Sven Neumann
Subject: [Gimp-developer] 2.4 showstoppers To: gimp-developer@lists.XCF.Berkeley.EDU Message-ID:
Content-Type: text/plain

Moin,

slowly but steadily the state of GIMP 2.3 is reaching a point where it can be released as 2.4. I would like to point out some showstoppers in the hope that we can get some help with them. There is also the list of bugs on the 2.4 milestone in Bugzilla and this mail somewhat overlaps with that. But it also mentions a few things that are not in Bugzilla (but probably should be).

Here's a small list of outstanding items for GIMP 2.4, from the top of my head, incomplete and subject to discussion:

Finish rectangle tools

The rewritten rectangle tools (rect and ellipse select as well as crop) are getting better, but there are still some regressions (mainly in the Crop tool, see Bugzilla) and the tool options still need an overhaul. Would be nice if we could come up with a decent tool options UI proposal, then implement it.

Finish color management

Main feature missing here is giving the display filters access to the image's color profile. As soon as that is implemented, we should have a prepress professional review the functionality. I would also like to further improve the color management preferences. In this case it seems like a good idea to try to get something that resembles the Photoshop color management configuration in terms of terminology and policies.

Sven

I have been playing with the color management in CVS and it is getting there for sure.

My thinking is the choice of controls and terminology should be guided by the 3 modes you have.

1. No color management means that and everything assumes RGB with no display compensation.

2. Managed Display - To me mode this should be used for web graphics and users with the large majority of inkjets which are indeed RGB devices in that they expect RGB data.

3. Press Simulation - Exactly that. Simulating CMYK Printers of all kinds.

In the case of #3, you could argue that having a choice to enable some form of gamut warning. Mind you gamut warnings are just that. I would not enable this for # 2

One thing which needs fixing is profile locations. Finding and setting the profiles is not obvious on Linux

On Linux/*nix, we've outlined those directories on openicc and most of it is taking hold as a spec. This should be a recursive search as some profile packages are now available for distros and they sometimes separate RGB and CMYK locations.

Windows NT and Win9x have different default locations, but they should be searched automatically IMO.

The trickier bit for me is how you handle importing CMYK images. I just did a test and it detects there is an embedded icc profile and asks correctly if I want to replace it or keep it. However, it is CMYK, yet asks to replace sRGB with a differently named SRGB profile and the console outputs:

'** (lcms:16300): WARNING **: Attached color profile is not for RGB color space.'

My thinking is that any CMYK image imported should have a simple warning that it is not currently supported and a best effort conversion is made to RGB.

File > Properties might be good place also to note if a given image has an embedded profile.

I'm game to writeup some docs before 2.4 is done on a color management. section. Without good docs, this will flood the mail lists and IRC with questions.

I did not mean this to be a comprehensive review and I know this is still a work in progress, but it is great to see what has been done so far.

Peter

On Wednesday 15 November 2006 11:38, Sven Neumann wrote:

snip

With the exception of printer CM support there is not that much work that needs to be done to GIMP to finish off the CM implementation.

Printing is left to plug-ins, so we don't need to deal with it except for providing ways for the plug-in to access the color management settings and the color profile that is attached to the image. Both is implemented already.

I think that the minimal solution is to make sure that users can convert images between color profiles. If you are using something like my proposal then this feature will be available. So you could even get by without providing plugin access to the GIMP CM settings and still have a usable CM system for the short term. This amount of CM support is a little on the basic side but the printing work flow would look like this:

1. Prepare image in the images native color space (ie. either the device color space or the users normal working color space) with whatever things you do such sharpening and whatever.

2. Use the color space conversion utilities to convert the image from the images native color space to the printer color space.

3. Send the image to the printer.

4. Undo the color space conversion.

The above can be used with printer drivers and plugins that know nothing about CM. But it does result in more work for the user than a more integrated approach. Providing ways for print plugins to access the various CM settings and image profiles will be needed in the long run so that CM features can be implemented in any print plugins in a way that is transparent to users and fully integrated with GIMP. Therefore I agree with your direction. I should add that the above printing work flow is not that much different from what happens in photoshop except some of the steps are hidden from the user by photoshop.

Hal

On Wednesday 15 November 2006 13:42, Plinnell wrote: snip

Sven

I have been playing with the color management in CVS and it is getting there for sure.

My thinking is the choice of controls and terminology should be guided by the 3 modes you have.

1. No color management means that and everything assumes RGB with no display compensation.

2. Managed Display - To me mode this should be used for web graphics and users with the large majority of inkjets which are indeed RGB devices in that they expect RGB data.

3. Press Simulation - Exactly that. Simulating CMYK Printers of all kinds.

I think this may be a false dichotomy. Most color printers are CMYK printers even if drivers in some environments like Windows expect RGB data. For example my Epson printer drivers on Windows expect RGB data but using Guten-print on Linux I can send CMYK data to the printer and by pass the drivers RGB to CMYK conversion routines. The same is true for users of RIPS on Windows and the Mac. My intension on Linux is to profile my printer as a CMYK device and do my color management directly into the printers true native color space. If anything I should actually get a slightly larger gamut then sending RGB data to Guten-print.

I think the Press Simulation (was Print Simulation on 2.3.12) is intended to be a preview mode so that users can have a better idea what their output will look like on the intended printer/ink/paper combo or other output device and I don't think this has anything to do with the output device being CMYK or RGB. This is also how this works in photoshop.

In the case of #3, you could argue that having a choice to enable some form of gamut warning. Mind you gamut warnings are just that. I would not enable this for # 2

I would agree that having a gamut warning option is a good thing. Since #2 is not a preview of the output results then it only makes sense to have this for #3. I can however live without this in the short term in part because my printer is a fairly wide gamut device and gamut clipping only happens under extreme conditions.

One thing which needs fixing is profile locations. Finding and setting the profiles is not obvious on Linux

On Linux/*nix, we've outlined those directories on openicc and most of it is taking hold as a spec. This should be a recursive search as some profile packages are now available for distros and they sometimes separate RGB and CMYK locations.

Krita, cinepaint and LProf all support the current *nix spec and LProf supports the Windows locations as well. I am not sure about Scribus but I think is does as well. So this is another thing that users will expect.

Windows NT and Win9x have different default locations, but they should be searched automatically IMO.

The last version I tried is 2.3.12 and selecting profiles was by file name. Most other CM aware software including (but not limited to) photoshop, The Windows Color control panel applet, cinepaint, Krita and LProf (should Scibus be in this list?) use the profile description tag rather than the file name in these drop down lists of profiles. This has been more or less standard for a long time and most CM savvy users will expect this same behavior from GIMP at least in the long run.

snip

File > Properties might be good place also to note if a given image has an embedded profile.

Or perhaps Image > Image Properties Or both?

I'm game to writeup some docs before 2.4 is done on a color management. section. Without good docs, this will flood the mail lists and IRC with questions.

This is critical. CM is hard for new users to understand and a little documentation will go a long way in helping users get started.

I did not mean this to be a comprehensive review and I know this is still a work in progress, but it is great to see what has been done so far.

I agree that there has been much progress. I will be getting a CVS build setup on my machine so that I can keep more in touch with progress on this as it gets closer to final release.

Hal

From: Sven Neumann
Date: Wed, 15 Nov 2006 20:38:07 +0100

On Wed, 2006-11-15 at 11:02 -0800, Hal V. Engel wrote:

> One area were many on the OpenICC list agree is that the > photoshop/proprietary OS approach to CM could be substantially > improved in the area of printing. My GIMP proposal did not deal > with color managed printing since my vision for how this should > be handled would require significant changes to the > gimp-print/guten-print plugin that I think are beyond the scope > of 2.3/2.4 and are in fact significantly different from how this > is handled in photoshop.

The gimp-print/guten-print plug-in is developed by different people and is not at all coupled to the GIMP release cycles. We should however consider to make the print plug-in that's being shipped with GIMP aware of the image's color profile.

I'd like to see the code that does this, so that the Gutenprint plugin can if possible do the same thing.

Hi,

2. Managed Display - To me mode this should be used for web graphics and users with the large majority of inkjets which are indeed RGB devices in that they expect RGB data.

As Hal pointed out, printing is irrelevant in this mode. Behind the scenes, "Managed Display" should be doing a simple Image (or Working Space) Profile -> Monitor Prorfile transform, so that users with a profiled monitor will see the correct colours.

I think the Press Simulation (was Print Simulation on 2.3.12) is intended to be a preview mode so that users can have a better idea what their output will look like on the intended printer/ink/paper combo or other output device and I don't think this has anything to do with the output device being CMYK or RGB. This is also how this works in photoshop.

This mode uses a proofing transform, so that colours are shown on screen as they would appear if rendered on another device - usually a printer or press. Whether this extra device profile is RGB or CMYK matters not one jot (not even at code level).

Why was this renamed to Press Simulation, BTW? This mode is every bit as valid and useful for profiled desktop printers as it is for printing presses - hence it's potentially useful for digital photographers, not just pre-press operatives.

All the best, --
Alastair M. Robinson

On Fri, 17 Nov 2006 08:26:14 +0100, Sven Neumann wrote:

Hi,

On Wed, 2006-11-15 at 19:22 +0100, gg@catking.net wrote:

when you said your list of stoppers was open for discussion I though you meant is was open for discussion.

Open for discussion on the mailing list, yes. But if you send your mail to me alone (which is what the mail header indicated you did), then we can't have a discussion and the issue is likely going to be forgotten.

Sven

Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again.

I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit "reply" in my email client and it replies to the list.

Since the msg came from the ml not from your address the reply-to header is counter intuitive.

Return-Path: From: Sven Neumann

Plus I have to remember the reply policy is opposite to other MLs I use.

I get it right most of the time. Appologies for the occasional lapse of concentration.

regards, gg.

gg@catking.net wrote:

Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again.

I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit "reply" in my email client and it replies to the list.

Since the msg came from the ml not from your address the reply-to header is counter intuitive.

It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html

Kind regards,

Mukund

On Saturday, November 18, 2006, 21:24:10, Mukund wrote:

It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html

Thankfully, some e-mail clients can work around this annoyance (sadly, it's not automatic, so I often misdirect my first message on such lists).

On Sat, 18 Nov 2006 21:24:10 +0100, Mukund wrote:

gg@catking.net wrote:

Ahh, I did not see what your previous comment meant. Caught out by this damn ML reply-to setting again.

I'm subscribed to several lists which operate in a more logical way: I get a msg from the list , I hit "reply" in my email client and it replies to the list.

Since the msg came from the ml not from your address the reply-to header is counter intuitive.

It actually isn't. You may want to read this: http://www.unicom.com/pw/reply-to-harmful.html

Kind regards,

Mukund

It isn't what? Counter intuitive, it is. I get an email for the list not from the individual, when I hit reply it replies to the individual I need to reply to the sender, ie the list.

There may be arguements for and an against but pls let's not start swamping gimp-devel with that.

I was simply offering my appologies for the confusion and explaining why.

gg.

Sven Neumann writes:

That brings up another showstopper for 2.4 that is missing from the list I posted earlier. We need to check if the new print plug-in is ready for release. Since I don't use GTK+ 2.10 yet, I didn't get a chance to have a look at it yet.

[ ... ]

It should at least do the basic things right. In other words, print a single image, allowing the user to specify the size and location on paper. Should probably default to the original size (determined by the image resolution) if that fits to the printable area. Otherwise it should scale the image down while preserving the aspect ratio.

For this plug-in I think we should focus on keeping it simple. Enough to fulfill basic printing needs but still usable without reading a manual. People who need more control can always install the gutenprint plug-in.

Has anyone done this evaluation? If not, can someone please volunteer to do it? We need to find out if we can we ship the plug-in as is or if there are issues that need to be addressed before 2.4.

I just upgraded to a distro that has gtk 2.10, so I can do the evaluation -- though for my own use I'm fairly happy with gimp-print/gutenprint.

I just tried the print plug-in in current CVS. This is the first time I've actually seen it, and I'm happy to see that there's a gnomeprint dialog now that lets me set printer parameters. But I found quite a few problems, and ultimately wasn't able to print anything with it:

- Bug: the Layout tab comes up with a unit of Inches, but Width and Height which are the pixel dimensions of the image. I hate to think what it would do if I let it print at 1160 inches wide.

- The Layout tab is really difficult to use compared to gimp-print, because it has no live preview. I have to click on the Page Setup button (why isn't that right in the Layout tab?) then try to guess what it means by Portrait, Reverse Landscape, etc. and what it will do for margins (does it always center, or what?)

- Minor Bug: the Page Setup dialog came up with the wrong paper size (A4 vs. my system default of Letter).

- UI issue: there's a Page Setup tab, plus a Page Setup button in the Layout tab which has a completely different function. Shouldn't one of these be renamed? (Moving the Page Setup button/ dialog options into the Layout tab and eliminating the dialog would solve this.)

- There doesn't seem to be any way to position an image on the page, so this dialog doesn't replace gimp-print for functions like printing out my holiday cards, where I have to print to the lower half of a page which will then be folded over.

- When I try to change the Width in inches to 4, as soon as I leave the Width field it reverts to the old value of pixel width. So I can't actually try printing anything to check the quality.

- When I click Print Preview, the dialog disappears and I get a GIMP Message dialog with a nice clear error message: Procedure 'gimp-image-set-unit' has been called with value 'pixels' for argument 'unit' (#2, type GimpUnit). This value is out of range.

More information:

Akkana Peck writes:

- When I click Print Preview, the dialog disappears and I get a GIMP Message dialog with a nice clear error message: Procedure 'gimp-image-set-unit' has been called with value 'pixels' for argument 'unit' (#2, type GimpUnit). This value is out of range.

Turns out I only get this dialog if I've tried to change width/height. If I simply bring up the print dialog and immediately click Print Preview, the print dialog silently disappears.

I wasn't watching stderr when I made my previous report. I get lots of:

(print:9163): LibGimp-CRITICAL **: _gimp_unit_cache_get_factor: assertion `unit >= GIMP_UNIT_INCH' failed

I see these when the print dialog initially comes up, any time I try to adjust width/height, and when I click Print Preview (whether or not I get the Message dialog).

Sven Neumann writes:

thanks for looking at the plug-in. It would help a lot if we could split your list into problems of the Print plug-in and problems of the GtkPrint API. The latter would have to be reported against GTK+.

I've filed a gimp bug (#387604) on the unit factor problems (I suspect the dialog disappearing on Print Preview is the same problem; at least it's not easily separable from it right now).

I'm not sure which of the other problems is GtkPrint vs. GIMP, because I'm not familiar with what GtkPrint does. Two bugs that seem worth filing:

- Not reading the system paper size (I'm guessing this is gtkprint) - Two different functions named Page Setup (I'm guessing this is GIMP)

Do my guesses sound right?

And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp:

- No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview

From: Sven Neumann
Date: Wed, 20 Dec 2006 08:35:35 +0100

On Tue, 2006-12-19 at 10:54 -0800, Akkana Peck wrote:

> And a few RFEs which would be needed to get the print dialog to > functionality comparable to the existing gimp-print plug-in. > I don't know whether these belong to gtkprint or gimp: >
> - No way to adjust margins
> - Page Setup should be in the Layout tab, not a separate dialog > - No live preview

I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Not saying that the new Print plug-in shouldn't be improved, but it should not be our goal to overload it until is has all the features that the gimp-print plug-in had.

Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them...

Sven Neumann writes:

I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality.

Robert L Krawitz writes:

Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them...

The live preview is essential for non-geeky people and visually oriented people (artist types), who aren't going to try to go from text like ".8 inches, Reverse Landscape" to visualizing what will actually be printed.

I might be biased. Gimp-print, and particularly its live preview, was the key that enabled me to switch to Linux full-time back in the day. Before that I'd been fighting with Photoshop LE, which had an absolutely horrible print UI: you had to click a secret unlabelled area in the status bar to pop up a preview window, which consisted of a white rectangle with an "X" over the part that would be printed. Gimp-print's low-res preview showing the actual image may not have been perfect, but it was a huge improvement in usability over anything I'd found on Windows.

Setting unequal margins is an intermediate case. That's really useful for one task a lot of non-geeky users might like to do: printing holiday cards. But maybe that one's less important since there's a workaround, even if it's more hassle (position the image on a white canvas 2.x times as large).

This is the specification for the rectangle + oval selection, and the crop tools. It is based on the state of GIMP 2.3.13.

handling the rectangle on the canvas

The algorithm for the size of the corner handles as implemented (handle height = rectangle height / 3, CLAMPed by 5 and 50, handle width = rectangle width / 3, CLAMPed by 5 and 50) allows fast interaction, and shall remain as-is.

The areas between two adjacent corner handles is called a side handle. The height of the two horizontal side handles shall be exactly the corner handle height, the width of the two vertical side handles shall be exactly the corner handle width. It is incredibly important that this change is made: to allow fast interaction by making the size of the side handles predictable.

The highlighting of all handle as implemented is good enough for rock-n-roll. no change. After evaluating the flashing of the side handles when you fly over them to get to a corner handle, I say: not a serious problem, user is focussed on that corner. Make a release and see how users get along with it.

When the mouse is over one of the handles, and one of the up/down/right/left cursor keys is pressed, the rectangle shall be resized by one (shift: 15) pixel in that direction. incredibly important: the mouse pointer shall move the same pixels in the same direction. This may sound forbidden but it is exactly what the user needs.

Mouse over rectangle but not over handle? Like above, but move (including the mouse pointer).

layer/canvas edges

It shall be possible to start a crop/selection rectangle outside the layer/canvas. Unless 'allow growing' for crop is checked (see below) the actual crop/selection rectangle shall be limited by the sides of the layer/canvas, also while the mouse is still down (rubber-banding). This is incredibly important for the 'use ratio' constraint.

For crop there shall be a new checkbox in the options panel: 'allow growing' (default: unchecked). Normally limiting cropping to the exact edges of the layer/canvas has the highest priority, hence the rules above. This checkbox overrides that, and the layer/canvas can be size up by dragging a bigger rectangle around it.

the 'use ratio' constraint and the shift key

Between the 'Expand from centre' and Highlight checkbox there shall be the 'use ratio' control (sketch attached), for the two select tools and crop.
It is a checkbox, combined with a single textfield and the two portrait + landscape icons from the New dialog. The textfield and icons shall be always displayed in the panel.

It is extremely important that the textfield shall be a single textfield with no up/down arrows. This allows for quicker input. The textfield shall accept the formats A/B and A:B, where A and B are two floating point numbers.

The default value for the textfield shall be "1:1" for the selection tools and
:
for the crop tool. When the user enters a value and confirms it by enter/return or removing the input focus from the textfield, this is the override value for this tool. It shall be displayed and used for this tool for the rest of the runtime session, for every file. This enable a pro to work 8 hours a day to cut out hundreds of 16:9 images.

This override value is cleared by clearing any numerical content from the field before confirming. This resets to displaying and using the default value for the tool.

When the checkbox is checked, the ratio shall be enforced while rubber-banding a rectangle. Pressing the shift key while rubber- banding shall toggle the checkbox in the other state.

The two icons shall be just icons, not in pushbuttons like in the New dialog. Clicking one of the icons shall simply enforce portrait or landscape in the textfield by swapping the two number values when necessary.

the tool option panels

From all three tool option panels, remove all the Fix buttons, The line with the Aspect fields, and the three buttons below it.

Selecting more than one of constant ratio/width/height actually sets a constant rectangle size and this makes for wild, chaotic rubber-banding behaviour. We could implement a radioing system for these 3 constraints, but the complexity and UI bandwidth usage is too much. So I chose the simple solution: specific widths and heights shall be typed and confirmed by enter/return or removing the input focus from the textfield. Clearing any numerical content from a field before confirming shall just restore the value displayed before the typing commenced.

All lines that contain textfields shall be sized such that they just fit inside a tool option panel that is 6 tool icons wide (the default, I believe...).

The guides pop-up menu left side shall be aligned with the left sides of the checkboxes, the pop-up menu right side shall be aligned with the left sides of the textfields.

Highlight

When the Highlight checkbox is checked, then the darkening effect shall not be displayed during rubber-banding. This allows for precise adjustments.

Phew, I am going on my christmas holiday. When needed we can discuss this during/at the 23c3...

--ps

principal user interaction architect man + machine interface works

http://mmiworks.net/blog : on interaction architecture

From: Sven Neumann
Date: Fri, 29 Dec 2006 17:18:58 +0100

- Clicking Print seems to get stuck if the printer isn't on when I click it. The progress bar goes to 100% and then stays there, and nothing shows up in the print queue. Subsequently turning the printer on doesn't help. If the printer is on when I click Print, it does eventually send something to the print queue (though it takes a surprisingly long time, even for a small image in Draft mode, compared to the gimp-print plug-in).

I have improved the status messages a little since you reported this. Printing is still rather slow though. I am not sure if and how this can be improved. Again, we seem to need advice from a GtkPrint expert here.

The hang could also be a spooler issue. Unless GtkPrint is doing some kind of special checking (or you're not using a spooler), it shouldn't even know if the printer that the printer isn't on.

- When I print using this plug-in, I get periodic horizontal light bands. I'll do more testing, but I think it's something this plug-in is doing (not a clogged nozzle on my printer or similar issue) because I can print at different scales and resolutions and the bands always show up at the same places relative to the original image, regardless of physical spacing on the page.

Yes, the banding comes from the fact that the plug-in paints the image in stripes of tile height. It does that to avoid having to allocate memory for the whole image. I hope that we can find a way to fix this.

How would this kind of banding affect the output?