Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
drizzt wrote: Hi all ! This is a long post, replying to many previous posts, and adding some parts from IRC chats, and some even from discussions with Gimp developers. Hi, Long it was, for sure. Sorry but if you don't want the GIMP UI to evolve and change, don't upgrade to new versions. Basic rules of interaction design applies to both open source and commercial projects. Now, open source and commercial projects can have completely different goals, and often have, but basic rules of interaction design still applies. With all due respect it to me sounds like you have not looked into interaction design at all and is just ranting based on your highly personal preferences. Looking into the world of interaction design will give you valuable insights. I recommend you to read the book The Inmates Are Running the Asylum by Alan Cooper. It is not a handbook on how to design interactive systems, but more of an eye-opener of what's wrong with todays products and processes as far as interaction design goes. In that book he addresses a lot of the points you are making. BR, Martin ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Martin Nordholts wrote: world of interaction design will give you valuable insights. I recommend you to read the book The Inmates Are Running the Asylum by Alan Cooper. It is not a handbook on how to design interactive systems, but I wouldn't bother. Whatever insights are contained in this book are completely clouded by the outright mistakes and predudice it containts. It is little more than a rant in itself. Graeme Gill. ___ 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
Andrew A. Gill wrote: [from here out, `you' refers to core GIMP developers] We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork. With all the excellent input from people in the printing industry, including you, I think it is as clear as it can be. GIMP needs to support editing in the CMYK color space. Support for editing only in the RGB color space will simply not be enough. The details on _how_ to support this is still an open question, but that we _need_ to is to me just unquestionable. Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes. If you tell us what we need to do, we can do it. That's the point of Open Source! If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else. From the outside, GIMP is seen as a shining example of what open source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS. I must say I find this a bit arrogant. Supporting someone that is inexperienced with hacking on the GIMP core to implement CMYK, which arguably is the toughest task one can currently take on as far as GIMP hacking goes, would be both very boring and very time consuming. That is not something I want to spend my spare time on. If you want to help implement better support for CMYK you should start working on and looking into the GIMP code. After working on the code for a while you will get your own ideas on how to implement CMYK in the best way. I've been contributing code to GIMP for quite a while now, and I don't know yet know exactly how to implement support for CMYK editing in the best way. All I know is that GEGL will be a much better base for this than the legacy code. So if you want to help getting CMYK into GIMP, helping with the integration of GEGL will be a good start. Best regards, Martin ___ 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
On Thu, 26 Mar 2009, Martin Nordholts wrote: I must say I find this a bit arrogant. Maybe. Probably. But I think it's time for me a a user to stop telling developers what I need and to start asking what you need to make that happen. I think it's time to stop looking at this from the position of nebulous wants and desires and to start looking at the end product and asking what restrictions need to be placed on its development. Where does it connect to the rest of the program? How does it interact with the rest of the program? When we know that, we'll be able to start figuring out how best to implememt it. Supporting someone that is inexperienced with hacking on the GIMP core I'm not asking for support. I'm just asking you what the shape of the hole is that the CMYK peg must fit into. I'm not really suggesting that I tackle the problem, but in my experience, the first response to ``You should have feature X'' is usually ``You forgot to attach the patch.'' Talk is cheap, and somebody needs to offer to help. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ 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
On Wed, 25 Mar 2009, Vincent Lordier wrote: Hello happy CMYK warriors, This is valuable input you're giving actually How about collecting these use cases for prepress in the wiki here http://wiki.gimp.org/gimp/ ? Well, I'm a man of my word and so I just contributed my wiki attempt to do my part to change this from pie-in-the-sky dreaming. There's an incomplete draft here: http://wiki.gimp.org/gimp/ToDo/FloorpieCMYK I still need to come up with a good color correction example and a good rich black example, but I should sleep now. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote: levels, curves - could support the user's intention more directly: - mark places in the image, which should be brighter/darker, or have more/less contrast or modified colors - the whitepoint, graypoint pickers could be adjustable markers on the image. Or a completely different method for whitebalance? - if tones are getting compressed, better control of where the clipping happens (separately for each of R,G,B, Value) Yup, on-canvas level/curves. Excellent point. Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape). Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
gradation map - nearly the same: map image points to positions in the gradient Yahvuu, you probably need to clarify: how is this different from Colors-Map-Gradient Map? On Thu, Mar 26, 2009 at 8:02 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote: levels, curves - could support the user's intention more directly: - mark places in the image, which should be brighter/darker, or have more/less contrast or modified colors - the whitepoint, graypoint pickers could be adjustable markers on the image. Or a completely different method for whitebalance? - if tones are getting compressed, better control of where the clipping happens (separately for each of R,G,B, Value) Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific Yup, on-canvas level/curves. Excellent point. Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape). If I had this, I'd probably delete all my gradients :) IMO this is a much more usable way in general, and premade gradients cover only a small subset of use cases. David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
Peter Hi, I think you should post this question to the GIMP-USERS list. I find it extremely useful to ask the users themselves what do they want to be a part of a package they are using... Irena On Wed, Mar 25, 2009 at 10:38 PM, peter sikking pe...@mmiworks.net wrote: hi all, at the end of may I am again teaching an interaction design course at the FH Voralrberg (university of applied sciences). here is the plan: the course is in the form of a design project, and the students work in small teams on a UI concept for GIMP. all (4) teams work on the same design problem. after the thing is over and they got their grades, I will take the overall concept further using their ideas and then spec a solution. so now we need a design problem. the course is short but intense, 3 days with me full-time to work up a solutions model and then they take some days to finish their presentation. so now huge redesign problems, more something like a compact tool. (like the free/poly select tool), or a tricky interactive dialog (like, combined brightness/contrast + levels + curves). please post your suggestions what we could do. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Irena Damsky irena.dam...@gmail.com 057-8165528 052-3294417 you can also find me on MSN: ira_dam...@hotmail.com Smile! and the world will smile with you! Cry! and you'll cry alone... ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] a good student UI project...
hi, David Gowers schrieb: gradation map - nearly the same: map image points to positions in the gradient Yahvuu, you probably need to clarify: how is this different from Colors-Map-Gradient Map? sorry for the misspelling. Exactly Colors-Map-Gradient Map is what i meant. Here again, a balance between emphasizing certain photo areas and adjusting the global tone is desired. On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote: - if tones are getting compressed, better control of where the clipping happens (separately for each of R,G,B, Value) Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific Indeed, clipping is under full control right now. Applying the on-canvas idea, it's interface could be supplemented by marking the border between important image regions and those regions which can be color-clipped without regret. More useful would be augmented feedback: - how harsh does the clipping start? - which details get lost? - is one of R,G,B clipping early? Something more advanced than letting the clipped pixels blink could be interesting here. greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
And finally, I agree with Sven that I don't know why anyone would want to have multipage PDF output for GIMP. This is very simple : Illustrator CS4 has just implemented a real multipage PDF support. My opinion, if worth, is that gimp don't have to copy adobe software, even if there are many good idea in those too. Gimp actual CMYK conversion process is good for most of the jobs and actually much more since i know only very few print shop working with a really accurate Color management. But it's true and in some cases having too rich black (such as 300 % or 360 % like i already get on day). Finally, there is a plugin that can export each plate separately, but needs improvement too, for sure. This is also the case with Inkscape. My workflow is usually to make the PDF in Scribus after having imported the RGB picture. The output seems to be better. (at least Adobe user could read InDesign documentation and see this also the workflow recommended now even in Adobe process. And i think once they'll have publish a complete PDF Ripping process it will be more and more the case). If that helps. pygmee ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CMYK editing (Was: GIMP PDF export plugin)
On Thursday, March 26, 2009, 21:20:53, Cédric Gémy wrote: This is very simple : Illustrator CS4 has just implemented a real multipage PDF support. You mean something that CorelDraw had for years? Then again, both CorelDraw and Illustrator are vector editing programs, and having multiple pages in them is natual. GIMP OTOH is primarily a bitmap editor, and as such multipage support doesn't make much sense (and wouldn't easily fit in the workflow). -- Jernej Simončič http://eternallybored.org/ Creativity varies inversely with the number of cooks involved with the broth. -- Fitz-Gibbon's Law ___ 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
Hi all, Louis Desjardins schrieb: Guillermo Espertino a écrit : Even though I agree that most of the CMYK cases mentioned use CMYK almost as spot colors, I can think of a very common usage scenario in Graphic Design where you need to be able to edit CMYK directly: Corporate colors. Most frequently Pantones. Brands have their corporate colors and ask designers to use them, but they can not always afford extra spot passes in offset press, so the colors have to be converted to the most aproximate CMYK combination (the Pantone Bridge catalog is for that). So you have to adjust the color of a photograph of a sign, a truck and a producto of your client to their corporate CMYK color. It's a photograph, you need CMYK, you can't use spot. just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first. Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be live, so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes. This is a very common scenario, and it's a task for a image manipulation program. I cannot agree more. It’s day-to-day work, day-to-day reality. We could add dozens of examples, I guess. Please do so. The general need for CMYK support beyond mere color separation has been put out quite clearly. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). By this i mean anything which can't be done by processing the plates as separate grayscale channels (see Øyvind Kolas's post). greetings, peter ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 50
On Thu, Mar 26, 2009 at 3:04 PM, gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@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. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: GIMP PDF export plugin (Louis Desjardins) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Louis Desjardins) 5. Re: Dockable Dialogs Should be Dockable Everywhere (Martin Nordholts) 6. Re: Dockable Dialogs Should be Dockable Everywhere (Graeme Gill) 7. Re: GIMP PDF export plugin (Martin Nordholts) -- Message: 1 Date: Wed, 25 Mar 2009 23:45:41 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Louis Desjardins louis_desjard...@mardigrafe.com Cc: gimp-developer gimp-developer@lists.XCF.Berkeley.EDU, gespert...@gmail.com Message-ID: alpine.lnx.1.00.0903252325460.7...@localhost Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed On Wed, 25 Mar 2009, Louis Desjardins wrote: To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality. I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- -- Message: 2 Date: Wed, 25 Mar 2009 23:59:02 -0400 From: Louis Desjardins louis_desjard...@mardigrafe.com Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Andrew A. Gill superlu...@frontiernet.net Cc: gimp-developer gimp-developer@lists.XCF.Berkeley.EDU, gespert...@gmail.com Message-ID: 49cafd86.3040...@mardigrafe.com Content-Type: text/plain; charset=windows-1252; format=flowed Andrew A. Gill a ?crit : On Wed, 25 Mar 2009, Louis Desjardins wrote: To this point I don?t believe it?s that important to start figuring out whether the case is as good an example as it possibly can. I guess we are not at all trying to make the trial of the use of CMYK in the printing industry! (Now, that would be a total waste of time!) For those interested I bet a full glass of beer ? available at LGM! ? that they can find without too much efforts plenty of explanations about CMYK use in the printing industry on the web. Even non-offset printing go by CMYK and inkjet printing involves CMYK plus Light Cyan, Light Mangenta and/or Vivid Magenta and some Black variations. Somehow, somewhere in the process these printers need to convert the data so the printer can use one of the CMYK inks that?s in the machine, be it toner or printing ink. There is no way to ignore this reality. I am informed that some CcMmYK printers accept only RGB data. In such cases, it would be better not to convert to CMYK, since it will only have to be converted back to RGB before it goes to the device. This mostly depends on the RIP that is attached to the printer but really, this doesn?t prove the point of the need of CMYK editing ability to be wrong, does it? Louis -- Message: 3 Date: Thu, 26 Mar 2009 00:10:01 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net Subject: Re: [Gimp-developer] GIMP PDF export plugin To: Louis Desjardins louis_desjard...@mardigrafe.com Cc: gimp-developer gimp-developer@lists.XCF.Berkeley.EDU
Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 49
On Thu, Mar 26, 2009 at 11:21 AM, gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@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. Re: GIMP PDF export plugin (Andrew A. Gill) 2. Re: a good student UI project... (yahvuu) 3. Re: GIMP PDF export plugin (Guillermo Espertino) 4. Re: GIMP PDF export plugin (Andrew A. Gill) 5. Re: GIMP PDF export plugin (Graeme Gill) 6. Re: GIMP PDF export plugin (Louis Desjardins) -- Message: 1 Date: Wed, 25 Mar 2009 20:40:25 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net Subject: Re: [Gimp-developer] GIMP PDF export plugin To: gra...@argyllcms.com Cc: gimp-developer gimp-developer@lists.XCF.Berkeley.EDU Message-ID: alpine.lnx.1.00.0903251935200.31...@localhost Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On Thu, 26 Mar 2009, Graeme Gill wrote: As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether. For the record, Scribus does allow pixel editing. When you right click on an image and select Edit Image, it opens the image in GIMP. I think that's pretty strong evidence that there's no intent to do raster editing in Scribus itself. I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead. FYI, Krita is extremely buggy. It has an SDI, which some people (e.g. me) don't like, but the code will improve and there may be improvements in the interface. Krita may indeed surpass GIMP. Sad, really, since I think GIMP can be the better product. [from here out, `you' refers to core GIMP developers] We want you to succeed, and all you need to do to succeed is to address some of the issues that users need. If you're telling us that GIMP has no intention of ever providing those things, we'll find another product. Maybe Krita when it becomes vaguely stable, or maybe a fork. But you've got the time to do it before the others catch up, and you've got GEGL, the toolset to do it right. Here's a thought: I can code. I'm sure others on this list can, too. Why don't you tell us what you would require for a CMYK mode to be incorporated into the trunk of GIMP. We can all read the API, but you can tell us what coding standards we need, what toes we can't step on and why other attempts to add similar functionality (like Cinepaint nee FilmGimp) foundered, and what we can do to avoid making those same mistakes. If you tell us what we need to do, we can do it. That's the point of Open Source! If you don't, people are going to get sick of the excuses and simply move on to develop this functionality somewhere else. From the outside, GIMP is seen as a shining example of what open source is capable of. Inside the OSS movement, it's seen much like the XFree86 guys--constantly bickering about the same issues. I'm sure that you'd have no trouble getting developers to work on a flagship product if they were convinced that it would end some of the internal conflicts in OSS. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- -- Message: 2 Date: Thu, 26 Mar 2009 02:12:03 +0100 From: yahvuu yah...@gmail.com Subject: Re: [Gimp-developer] a good student UI project... To: peter sikking pe...@mmiworks.net Cc: GIMP Developer gimp-developer@lists.XCF.Berkeley.EDU Message-ID: 49cad663.9060...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi Peter, some ideas from a typical photo workflow: perspective correction- select some prominent lines from the image and get them straight alignment of horizon line - in cooperation with an automated guess? crop rotate, set- virtual photography ala google earth? aspect ratioperhaps even with composition aids (rule of thirds, Westhoff's Diagonal Method, etc) levels, curves - could support the user's intention more directly:
Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 48
On Thu, Mar 26, 2009 at 7:40 AM, gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@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. Re: Dockable Dialogs Should be Dockable Everywhere (Alexandre Prokoudine) 2. Re: GIMP PDF export plugin (Andrew A. Gill) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Graeme Gill) 5. a good student UI project... (Nicolas Robidoux) 6. a good student UI project... (Nicolas Robidoux) -- Message: 1 Date: Thu, 26 Mar 2009 01:16:04 +0300 From: Alexandre Prokoudine alexandre.prokoud...@gmail.com Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere To: GIMP Developer gimp-developer@lists.xcf.berkeley.edu Message-ID: 733f2c730903251516l180719d6pdb254a6c548d5...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote: A tool should work out of box and help getting the work done right away. But if each time you take your tool out of the box, it's behavior has changed, you cannot use it. So maybe you are creating a thing new users can play with, but please keep in mind that there are people currently using the tool !!! I feel justified to reply only to this one, but it basically covers all of your email. You seem to be separating users into two groups: 1) those who like GIMP the way it is now and do not want any other UI and 2) new users who don't care what the previous UI looked like. And you seem to be in the first group. Too bad, because this distinction is incorrect. There's plenty of actual GIMP users who desperately want a better UI , a lot of users who kind of don't mind a new UI and a whole lot of users who don't know yet how much they will love a new UI. Now regarding old tool/new tool. Do you know what is one of most disgusting things in applications like ACD Canvas that are over 20 years old? It's the ugly way their developers never ever refine them. Just like you say they keep all the old tools, all the old behaviours, everything they don't feel comfortable to throw away. And it piles up. How about A hotkey that is in use by three (sic!) different tools depending on tool group? How about 3-level nested toolbox? How about separate erasers for bitmap and vector objects? These applications become a horror to use for both old-timers and novices. Now please give this a lot of thought before replying. P.S. Shouting is of no help in this list. Alexandre -- Message: 2 Date: Wed, 25 Mar 2009 18:20:46 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net Subject: Re: [Gimp-developer] GIMP PDF export plugin To: peter sikking pe...@mmiworks.net Cc: GIMP Developer gimp-developer@lists.XCF.Berkeley.EDU, scri...@lists.scribus.info Message-ID: alpine.lnx.1.00.0903251807280.31...@localhost Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On Wed, 25 Mar 2009, peter sikking wrote: Alexandre Prokoudine wrote: There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis: 1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare. 2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K=100%) and blue (C=100%M=0%Y=0%K=0%). separate+ however separates black to 4 channels. 3. Some print houses set limit to overall sum of colors, for example 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a little of K and Y this will result in unnatural colors in a newspaper. 4. Live density control for each CMYK channel is a must (Scribus/SVN has that in preview dialog). To me it's somewhat strange that GIMP's product vision doesn't mention prepress needs explicitly. A vision is an expression of the project of what they want the software to be. There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported. Now what about that prepress. I think it is fairly
Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 54
On Fri, Mar 27, 2009 at 4:58 AM, gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@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. Re: Gimp-developer Digest, Vol 78, Issue 48 (Hollywoodkiller Movies) -- Message: 1 Date: Fri, 27 Mar 2009 04:57:59 +0800 From: Hollywoodkiller Movies hollywoodkillermov...@gmail.com Subject: Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 48 To: gimp-developer@lists.xcf.berkeley.edu Message-ID: 43e4d8fe0903261357qf24c151m7d4763a7df4aa...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 On Thu, Mar 26, 2009 at 7:40 AM, gimp-developer-requ...@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-requ...@lists.xcf.berkeley.edu You can reach the person managing the list at gimp-developer-ow...@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. Re: Dockable Dialogs Should be Dockable Everywhere (Alexandre Prokoudine) 2. Re: GIMP PDF export plugin (Andrew A. Gill) 3. Re: GIMP PDF export plugin (Andrew A. Gill) 4. Re: GIMP PDF export plugin (Graeme Gill) 5. a good student UI project... (Nicolas Robidoux) 6. a good student UI project... (Nicolas Robidoux) -- Message: 1 Date: Thu, 26 Mar 2009 01:16:04 +0300 From: Alexandre Prokoudine alexandre.prokoud...@gmail.com Subject: Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere To: GIMP Developer gimp-developer@lists.xcf.berkeley.edu Message-ID: 733f2c730903251516l180719d6pdb254a6c548d5...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Thu, Mar 26, 2009 at 12:52 AM, drizzt wrote: A tool should work out of box and help getting the work done right away. But if each time you take your tool out of the box, it's behavior has changed, you cannot use it. So maybe you are creating a thing new users can play with, but please keep in mind that there are people currently using the tool !!! I feel justified to reply only to this one, but it basically covers all of your email. You seem to be separating users into two groups: 1) those who like GIMP the way it is now and do not want any other UI and 2) new users who don't care what the previous UI looked like. And you seem to be in the first group. Too bad, because this distinction is incorrect. There's plenty of actual GIMP users who desperately want a better UI , a lot of users who kind of don't mind a new UI and a whole lot of users who don't know yet how much they will love a new UI. Now regarding old tool/new tool. Do you know what is one of most disgusting things in applications like ACD Canvas that are over 20 years old? It's the ugly way their developers never ever refine them. Just like you say they keep all the old tools, all the old behaviours, everything they don't feel comfortable to throw away. And it piles up. How about A hotkey that is in use by three (sic!) different tools depending on tool group? How about 3-level nested toolbox? How about separate erasers for bitmap and vector objects? These applications become a horror to use for both old-timers and novices. Now please give this a lot of thought before replying. P.S. Shouting is of no help in this list. Alexandre -- Message: 2 Date: Wed, 25 Mar 2009 18:20:46 -0400 (EDT) From: Andrew A. Gill superlu...@frontiernet.net Subject: Re: [Gimp-developer] GIMP PDF export plugin To: peter sikking pe...@mmiworks.net Cc: GIMP Developer gimp-developer@lists.XCF.Berkeley.EDU, scri...@lists.scribus.info Message-ID: alpine.lnx.1.00.0903251807280.31...@localhost Content-Type: TEXT/PLAIN; format=flowed; charset=US-ASCII On Wed, 25 Mar 2009, peter sikking wrote: Alexandre Prokoudine wrote: There was a somewhat heated discussion of this thread at linuxgraphics.ru
Re: [Gimp-developer] Gimp-developer Digest, Vol 78, Issue 51
) Yup, on-canvas level/curves. Excellent point. Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape). Alexandre -- Message: 4 Date: Thu, 26 Mar 2009 20:29:48 +1030 From: David Gowers 00a...@gmail.com Subject: Re: [Gimp-developer] a good student UI project... To: Alexandre Prokoudine alexandre.prokoud...@gmail.com Cc: GIMP Developer gimp-developer@lists.xcf.berkeley.edu Message-ID: 23f4e3390903260259p4a6d55ebtb4e9b2d339852...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 gradation map - nearly the same: map image points to positions in the gradient Yahvuu, you probably need to clarify: how is this different from Colors-Map-Gradient Map? On Thu, Mar 26, 2009 at 8:02 PM, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Thu, Mar 26, 2009 at 4:12 AM, yahvuu wrote: levels, curves - could support the user's intention more directly: ? ? ? ? ? ? ? ? ? - mark places in the image, which should be brighter/darker, ? ? ? ? ? ? ? ? ? ? or have more/less contrast or modified colors ? ? ? ? ? ? ? ? ? - the whitepoint, graypoint pickers could be adjustable markers ? ? ? ? ? ? ? ? ? ? on the image. Or a completely different method for whitebalance? ? ? ? ? ? ? ? ? ? - if tones are getting compressed, better control of where the ? ? ? ? ? ? ? ? ? ? clipping happens (separately for each of R,G,B, Value) Better? We already have exact control of clipping for each of R,G,B,Value , so do you mean a change in the quality of clipping control? I think this needs to be more specific Yup, on-canvas level/curves. Excellent point. Another idea: Gradient fill tool that has color stops editable on canvas (a-la Inkscape). If I had this, I'd probably delete all my gradients :) IMO this is a much more usable way in general, and premade gradients cover only a small subset of use cases. David -- Message: 5 Date: Thu, 26 Mar 2009 18:51:30 +0200 From: Irena Damsky irena.dam...@gmail.com Subject: Re: [Gimp-developer] a good student UI project... To: peter sikking pe...@mmiworks.net Cc: GIMP Developer gimp-developer@lists.xcf.berkeley.edu Message-ID: 4ecb01410903260951i612ac6a6pebbd3444e1ef5...@mail.gmail.com Content-Type: text/plain; charset=iso-8859-1 Peter Hi, I think you should post this question to the GIMP-USERS list. I find it extremely useful to ask the users themselves what do they want to be a part of a package they are using... Irena On Wed, Mar 25, 2009 at 10:38 PM, peter sikking pe...@mmiworks.net wrote: hi all, at the end of may I am again teaching an interaction design course at the FH Voralrberg (university of applied sciences). here is the plan: the course is in the form of a design project, and the students work in small teams on a UI concept for GIMP. all (4) teams work on the same design problem. after the thing is over and they got their grades, I will take the overall concept further using their ideas and then spec a solution. so now we need a design problem. the course is short but intense, 3 days with me full-time to work up a solutions model and then they take some days to finish their presentation. so now huge redesign problems, more something like a compact tool. (like the free/poly select tool), or a tricky interactive dialog (like, combined brightness/contrast + levels + curves). please post your suggestions what we could do. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- Irena Damsky irena.dam...@gmail.com 057-8165528 052-3294417 you can also find me on MSN: ira_dam...@hotmail.com Smile! and the world will smile with you! Cry! and you'll cry alone... -- next part -- An HTML attachment was scrubbed... URL: /lists/gimp-developer/attachments/20090326/58e3c3be/attachment-0001.html -- Message: 6 Date: Thu, 26 Mar 2009 18:37:39 +0100 From: yahvuu yah...@gmail.com Subject: Re: [Gimp-developer] a good student UI project... To: GIMP Developer gimp-developer@lists.xcf.berkeley.edu Message-ID: 49cbbd63.8060...@gmail.com Content-Type: text/plain; charset=ISO-8859-1 hi, David Gowers schrieb: gradation map - nearly the same: map image points to positions in the gradient Yahvuu, you probably need to clarify: how is this different from Colors-Map-Gradient Map? sorry for the misspelling. Exactly Colors-Map-Gradient Map is what i meant. Here again, a balance between emphasizing certain photo areas and adjusting the global tone is desired. On Thu, Mar 26
Re: [Gimp-developer] GIMP PDF export plugin
El jue, 26-03-2009 a las 21:43 +0100, yahvuu escribió: Hi all, just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first. It won't be useful if the image has to be imported in a program that actually lets you assign CMYK values. Following with my example, the bitmap could be imported into scribus and put together with a logo, with the right CMYK values. Chances are that, though quite similar, the colors won't be the same. Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be live, so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes. But it will still be difficult to specify a color. For instance: I need the background of the image to be C=60%, K=100%. I'd use that combination because I want a rich black with cold shades of gray. If I use RGB, the separation will include Magenta and Yellow depending on the output profile and I wouldn't want that. Please do so. The general need for CMYK support beyond mere color separation has been put out quite clearly. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). By this i mean anything which can't be done by processing the plates as separate grayscale channels (see Øyvind Kolas's post). It's fine to adjust the grayscale channels if we get a corrected preview interactively. In fact, that's the way you do some adjustments in Photoshop. But there are several tools (channel mixer, curves) that is useful to have working in CMYK space. --- Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created. If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable. ___ 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
2009/3/27 Guillermo Espertino wrote: Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created. If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable. It was actually covered by one of the examples I provided, where a user had to do a poster in another application, because the main image was saved and sent in CMYK by his customer :) While it's important to teach customers not to @#$%$#% do so :), it's also important to teach *and* still be able to do the job. Otherwise you would have no return customers and that's what really matters. Alexandre ___ 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
Alexandre Prokoudine schrieb: 2009/3/27 Guillermo Espertino wrote: Also, in this discussion it seems that it was never considered that you can be working on images that somebody else sent you and you don't control how they were created. If somebody sent you a separated tiff of a magazine ad and you have to do some editing on it, you'll be destroying the original separation converting it to RGB. And that's unacceptable. It was actually covered by one of the examples I provided, where a user had to do a poster in another application, because the main image was saved and sent in CMYK by his customer :) While it's important to teach customers not to @#$%$#% do so :), it's also important to teach *and* still be able to do the job. Otherwise you would have no return customers and that's what really matters. actually, it was your first item in the list ;) greetings, peter ___ 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
On Thu, 26 Mar 2009, yahvuu wrote: just to be shure (i'm probably just paraphrasing Andrew A. Gill's follow-up): No, you're not. That came out a little sharp. Let me try to soften it. You're entitled to your opinion, but I just want to make sure that there's no misunderstanding. I think this task can be done equally well in an RGB space, say sRGB. If Pantone's Bridge has sRGB approximations, it should be trivial. If not, you have to convert that single color from your best-guess CMYK to sRGB first. I said before that I didn't think this was a real use for CMYK, but that is because I think that even if GIMP had CMYK support, it would not be able to perform this task well enough. GIMP would need native Pantone support, which I don't think is really that useful at this time. As little as I trust Pantone to CMYK, I trust Pantone to RGB even less. By this i mean anything which can't be done by processing the plates as separate grayscale channels (see ?yvind Kolas's post). This is not fun. What you are suggesting is a very laborious process, and having such a process work properly would probably result in tens of minutes to hours of wasted time, depending on the image in question. And it still would result in one of the following: 1.) A helper application which creates the CMYK image 2.) GIMP still is unable to deal with trapping or rich black. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ 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
On Thu, Mar 26, 2009 at 10:14 PM, Andrew A. Gill superlu...@frontiernet.net wrote: As little as I trust Pantone to CMYK, I trust Pantone to RGB even less. By this i mean anything which can't be done by processing the plates as separate grayscale channels (see ?yvind Kolas's post). This is not fun. What you are suggesting is a very laborious process, and having such a process work properly would probably result in tens of minutes to hours of wasted time, depending on the image in question. And it still would result in one of the following: 1.) A helper application which creates the CMYK image 2.) GIMP still is unable to deal with trapping or rich black. I was not describing user interface anywhere in my mail, I was describing underlying implementation mechanisms. GEGL stores pixels in buffers that can store and on demand convert to and from RGB, YCbCr, CIE Lab and Grayscale (dynamically extendable with other color models). Allowing image processing operations to be implemented using the models best fit for a particular operation. GeglBuffers are not designed to deal with the special cases of multi spectral images (lets say 32bands), spot colors (print plates). Render layers as present in EXR files (blender for instance produces multiple layers that are useful in post processing of the render). These will have to be dealt with on top. For CMYK the following ops need to be implemented: CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output. CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof. CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op. Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented. If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI. The primitives above should provide both preview and control over CMYK the fact that the innermost core doesn't care about CMYK would probably bleed into the user interface in the form that not all operations operate on CMYK images like they do on RGB images, it might not even make sense to accomodate for having layers of CMYK objects but only cater to the hard-core CMYK needs of pre-press, with a core set of the tools (color picker, color balance, curves, color picker) aware of how to deal with the CMYK bundle. Doing things like blurs and pastes would normally operate on the single selected plate, but electing to process for all plates should be possible. At the moment I do not have interest in CMYK but the above outline is in line with my ideas on how GEGL should evolve. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ 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
Date: Thu, 26 Mar 2009 23:08:37 + From: =?ISO-8859-1?B?2Hl2aW5kIEtvbOVz?= islew...@gmail.com For CMYK the following ops need to be implemented: CMYK-from-RGB - takes a GeglBuffer as input, has options for black subtraction, ICC profile selection, gamut handling and similar, provides four gray scale GeglBuffers as output. CMYK-to-RGB - takes a four separate gray scale GeglBuffers as input and provides an RGB soft proof. CMYK-to-CMYK - which converts to a CMYK GeglBuffer (OK, GEGL and babl actually support very naive CMYK buffers, these buffers are fragile and should probably only be used as a prestep to passing the buffer to a TIFF or similar saving op. Similar duotone-from-RGB and a configurable duotone-to-RGB or special five channel ops for use with CMYK with additional spot colors, or perhaps even a generic configurable ink-mixer op could be implemented. If a person with interest in these things want to he could also add support for 1bit GeglBuffers and generate the final raster to be printed at the printers native DPI. FYI, most inkjet printers these days are actually 2 bits per physical channel. A lot of this already exists in Gutenprint; you may want to look at that. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail l...@uunet.uu.net Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
hey crew, this whole pdf/cmyk discussion has been a nice exercise for me in getting to know the activity as Don Norman calls it. this is what I digest from all that has been said here: rule #1: the topic we are talking all the time about here is not cmyk, tiff or pdf. the topic we are talking about is mastering for the printing press everything evolves around that. 2) even though the printing press can be digital, plates is what it is all about. cmyk is the bleeding obvious way to set up those plates, but anything can happen (spot, CMKYGO). 3) control over what is on each plate, and then how they combine is the name of the game. I do not underestimate how much adjustment is needed for each plate (or multiple plates), basically the whole monochrome collection of image operations. 4) tiff or pdf? it is just a transport method. it is a strategic choice what to do first/better/at all. 5) there is the creative work to make the image and there is the mastering for the printing press. in general these two jobs randomly alternate during the life cycle of the image file. one moment there is creative development, the next there is work on the plates, then back to the creative part, etc. 6) if an image is in cmyk then we are stuffed when it comes to creative work. lots of operations/plugins will stop working or only via (implicit) cmyk-(other color model)-cmyk conversions, which are a no-no. 7) when opening a file in cmyk format, it has obviously been mastered for a printing press. either this mastering needs corrections, or this image is an 'found image' that goes into another creative work. the latter is better done in rgb (see 6). 8) trapping is an example of explicit printing press support. 9) it is necessary to set the same point on all plates to an exact ink value (think of setting a hard cmyk value for a block of text or selection of pixels). after writing the above I have reread for the third time all the emails in the thread. AFAIK all the input in the thread is captured in the above observations. my conclusions from this: 1) all creative work in GIMP is in rgb. 2) when it is one of those times (plural) to work on the printing press mastering of this file, then pull the press projection over the image window. now you can see the plates (similar to layers) and work on each or combinations. 3) the set-up of the press projection plates is of course the separation set-up (with printing press profile) and can be freely defined from the composite or individual layers of the image file (channel mixing on steroids). standard cmyk type of separations will be the bleeding obvious defaults to choose from. CMKYGO can easily be also a default. 4) flip the press projection up again and continue to work on the creative part. flip the press projection down again and the plates are updated from the image changes. with previous plate modifications applied on top. 5) the press projection set-up and all modifications made to the plates on the press projection are also saved in the GIMP file. 5) when it is time to send the printing press master then from the press projection it can be exported to a few suitable formats (tiff, pdf, ...). 6) importing a cmyk file? there should be a choice to either shove this straight into a press projection to do some mastering corrections, or to convert to rgb to be part of a new work of art. whew, --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
From: peter sikking pe...@mmiworks.net Date: Fri, 27 Mar 2009 01:20:48 +0100 this whole pdf/cmyk discussion has been a nice exercise for me in getting to know the activity as Don Norman calls it. this is what I digest from all that has been said here: rule #1: the topic we are talking all the time about here is not cmyk, tiff or pdf. the topic we are talking about is mastering for the printing press everything evolves around that. I think the case of text black is a partial, qualified exception -- but it's arguable that it has any bearing on RGB vs. CMYK. It really means the darkest, sharpest black that can be produced regardless of rendering device. It could just as well be represented as RGB+K, or simply as a separate layer. I'd argue that it's actually a creative choice, though. So I'd say that it's really not at odds with what you're saying. Perhaps prepress tasks would better be implemented as a plugin (or set of plugins)? It's hard for me to see how trapping (for example) would make any sense at all as part of the core, but as a plugin it would make perfect sense. I know Adobe at least used to sell a product called TrapWise whose purpose in life was to do nothing but trapping. I don't know if it had a Photoshop plugin component or not. -- Robert Krawitz r...@alum.mit.edu Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail l...@uunet.uu.net Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
gimp-developer-boun...@lists.xcf.berkeley.edu wrote: Hi all ! This is a long post, replying to many previous posts, and adding some parts from IRC chats, and some even from discussions with Gimp developers. ... I have a degree of sympathy with this post although it seems to go to the other extreme. Backwards compatibility *is* overrated. Autotools is a great example of what happens if you don't trim the crud out of your software. No doubt, I can compile Gimp on every Unix platform ever conceived between now and 1972 but I still have to learn about 4 different languages before I can begin to start understanding how it works, let alone deciphering the scripts. Call me an idiot if you like, but it shouldn't be easier to learn the finer points of C++ than the tool that simply builds it. On the other hand, we have KDE 4. Plenty of improvements, no doubt, but no users left to appreciate them. :) As for customisability? I think that it's probably underestimated. Take the example of me spending half an hour or more on google this evening trying to work out how to enable menu tear-offs in Gnome. As far as I can tell, the feature just isn't there any more. Luckily for me, canvas right-click still provides the feature. I needed it, btw, because I wanted to add several guides to my project, one after the other. Rather than having to navigate all the way to that menu item every time, it's much easier to just have it available on the screen. That's not the only use of this feature, btw. Another good use is for learning keyboard shortcuts. No need to hover the mouse over an icon for half a second; just glance at the menu. Like I said, I don't know what's happened to this (really nice) feature but I did find a clue in some Java/GTK SDK documentation which states that usability studies have concluded that menu tear-offs are a bad idea and should be avoided. Oh dear, I thought. Someone's been conducting usability studies. Not that I have anything particularly against UI studies, but the method had better be sound, the assumptions had better be correct, and the results had better be applied appropriately. If the conclusion comes as a surprise, re-examine the experiment...carefully. Anyway, getting back to the Gimp, I'd be willing to bet real money that whatever ideas you have about a typical Gimp user are probably wrong. By all means, design for whatever you think the common use case is likely to be but remember that Gimp is (to borrow a programming term) a low-level IMP. That makes it even more likely that usage patterns from one user to the next will be radically different. If you don't enable Gimp's users to do the things that you can't think of, you'll just have non-plussed Gimpers. If you take away those things? Well, good luck with all the hate. :) ---AV Spam Filtering by M+Guardian - Risk Free Email (TM)--- ___ 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
On Thu, 26 Mar 2009, ?yvind Kol?s wrote: I was not describing user interface anywhere in my mail, To be honest, I think I missed your message. If I have mischaracterized what you have said (and judging from what you say below, it looks like someone has), I crave pardon. Here's what I was disagreeing with: yahvuu: Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space (which is a good thing, btw). To justify this, the message continues: yahvuu: By this i mean anything which can't be done by processing the plates as separate grayscale channels (see ?yvind Kolas's post). It sounds to me like the latter sentence is referring to the UI, considering the content of the former sentence. I was describing underlying implementation mechanisms. GEGL stores pixels in buffers that can store and on demand convert to and from RGB, YCbCr, CIE Lab and Grayscale (dynamically extendable with other color models). Allowing image processing operations to be implemented using the models best fit for a particular operation. I certainly don't take issue with that. At the moment I do not have interest in CMYK but the above outline is in line with my ideas on how GEGL should evolve. At first blush, what you said seems about right. I'll read it more closely and give it more thought. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] digested: printing presses, cmyk, tiff + pdf...
I think I agree with 99% of what you wrote. Clarifications/quibbles: (wait. Nevermind. Probably about 75%) On Fri, 27 Mar 2009, peter sikking wrote: 4) tiff or pdf? it is just a transport method. it is a strategic choice what to do first/better/at all. PDF isn't really appropriate for raster images, but printers know how to deal with them and some expect it. 1) all creative work in GIMP is in rgb. Is currently? Or should be? I can agree that it is currently, but it should allow CMYK editing. 2) when it is one of those times (plural) to work on the printing press mastering of this file, then pull the press projection over the image window. now you can see the plates (similar to layers) and work on each or combinations. This would make a very useful feature, but it must accompany full CMYK editing. CMKYGO can easily be also a default. Probably not, for a few reasons. Hexachrome(R) is patent-encumbered, for starters. 4) flip the press projection up again and continue to work on the creative part. flip the press projection down again and the plates are updated from the image changes. with previous plate modifications applied on top. Ah. This is needlessly complicated and would require two versions of the same image. Remember--rich black is a necessary CMYK color and cannot be represented in RGB. Trapping images requires CMYK and the trapped image cannot be represented in RGB. Changes to one image cannot be automatically transferred to the other without complicated transforms. This is far more than just RGB CMYK. This would involve things like edge detection and intelligent algorithms to determine when a boundary between two colors in one version of the image has shifted and thus requires a change to the other version. To put it simply, this solution would require probably twice as much work as CMYK editing would. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | superlu...@frontiernet.net http://www.needsfoodbadly.com | -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
