Re: [Gimp-developer] GIMP PDF export plugin
Andrew A. Gill wrote: As little as I trust Pantone to CMYK, I trust Pantone to RGB even less. Actually, Pantone to Spectral to L*a*b* to device space (RGB/CMYK whatever) is pretty good. 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
Hi all, my previous posting does not stand a quality test, to put it mildly. To save the list from multiple nearly indentical follow-ups, i thinks it's best to bundle my replies here. My apologies for the noise. yahvuu schrieb: Thanks to GEGL's dynamic nature, the sRGB-CMYK separation will be live, so the resulting CMYK can be cross-checked immediately, like read-after-write with good old audio tapes. that's my personal wishful thinking. I have to take the blame for misguiding user interface speculations. Yet AFAIKS none of the examples has shown a requirement for doing actual image processing in CMYK space this is plain wrong. Already the levels curves example shuts me up. 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
Hi, On Wed, 2009-03-25 at 23:21 -0400, Louis Desjardins wrote: At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)? Without CMYK support in GEGL/babl, there will be no direct editing of CMYK in GIMP. So whoever wants to see CMYK editing in GIMP should help to - change GIMP to do all editing using GEGL - make sure that babl/GEGL gains first-class CMYK support Sven ___ 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] 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 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
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] GIMP PDF export plugin
On Mon, Mar 23, 2009 at 11:17 PM, Sven Neumann wrote: Hi, On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote: Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space. Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason. 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. 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
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/ ? (like the UI team did with brainstorm here : http://gimp-brainstorm.blogspot.com/ ) You could put it using these kind of chapters : https://wiki.ubuntu.com/UbuntuWithoutRestricted This way, we could specify the GIMP a bit better and coordinate dev efforts ;) enjoy this day ! vincent On Wed, Mar 25, 2009 at 16:21, Alexandre Prokoudine alexandre.prokoud...@gmail.com wrote: On Mon, Mar 23, 2009 at 11:17 PM, Sven Neumann wrote: Hi, On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote: Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space. Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason. 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. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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, Mar 25, 2009 at 6:21 PM, Alexandre Prokoudine wrote: 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). I was reminded that I actually forgot 5. Part of an image should be b/w and the rest should be colorized with just one tint. E.g. Cyan + Black for sea. separate+ and exporting are of no help here. 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
On Wed, 25 Mar 2009, Alexandre Prokoudine wrote: 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. The Christian Science Monitor does this pretty frequently, and 2-color ads and brochures are fairly popular because they are cheap. You can look online for examples, but I have to get to my prepress job now. To me it's somewhat strange that GIMP's product vision doesn't mention prepress needs explicitly. Agreed. I don't think anyone here is looking for a Photoshop clone (I know that I personally hate PS for a variety of reasons), but we do realize that it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not the best move. -- | 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: 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/ ? (like the UI team did with brainstorm here : http://gimp-brainstorm.blogspot.com/ ) You could put it using these kind of chapters : https://wiki.ubuntu.com/UbuntuWithoutRestricted This way, we could specify the GIMP a bit better and coordinate dev efforts ;) enjoy this day ! I'd be happy to, but I've got to get to work. InDesign is a flaky POS software that makes me wish there were a better free alternative. But since there isn't, I'll have to write up some examples when I get home. -- | 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, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote: Agreed. I don't think anyone here is looking for a Photoshop clone (I know that I personally hate PS for a variety of reasons), but we do realize that it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not the best move. Do we realize that? :) It is true that GIMP is usually seen as to-be-photoshop-substitution and its maturity in various areas in fact is the reason why people switch to GIMP. However GIMP doesn't seem to be driven by a will to make Photoshop die, die, die :) 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 wrote: There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis: 1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare. 2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K=100%) and blue (C=100%M=0%Y=0%K=0%). separate+ however separates black to 4 channels. 3. Some print houses set limit to overall sum of colors, for example 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a little of K and Y this will result in unnatural colors in a newspaper. 4. Live density control for each CMYK channel is a must (Scribus/SVN has that in preview dialog). To me it's somewhat strange that GIMP's product vision doesn't mention prepress needs explicitly. A vision is an expression of the project of what they want the software to be. There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported. Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this. The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk). --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] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote: There is choice in there, and the user community cannot demand that GIMP does certain things. It's quite an interesting point, because you are talking about demanding, whereas I'm talking about meeting users needs :) And you do understand the difference, do you? :) presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. So what you are saying basically is that you see GIMP users as human beings living in a parallel world where all of the things mentioned above do not exist, workflows are perfectly RGB based and nobody ever has to deal with color separations other than exporting :) Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level. 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 wrote: On Wed, Mar 25, 2009 at 8:44 PM, peter sikking wrote: There is choice in there, and the user community cannot demand that GIMP does certain things. It's quite an interesting point, because you are talking about demanding, whereas I'm talking about meeting users needs :) And you do understand the difference, do you? :) in general: users have lots of needs, but it is GIMP's team choice to meeting these needs _well_. the stress is on well, because if you decide to do it in your vision, you have to strive to be the best in that department. website mock-ups and code generation; multi-page, multi-column page layouts; hard disk de-fragmentation: users have these needs, but GIMP will not help them with these. presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. So what you are saying basically is that you see GIMP users as human beings living in a parallel world where all of the things mentioned above do not exist, workflows are perfectly RGB based and nobody ever has to deal with color separations other than exporting :) If you had carefully read what I am offering to design for GIMP you will see that it is a lot more than an export. I am talking about covering the main image window with a projection screen in this case for cmyk, whenever one wants, from the first to the last second of the project, that with the profile of the printing press will give you some idea (I know there are limits) of how it will come off the press. this projection screen will have its own layers where one can take corrective measures to make the output look good within the possible output range. these corrective layers will hen be used of course for the mastering/export to cmyk. all the cmyk tricks you talk about (ink decomposition, trapping) can be set up for the projection screen and where possible previewed there. the overall task is actually mastering the image for printing press, where cmyk happens to be an important factor in the world of today. Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level. I would like to have this answered answer first: why can't they do it with scribus? are we the last piece of (free) software in the world that can help them? --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] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 12:44 PM, peter sikking pe...@mmiworks.net wrote: Mix master tape (in rgb) and then cut the lp (in cmyk). I can express any CMYK color in RGB - but not the other way around. Therefore, I master all of my print jobs in CMYK, and if I cut something like a preview for a client then I use RGB space. So you see, it's actually quite the opposite in my world. This is why GIMP is only a small portion of my day to day work flow - it is not printer-friendly (yes, friendly to the device sitting on your desk, but not a person who is a printer). And I agree that Scribus is coming along nicely and will (hopefully) become a robust page layout program - but I think where GIMP comes into the arena is creating a single image that will be printed (in a magazine, screen printed, newspaper, whatever). Something like PDF+CMYK export is a good first step, but ultimately CMYK editing and channel operations are needed to make GIMP suitable for preparing an image for print. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 1:58 PM, peter sikking pe...@mmiworks.net wrote: Alexandre Prokoudine wrote: Which means in fact that the team does not wish to meet *real* prepress users needs on product vision level. I would like to have this answered answer first: why can't they do it with scribus? are we the last piece of (free) software in the world that can help them? Ah, but Scribus is a layout program, not an image editor. Ideally, one would prepare images for printing with GIMP, then embed them in a page with Scribus. Having control over the CMYK (or spot color) makeup of the image in GIMP should make things smoother when setting the image in Scribus. As to the projection screen, that approach sounds complicated. But if it can give a fairly honest CMYK projection and allow for manually adjusting the channels, then it would go a long way toward solving some of these problems. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 7:06 PM, Chris Mohler cr33...@gmail.com wrote: On Wed, Mar 25, 2009 at 12:44 PM, peter sikking pe...@mmiworks.net wrote: Mix master tape (in rgb) and then cut the lp (in cmyk). I can express any CMYK color in RGB - but not the other way around. Therefore, I master all of my print jobs in CMYK, and if I cut something like a preview for a client then I use RGB space. So you see, it's actually quite the opposite in my world. This is why GIMP is only a small portion of my day to day work flow - it is not printer-friendly (yes, friendly to the device sitting on your desk, but not a person who is a printer). And I agree that Scribus is coming along nicely and will (hopefully) become a robust page layout program - but I think where GIMP comes into the arena is creating a single image that will be printed (in a magazine, screen printed, newspaper, whatever). Something like PDF+CMYK export is a good first step, but ultimately CMYK editing and channel operations are needed to make GIMP suitable for preparing an image for print. I consider spot colors much more important than CMYK. I also consider CMYK a special case of spot colors. Spot colors could be implemented using GEGL ops that take a set of grayscale buffers (plates) as input and provides RGB soft-proofing (potentially even animated for gloss/metallic inks). This would leave the image processing algorithms dealing with sane or mildly sane color models like gray scale, RGB, YCbCr or CIE Lab, while allowing the user direct control over the contents of spot colors and seeing a preview of the resulting processing. If the above is considered CMYK support I would be supportive of it. CMYK support in the form of CMYK and CMYKA pixel buffers as a first class citizen (or even a third grade citizen) with support in most operations and routines is something I will continue to oppose. /Ø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
Hi, Chris Mohler schrieb: I can express any CMYK color in RGB - but not the other way around. now i'm confused :) Is CMYK-RGB-CMYK roundtrip safe? From past examples (trapping, rich black) i've come to think that hand-optimized CMYK separations can't be transformed back to RGB losslessly (quite opposite to gamut issues). Can some RGB color space be tricked to accommodate overprinting uses? 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 Wed, Mar 25, 2009 at 2:44 PM, yahvuu yah...@gmail.com wrote: Hi, Chris Mohler schrieb: I can express any CMYK color in RGB - but not the other way around. now i'm confused :) Is CMYK-RGB-CMYK roundtrip safe? Not really. What I was trying to say is that I send RGB proof images to my customers, even though the artwork is in CMYK - and they get a fairly honest representation of the final print. I do not actually convert from CMYK-RGB-CMYK though - just export RGB from the CMYK image. From past examples (trapping, rich black) i've come to think that hand-optimized CMYK separations can't be transformed back to RGB losslessly (quite opposite to gamut issues). Yeah - that will lead to problems. Can some RGB color space be tricked to accommodate overprinting uses? On that I have no idea... Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Wed, Mar 25, 2009 at 10:44 PM, yahvuu wrote: I can express any CMYK color in RGB - but not the other way around. now i'm confused :) Is CMYK-RGB-CMYK roundtrip safe? It's not :) And I believe that a small portion of CMYK colors is out of gamut for RGB too , by the way :) 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 wrote: It's not :) And I believe that a small portion of CMYK colors is out of gamut for RGB too , by the way :) Both RGB and CMYK are device dependent color spaces and without any kind or further specification one can not say how the former relates to the latter You can compare for instance sRGB RGB and US Web Coated SWOP CMYK, but not just RGB and CMYK Sorry for nitpicking - 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 Wed, Mar 25, 2009 at 11:06 PM, Martin Nordholts wrote: Both RGB and CMYK are device dependent color spaces and without any kind or further specification one can not say how the former relates to the latter That goes without saying :) 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 a écrit : On Wed, Mar 25, 2009 at 6:21 PM, Alexandre Prokoudine wrote: 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). I was reminded that I actually forgot 5. Part of an image should be b/w and the rest should be colorized with just one tint. E.g. Cyan + Black for sea. separate+ and exporting are of no help here. Working in CMYK at one point in the workflow is a question of control. You need to obtain a predictable result on press and you need to work with what you really have, often exactly, in terms of color combination. When printing in color on an offset press you have 3 possibilities. a) Spot colors (blended or preblended inks that could be just any color), b) 4-color process (CMYK inks) c) Hexachrome or 6-color process CMKYGO. So, pursuing with this interesting list of real-case scenario or why can’t we just rely on RGB throughout the creation process (while I agree some people can decide they work only with it): 6. In a layout, you have a picture from which you want to pick a specific color and apply it to another element in the page. You will want to have control over that color. For instance, if this color is to be applied on text, you will want to make sure you don’t end up with ink in the four channels because on press you might (you probably will) encounter registration issues with such tiny elements as the hairline portion of a font. You will need to limit this to a 3 color combinations. Now, how do you do this with a RGBCMYK converter? There has to be some human supervision in the process. So, it doesn’t matter really if you do the whole work in GIMP instead of if you split the job between Scribus and GIMP or Inkscape for instance: at some point you will need to have all color elements to speak the same language and this language will have to be the lower common denominator: CMYK. 7. You want side by side a dark background and a color image. Both can be created in GIMP but for the dark background you will really want to control the combination of inks that produces that specific color and again it’s going to be difficult to just let the converter do the job without you being in full knowledge of what’s going on behind the scene. I realise that my examples are not purely image manipulation (which is the core task of GIMP) but instead image usage and combination but really, this is mostly what graphic design is all about! 8. If a user is not concerned about precision, he/she might not need that much control over an image but if you work for an ad agency that needs to produce tons of images that include, for instance, skin tone — then you also need to have total control over the colors and this has to be done in CMYK which is the very end of the workflow. In the end we will have to turn the image into CMYK and it does really happen often that we have to adjust colors at this far point in the workflow. 9. While prepress and press shops can handle pretty easily RGB data, it’s going to be a best effort made by the RIP itself according to curves and algoritms the designer has no control over. And I know not many designers who will accept that. At some point, they will need both a good converter and means to adjust the resulting image. This is fine-tuning, I agree. 10. The packaging industry makes a great use of CMYK + Spot colors. To convince yourself, unfold any packaging and you will notice all the press marks on the inner flaps and the colors used. This means that both pixel and vector driven applications need to be able to work in CMYK + Spot if we want to address the packaging industry needs. There is quite a lot of design there to accomplish! I guess we could find other real life scenarios where CMYK control is important or even stronger, a necessity. I humbly wish this short intervention will help understand better the needs from the print point of view. Louis 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
On Wed, 25 Mar 2009, peter sikking wrote: Alexandre Prokoudine wrote: There was a somewhat heated discussion of this thread at linuxgraphics.ru forum and here are several examples from people who deal with prepress work on daily basis: 1. Client brings an image for poster in CMYK which needs color correction. Urgent work, not time to ask him to redo it. Double color space conversion is out of question. So he had to use Photoshop from VMWare. 2. You have a newspaper where first page should have a two-color photo: black (C=0%M=0%Y=0%K=100%) and blue (C=100%M=0%Y=0%K=0%). separate+ however separates black to 4 channels. 3. Some print houses set limit to overall sum of colors, for example 180%. So if you take Cyan 100% + Magenta 100% (already 200%) + a little of K and Y this will result in unnatural colors in a newspaper. 4. Live density control for each CMYK channel is a must (Scribus/SVN has that in preview dialog). To me it's somewhat strange that GIMP's product vision doesn't mention prepress needs explicitly. A vision is an expression of the project of what they want the software to be. There is choice in there, and the user community cannot demand that GIMP does certain things. For instance making web mockups (including the required html + css generation) is explicitly not supported. Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this. Scribus is vector-based, not raster based. I do not believe that Scribus has any intent to be allow raster-based editing, but I could be wrong. I have CC'd the Scribus list. Let us hear their opinions. Does Scribus intend to allow people to tackle the problems listed above? Or would you be able to trap the following image with Scribus? http://www.ets.ru/images/pk75.jpg The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk). As someone who works in prepress, I can tell you that when we take it from original artwork to press, we have to run any raster artwork through Photoshop or a competing product. -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | 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, Alexandre Prokoudine wrote: On Wed, Mar 25, 2009 at 7:27 PM, Andrew A. Gill wrote: Agreed. I don't think anyone here is looking for a Photoshop clone (I know that I personally hate PS for a variety of reasons), but we do realize that it has to compete with Photoshop, and not addressing the issues of large sections of the design market when your competitor does is probably not the best move. Do we realize that? :) It is true that GIMP is usually seen as to-be-photoshop-substitution and its maturity in various areas in fact is the reason why people switch to GIMP. However GIMP doesn't seem to be driven by a will to make Photoshop die, die, die :) http://www.businessdictionary.com/definition/competitor.html It's a product that has similar features. It's a competing product. (Personally, I want to make Photoshop die, die, die, but that's mainly because of a deep loathing for the UI.) -- | Andrew A. Gill To ensure continued quality of service, | |this e-mail is being monitored by the NSA | | 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
peter sikking wrote: Now what about that prepress. I think it is fairly safe to say that scribus' vision is to be prepress-king and GIMP should watch it not to want to overlap too much in that department. Everything in the above examples that reeks of newspaper, publications or multiple pages is a job for scribus. They want to do this. As I understand it, Scribus is not a pixel editor, it is a page layout package, rather a different thing altogether. So you're saying that Scribus should add a pixel editing package to their application, so that they can support CMYK and other non-RGB color spaces, duplicating an awful lot of what's in GIMP ? The vision does speak about creating original art and I am all for it to bring this original art to the printing press. And not via the print dialog (I am also mr. openPrinting) but those printing presses that have operators. From the description above you can see what is should be like: first you create the art, then you bring it to the press. Mix master tape (in rgb) and then cut the lp (in cmyk). I really don't think people working in the graphic arts are going to want to master two different pixel editing packages, simply because one of them doesn't support anything other than RGB. If they're in the Linux sphere, then I guess they need to go and look at using Krita instead. [ ie. handling CMYK and other colorspaces is a superset capability, with RGB being a subset, and the colorspace is orthogonal to the pixel manipulation capabilities ] Graeme Gill. ___ 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, 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 | -- ___ 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
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. This is a very common scenario, and it's a task for a image manipulation program. Gez. ___ 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, Guillermo Espertino wrote: 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. This is a very common scenario, and it's a task for a image manipulation program. Sadly for the cause of CMYK, that's not really a good example. That's a better example for the need for Pantone and other color matching system support. Which GIMP will eventually need, but I'm thinking that day will come a decade or two from now, hopefully when there's an open source rival for Pantone. (I actually plan to take that task on, myself in a few years, as part of some research) -- | 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
yahvuu wrote: Chris Mohler schrieb: I can express any CMYK color in RGB - but not the other way around. now i'm confused :) Is CMYK-RGB-CMYK roundtrip safe? It depends on the gamuts of the respective colorspaces. These are all device dependent colorspaces, so their gamuts depend on the device in question. A gamut can be described by a 3 Dimensional volume, and in general two gamuts will have some region in common, a region unique to one gamut, and a different region unique to the other gamut. This is often the case with RGB and CMYK spaces (ie. sRGB and a typical offset press). Whether CMYK-RGB-CMYK is roundtrip safe depends on whether the RGB space fully encompasses the CMYK space, or (if it does not), if the gamut mapping is being reversed through the transformations. Some people deliberately use a very large RGB gamut working space to avoid clipping CMYK colors. Note that by definition you loose the black inking information though such a conversion, as well as a degree of fidelity. A traditional graphic arts workflow often looks something like: Capture in RGB Edit/adjust in RGB and/or Lab Convert/Separate to CMYK Adjust in CMYK Layout/Compose/Add non-image elements in CMYK. Convert to RGB for soft preview. Print the CMYK. Although there are other more complicated ones, including late binding (separating for the particular output device after layout/composition). 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
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. 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. 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. We’re back to the basics of color reality. It’s either a projection of light or a reflexion of light. I mean, there are good books on the subject. This part is easy. At this point in the discussion, it would be great to hear if the quality of the information provided so far in terms of explanations and examples is enough to lead someone or a group of developers in the GIMP team to envision how this CMYK capability would be implemented into GIMP and into what kind of developing frame (time, resource, GSoC, etc.)? If we do need further examples, I am ready to provide more info, although I find the examples so far to be really on target. Cheers! Louis Gez. ___ 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, 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 | -- ___ 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, Louis Desjardins wrote: 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? On the contrary. Just trying to give people all the facts. I find it helps to avoid being accused of partisanship. -- | 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
Andrew A. Gill a écrit : On Wed, 25 Mar 2009, Louis Desjardins wrote: 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? On the contrary. Just trying to give people all the facts. I find it helps to avoid being accused of partisanship. :-) Ok! ___ 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/22 peter sikking pe...@mmiworks.net: Sven wrote: bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export? Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more in line with our product vision. when I wrote the previous message I already knew that this is the only counter-argument that I was going to accept. so now we really need some trend spotting from those in our community who deal with serious printing jobs. I often use GIMP as a part of my work flow - but almost never for preparing the final artwork for submission to the printing company - mainly due to the aforementioned lack of CMYK color space. Only ~1% of my PDF files submitted to printing companies are 100% raster. PDF seems (to me) to be gaining ground against formats like TIFF, but it's not a standard yet (for raster images anyway). On one hand, TIFF is still more widely accepted than PDF. On the other hand, PDF is well documented. On the gripping hand, neither format is useful for print jobs without the CMYK color space - which I know is somewhat arbitrary, but many printing companies expect files in CMYK. If I have a choice, I use TIFF or PNG for raster pre-press images - but it might be wise to look to the future: PDF format has options (like crop area and bleed) that are useful to printers and the format seems to be slowly catching up to the standards (at least in my experience over the past few years in the US). and when then moving forward with pdf, we should keep in mind what a GIMP document actually is: a single canvas/image (please do not mention the animation hacks we have...) You and I are in 100% agreement on this point ;) So to recap, I would welcome a printer-friendly PDF export if someone wants to work on it, though without CMYK support built-in it's not very useful just yet. From what I understand though, once GEGL integration is complete, any plugin could be refactored or rewritten to use higher bit depth and other color spaces. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
Hi, On Mon, 2009-03-23 at 14:31 -0500, Chris Mohler wrote: So to recap, I would welcome a printer-friendly PDF export if someone wants to work on it, though without CMYK support built-in it's not very useful just yet. From what I understand though, once GEGL integration is complete, any plugin could be refactored or rewritten to use higher bit depth and other color spaces. We don't plan to support editing images in CMYK. But what you need to get your images printed is a color separation based on the RGB and printer CMYK color profiles. This can very well be part of a PDF export plug-in. The separate+ plug-in shows how this can be done for TIFF files. Sven ___ 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
Sven Neumann wrote: We don't plan to support editing images in CMYK. Sven The product vision states that GIMP is a high-end photo manipulation application and that certainly includes support for editing images in the CMYK color space. We can't call ourselves high-end without that support. I, for one, have plans to implement support for CMYK editing, but that is quite far into the future. - 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
Hi, On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote: The product vision states that GIMP is a high-end photo manipulation application and that certainly includes support for editing images in the CMYK color space. It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos. Being able to do a color separation to CMYK is sometimes required in order to prepare an image for print (even though the printer can almost always do this much better). Editing an image in CMYK is not required though. Sven ___ 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
Sven Neumann wrote: On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote: The product vision states that GIMP is a high-end photo manipulation application and that certainly includes support for editing images in the CMYK color space. It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos. Photos are usually taken in the RGB color space, but usually printed in the CMYK color space. Support for editing in both these color spaces is to me clearly within the scope of a high-end photo manipulation application. Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space. - 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
Hi, On Mon, 2009-03-23 at 21:02 +0100, Martin Nordholts wrote: Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space. Why? Because you say so? All high-end photo editing applications are pushing for an RGB only work-flow these days. There is no need to do any editing in CMYK. If you really want to insist that being able to edit CMYK is needed and that developer resources should be spent on it, then you should at least give a compelling reason. Sven ___ 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 Mon, Mar 23, 2009 at 2:57 PM, Sven Neumann s...@gimp.org wrote: Hi, On Mon, 2009-03-23 at 20:43 +0100, Martin Nordholts wrote: The product vision states that GIMP is a high-end photo manipulation application and that certainly includes support for editing images in the CMYK color space. It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos. Being able to do a color separation to CMYK is sometimes required in order to prepare an image for print (even though the printer can almost always do this much better). Editing an image in CMYK is not required though. It is helpful to see an approximation of CMYK on the screen before you go to print - many colors available in the RGB color space fall outside of the CMYK gamut. RGB blue is likely the worst offender - fill an image with solid #FF and print it to a color printer and you will see quite a shift in color. Take a simple case: annotating a photo with some text (for print use) - working in CMYK space would prevent the user from using #FF as the text color (or actually convert it from #FF to its CMYK equiv on the fly) - giving a reasonably accurate representation of the final printed output on the screen. A more complicated case: removing small black text from the CMY channels manually (to improve legibility) - or more realistically only applying the small text to the K channel. Editing the channels in CMYK would be more comfortable than running through the separation process first and then making changes - and the ability to use CMYK swatches (in this case C=0, M=0, Y=0, K=100) could also speed things up dramatically. Of course this is not a trivial task, and I'm not holding my breath. Although it might not be hard to throw up a projection of the current image with a generic CMYK profile applied to it - that would be enough to satisfy the simple use-case above. Oh, and I guess we're rapidly drifting off-topic in re to PDF export ;) Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
FYI, my company writes most of its own output in PostScript for high end laser printers (e.g., Xerox I-GEN 3 and 4). We avoid CMYK. But we're not a pre-canned application company, we write everything ourselves. All of our printers work great with RGB colorspace. The need for CMYK is usually based on the software that goes with the printer or the shop's chosen software helper applications. I suspect that CMYK in the laser printer market is just something passed on from wet press. However, people often send CMYK art to us, and we need the ability to import CMYK into RGB. About PDF: PDF has some of its own drawing language, but when it comes to raster, it simply embeds bitmaps. That imbedded bitmap can be an almost exact copy of tiff, png, gif, whatever. PDF is a hybrid vector language with embedded bitmap. I'd love the ability to import or export with PDF pages translated to/from layers. And kudos to gimp for having the best quality PostScript. Gimp outputs valid PostScript, which I can't say the same for on most Adobe products. PDF used to be a proprietary thing, where Adobe made readers free, and writers pay, but they turned it into an open standard and anyone is free to do whatever they want these days. I'd trust gimp to do a better job at a PDF implementation than I would Adobe. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ 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, On Mon, 2009-03-23 at 15:27 -0500, Chris Mohler wrote: It is helpful to see an approximation of CMYK on the screen before you go to print - many colors available in the RGB color space fall outside of the CMYK gamut. RGB blue is likely the worst offender - fill an image with solid #FF and print it to a color printer and you will see quite a shift in color. GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors. Take a simple case: annotating a photo with some text (for print use) - working in CMYK space would prevent the user from using #FF as the text color (or actually convert it from #FF to its CMYK equiv on the fly) - giving a reasonably accurate representation of the final printed output on the screen. In order to do that, all you need is to be able to select an RGB color by specifying the CMYK values (and of course you should get exactly that CMYK color then as a result of the RGB-CMYK conversion). You can already do that. If you specify a CMYK profile, the CMYK color selector will make use of that. Sven ___ 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 Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote: GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors. Last time I did a softproof in GIMP I ended up with darker and less saturated prints. So I did a simple test --- captured screenshots of a window holding normal view of a photo and a softproof, then merged them into a multilayer image and changed softproof shot's layer mode to difference. Everything except just few pixels was black. I was probably doing something really stupid, but to me it sounded like softproof was broken. It was fairly recently and I didn't have time to write a proper report (and I didn't try that with other photos). If you are interested, I still could do that. 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 wrote: On Mon, Mar 23, 2009 at 11:49 PM, Sven Neumann wrote: GIMP already provides that. You can ask for a Soft Proof and it will show you an approximation of what will be printed based on the CMYK printer profile you specified. It can also show you out-of-gamut colors. Last time I did a softproof in GIMP I ended up with darker and less saturated prints. So I did a simple test --- captured screenshots of a window holding normal view of a photo and a softproof, then merged them into a multilayer image and changed softproof shot's layer mode to difference. Everything except just few pixels was black. I was probably doing something really stupid, but to me it sounded like softproof was broken. This doesn't say much about soft-proof being broken or not, it depends on many things such as the accuracy of the color profile, the image itself, and the rendering intent that was used. - 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
Sven wrote: Martin wrote: Yes, processing shall as long as possible be done in RGB, but at some point you need to convert to the CMYK color space and a high-end photo app should support editing also in this color space. Why? Because you say so? wow, the return of the cmyk wars. the photo part is not the issue, the vision also speaks of GIMP [...] supports creating original art from images I agree with the point that all of GIMP should be pure rgb based, with support for cymk import, export and cymk color selection. let me quote myself from 2 weeks ago about managing and checking and optimising export to lossy formats: my rough plan for supporting that looks like overlaying the image with a projection screen (lets not call it a layer) that simulates the lowering of fidelity. then this projection screen itself could contain several layers of optimisations and corrections that users may want to take. the high fidelity image data is still available for further development. bonus: that recent ars technica review had a really clarifying metaphor for cmyk for print workflows. along the lines of: the cmyk file is the LP pressing of the rgb master tape. seeing this cmyk conversion as a fidelity reducing (colour gamut) 1-way conversion, it looks like the projection screen plan above could be the beginning of a working cmyk support solution. --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] GIMP PDF export plugin
Sven Neumann wrote: It certainly doesn't. Photos are taken in an RGB color space. It makes sense to do some processing in other color spaces such as LAB. But CMYK is totally inadequate for manipulating photos. It really depends on what you are used to. To *you* RGB seems natural, while to someone who has been brought up in the printing world, CMYK seems natural, and it's RGB that is weird. (You know which is which when you ask them to evaluate a photograph. If they say things like it needs a couple of percent more magenta in the mid tones, and a little less yellow there, ..., they are from the print world, and think in CMYK. Many of these professionals are unbelievably good at being able to spot what needs to be done to an image in CMYK to correct it). When preparing photographs for printing, it is extremely common to want to edit them in CMYK space so as to be able to get the best looking result within the limitations of that colorspace, and to meet other technical requirements (total ink coverage, black separation, etc.). There is also the question of whether you define your goals narrowly as photographs, or more generally as images or raster files. If the latter, then there (ideally) shouldn't be any limitation on the number of channels or colorspaces supported by an editing program. 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
Hi, On Sat, 2009-03-21 at 21:36 +0200, LightningIsMyName wrote: I believe that we should have the option to export multi-paged PDFs, since we have the option to import them, and to me it makes sense that we should be able to export what we can import. The whole point of calling it Import is to make clear that you can't save this again. Gimp may not be a page-layout program, yet doing multi-paged PDFs isn't too hard, and won't hurt anyone... Of course it would hurt. It binds development resources for creating and maintaining it. If a feature does not fit with our product vision, then we are not going to include it. Doing multi-page PDF export simply because we can do it is not going to happen. What we need here is a user story. Without that, it doesn't make sense to discuss PDF export at all. And about what you said on page layout tools, there is some sense in what you said. Therfore, I think it would be indeed simpler to ignore paths untill gimp has vector layers, since these aren't the main point of the PDF plugin. The only feature I believe that is necessary, is to draw single-colored rectangles as drawing and not as bitmap-images (Imagine a background layer for a large scale image - a bitmap image can be a big waist of memory). I don't understand why that is needed. What is our goal here? To create PDF files as small as possible? IMO the goal for PDF export should be to improve support for professional printing. File size is not important for that. Paths are also not important for that. If people need vector art, then they should use a vector editor. What matters is color profiles, CMYK color separation in the export process, support for spot colors, crop marks, ... As I said already, we can't discuss the details unless we know what the goals are. So we need to have one or more user stories for PDF export first. And we need to check these against our product vision to see if they are worth supporting. Sven ___ 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 Sun, Mar 22, 2009 at 6:19 AM, Sven Neumann s...@gimp.org wrote: [...] I don't understand why that is needed. What is our goal here? To create PDF files as small as possible? IMO the goal for PDF export should be to improve support for professional printing. File size is not important for that. Paths are also not important for that. If people need vector art, then they should use a vector editor. What matters is color profiles, CMYK color separation in the export process, support for spot colors, crop marks, ... As I said already, we can't discuss the details unless we know what the goals are. So we need to have one or more user stories for PDF export first. And we need to check these against our product vision to see if they are worth supporting. I see two possible use cases: 1. Proofing artwork - you need to prepare a proof before going to press. You send that proof to a client and they print it out and get a reasonable hard proof. 2. Submission to a printing company - you need to submit hi-res artwork to a printing company. For either case to be useful, the PDF export needs to at least support: CMYK color mode, ICC profiles, spot colors, trim marks, crop area, and bleed area. Embedding or outlining (vector) fonts, registration marks, encryption, and downsampling of image/photo layers could possibly be useful. That being said, both use cases would only come about when setting up a full-color job (CMYK, etc.) - and it is very likely that the printing company would accept (and perhaps prefer) a hi-res raster format like TIFF, PNG, or JPEG. I submit PDFs all of the time for proofing and printing but 90% are pure vector, 9% are vector with embedded bitmap images, and only the remaining 1% are completely raster (I've used at least one printing company that accepts pdf *only*). IMHO: Attempting to redraw solid colors as vector would not be a good idea . File size is not really a concern - creating PDFs that print in a reliable manner and are as accurate as possible would be the main challenge. If GIMP comes to support vector layers at some point, then an option to rasterize those layers or keep them as vector should be presented at the time of PDF export. Multi-page is not something that GIMP should worry about at all - there are plenty of tools to join PDFs already, and multi-page documents are more the domain of page layout software. PDF export might be a nice feature, but as a designer I would not use it very often. If I did use it, I would expect it to be *extremely* reliable, and quite verbose about any errors before or during export. Chris ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP PDF export plugin
On Sun, 22 Mar 2009 09:47:00 -0500, Chris Mohler wrote: I see two possible use cases: 1. Proofing artwork - you need to prepare a proof before going to press. [...] 2. Submission to a printing company - you need to submit hi-res artwork to a printing company. [...] What would be the advantage of handling a .pdf generation at application level instead of at operating system level ? (i.e. via print command) Cristi ___ 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/22 Cristian Secară wrote: What would be the advantage of handling a .pdf generation at application level instead of at operating system level ? (i.e. via print command) Far more features supported. Install Scribus, go to File - Export - Save as PDF, then visit Fonts, Security, Color (make sure you choose Output intended for: Printer and enable Use custom rendering settings checkbox) and Pre-Press tabs. 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
Hi, On Sun, 2009-03-22 at 09:47 -0500, Chris Mohler wrote: I see two possible use cases: 1. Proofing artwork - you need to prepare a proof before going to press. You send that proof to a client and they print it out and get a reasonable hard proof. 2. Submission to a printing company - you need to submit hi-res artwork to a printing company. For either case to be useful, the PDF export needs to at least support: CMYK color mode, ICC profiles, spot colors, trim marks, crop area, and bleed area. Embedding or outlining (vector) fonts, registration marks, encryption, and downsampling of image/photo layers could possibly be useful. That being said, both use cases would only come about when setting up a full-color job (CMYK, etc.) - and it is very likely that the printing company would accept (and perhaps prefer) a hi-res raster format like TIFF, PNG, or JPEG. Thanks a lot for your input. That was very useful. So would you say that it makes more sense to spend time improving the TIFF save plug-in or would it be a better idea to invest that development into a powerful PDF export? My experience with TIFF is that it is an extremely difficult format as most of the important features are implemented as some sort of extension that is not part of the TIFF 6.0 specification. I would hope PDF to be better specified. Sven ___ 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
Sven wrote: So would you say that it makes more sense to spend time improving the TIFF save plug-in or would it be a better idea to invest that development into a powerful PDF export? My experience with TIFF is that it is an extremely difficult format as most of the important features are implemented as some sort of extension that is not part of the TIFF 6.0 specification. I would hope PDF to be better specified. bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export? --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] GIMP PDF export plugin
On Sun, 22 Mar 2009 21:23:24 +0300, Alexandre Prokoudine wrote: Far more features supported. Install Scribus, go to File - Export - Save as PDF, then visit Fonts, Security, Color [...] I assume it all depends on the application used for .pdf generation. Adobe Distiller ( Acrobat) has a comprehensive set of options. Not 100% sure, but perhaps Ghostscript based applications too, except that the user has to know the Ghostscript parameters (i.e. hard to use for more than basic .pdf generation, but possible). Cristi ___ 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, On Sun, 2009-03-22 at 19:33 +0100, peter sikking wrote: bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export? Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more in line with our product vision. Sven ___ 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
Sven wrote: bummer about the non-standard, but would industrial-strength TIFF in and export not be significantly more in line with our product vision than industrial-strength pdf in and export? Depends on what gets used nowadays. If professionals are turning away from TIFF and start to adopt PDF instead, then PDF support would be more in line with our product vision. when I wrote the previous message I already knew that this is the only counter-argument that I was going to accept. so now we really need some trend spotting from those in our community who deal with serious printing jobs. and when then moving forward with pdf, we should keep in mind what a GIMP document actually is: a single canvas/image (please do not mention the animation hacks we have...) --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] GIMP PDF export plugin
Just my two cents; TIFF is more important to GIMP because TIFF is widely used on printing and CG works. Its a common practice to use TIFF images in professional page layout programs like Scribus and Adode InDesign for example. And some 3d programs (like zbrush) use TIFF for export texture maps (in high bit dephs). A better TIFF support would be more in sync with GIMP, me thinks. PS: sorry for any English mistakes. =/ -- Filipe Soares Dilly dilly.carbonmade.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 Sun, Mar 22, 2009 at 11:13 PM, peter sikking wrote: so now we really need some trend spotting from those in our community who deal with serious printing jobs. It's difficult to talk about trends with regards to printing industry which tends to be quite conservative. If you tell Scribus guys My printer demands TIFF they will most likely reply Then you bloody well find another printer. Except there can be no other printer. Just two weeks ago I've heard from two different people: for the first guy there was no printer in his area to do color trapping on-site, so they asked him to do it himself, and no free DTP software supports it; for the second guy the printer demanded CDR (native Corel files) instead of PDF. Point of fact: a really good application should be implying the least dangerous workflow (which is definitely PDF based) while supporting all kinds of perversions. 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
I send files to print shops every week. Here in argentina even serious printers require proprietary file formats like AIs and CDR, though they're fine with tiffs and PDFs. I don't understand why there is so much interest in supporting PDF export from GIMP, since the exported data will be only bitmap, and in that case a tiff file is enough and is absolutely compatible with every design program out there. In my oppinion, PDF only makes sense if there is mixed data like bitmap images and vector shapes or text. For flattened bitmaps, I'd say TIFF is even safer than PDF. My current workflow consists in separate RGB images to a CMYK tiff using the Separate+ Plugin. Usually I do some black overprint tweaking using the faux channels that Separate+ creates. When I need a PDF, I use Scribus or this script:http://my.opera.com/area42/blog/cmyk-tiff-2-pdf-for-gimp I think PDF will only make sense when vector shapes, CMYK color and spot channels are in GIMP. Meanwhile, Separated Tiffs are enough and I think that putting time and efforts on a PDF exporter wouldn't make a real difference. I'd prefer to see the separate plugin integrated in gimp, direct save of the separated tiff through the save plugin, importing separated tiffs directly (opening CMYK tiffs currently results in an uncorrected image with distorted colors wich is pretty unusable). So -1 to this. There are oteher things far more important than this. Gez. ___ 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, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. Sven ___ 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
Sven Neumann wrote: Hi, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. Sven Indeed, what is the advantage of pdf export of a single image? Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image. PDF would just be a simple wrapper and this would best be done by and pdf editor that fully supports all the pdf features. It's unlikely gimp would want to maintain full functionality just to do this export. The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to. I could be wrong but that was my recollection. ___ 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
gg wrote: Sven Neumann wrote: Hi, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. Sven Indeed, what is the advantage of pdf export of a single image? Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image. PDF would just be a simple wrapper and this would best be done by and pdf editor that fully supports all the pdf features. It's unlikely gimp would want to maintain full functionality just to do this export. The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to. I could be wrong but that was my recollection. Maybe. But my OpenOffice has export as PDF options in Impress (PowerPoint-like), Calc (Excel-like) and Writer (Word-like). OpenOffice is free and available, as we all know, for Windoze, MAC, and *nix. When I want a multipage PDF of a bunch of images, I write them to jpg, paste them into a Writer document, then export them to PDF. I know it's clunky, but it works. -- Burnie ___ 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, On Sat, 2009-03-21 at 12:41 +0100, gg wrote: The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to. I am pretty sure that this is not the case. The GIMP Print plug-in creates PDF files easily and we don't pay Adobe any money for that. Sven ___ 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, On Sat, 2009-03-21 at 12:41 +0100, gg wrote: Indeed, what is the advantage of pdf export of a single image? If it is just a simple PDF, then nothing. But if it includes color profiles, support for spot colors, resolution-independent text layers, crop markers etc., then it would be a versatile format for getting your image printed processionally. But we definitely need someone who has some experience with using PDF for this purpose to tell us what exactly is needed. Sven ___ 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
Hello again, On Sat, Mar 21, 2009 at 11:15 AM, Sven Neumann s...@gimp.org wrote: Hi, On Fri, 2009-03-20 at 22:04 +0200, LightningIsMyName wrote: 1. How will the user create multi-paged PDFs? Should he choose different images, one for each page? (This sounds like the most reasonable way compared to other ways I thought of). Why would we want to allow the user to create multi-paged PDF files? Perhaps, before anything else, we need to clearly define what the purpose of PDF export is. We certainly don't want to provide a tool to create an illustrated book. That's what page layout applications are used for. I believe that we should have the option to export multi-paged PDFs, since we have the option to import them, and to me it makes sense that we should be able to export what we can import. Gimp may not be a page-layout program, yet doing multi-paged PDFs isn't too hard, and won't hurt anyone... And about what you said on page layout tools, there is some sense in what you said. Therfore, I think it would be indeed simpler to ignore paths untill gimp has vector layers, since these aren't the main point of the PDF plugin. The only feature I believe that is necessary, is to draw single-colored rectangles as drawing and not as bitmap-images (Imagine a background layer for a large scale image - a bitmap image can be a big waist of memory). However, this can be solved easily by finding all the layers in the image which have only 1 color (same RGBA values everywhere). I still need to figure out how to do this (probably using gimp_histogram in some way). -- LightningIsMyName ___ 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 3/21/09, gg wrote: Despite the current obsession with this format it is pretty clunky and inflexible. I don't see much point for a single image. Ahem, and what is your expertize to make such a bold statement? The other question is licensing of pdf. IRCC pdf viewing is allowed in a fairly liberal sense but creating pdf is what Abode make money on and retains the rights to. I nearly choked when I read this. The next statement of that kind would be GIMP doesn't support CMYK because of patents. I don't really know what makes you think there is any legal issue regarding creating PDF files, but rest assured that there is no such issue. 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
Hi, On Fri, 2009-03-20 at 19:15 +0200, Lightning LIMN wrote: I managed to export text while keeping the same appearance that it had in GIMP using PangoCairo. Exporting images with cairo was also possible if I saved the images first as PNGs and then used cairo PNG surfaces to draw them. Why so complex? You can have a look at the Print plug-in to see how to transfer the image projection to a Cairo surface without the need to save as PNG. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
