Re: [Gimp-developer] Annoying behavior of shared settings for file save plug-ins
Date: Fri, 31 Aug 2007 17:39:45 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet [EMAIL PROTECTED] If you want to save several images with the same settings, you can use the buttons Save defaults and Load defaults. We also have an enhancement request (bug #120829) about providing multiple presets that could be saved and re-loaded when necessary. I think that it is much better to require an explicit action if you want to re-use some settings from one image to the next, instead of always doing this automatically. Each image should have its own settings and should not be influenced by how you saved unrelated images in the same session. As in the example given by Jakub, it is annoying that the parameters used for saving a high-quality DSLR image are automatically re-used for saving a low-quality cameraphone image. This should definitely change for 2.6. But my question was about what kind of workaround can be implemented quickly for 2.4. It looks like it might be better to have all plug-ins broken in the same way instead of just fixing the most used ones, so that would be the second option that I described in my previous message: ignore the settings from the original JPEG images and always re-use the parameters from the last saved image. This is bad, but at least this is consistent with other file plug-ins (until they can all be fixed). It sounds like what's happening is something like this: 1) Current JPEG quality setting is 85 2) User selects Use quality settings from original image if original image is better 3) Original image has quality setting of 98 4) User saves image 5) Now the current JPEG quality setting is changed to 98 Is that correct? If so, then (5) seems wrong to me. The JPEG plugin should remember that the current JPEG quality setting is 85, and that the user has selected Use quality settings from original image. If the user then saves another image that has a quality setting of 60, it shouldn't be saved at 98, but at 85. My own preference is to err on the side of caution; I'd rather make a mistake of saving at too high of a quality (which loses less information) than too low. If I accidentally save a thumbnail at quality 98 or 100, all I've done is wasted a little disk space; if I save a good image at 85, I've lost a lot of data. Yes, I know that I shouldn't save a master copy of an image as a JPEG, and I don't intentionally. But I'm human and occasionally make mistakes... -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] New option Use custom quality settings for JPEG files
Date: Wed, 15 Aug 2007 10:25:54 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet [EMAIL PROTECTED] On Mon, 13 Aug 2007 13:36:05 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Mon, 13 Aug 2007 07:10:30 -0400, Robert L Krawitz [EMAIL PROTECTED] wrote: Would Use existing image quality settings be a better name for this? I considered naming this option Use original quality settings, but one thing that I forgot to mention in my previous messages is that it is possible to write a script or plug-in that attaches different quantization tables to any image. [...] Although I was a bit reluctant to do this, we could try to change the name of this option to Use original quality settings or Use quality settings from original image or something like that. This would require several changes in behavior explained below. This new meaning may not be appropriate if other quantization tables than the original ones are attached to the image, but if we consider that usage to be an exception, then maybe we can optimize for the common case if this could make the option more understandable. Anyway, if we want to change that string, then we have to reach a consensus on that in the next few hours and make sure that it will not change again until GIMP 2.4 is out. We should be in string freeze now. ... Implementing these changes would be easy (except for the last one, maybe) and I know exactly what would have to be be changed so the code itself is not an issue here. But we should quickly decide what this option should mean. I like the current meaning (custom tables) but some of you think that it would be easier to understand something referring to the original quality settings. If we can reach a quick agreement on what is better (considering the differences explained above) and if it is not too late for 2.4rc1, then maybe I could change that option. The problem is that custom tables seems very confusing -- it sounds like the user's going to be asked to input something she knows nothing about. One could argue that Use existing image quality settings means the same thing as Use quality settings currently attached to the image, and then nothing about the behavior would have to change. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] New option Use custom quality settings for JPEG files
Date: Mon, 13 Aug 2007 10:08:27 +0200 From: =?UTF-8?B?UmFwaGHDq2w=?= Quinet [EMAIL PROTECTED] On Mon, 13 Aug 2007 09:22:58 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Sun, 2007-08-12 at 23:44 +0200, Raphaël Quinet wrote: Since Friday, I added a new option to the JPEG save dialog: Use custom quality settings. If some quantization tables were attached to the image when it was loaded, then this option allows you to use them instead of the standard ones (different quantization tables are generated by the IJG JPEG library for each quality level). Why do we need an option in the GUI for this? If there are quantization tables attached and the user doesn't change the save quality, then just use them. Or is there a real disadvantage in doing that? To me it looks like you are asking the user a question that she is unlikely going to understand. And you are forcing the user to make a decision that you can better do for her. I think that this option is still useful. Maybe not for disabling it when it is enabled, but for enabling it when it is not enabled automatically. It is usually better to use the custom quantization tables if they are better than your default quality settings. But if they are not better, then it is nice to give a choice to the user. If the quantization tables found in the original file are not better than your default quality settings, then the option Use custom quality settings will be available but not enabled. This ensures that you always get at least the minimum quality specified in your defaults. If you did not make major changes to the image and you want to save it using the same quality as the original, then you can do it by enabling this option. Would Use existing image quality settings be a better name for this? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Date: Sun, 08 Jul 2007 11:44:17 +0200 From: [EMAIL PROTECTED] On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino [EMAIL PROTECTED] wrote: In Gimp, it saves the file directly, without asking for the compression setting. Result: an image over-compressed with artifacts. Smaller size than the original. In Photoshop, it shows the quality settings the first time you hit CTRL+S. I think we're finally getting closer to the truth. There is something non standard in the file the camera is producing. It seems that PS knows there's a problem and thus prompts for the quality parameter, gimp it would seem is either reading this value as the IJG quality when it isn't or is applying a not too good default when it fails to read it. If it's an incorrect value put in by the camera that gimp is correctly reading it's not a gimp issue. If it is a missing value gimp should probably use it's jpeg default of 85 (or prompt as you suggest) which it does not seem to be doing. If you have imagemagick installed, use the following to see what information is in one of your camera images before you affect it with either gimp or ps and then again after gimp (and/or PS) does a save on it: identify -verbose unadulterated_image.jpeg That should give some info on what is in the jpeg header. This appears to be the case. The original image gives me this: $ identify -verbose /images/dcim/193canon/img_9309.jpg Image: /images/dcim/193canon/img_9309.jpg ... Filesize: 2.96358mb ... Compression: JPEG Quality: 98 Orientation: LeftBottom JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x1,1x1,1x1 However, when I save it out, it's clearly not using the original quality setting: $ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg ... Filesize: 901.654kb ... Compression: JPEG Quality: 85 Orientation: TopLeft JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x2,1x1,1x1 If I explicitly save it out using the same settings as what came from the file, I wind up with a slightly shrunk file: $ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg ... Filesize: 2.65972mb ... Compression: JPEG Quality: 98 Orientation: TopLeft JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x1,1x1,1x1 Note that GIMP is not the only application that does this; KPhotoAlbum also changes the quality setting (to 75!). In this case, I suspect that it simply doesn't tell the appropriate library what the actual quality setting is from the original file. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] jpeg quality factor.
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 08 Jul 2007 15:12:03 +0200 On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Think of the quality setting as an indication of expectations rather than a specific outcome. It may not be possible to get the exact same outcome (and obviously -- at least to us -- there's no way to retroactively improve the result), but the quality setting could be treated as the user's expectation for the result. It's certainly true that a couple of iterations of saving at a quality setting of 85 (say) will yield a substantial degradation, and a couple of iterations at 65 will yield even more degradation, but a couple of iterations at a setting of 98 won't yield very much degradation at all. By this reasoning, if a user opens a file with a quality setting of 98, her expectation when saving the file is that the quality will still be very high, while if the quality setting of the incoming file is only 85, her expectations will be lower. A single default setting won't cover all cases. If the choice really is that arbitrary (and you make a good argument to that effect), why not simply use the quality setting of the incoming file as the implied default? I think it would at least align better with user expectations, particularly for files shot at high quality settings on digital cameras. BTW, on the Canon S3, the Superfine, Fine, and Normal settings correspond to 96, 90, and 68 respectively. So anyone who shoots in one of those two settings and then decides to do a quick edit will get a rude surprise. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] jpeg quality factor.
Date: Mon, 9 Jul 2007 00:26:21 +0930 From: David Gowers [EMAIL PROTECTED] On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make The image may well be quite unlike the input due to lossy compression -- see below. The question to my mind is what's going to be closest to the user's expectations in terms of quality and size, not what's going to be pixel for pixel identical. When saving (or, I'd argue, exporting) an image from a lossless format (png, or even more so xcf) to a lossy format, we can really only guess, and in that case having a settable default is good. However, when we're working with JPEG files, we have a bit more information about what the user likely wants, based on the quality setting and perhaps the file size. the existing choice of jpeg_quality irrelevant. It represents the users choice of size/quality trade-off. I see no justification to discard that choice as irrelevant. AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG. Sure, but if the image was originally saved at quality 98, and then you resave it at 75, you're going to wind up with a lot more artifacts, which would be a surprising result if you don't understand how JPEG works. If the original image was saved at 60, and you resave it at 98, you might wind up with a much bigger image (I'm less certain of that), which is also not what I think would be expected. The issue at hand is a special, but IMHO important, case -- a very high quality JPEG gets minor edits (perhaps to remove redeye or the like) and resaved; the result is *markedly* lower quality because the default of 85 is much less than the original. Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation. As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BD thing; basically the only two possibilities are a) Image mutilation b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME) -- this often inflates the filesize beyond that of lossless image formats like PNG.) What about the case where the original quality was 96 or 98, and it's resaved at the same quality level? My quick test showed a slight decrease in file size, but probably very little in the way of image degradation. About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file. That would be a good idea, but I believe that there are at least some common cases where it's possible to do a bit better. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] jpeg quality factor.
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 08 Jul 2007 23:48:28 +0200 On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote: What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? Because you are using JPEG despite better knowledge that it will do exactly that. Sorry for the harsh tone, but I am only replying the way you are putting it. Sven, I do think you're being unreasonably hard on Guillermo. Never mind that using JPEG per se won't do exactly that -- what's really degrading the quality so badly is GIMP's choice of a quality factor compared to that of the original JPEG. Not to mention that I think Guillermo is being quite reasonable. A lot of people (particularly folks who just casually want to lighten a shot or remove redeye) don't know it. All they know is that they have a picture that their camera took, they've corrected it, and all of a sudden the image quality fell apart. They don't know anything about JPEG's, or compression (lossy or otherwise), all they know is that GIMP ruined their photo. That's not going to be very helpful to anyone. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful. Well, as was noted ImageMagick is able to access this information, so it's apparently there. Maybe this isn't going to be an easy problem to solve, and that's OK, but I think that this is a real problem, not simply a user error (and even if it is a user error, wouldn't it be best to help users not make this kind of error?). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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-Developer] One-click binary downloads via the gimp website
Date: Thu, 29 Mar 2007 09:09:05 +0200 From: Martin Nordholts [EMAIL PROTECTED] I don't see why providing links to recomended binaries on the front page would put any more responsibility on us. We already direct users to recomendeded binaries, and as long as we continue to be clear that we don't build those binaries ourselves, why should we not make it easier to reach those? Because whatever disclaimers etc. you use, users will see the binaries as coming from the GIMP project, and will blame you if there are any download problems or corrupted (or trojaned!) binaries. The content of a website should be organized in such a way that the most usable information should be the most reachable, and I am pretty confident that most visitors on gimp.org looks for binaries, hence we should have binaries on the front page. I don't see why we would have to also host the Win32 FAQ etc because of this. Just link to those external pages. Sure, coherency is important but let's not take it to the extreme, let's focus on providing a pragmatic gimp.org. Martin Nordholts les, just link to themourselves Sven Neumann skrev: Hi, On Thu, 2007-03-29 at 00:29 +0100, David Marrs wrote: Sven indicated that this idea has already been considered and rejected by the team and that I should bring it up for discussion here before proceeding any further. We haven't really discussed and rejected this particular idea. The point here is just that the current rule is that the GIMP team only provides the source code. The creation, distribution and maintainance of binary packages has been left to other parties. The current website tries to explain this point and only gives recommendations for binary packages. In my opinion we should stick to this rule. It would make a lot of sense to make it easier for the user to locate our recommendations for binary packages. If user agent detection helps to remove one or two clicks, then I am fine with that. But if there's a download button on the front-page that directly instantiates the download, then we are effectively providing binary packages. It doesn't matter if the packages are hosted elsewhere. To the user it will appear as if we would provide the binaries. If we decided that we want to do this, then we should probably really provide the binaries and we would have to move things like the Win32 user FAQ (http://gimp-win.sourceforge.net/faq.html) and the gimp-app bug-tracker (http://sourceforge.net/projects/gimp-app) to gimp.org and to our bug-tracker. I don't think we are prepared to do that. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Denoising Plugin
Date: Thu, 29 Mar 2007 13:50:02 -0700 From: William Skaggs [EMAIL PROTECTED] Jim Sabatke wrote: I've just compiled a plugin based on a denoising program that attracted slashdot's attention a short while ago. [...] Jim, there is already a GREYCstoration gimp plugin, which you can find out about by googling greycstoration gimp plugin. Is yours better? In any case, the main gimp distribution doesn't currently include anything written in C++. Greycstoration is extremely slow. If there's a faster one that does a good job (and at least with the settings I tried, greycstoration didn't do that great of a job), I'd be very interested in seeing it. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Denoising Plugin
Date: Thu, 29 Mar 2007 16:10:03 -0500 From: Jim Sabatke [EMAIL PROTECTED] Robert L Krawitz wrote: Date: Thu, 29 Mar 2007 13:50:02 -0700 From: William Skaggs [EMAIL PROTECTED] Jim Sabatke wrote: I've just compiled a plugin based on a denoising program that attracted slashdot's attention a short while ago. [...] Jim, there is already a GREYCstoration gimp plugin, which you can find out about by googling greycstoration gimp plugin. Is yours better? In any case, the main gimp distribution doesn't currently include anything written in C++. Greycstoration is extremely slow. If there's a faster one that does a good job (and at least with the settings I tried, greycstoration didn't do that great of a job), I'd be very interested in seeing it. The new version is MUCH faster and does a much better job than the old plugin. The Greycstoration's original author and the gimp plugin's original author never did see eye to eye on the plugin. You can try out the new plugin, source at: http://sound.eti.pg.gda.pl/~greg/gimp/ It's basically a windows version, but if you put CC=g++ and LDFLAGS=-lpthread in the ENV, then gimptool does it's job on my version of linux just fine (SuSE 10.0). It shows up under Filters-Enhance At least at first glance, it does appear to be markedly better. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] changes in script-fu in 2.3.14
Date: Tue, 20 Feb 2007 10:35:59 +0100 From: [EMAIL PROTECTED] On Fri, 16 Feb 2007 13:01:16 +0100, Robert L Krawitz [EMAIL PROTECTED] wrote: Date: Fri, 16 Feb 2007 09:33:40 +0100 From: [EMAIL PROTECTED] There is also problems with the way changes broke the interface with gimp=print, amongst other things. Gimp 2.3 is still seriously unfinished as far as the print dlg goes yet it seems I still cannot use gutenprint with 2.2. What problem are you having using Gutenprint with GIMP 2.2? It should work fine, and I'd like to help you fix it. I only just noticed this comment at the top of your reply. The problem is that my distro , Gentoo, has a dependancy block on gimp-print4.2.7 with gimp-2.2 Now from what you say this may be an error or a misunderstanding of old issues. I recall quite some time ago I put in a bug report at bugs.gentoo.org and got this was an upstream issue and the block would remain until that was resolved. This problem's a bit more complicated. GIMP 2.2 does have a dependency on Gimp-Print 4.2; the Print plugin in GIMP 2.2 requires the Gimp-Print 4.2 library, and Gutenprint 5.0 has an incompatible API. However, we've already thought of that; it's possible to have both Gimp-Print 4.2 and Gutenprint 5.0 installed concurrently. Is the conclusion from this that the src tarball for gimp 2.2.x needs these checks to be changed because gimp-print-5.x does now work with it? Well, the actual story is that Gutenprint 5.0 includes its own Print plugin for the GIMP that replaces the one in GIMP 2.2. The best thing to do is to configure the GIMP with configure --disable-print (or --without-print, I don't remember which) and then to install Gutenprint on top of it. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] changes in script-fu in 2.3.14
Date: Fri, 16 Feb 2007 09:33:40 +0100 From: [EMAIL PROTECTED] There is also problems with the way changes broke the interface with gimp=print, amongst other things. Gimp 2.3 is still seriously unfinished as far as the print dlg goes yet it seems I still cannot use gutenprint with 2.2. What problem are you having using Gutenprint with GIMP 2.2? It should work fine, and I'd like to help you fix it. Net result I can't use my printer with gimp. As I understood that rather contentious exchanges between Sven and the gp lead dev this was because there were incompatible changes in the API. That's not the issue. The GIMP folks are quite innocent here. The primary problem was that on the Gutenprint side (I'm the project lead for Gutenprint) we were taking excessively long to release our stable version (5.0). I was hoping that we could hand over maintenance of the Gutenprint-based plugin to the GIMP team, but since our release was long-delayed we weren't able to make the releases line up. The Gutenprint delay was, in my opinion, for the better -- we resolved some important API issues late in the release cycle -- but it prevented us from handing off the plugin in time for 2.2. There were also issues with the Gutenprint-based plugin's user interface -- it's admittedly no work of art. Sven and I did have a disagreement over exactly which versions of the GIMP and GTK to target compatibility at -- Sven urged us to drop support for GIMP versions earlier than 2.2 to take advantage of newer features, while I wanted to maintain compatibility back to 2.0. But that was a subsidiary issue. Obviously, had we been able to hand over the plugin to the GIMP team this would have been a non-issue. There are quite obvious issues with running everything in the same name space. Surely the best way to address this issue would be to run a separate instance of the interpreter rather than put new conditions on the scripts that breaks a number of the ones in the registry and very likely at lot that are not. This would seem to be a work around for a flaw in the way gimp handles this. I'm a firm believer in maintaining back compatibility myself, but in this case I think the tiny-fu approach is much better than trying to maintain bug-for-bug compatibility. Any act of separating the namespaces is sure to cause some breakage because some script or other is going to implicitly rely on previous state, resulting in very tricky problems to debug. Better to take this hit once -- and most of the hit is on poorly-written scripts that will inevitably be hard to maintain -- than to be dealing with a broken architecture forever. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] Meaning of delay in screenshot plugin
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 31 Jan 2007 08:38:21 +0100 On Tue, 2007-01-30 at 22:03 +0100, [EMAIL PROTECTED] wrote: I'm not sure if you're assuming everyone is using gnome here. I work on xfce4 and I dont have a screenshot applet or whatever. I have scrot if I dont use gimp. Most window manager screenshots seems just to grab the whole screen. The nice thing about the gimp one was that it's more specific and precise. Of course I am not assuming that. But I don't know all the other desktop environments out there and I expected that they more or less all have a reasonably well working way of taking screenshots. After all this is where the functionality belongs. Perhaps the xfce project should think about adding such a tool. Or simply integrate an existing tool. All that needs to be done is to set up some global keyboard shortcuts. But that's better discussed on the xfce lists, I guess... A lot of people don't run an all-out desktop environment; they run a simple window manager (fvwm, ctwm) precisely because they don't want a heavyweight environment weighted down with gadgets. xfce4 is popular because it is much lighter weight than KDE or GNOME. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] Meaning of delay in screenshot plugin
From: Sven Neumann [EMAIL PROTECTED] Date: Tue, 30 Jan 2007 09:35:17 +0100 On Tue, 2007-01-30 at 02:26 -0600, Clarence Risher wrote: On 1/30/07, Sven Neumann [EMAIL PROTECTED] wrote: to propose a user interface that fits all needs. imho, the 2.2 interface met all needs. i have yet to hear any reason for eliminating either option, other than removing ONE element from the screenshot GUI. We have had several reports about this UI being confusing. Users filed bug reports claiming that the plug-in wouldn't do the right thing. Obviously they did not understand the user interface. And that is not surprising because it is quite irritating. Just try the user interface on your grandmother. Now someone please show some creativity. Asking for the changes to be reverted is a punch in the face of the people that have put their free time into improving the usability of this plug-in. If those people choose to take it that way. Another way to interpret it is that the experiment was tried, but failed. IMHO the criterion that all functionality should be easy and obvious for a naive user is misplaced, particularly when it's taken to the extreme of we shouldn't have any functionality that isn't easy and obvious for a naive user. There are a lot of interesting things that aren't easy or obvious to people who don't have the context, and sometimes that context is by its nature quite extensive. To say that we shouldn't do these things because innocent users might stumble across them and get confused is to permanently doom ourselves to having very limited functionality. I'm well aware that I tend toward the opposite extreme, but even with Gutenprint I have people asking for more tunables because they have no other way of doing what they want (these are OS X users -- largely professional photographers, I think -- who want very fine grained control over the ink generation). I understand that no project has time to implement every single feature demanded by every single user, and that feature bloat carries maintenance costs. That argument doesn't apply to this situation -- this isn't a newly-added feature; it was a conscious decision to remove something (in a plugin, not in the core application) that was already there and working. If the interface is confusing, then maybe it's a reason to improve it; maybe something as simple as improving the help message would serve the purpose. The two options really serve two entirely different purposes; it may inherently be impossible to combine them into one that works for everyone. For my part, I've been awfully tempted to port the GTK 1.2 file load and save dialogs forward to GTK 2.x. I suspect that my limited time is better spent on Gutenprint and perhaps KPhotoAlbum, but those dialogs are simply very painful to use. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] Meaning of delay in screenshot plugin
Date: Tue, 30 Jan 2007 15:13:45 +0300 From: Alexandre Prokoudine [EMAIL PROTECTED] On 1/30/07, Robert L Krawitz wrote: For my part, I've been awfully tempted to port the GTK 1.2 file load and save dialogs forward to GTK 2.x. I suspect that my limited time is better spent on Gutenprint and perhaps KPhotoAlbum, but those dialogs are simply very painful to use. http://prokoudine.info/shots/gimp/gtk-autocomplete.png With gtk 2.10.x I see no point either porting gtk 1.2 dialog or even discussing it :)) Could you at least put file modification time (not just date) and size in the information? Then there's also the problem of the save dialog not showing what directory it's saving into (the folder name isn't very helpful if I have multiple directories with the same name). The path bar on the open dialog is quite useful and would be just as useful on the save dialog. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] changes in script-fu in 2.3.14
Date: Tue, 30 Jan 2007 17:24:59 +0200 From: Alexander Rabtchevich [EMAIL PROTECTED] Raphaël, this IS exactly my point! Why should the global variables be prohibited if there is no difference in memory consumption with local ones, only additional efforts to a programmer to track all parenthesis. The common namespace is the other problem - it is due the luck of interpreter usage or implementation, not the language itself. Also, does it make sense to worry about leaving a variable and its context in memory for a little while when this variable only takes a few bytes and the data that you are manipulating is several orders of magnitude larger? Keeping an integer and its context on the stack means almost nothing in comparison with the megabytes of image data that the script is processing. Raphael is quite correct. Global variables are serious bad juju in this situation. The basic problem here is that script-fu runs all scripts in the same environment. It isn't invoked separately for each plugin. This means that any plugin that uses a global variable without setting it first (basically, an unitialized variable) is at the mercy of any other plugin that may have set that variable. That means that if the programmer isn't careful the results obtained will depend upon what happened to be run previously -- in other words, plugins may give different results depending upon what happened before. If you're going to initialize all global variables each time you run a script (which is the only safe thing to do, for the above reason), you might as well just not use them, since they're effectively going to be local, anyway. The first time you have to track down a bug caused by cross-script global variable pollution will cost you more time than *all* of the time you spend tracking parentheses on every script you write in your lifetime, practically guaranteed. I remember one bug that took me something like 12 hours to find, in 6.001 (the intro programming class at MIT -- taught in Scheme, at least when I was there). It was due to a variable in the project code that was named exp that I was somehow picking up (I've long since forgoten the details -- I fired off an angry and frustrated email to Sussman and Abelson, and received a prompt apology). A few of those will change one's outlook in a hurry. I won't go so far as to say that global variables should *never* be used -- just like all good rules, there are exceptions. A shared environment that's running many programs without any namespace separation is one place where there really should *never* be global variables that the individual programs can use read/write (as opposed to global read-only variables exported by the environment, which are safe). Statically scoped variables would be safe enough; I don't recall that Scheme supports them (as I recall, everything in Scheme is supposed to be lexically scoped). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] HSL patch
From: Sven Neumann [EMAIL PROTECTED] Date: Fri, 12 Jan 2007 21:33:01 +0100 On Thu, 2007-01-11 at 21:10 -0500, Robert L Krawitz wrote: Uh, maybe that I didn't look closely enough :-? Here's an updated patch. Thanks. I think it's about time that you open a bug report for this new feature and attach your patch to it. That's still the preferred way of submitting patches. Done (bug 395928). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] HSL patch
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 11 Jan 2007 08:22:20 +0100 On Wed, 2007-01-10 at 06:53 -0500, Robert L Krawitz wrote: From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 10 Jan 2007 08:53:02 +0100 can you explain to me why your patch introduces new functions in libgimpcolor? Couldn't you just use the existing gimp_rgb_to_hsl() and gimp_hsl_to_rgb()? I did it the way I did to use the same implementation as the existing compose_hsv() function. In addition, it isn't clear to me why there should be gimp_rgb_to_hsv4 but not gimp_rgb_to_hsl4. gimp_rgb_to_hsv4() is there for historical reasons. If we could, we would probably remove it from the API. I don't think we want to introduce a HSL variant of it now. I'll try to get to it tonight, although I think it would be useful to have the floating point version also -- if someone's writing a plugin that's doing multiple transformations, it keeps more precision to do the math in floating point vs. with chars. In this case, I suggest that the other floating point variants should be marked deprecated. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] HSL patch
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 10 Jan 2007 08:53:02 +0100 can you explain to me why your patch introduces new functions in libgimpcolor? Couldn't you just use the existing gimp_rgb_to_hsl() and gimp_hsl_to_rgb()? I did it the way I did to use the same implementation as the existing compose_hsv() function. In addition, it isn't clear to me why there should be gimp_rgb_to_hsv4 but not gimp_rgb_to_hsl4. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] HSL patch
Unfortunately, there's a little bug in the HSL compose patch, in
gimp_hsl_to_rgb4 in the case of zero saturation. This fixes that.
I'd like to have an option to use luminosity rather than value in
curves and layers; I'm not sure how to do it without introducing
additional complexity.
--- ./libgimpcolor/gimpcolorspace.c~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.c 2007-01-06 14:57:28.0 -0500
@@ -1003,6 +1003,90 @@
}
/**
+ * gimp_rgb_to_hsl4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Pointer to hue channel (0..1)
+ * @saturation: Pointer to saturation channel (0..1)
+ * @luma: Pointer to luma channel (0..1)
+ *
+ * Convert an RGB color value to an HSL (Hue, Saturation, Lightness)
+ * color value.
+ *
+ * Since: GIMP 2.4
+ **/
+void
+gimp_rgb_to_hsl4 (const guchar *rgb,
+ gdouble *hue,
+ gdouble *saturation,
+ gdouble *luma)
+{
+ gdouble red, green, blue;
+ gdouble h, s, l;
+ gdouble min, max;
+ gdouble delta;
+
+ red = rgb[0] / 255.0;
+ green = rgb[1] / 255.0;
+ blue = rgb[2] / 255.0;
+
+ h = 0.0; /* Shut up -Wall */
+
+ if (red green)
+{
+ max = MAX (red, blue);
+ min = MIN (green, blue);
+}
+ else
+{
+ max = MAX (green, blue);
+ min = MIN (red, blue);
+}
+
+ l = (max + min) / 2.0;
+
+ if (max == min)
+{
+ s = 0.0;
+ h = GIMP_HSL_UNDEFINED;
+}
+ else
+{
+ if (l = 0.5)
+s = (max - min) / (max + min);
+ else
+s = (max - min) / (2.0 - max - min);
+
+ delta = max - min;
+
+ if (delta == 0.0)
+delta = 1.0;
+
+ if (red == max)
+{
+ h = (green - blue) / delta;
+}
+ else if (green == max)
+{
+ h = 2.0 + (blue - red) / delta;
+}
+ else if (blue == max)
+{
+ h = 4.0 + (red - green) / delta;
+}
+
+ h /= 6.0;
+
+ if (h 0.0)
+h += 1.0;
+}
+
+ *hue= h;
+ *saturation = s;
+ *luma = l;
+}
+
+/**
* gimp_hsv_to_rgb4:
* @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
* rgb[2] is blue (0..255)
@@ -1083,3 +1167,45 @@
rgb[1] = ROUND (saturation * 255.0);
rgb[2] = ROUND (value * 255.0);
}
+
+/**
+ * gimp_hsl_to_rgb4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Hue channel (0..1)
+ * @saturation: Saturation channel (0..1)
+ * @luma: Luma channel (0..1)
+ *
+ * Convert an HSL color value (Hue, Saturation, Lightness) to an RGB
+ * color value.
+ *
+ * Since: GIMP 2.4
+ **/
+void
+gimp_hsl_to_rgb4 (guchar *rgb,
+ gdouble hue,
+ gdouble saturation,
+ gdouble luma)
+{
+ if (saturation == 0.0)
+{
+ rgb[0] = ROUND(luma * 255.0);
+ rgb[1] = ROUND(luma * 255.0);
+ rgb[2] = ROUND(luma * 255.0);
+}
+ else
+{
+ gdouble m1, m2;
+
+ if (luma = 0.5)
+m2 = luma * (1.0 + saturation);
+ else
+m2 = luma + saturation - luma * saturation;
+
+ m1 = 2.0 * luma - m2;
+
+ rgb[0] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 + 2.0) * 255.0);
+ rgb[1] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0) * 255.0);
+ rgb[2] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 - 2.0) * 255.0);
+}
+}
--- ./libgimpcolor/gimpcolorspace.h~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.h 2007-01-06 13:07:47.0 -0500
@@ -94,6 +94,14 @@
gdouble hue,
gdouble saturation,
gdouble value);
+voidgimp_rgb_to_hsl4(const guchar *rgb,
+ gdouble *hue,
+ gdouble *saturation,
+ gdouble *luma);
+voidgimp_hsl_to_rgb4(guchar *rgb,
+ gdouble hue,
+ gdouble saturation,
+ gdouble luma);
G_END_DECLS
--- ./libgimpcolor/gimpcolor.def~ 2006-09-01 07:14:32.0 -0400
+++ ./libgimpcolor/gimpcolor.def2007-01-06 14:42:27.0 -0500
@@ -18,6 +18,7 @@
gimp_cmyka_set_uchar
gimp_hsl_get_type
gimp_hsl_to_rgb
+ gimp_hsl_to_rgb4
gimp_hsl_to_rgb_int
gimp_hsv_clamp
gimp_hsv_get_type
@@ -55,6 +56,7 @@
gimp_rgb_to_cmyk
gimp_rgb_to_cmyk_int
gimp_rgb_to_hsl
+ gimp_rgb_to_hsl4
gimp_rgb_to_hsl_int
gimp_rgb_to_hsv
gimp_rgb_to_hsv4
--- ./plug-ins/common/decompose.c~ 2006-06-27 06:33:49.0 -0400
+++ ./plug-ins/common/decompose.c 2007-01-06
[Gimp-developer] PATCH: Add HSL to compose/decompose plugins
The attached patch (against 2.3.13) adds support for the HSL color
space to compose/decompose. In my experience, HSL is often a better
color space for manipulation than HSV; it better reflects our
perception than HSV. An example is a photo I'm currently working on
of a red leaf backlit against a blue sky; I'm trying to balance the
leaf against the sky. The leaf is perceptually considerably darker
than the sky (which is reflected well in luminosity), but the values
of the leaf and the sky are very similar, making it hard to correct
via curves. As a result, this is not difficult to correct in HSL
space, but is very difficult to enhance in HSV.
Note that the definition of saturation is a bit different in HSL
vs. HSV.
In Gutenprint we use another color space for corrections, HLK
(hue/luminosity/black). K is defined in the usual way of min(C,M,Y)
(white would be defined as min(R,G,B)). The H and L components are
then computed from the residual; S is implicitly 1 since min is zero
(and L is never greater than 0.5, for the same reason, so a reasonable
HLK space would double the L value). This is more useful for CMYK
printing than it likely is for RGB image manipulation; it allows us to
correct the properties of the color inks without affecting the black
generation, as would otherwise happen if we were to use HSL space (and
it also simplifies the color correction since we don't have to worry
about saturation). This was one of the major advances in color
correction we made in 5.0. I'd be happy to code it up if people are
interested.
--- ./libgimpcolor/gimpcolorspace.c~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.c 2007-01-06 13:07:51.0 -0500
@@ -1003,6 +1003,85 @@
}
/**
+ * gimp_rgb_to_hsl4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Pointer to hue channel (0..1)
+ * @saturation: Pointer to saturation channel (0..1)
+ * @luma: Pointer to luma channel (0..1)
+ **/
+void
+gimp_rgb_to_hsl4 (const guchar *rgb,
+ gdouble *hue,
+ gdouble *saturation,
+ gdouble *luma)
+{
+ gdouble red, green, blue;
+ gdouble h, s, l;
+ gdouble min, max;
+ gdouble delta;
+
+ red = rgb[0] / 255.0;
+ green = rgb[1] / 255.0;
+ blue = rgb[2] / 255.0;
+
+ h = 0.0; /* Shut up -Wall */
+
+ if (red green)
+{
+ max = MAX (red, blue);
+ min = MIN (green, blue);
+}
+ else
+{
+ max = MAX (green, blue);
+ min = MIN (red, blue);
+}
+
+ l = (max + min) / 2.0;
+
+ if (max == min)
+{
+ s = 0.0;
+ h = GIMP_HSL_UNDEFINED;
+}
+ else
+{
+ if (l = 0.5)
+s = (max - min) / (max + min);
+ else
+s = (max - min) / (2.0 - max - min);
+
+ delta = max - min;
+
+ if (delta == 0.0)
+delta = 1.0;
+
+ if (red == max)
+{
+ h = (green - blue) / delta;
+}
+ else if (green == max)
+{
+ h = 2.0 + (blue - red) / delta;
+}
+ else if (blue == max)
+{
+ h = 4.0 + (red - green) / delta;
+}
+
+ h /= 6.0;
+
+ if (h 0.0)
+h += 1.0;
+}
+
+ *hue= h;
+ *saturation = s;
+ *luma = l;
+}
+
+/**
* gimp_hsv_to_rgb4:
* @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
* rgb[2] is blue (0..255)
@@ -1083,3 +1162,40 @@
rgb[1] = ROUND (saturation * 255.0);
rgb[2] = ROUND (value * 255.0);
}
+
+/**
+ * gimp_hsl_to_rgb4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Hue channel (0..1)
+ * @saturation: Saturation channel (0..1)
+ * @luma: Luma channel (0..1)
+ **/
+void
+gimp_hsl_to_rgb4 (guchar *rgb,
+ gdouble hue,
+ gdouble saturation,
+ gdouble luma)
+{
+ if (saturation == 0.0)
+{
+ hue= luma;
+ saturation = luma;
+ luma = luma;
+}
+ else
+{
+ gdouble m1, m2;
+
+ if (luma = 0.5)
+m2 = luma * (1.0 + saturation);
+ else
+m2 = luma + saturation - luma * saturation;
+
+ m1 = 2.0 * luma - m2;
+
+ rgb[0] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 + 2.0) * 255.0);
+ rgb[1] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0) * 255.0);
+ rgb[2] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 - 2.0) * 255.0);
+}
+}
--- ./libgimpcolor/gimpcolorspace.h~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.h 2007-01-06 13:07:47.0 -0500
@@ -94,6 +94,14 @@
gdouble hue,
gdouble saturation,
gdouble value);
+voidgimp_rgb_to_hsl4(const guchar *rgb,
+ gdouble *hue,
+
Re: [Gimp-developer] PATCH: Add HSL to compose/decompose plugins
From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 06 Jan 2007 20:11:06 +0100 the new function in libgimpcolor needs to be marked as new in 2.4. You can do that by adding Since: GIMP 2.4 as the last line in the gtk-doc comment. The gtk-doc comment also lacks a description of what the function does. If that is corrected, I think we can still include this patch for 2.4. Where does this go? Does it go in here somewhere? /** * gimp_hsl_to_rgb4: * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green, * rgb[2] is blue (0..255) * @hue:Hue channel (0..1) * @saturation: Saturation channel (0..1) * @luma: Luma channel (0..1) **/ -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] PATCH: Add HSL to compose/decompose plugins
BTW, I believe I also have to add appropriate lines to gimpcolor.def, correct? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] PATCH: Add HSL to compose/decompose plugins
From: Sven Neumann [EMAIL PROTECTED]
Cc: gimp-developer@lists.xcf.berkeley.edu
Date: Sat, 06 Jan 2007 20:11:06 +0100
Hi,
the new function in libgimpcolor needs to be marked as new in 2.4. You
can do that by adding Since: GIMP 2.4 as the last line in the gtk-doc
comment. The gtk-doc comment also lacks a description of what the
function does. If that is corrected, I think we can still include this
patch for 2.4.
Never mind, I figured it out.--- ./libgimpcolor/gimpcolorspace.c~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.c 2007-01-06 14:57:28.0 -0500
@@ -1003,6 +1003,90 @@
}
/**
+ * gimp_rgb_to_hsl4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Pointer to hue channel (0..1)
+ * @saturation: Pointer to saturation channel (0..1)
+ * @luma: Pointer to luma channel (0..1)
+ *
+ * Convert an RGB color value to an HSL (Hue, Saturation, Lightness)
+ * color value.
+ *
+ * Since: GIMP 2.4
+ **/
+void
+gimp_rgb_to_hsl4 (const guchar *rgb,
+ gdouble *hue,
+ gdouble *saturation,
+ gdouble *luma)
+{
+ gdouble red, green, blue;
+ gdouble h, s, l;
+ gdouble min, max;
+ gdouble delta;
+
+ red = rgb[0] / 255.0;
+ green = rgb[1] / 255.0;
+ blue = rgb[2] / 255.0;
+
+ h = 0.0; /* Shut up -Wall */
+
+ if (red green)
+{
+ max = MAX (red, blue);
+ min = MIN (green, blue);
+}
+ else
+{
+ max = MAX (green, blue);
+ min = MIN (red, blue);
+}
+
+ l = (max + min) / 2.0;
+
+ if (max == min)
+{
+ s = 0.0;
+ h = GIMP_HSL_UNDEFINED;
+}
+ else
+{
+ if (l = 0.5)
+s = (max - min) / (max + min);
+ else
+s = (max - min) / (2.0 - max - min);
+
+ delta = max - min;
+
+ if (delta == 0.0)
+delta = 1.0;
+
+ if (red == max)
+{
+ h = (green - blue) / delta;
+}
+ else if (green == max)
+{
+ h = 2.0 + (blue - red) / delta;
+}
+ else if (blue == max)
+{
+ h = 4.0 + (red - green) / delta;
+}
+
+ h /= 6.0;
+
+ if (h 0.0)
+h += 1.0;
+}
+
+ *hue= h;
+ *saturation = s;
+ *luma = l;
+}
+
+/**
* gimp_hsv_to_rgb4:
* @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
* rgb[2] is blue (0..255)
@@ -1083,3 +1167,45 @@
rgb[1] = ROUND (saturation * 255.0);
rgb[2] = ROUND (value * 255.0);
}
+
+/**
+ * gimp_hsl_to_rgb4:
+ * @rgb:RGB triplet, rgb[0] is red channel, rgb[1] is green,
+ * rgb[2] is blue (0..255)
+ * @hue:Hue channel (0..1)
+ * @saturation: Saturation channel (0..1)
+ * @luma: Luma channel (0..1)
+ *
+ * Convert an HSL color value (Hue, Saturation, Lightness) to an RGB
+ * color value.
+ *
+ * Since: GIMP 2.4
+ **/
+void
+gimp_hsl_to_rgb4 (guchar *rgb,
+ gdouble hue,
+ gdouble saturation,
+ gdouble luma)
+{
+ if (saturation == 0.0)
+{
+ hue= luma;
+ saturation = luma;
+ luma = luma;
+}
+ else
+{
+ gdouble m1, m2;
+
+ if (luma = 0.5)
+m2 = luma * (1.0 + saturation);
+ else
+m2 = luma + saturation - luma * saturation;
+
+ m1 = 2.0 * luma - m2;
+
+ rgb[0] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 + 2.0) * 255.0);
+ rgb[1] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0) * 255.0);
+ rgb[2] = ROUND (gimp_hsl_value (m1, m2, hue * 6.0 - 2.0) * 255.0);
+}
+}
--- ./libgimpcolor/gimpcolorspace.h~2006-06-27 06:33:48.0 -0400
+++ ./libgimpcolor/gimpcolorspace.h 2007-01-06 13:07:47.0 -0500
@@ -94,6 +94,14 @@
gdouble hue,
gdouble saturation,
gdouble value);
+voidgimp_rgb_to_hsl4(const guchar *rgb,
+ gdouble *hue,
+ gdouble *saturation,
+ gdouble *luma);
+voidgimp_hsl_to_rgb4(guchar *rgb,
+ gdouble hue,
+ gdouble saturation,
+ gdouble luma);
G_END_DECLS
--- ./libgimpcolor/gimpcolor.def~ 2006-09-01 07:14:32.0 -0400
+++ ./libgimpcolor/gimpcolor.def2007-01-06 14:42:27.0 -0500
@@ -18,6 +18,7 @@
gimp_cmyka_set_uchar
gimp_hsl_get_type
gimp_hsl_to_rgb
+ gimp_hsl_to_rgb4
gimp_hsl_to_rgb_int
gimp_hsv_clamp
gimp_hsv_get_type
@@ -55,6 +56,7 @@
gimp_rgb_to_cmyk
gimp_rgb_to_cmyk_int
gimp_rgb_to_hsl
+ gimp_rgb_to_hsl4
gimp_rgb_to_hsl_int
gimp_rgb_to_hsv
Re: [Gimp-developer] Print dialog
From: Sven Neumann [EMAIL PROTECTED] Date: Fri, 29 Dec 2006 17:18:58 +0100 - Clicking Print seems to get stuck if the printer isn't on when I click it. The progress bar goes to 100% and then stays there, and nothing shows up in the print queue. Subsequently turning the printer on doesn't help. If the printer is on when I click Print, it does eventually send something to the print queue (though it takes a surprisingly long time, even for a small image in Draft mode, compared to the gimp-print plug-in). I have improved the status messages a little since you reported this. Printing is still rather slow though. I am not sure if and how this can be improved. Again, we seem to need advice from a GtkPrint expert here. The hang could also be a spooler issue. Unless GtkPrint is doing some kind of special checking (or you're not using a spooler), it shouldn't even know if the printer that the printer isn't on. - When I print using this plug-in, I get periodic horizontal light bands. I'll do more testing, but I think it's something this plug-in is doing (not a clogged nozzle on my printer or similar issue) because I can print at different scales and resolutions and the bands always show up at the same places relative to the original image, regardless of physical spacing on the page. Yes, the banding comes from the fact that the plug-in paints the image in stripes of tile height. It does that to avoid having to allocate memory for the whole image. I hope that we can find a way to fix this. How would this kind of banding affect the output? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] 2.4 showstoppers
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 20 Dec 2006 08:35:35 +0100 On Tue, 2006-12-19 at 10:54 -0800, Akkana Peck wrote: And a few RFEs which would be needed to get the print dialog to functionality comparable to the existing gimp-print plug-in. I don't know whether these belong to gtkprint or gimp: - No way to adjust margins - Page Setup should be in the Layout tab, not a separate dialog - No live preview I don't think that comparable functionality is a goal of the new Print plug-in. People can always install the gutenprint plug-in if they need this functionality. Not saying that the new Print plug-in shouldn't be improved, but it should not be our goal to overload it until is has all the features that the gimp-print plug-in had. Whatever one thinks of all the color adjustments and the Gimp-Print/Gutenprint UI in general, the live preview and margin/page adjustments always attract comment if something breaks about them... -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] 2.4 showstoppers
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 15 Nov 2006 20:38:07 +0100 On Wed, 2006-11-15 at 11:02 -0800, Hal V. Engel wrote: One area were many on the OpenICC list agree is that the photoshop/proprietary OS approach to CM could be substantially improved in the area of printing. My GIMP proposal did not deal with color managed printing since my vision for how this should be handled would require significant changes to the gimp-print/guten-print plugin that I think are beyond the scope of 2.3/2.4 and are in fact significantly different from how this is handled in photoshop. The gimp-print/guten-print plug-in is developed by different people and is not at all coupled to the GIMP release cycles. We should however consider to make the print plug-in that's being shipped with GIMP aware of the image's color profile. I'd like to see the code that does this, so that the Gutenprint plugin can if possible do the same thing. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP 1.2 support removed from Gutenprint 5.1 mainline
I've removed the GIMP 1.2 support from the Gutenprint mainline per plan. Gutenprint 5.1 and beyond will only support GIMP 2.0 and above. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] on moving toward a 2.4 release
Date: Fri, 11 Aug 2006 09:09:44 -0700 From: William Skaggs [EMAIL PROTECTED] GIMP 2.0 was released on March 23, 2004, and then GIMP 2.2 on December 19, 2004. This was a 9 month release cycle, which is quite reasonable. Howver, it has been over a year and a half since the 2.2 release, and we are still not visibly nearing a 2.4 release. This slow progress is holding up important things, including, especially, GEGL integration. What can be done? Compared with us (Gutenprint), that's still positively speedy. GIMP 2.2 is a great application, albeit with some serious limitations (no 16-bit support, etc.). I'd personally prefer to see you folks take more time -- even quite a bit more time -- to get it right rather than try to rush a release. Keep doing 2.2-based releases with incremental functionality while working on a next generation release that will really improve matters. I was hoping that we'd be able to do our followon to Gimp-Print 4.2 within 12-18 months, but it didn't work out that way -- it was more like 4.5 years between Gimp-Print 4.2 and Gutenprint 5.0. There was a lot of churn along the way, but we rearchitected a lot of the internals to come up with a really general option system and a fully orthogonal 16-bit internal architecture (i. e. all of the input types we accept are capable of both 8 and 16 bits). Doing that design -- along with beating the color architecture into shape -- simply took a lot of time. If GEGL integration really is a hard problem, it's going to come out a lot better if you take the time to do it right rather than rushing it. I'd like to see a 16-bit GIMP as much as anyone -- it's a critical part of a RAW-based workflow, and it's needed for HDR imaging, which is something I'd really like to try -- but it's going to be a lot better if it's done right. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gutenprint 5.0.0 release
The Gutenprint project is pleased to announce the first public release of Gutenprint 5.0. This release, which has been under development for over four years, offers improved quality, greatly enhanced functionality, and support for many more printers than our previous version, Gimp-Print 4.2. Currently only the source package is available. We expect to release a binary installer for Macintosh OS X in the very near future. The package may be downloaded from http://prdownloads.sourceforge.net/gimp-print/gutenprint-5.0.0.tar.bz2?download. Please see the full release notes at http://sourceforge.net/project/shownotes.php?release_id=435706group_id=1537. Abbreviated release notes follow. I) GENERAL REQUIREMENTS Gutenprint will run on any reasonably modern computer running Linux, Macintosh OS X (10.2 or above), Solaris, or any other UNIX-like operating system. If you plan to compile this package from source, you will also need an ANSI C compiler, such as gcc (recommended). A compiler is not required if you are installing a pre-compiled package. Processor and memory requirements vary depending upon the printer and runtime options selected; it is suggested that you have at least 64 MB of memory for general purpose printing, 256 MB or more for high quality printing on a good printer, and 1 GB or more for large format printing at high resolution. You should have at least 50 MB of free disk space to compile and install Gutenprint. Disk space requirements for printing will vary depending upon how you use Gutenprint, but are generally modest except as noted below. We recommend a processor speed of at least 300 MHz. Fast printers may require a faster processor to achieve maximum printing speed. For general use, you should have the Common UNIX Printing System, CUPS (version 1.1.15 or above) or Foomatic (2.0 or above) installed. Please the rest of the release notes, in particular the Exceptions and Workarounds, for full details on installation, as there is important information to be aware of. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gutenprint provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gutenprint as a general-purpose printing solution. The enhanced Print plug-in for the GIMP requires either the GIMP 2.0 or above, or 1.2.3 or above on the 1.2 line (1.2.5 is recommended). This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. If you are printing photographs in large format from the GIMP at very high resolution, disk space requirements may be substantial, and we recommend at least 2 GB of free disk space for that purpose. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. This driver should be used in conjunction with Foomatic to configure printers. Users of Macintosh OS X 10.2 (Jaguar), 10.3 (Panther), and 10.4 (Tiger) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We strongly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5). The printing system used with these versions of OS X is not compatible with Gutenprint. OS X 10.2 and above use CUPS as the basis of the printing system, which is compatible with Gutenprint. The README file included with this package provides full instructions for building and installing Gutenprint. II) MAJOR CHANGES FROM PREVIOUS RELEASES A) MAJOR CHANGES BETWEEN GUTENPRINT 5.0.0 RELEASE CANDIDATE 3 AND GUTENPRINT 5.0.0: 1) A serious problem with margins when printing from CUPS in some cases was introduced in Gutenprint 5.0.0-rc3. The symptoms are that when printing certain kinds of material on certain printers, the print is positioned incorrectly on the page (too far to the right and too far down the page). This problem has been fixed. 2) The Ghostscript driver used with Foomatic now prints all pages of a document correctly. Previously it did not print any page except the first page of a document, or printed all other pages with possibly incorrect settings (bug 1501816). 3) A new user's manual has been added in doc/gutenprint-users-manual.odt (ODF format) and doc/gutenprint-users-manual.pdf, replacing the
[Gimp-developer] Link to the Gutenprint 20060703 snapshot
Here's a direct download link to the snapshot: http://prdownloads.sourceforge.net/gimp-print/gutenprint20060703.tar.bz2?download ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] Gutenprint 5.0 snapshot
Date: Tue, 04 Jul 2006 16:15:38 +0200 From: Till Kamppeter [EMAIL PROTECTED] Robert L Krawitz wrote: 7) Various minor problems in the PPD files have been fixed. The most notable change is that the names of the option groups have been shortened so that they are shorter than 40 characters in all cases except for one case in French. I get the following (was probably the same before): /usr/share/cups/model/gutenprint/5.0/C/stp-escp2-cx4100.5.0.ppd.gz: FAIL **FAIL** Bad Resolution choice None! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 360x120sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 360x240sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 360sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 720x360sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 720sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 1440x720sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 720x1440sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 1440x1440ov! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 2880x1440sw! REF: Page 84, section 5.9 **FAIL** Bad Resolution choice 5760x1440sw! REF: Page 84, section 5.9 [EMAIL PROTECTED] g]# due to not standard-conforming choice names in the Resolution option. I do not know whether it breaks printing, as I do not have an appropriate test printer here, but it can be fixed by changing the short name of the Resolution option to something else than Resolution or by renaming the choices. This has been around for as long as we've had a CUPS driver. My version of cupstestppd doesn't flag this, even in strict mode. It's not clear to me how best to fix it (or whether to fix it at all). Some printers offer multiple choices for a given resolution, although that problem's nowhere near as bad as it was in 4.2. It's not clear to me that we can fix it in any kind of compatible way. Any ideas? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Gutenprint 5.0 snapshot
I've posted a Gutenprint 5.0 snapshot. Please test it. I've also cleared up some null pointer references in debug code in the Ghostscript and CUPS drivers that cause problems on some platforms (I never caught them because the glibc printf handles null string pointers gracefully, but someone reported them on Solaris). I think I've caught all of these problems; they've been around for a long time. GIMP folks, your big change is #9. I'm still waiting to hear whether 2.3 or 2.4 should be the cutover point for this (I could make it be a specific 2.3 point release, but I'd rather not). The documentation now refers to the Gutenprint plugin as an enhanced Print plugin for the GIMP. A) MAJOR CHANGES BETWEEN GUTENPRINT 5.0.0 RELEASE CANDIDATE 3 AND GUTENPRINT 5.0.0: 1) A serious problem with margins when printing from CUPS in some cases was introduced in Gutenprint 5.0.0-rc3. The symptoms are that when printing certain kinds of material on certain printers, the print is positioned incorrectly on the page (too far to the right and too far down the page). This problem has been fixed. 2) The Ghostscript driver used with Foomatic now prints all pages of a document correctly. Previously it did not print any page except the first page of a document, or printed all other pages with possibly incorrect settings (bug 1501816). 3) The Postscript driver now handles PPD files with non-integer imageable areas correctly in all locales (the PPD files certain HP inkjet printers using the HPIJS driver have non-integer imageable areas for some paper sizes). In 5.0.0-rc3, this was handled incorrectly in locales that do not use the decimal point (.) for separating fractions from integers. 4) The PPD file parameter is now always accessible when using the Postscript driver in third party Gutenprint-enabled applications. This was not an issue with the enhanced Print plugin for the GIMP. 5) The Epson driver now chooses unidirectional vs. bidirectional mode more intelligently on new printers that are capable of producing excellent quality in bidirectional mode at high resolutions. This improves printing speed with the default settings in certain cases and in some cases improves print quality. 6) The Epson driver offers the same quality choices as 5.0.0-rc2 for certain new printers such as the R800, R1800, and R2400. Certain quality choices (in particular Super Photo and Ultra Photo) were not available in 5.0.0-rc3. 7) Various minor problems in the PPD files have been fixed. The most notable change is that the names of the option groups have been shortened so that they are shorter than 40 characters in all cases except for one case in French. 8) The French, Danish, Hungarian, and Swedish translations have been updated. 9) In the GIMP 2.4 and above (forthcoming as of Gutenprint 5.0 release), the enhanced Print plugin will be named Print with Gutenprint so as not to collide with the GtkPrint-based plugin bundled with that version of the GIMP. The Print plugin bundled with GIMP 2.0 and 2.2 is based on Gimp-Print 4.2; the Print plugin in this package simply replaces the Print plugin in those versions of the GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] RELEASE ANNOUNCEMENT: Gutenprint 5.0.0-rc3
Gutenprint 5.0.0-rc3 is the third (and hopefully final) release candidate for Gutenprint 5.0. It incorporates extensive feedback from earlier release candidates. In addition to the changes listed below, it now features a Macintosh OS X Universal Binary. The release may be found at http://sourceforge.net/project/showfiles.php?group_id=1537package_id=143930release_id=418068 MAJOR CHANGES BETWEEN GUTENPRINT 5.0.0 RELEASE CANDIDATE 2 AND GUTENPRINT 5.0.0 RELEASE CANDIDATE 3: 1) The package now offers explicit support for many more printers. All printers supported by Gutenprint are now listed explicitly rather than via the compatibility list. As a result, CUPS PPD files and Foomatic are now generated for each supported printer. 2) CUPS and Foomatic/IJS now produce correctly dimensioned and positioned output. Previous pre-releases of Gutenprint 5.0 produced incorrectly dimensioned and/or positioned (offset from the correct position) output in certain cases. This happened in the following circumstances: a) When a printer capable of optional full-bleed or borderless operation was used in full-bleed/borderless mode, the output was stretched to fit the expanded dimensions. The result was that lines of specified lengths were printed slightly longer than desired, and since the vertical and horizontal stretching was normally not identical, the output was distorted slightly. b) When printing directly to a CD, the output was shrunk horizontally and/or positioned incorrectly by a small amount (typically a few mm). c) Depending upon the application doing the printing and the printer selected, the output was shifted down and to the right by several mm. The PPD files and driver have been modified to specify zero borders in all cases when a printer with borderless capability is used. If normal (non-borderless) mode is selected, the border is simply not printed, leaving correct dimensions for everything within the imageable area. However, as a result of this, the driver no longer prints true full bleed (overprinting the edge of the page). The margins are set to zero, and typically there will be very narrow unprinted margins (less than 1 mm) on one or more sides. Printing to CD's works correctly whether or not full bleed mode is selected. This change has no effect in the GIMP plugin and in other applications which directly use Gutenprint, as there was never any problem in those contexts. 3) The IJS driver now correctly ejects the last page of a job. Previously it did not always eject the last page with certain Epson printers. 4) The Epson Stylus Photo R800, R1800, R2400, and related printers should now print at full speed in all cases. Previously these printers were extremely slow (about 10 times slower than normal) in many cases. Related to this, the list of resolutions offered for these printers are slightly different from before. Resolutions above 2880x1440 DPI are no longer offered; instead, resolutions of 2880x1440 high quality and 2880x1440 highest quality are offered. These resolutions use extra passes of the print head to reduce banding. In addition, these resolutions are actually 1440 DPI horizontally and 2880 DPI vertically. 5) The HP DeskJet 690 and other supported PCL printers capable of 6-color photo printing (such as the Apollo P-2100 and Apple Color StyleWriter 4500) no longer result in the driver crashing if black and white output mode was selected. Also, Canon printers capable of 6 or 7 color photo printing no longer result in a crash if black and white output mode is selected. 6) Canon and Lexmark inkjet printers now print if color output mode is selected with a black and white cartridge installed. Previously this was not possible in the GIMP plugin; the CUPS and Foomatic drivers permitted this to be set, but gave a runtime error when a job with these settings was printed. These printers now accept the job and simply print it in black and white. 7) The cleaning and nozzle check functions of escputil now work properly on most printers, and escputil no longer crashes if you type ctrl-D to a command prompt. In addition, the status printed via the status command is now much more readable. 8) The color quality for the Epson R300, R800, R2400, and related printers has been improved. 9) Raw output now works correctly on the Epson R800 and R1800. 10) The Canon driver now handles color and grayscale, and also photo ink cartridges (previously it sometimes handled these incorrectly or even crashed). However, many of these printers still do not print correctly with a photo cartridge installed (the width of the printout is
Re: [Gimp-developer] Compiling gimp under debian with gimp-print support
Date: Sun, 16 Apr 2006 09:44:22 -0700 From: Akkana Peck [EMAIL PROTECTED] Frédéric writes: I successfully compiled gimp-cvs under my debian testing, but without gimp-print support. What do I need to install to get it ? I can't find any gimp-print-dev or so package... When you're searching, be sure you use a search that would catch both gimp-print and gimpprint, e.g. aptitude search gimp | grep print. But it's likely that they've switched to gutenprint (new name, same project), and although there's a libgutenprint-dev package (at least here in Ubuntu), GIMP's configure script is only set up to look for older gimp-print headers, not the newer gutenprint ones. My understanding is that the gutenprint gimp plug-in is now expected to come from gutenprint, rather than from gimp. (Maybe someone else can clarify that.) In any case, it does work to build gutenprint from source (http://gutenprint.sourceforge.net/ ... and yes, the page still says Gimp-Print, but if you click on Download you'll find the gutenprint releases. It's all very confusing). Make sure that the gimp2 print plugin is enabled (I believe it is by default, at least if you have the gimp dev headers installed). Then the plugin will be built in the gutenprint source tree for use with your CVS gimp. The right thing to do here is to build the GIMP without print support, and then build Gutenprint from source, as Akkana suggests. Yes, we know that the web site names are confusing, but we don't have anyone to create a new web site (i. e. we need help :-) ). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] Compiling gimp under debian with gimp-print support
From: =?iso-8859-15?q?Fr=E9d=E9ric?= [EMAIL PROTECTED] Date: Sun, 16 Apr 2006 20:32:48 +0200 On Dimanche 16 Avril 2006 19:36, Robert L Krawitz wrote: The right thing to do here is to build the GIMP without print support, and then build Gutenprint from source, as Akkana suggests. Do you think it will work if I rebuild gutenprint from debian source=20 package ? At this time, it is the version 5.0.0-rc2 in testing... I'd expect so; Roger Leigh can add any comments. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] A few suggestions forThe Gimp
Date: Sat, 1 Apr 2006 14:34:45 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] CS browser is just one of those flat-file Microsoft thingies. Why not incorporate a real relational database? So, my suggestion is to dramatically improve workflow by developing a MySQL database companion for Gimp, that allows users to search and sort large image databases like mine (30,000 digital images). Images could be tagged while they are being processed, or batch tagged. Interesting idea. I suspect you would need to sponsor a developer if you really wanted it to happen though. As director of photography for North American Women's Baseball League (NAWBL), I know that searching and sorting images can be very time-consuming work. Using Gimp you could automatically transfer image metadata to tags. It would be very useful to do a search involving all the images shot at f/2.8 or f/4.0? All the photos shot with a particular lens. All the photos shot at ISO 100, or ISO 800. Photos of Programs like Bibble Pro, Aperture (from Apple) and Adobe Lightroom sound better suited to these tasks of batch processing sets of photos and RAW files. These are seperate and distinct programs from the likes of Adobe Photoshop, Corel Paint, and Macromedia Fireworks. I wonder if trying to shoehorn even more functionality into the GIMP in a clean and organised way is really managable. Check out KPhotoAlbum (http://ktown.kde.org/kphotoalbum/), which previously was named KimDaBa (KDE Image Database). It uses an XML file rather than a relational database for its back end storage, but it has this kind of search capability (including user tagging, date ranges, and EXIF data in the current pre-release snapshot, via SQLite). It's very fast. I have about 12,000 images and there's very little delay on just about any operation. There has been some discussion about using an RDBMS backend for storage vs. the XML backend. My own calculations suggest that at least up to 50,000 or so images there's no need for anything more elaborate, and there are significant advantages to the textual XML storage. That said, merging image storage with image manipulation doesn't feel quite right to me. KPhotoAlbum was designed for one purpose -- to maintain large collections of images with excellent search capability. The GIMP is also designed for one purpose -- to create and edit images. These two functions seem completely orthogonal to me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Plea for a new interface for the GIMP
Date: Fri, 31 Mar 2006 19:51:08 -0400 From: Roland Wild [EMAIL PROTECTED] I saw your example but i continue to say that the GIMP can be uncomfortable to use. In your example http://prokoudine.info/shots/gimp_layout.jpg you don't have all the funcfionnality offer by the program (see http://docs.gimp.org/en/concepts-beginners.html#gimp-concepts-usage ). 1 You don't have on your screen the tool options box and if you want it, it is accessible after several clicks. Maybe there should be something in the menu bar that opens it on a single click (rather than click/drag/release). 2 When you click on your image window the main toolbox disappear behind. What do you do? That's a function of your window manager setting. If you use click raise, this will happen. I don't have this problem personally, since I don't use click to raise (click on the title bar or a hotkey are the only ways for me to raise a window). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] Bring Back the Keyboard!
From: Leon Brooks [EMAIL PROTECTED] Date: Wed, 15 Feb 2006 18:28:22 +0800 On Wednesday 15 February 2006 16:18, Sven Neumann wrote: The user should never ever have to do this. We need to either move some of our resource files into a visible folder or we need to provide a user interface to manage resource files that doesn't involve using a file manager. All of which sounds like _much_ more work (and many more design decisions) than simply making the file selector work consistently. Not to mention that someone might want to edit files in a hidden directory for other reasons (e. g. thumbnail files stored in .thumbnails). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] 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] [PATCH] Fix generating src/main/gutenprint.pc
Date: Sun, 30 Oct 2005 12:09:29 +0100
From: Timo Gerke [EMAIL PROTECTED]
This is a multi-part message in MIME format.
--050206030204030108080208
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Hi all,
I just found out that gutenprint.pc is not
created correctly.
In the generated we have
Version: @gutenorint_version@
kind regards,
Timo Gerke
This belongs on gimp-print-devel, not gimp-developer. Forwarding.
--050206030204030108080208
Content-Type: text/plain;
name=gutenprint.pc.in.diff
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename=gutenprint.pc.in.diff
Index: src/main/gutenprint.pc.in
===
RCS file: /cvsroot/gimp-print/print/src/main/gutenprint.pc.in,v
retrieving revision 1.1
diff -u -r1.1 gutenprint.pc.in
--- src/main/gutenprint.pc.in 17 Sep 2004 18:38:21 - 1.1
+++ src/main/gutenprint.pc.in 30 Oct 2005 11:08:24 -
@@ -5,6 +5,6 @@
Name: Gutenprint
Description: Gutenprint Top Quality Printer Drivers
-Version: @gutenprint_version@
+Version: @VERSION@
Libs: -L${libdir} @gutenprint_libs@
Cflags: -I${includedir} @gutenprint_cflags@
--050206030204030108080208
Content-Type: text/plain; charset=us-ascii
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
--050206030204030108080208--
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gutenprint 5.0.0-rc1
Welcome to Gutenprint 5.0.0-rc1! Please read these release notes carefully. Gutenprint, formerly named Gimp-Print, is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2, 10.3, and 10.4) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. The package has been renamed in order to clearly distinguish it from the GIMP. While this package started out as the Print plugin for the GIMP, it has expanded into a collection of general purpose printer drivers, and the Print plugin for the GIMP is now only a small (but important) piece of the package. Furthermore, the name Gutenprint recognizes Johannes Gutenberg, the inventor of the movable type printing press. Finally, the word guten means good in German. Gutenprint 5.0.0-rc1 is the first release candidate of Gutenprint 5.0. It is based on the Gimp-Print 4.3 series that has been in development for over three years, and includes many improvements over the very popular 4.2 series. This release is believed to be quite stable, but further testing is required before final release. We believe this release to be stable enough for day to day use, and encourage people to test it and report their results. Gutenprint currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line (1.2.5 is recommended), or the GIMP 2.0 or above. You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes, in particular the Exceptions and Workarounds, for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gutenprint provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gutenprint as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar), 10.3 (Panther), and 10.4 (Tiger) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. The README file included with this package provides full instructions on building and installing Gutenprint. * Major changes between Gutenprint 5.0.0 beta 4 and Gutenprint 5.0.0 release candidate 1: 1) Color correction is greatly improved, particularly for Epson printers. The following general and specific improvements have been made: * The default gamma for all Epson printers has been increased to resolve long-standing issues with overly dark prints. The user gamma adjustment is specified as a correction, so the default value of 1.0 will yield correct results. * Luminosity (darkness) correction has been simplified and improved by performing correction only on the color component, without adjusting the gray component. This improves dark cyans and greens in particular, and generally yields smoother tonal changes. * Red and blue generation for the Epson Stylus R800 and R1800 (and for any future
Re: [Gimp-developer] GIMP print dialog issues
From: Roger Leigh [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], gimp-developer@lists.xcf.berkeley.edu Date: Thu, 25 Aug 2005 22:34:52 +0100 -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Robert L Krawitz [EMAIL PROTECTED] writes: From: Roger Leigh [EMAIL PROTECTED] Date: Wed, 17 Aug 2005 18:58:14 +0100 [snip libgutenprintui2 horribleness] I wanted to do this, but the fact that we have to support both GTK+-1.2 (for Cinepaint) and GTK+-2.0 (for Gimp) versions of the codebase caused serious problems keeping the two versions in sync. It also meant that the 2.0 version was basically restricted to using the 1.2 era features, otherwise syncing changes would become impossible. All I could do was a minimal conversion from 1.2 to 2.0. I don't see why we necessarily have to keep the capabilities of the two in sync. The 1.2 plugin already supports all of the 5.0 capabilities, and keeping them in sync doesn't really reduce the testing burden. It might be a bit late to do it now, but if you want to get started, go ahead. I don't want to break anything so near to release, so I'd like to do this on a branch, and then we can merge things back to 5.0.x, or to the new mainline depending on what happens. Would that be OK? If you want. I'd rather make changes before 5.0.0 than in a 5.0.x release, though. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 17 Aug 2005 10:39:39 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: This helps. The GIMP actually includes its own copy of the Print plugin, but I don't know exactly what source that's based on. What you might try is using --disable-print with the GIMP, and configuring Gimp-Print with --enable-gimp (which builds the Print plugin out of the Gimp-Print source). Which is actually what debian is doing (at least in sid). They recently switched from the included plug-in to the one that comes with gutenprint. I have been very disappointed to find out that none of the user interface improvements that we have done to the Print plug-in over the last years have been incorporated into that version. Basically the Print dialog looks like crap now. 1) I don't remember anyone ever feeding them back to us. Mitch did some improvements once, years ago, but no one's ever contacted us since. 2) We're not interested in any changes to the 4.2-based plugin at this point; 5.0 is the wave of the future. They're different enough that changes to one won't port very easily to the other. 3) That's what happens when nobody steps forward to maintain the plugin and I have to do UI stuff. The best way to utilize me for UI programming is to take whatever I do and invert it. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
From: Roger Leigh [EMAIL PROTECTED] Date: Wed, 17 Aug 2005 18:58:14 +0100 Sven Neumann [EMAIL PROTECTED] writes: Robert L Krawitz [EMAIL PROTECTED] writes: This helps. The GIMP actually includes its own copy of the Print plugin, but I don't know exactly what source that's based on. What you might try is using --disable-print with the GIMP, and configuring Gimp-Print with --enable-gimp (which builds the Print plugin out of the Gimp-Print source). Which is actually what debian is doing (at least in sid). They recently switched from the included plug-in to the one that comes with gutenprint. I have been very disappointed to find out that none of the user interface improvements that we have done to the Print plug-in over the last years have been incorporated into that version. Basically the Print dialog looks like crap now. I wanted to do this, but the fact that we have to support both GTK+-1.2 (for Cinepaint) and GTK+-2.0 (for Gimp) versions of the codebase caused serious problems keeping the two versions in sync. It also meant that the 2.0 version was basically restricted to using the 1.2 era features, otherwise syncing changes would become impossible. All I could do was a minimal conversion from 1.2 to 2.0. I don't see why we necessarily have to keep the capabilities of the two in sync. The 1.2 plugin already supports all of the 5.0 capabilities, and keeping them in sync doesn't really reduce the testing burden. It might be a bit late to do it now, but if you want to get started, go ahead. The only 1.2 clients we need to be concerned with are the GIMP and Cinepaint. The GIMP folks have no interest in 1.2, and if Cinepaint wants to improve it, they can maintain it. As soon as 5.0.0 is released and stable branched in CVS, I'd like to rip out the 1.2 UI code and do some real work on the 2.0 code, which will include merging the Gimp changes over, as well as splitting it out into discrete GObjects; I'm not too happy with the current slew of global variables. That code really is rather brutal, isn't it... -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 19:30:35 -0700 From: Brian Thomason [EMAIL PROTECTED] Roger, Brian has a rather odd problem whereby when he starts the Print plugin on a fresh image he gets completely empty positioning boxes (nothing filled in for any of the position/sizing boxes). I'll send you a screenshot under separate cover. One thing to note, Roger, is that this is only prevalent in our packaging of gimp 2.2.8, as Debian's package, last I checked, has printing explicitly disabled for some reason. (Perhaps for the same problem, but I doubt it) I'm sure you have far more insight on this than I do, however. This helps. The GIMP actually includes its own copy of the Print plugin, but I don't know exactly what source that's based on. What you might try is using --disable-print with the GIMP, and configuring Gimp-Print with --enable-gimp (which builds the Print plugin out of the Gimp-Print source). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Tue, 16 Aug 2005 11:19:57 -0700 From: Bill Kendrick [EMAIL PROTECTED] On Tue, Aug 16, 2005 at 10:33:56AM -0700, Brian Thomason wrote: We did that, and the plugin works, but the orientation/position fields are all empty upon launching it. FWIW, I fired up Gimp on my Debian/etch box last night, drew a picture, hit 'Print', and the dialog that appeared also lacked values in the position fields (until I played with the orientation pulldown or the scale slider). However, if I printed while they were blank, it seemed to print ok, full-page on US letter. I can't recall what versions of anything I was using, but it's whatever's the latest in Testing (etch) as of a couple days ago. Does this only happen with an unsaved image? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Tue, 16 Aug 2005 17:42:01 -0700 From: Brian Thomason [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu Robert L Krawitz wrote: Date: Tue, 16 Aug 2005 11:19:57 -0700 From: Bill Kendrick [EMAIL PROTECTED] On Tue, Aug 16, 2005 at 10:33:56AM -0700, Brian Thomason wrote: We did that, and the plugin works, but the orientation/position fields are all empty upon launching it. FWIW, I fired up Gimp on my Debian/etch box last night, drew a picture, hit 'Print', and the dialog that appeared also lacked values in the position fields (until I played with the orientation pulldown or the scale slider). However, if I printed while they were blank, it seemed to print ok, full-page on US letter. I can't recall what versions of anything I was using, but it's whatever's the latest in Testing (etch) as of a couple days ago. Does this only happen with an unsaved image? On my Linspire machine, it happens with both saved and unsaved images. I can't reproduce this at all with 5.0. I'm not able to get 4.2 to run right now for some reason. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 16:12:17 -0700 From: Brian Thomason [EMAIL PROTECTED] Hi, I am packaging up gimp 2.2.8 for Linspire and have noticed some strange issues in the print dialog that my non-existent C skills have been unable to resolve. I'm not the best in the world at describing problems, so I have attached a screenshot to help out a bit. Problem 1: When the print dialog is open, the orientation is set to Auto, which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. I'm the project lead for Gutenprint. Can you describe for me more specifically what you mean? Why will it fail as it is? Problem 2: Consequently, as a result of problem 1, the preview pane is distorted. Changing the orientation, alignment, or any such settings solves the problem, but I am unable to achieve these same results by manually calling the various callback functions associated with these actions. I either end up with a segfault, or simply nothing being changed. Any help would be greatly appreciated. What are you trying to do here? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 16:28:54 -0700 From: Brian Thomason [EMAIL PROTECTED] I'm the project lead for Gutenprint. Can you describe for me more specifically what you mean? Why will it fail as it is? Because there are no values automatically filled in to the Left, Right, Left Border, Top, and Right Border fields. Thanks for sending me the screenshot. Problem 2: Consequently, as a result of problem 1, the preview pane is distorted. Changing the orientation, alignment, or any such settings solves the problem, but I am unable to achieve these same results by manually calling the various callback functions associated with these actions. I either end up with a segfault, or simply nothing being changed. Any help would be greatly appreciated. What are you trying to do here? I'm simply trying to have these values filled in by default, and have the image vertically aligned, by default. It would help if I had actually attached the image. (doh!) Many thanks for the fast response. I've never seen anything like this, with the dimension/positioning boxes not filled in, even when using the Postscript driver without a PPD file. Which release of Gimp-Print are you using (4.2.7 is the most recent, and last, 4.2 release)? Are you using the unmodified source code? Can you supply a reproducible test case? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 19:30:54 -0400 From: michael chang [EMAIL PROTECTED] On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: I am packaging up gimp 2.2.8 for Linspire and have noticed some strange When the print dialog is open, the orientation is set to Auto, which is good, but none of the default position indentions are set. (Left, Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. Which printing system does Linspire use? (e.g. CUPS, BSD, etc.) Does it make one of it's own to make it similar to Windows? That shouldn't have any effect here. Gimp-Print doesn't really care what the underlying spooling system is. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 19:41:15 -0400 From: michael chang [EMAIL PROTECTED] On 8/15/05, Robert L Krawitz [EMAIL PROTECTED] wrote: That shouldn't have any effect here. Gimp-Print doesn't really care what the underlying spooling system is. How does it contact the spooling system? Or does it use specific methods for each printing system? It just uses the lpr or lp command -- nothing fancy. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 16:52:33 -0700 From: Brian Thomason [EMAIL PROTECTED] Cc: gimp-developer@lists.xcf.berkeley.edu michael chang wrote: On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: michael chang wrote: On 8/15/05, Brian Thomason [EMAIL PROTECTED] wrote: I am packaging up gimp 2.2.8 for Linspire and have noticed some strange Right, left Border, etc...) For the common user, he will just hit print when presented with the dialog, and this will simply fail as it is. At odd times, if the user doesn't flatten the image before printing, it will only print the current layer. And he'll wonder why half his image is gone. [I can't remember what version of GIMP/GIMP-Print this is in.] Some who are prompted for auto-flattening-export think it will perminantly flatten their image, and look for a work around. Are you packing gutenprint/gimpprint also? Not unless needed. We've been happy with 4.2.7 up to this point. Are you using the 4.2.7 tarball from gimp-print.sourceforge.net? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP print dialog issues
Date: Mon, 15 Aug 2005 16:50:14 -0700 From: Brian Thomason [EMAIL PROTECTED] Robert L Krawitz wrote: I've never seen anything like this, with the dimension/positioning boxes not filled in, even when using the Postscript driver without a PPD file. Which release of Gimp-Print are you using (4.2.7 is the most recent, and last, 4.2 release)? Are you using the unmodified source code? Can you supply a reproducible test case? Yes, I am using 4.2.7, completely unmodified. If you have a spare box to install Linspire 5.0 on, absolutely. (Debian Sarge might also suffice, but I'm not sure.) I don't have a spare box. Simply installing gimp 2.2.8, creating an image, of any size, and selecting Print from the file menu of that image reproduces this. I've never seen this kind of problem, and this is the first report I've heard of anything of this sort. I'm cc'ing Roger Leigh, our Debian expert. Roger, Brian has a rather odd problem whereby when he starts the Print plugin on a fresh image he gets completely empty positioning boxes (nothing filled in for any of the position/sizing boxes). I'll send you a screenshot under separate cover. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 23 Jun 2005 10:35:51 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Isn't that at least enough reason to take a closer look at the issue? Are you as well starting with this accusation now? We are taking a close look at this. We have already spent a lot of time on this, probably way more than we should. I have been contributing patches and suggestions to the file-chooser for quite a while now. This has turned the dialog into something that works rather well for me. Perhaps it is time that you start doing that as well. The context for this was: Marc, it is you who's being idiotic here. You state that there are a number of people. What number? How large is that number compared to the number of happy users? We can hardly decide anything unless we know the answer to these questions. You asked how many people were involved here. I went and looked at how many people have posted on precisely this issue, and posted my numbers. I've been contributing suggestions both here and on the bugzilla.gnome.org bug (whose number I forget). Yes, it's true that my suggestion boils down to bring back the text entry box! and not a whole lot else. Every time anyone here makes that suggestion you dismiss it with You basically have no clue on how the new dialog works or I have already explained [how a text entry with completion would conflict with being able to use the file dialog's other features] without really getting to the heart of the matter -- a lot of people just plain want a text entry box, because it's such a natural way to work (a filename, or pathname for that matter, is a text string, and people just want to be able to type it in a natural manner). The only reason why someone sensible would complain on this subject on the gimp-developer mailing list is that he/she wants to discuss the issue in the context of using the dialog from within GIMP. The goal of such a discussion should be to prepare a proposal or even patches in order to present them to the GTK+ developers. The only GTK2 app that I use on any kind of routine basis that uses this dialog is the GIMP. This has given me a good reason to do everything I can to avoid other GTK2 apps. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Date: Thu, 23 Jun 2005 07:43:07 -0400 From: Robert L Krawitz [EMAIL PROTECTED] I've been contributing suggestions both here and on the bugzilla.gnome.org bug (whose number I forget). Yes, it's true that my suggestion boils down to bring back the text entry box! and not a whole lot else. Every time anyone here makes that suggestion you dismiss it with You basically have no clue on how the new dialog works or I have already explained [how a text entry with completion would conflict with being able to use the file dialog's other features] Actually, I should correct myself here: the second comment (explaining how the text entry would conflict is a legitimate explanation, not merely dismissing objections. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Date: Thu, 23 Jun 2005 21:13:41 +0100 (BST) From: Alan Horkan [EMAIL PROTECTED] I do not disagree with Sven on this. Please do not count me in on this arguement, I probably should not have commented at all. On balance the new file chooser is better, it just happens to be worse in some of the ways the old file chooser was good and I do recognise it has issues. Fair enough. ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gtk file choser widget
So here's a half baked proposal. Make of it what you will. I am beginning to see why it is quite complicated. The current file chooser stays the same by default, except that a label is added somewhere that reads Type a filename or whatever (to give some kind of visual cue that you can type a filename to it). This isn't essential to my proposal, but I think that the cue should be there in any case. Also by default, starting to type a filename pops up a filename entry, as currently done. However, there's one additional little checkbox named Dock With Chooser or the like. If this is checked, the filename entry (and checkbox) immediately integrates with the chooser, and stays there until/unless Dock With Chooser is unchecked. This state is saved, so the next time the chooser pops up it's in the same state as it last was. Therefore, if Dock With Chooser is not checked, everything behaves exactly as it does now. If it is checked, the main dialog has a tab completing pathname entry box. What happens when Dock With Chooser is selected? Let's start with some definitions: * A filename refers to the base name component of a path (i. e. what basename returns). * A dirname refers to the directory component of a path (i. e. what dirname returns, with a path component separator appended). * A pathname refers to the concatenation of a (possibly empty) directory name with a (possibly empty) filename The focus (or whatever it's called in this situation -- it's not the window receiving focus, but rather the active widget) is the same as usual, but if you start typing, focus is switched to the text entry box. The entry box starts with an empty pathname. Next, some definitions: How does tab work? Here are the cases: 1) If the entry box contains an empty pathname, tab always goes to the next widget. 2) If the most recent action was switching into the entry box, tab simply switches to the next widget. 3) If the most recent action was typing something into the entry box, tab attempts to complete as much as it can. The next tab switches to the next widget (i. e. two tabs in a row switches out). Alternatively, tab only completes as far as a single directory name. Typing tab again completes as much as it can within the next directory, and then the next tab switches out. I was also thinking that the normal tab order should simply skip the entry box, so the only ways to use the entry box are to either click in it with the mouse or start typing. That's also an alternative. (Have I missed anything?) A few more things: 1) If the dirname in the entry box is empty, any filename is interpreted relative to the otherwise selected directory. 2) If the dirname in the entry box is not empty, the directory of the entire file chooser is dynamically set to the dirname of the entry box (e. g. as a path component is typed or erased, the directory of the file chooser changes on the fly). 3) Selecting another directory with any other widget replaces any directory component typed into the chooser, but leaves the file component intact. Thus, if I've typed /foo/bar.j into the browser, and then select /home/rlk, /foo/ is erased from the entry widget, leaving /foo/bar.j. 4) Selecting a filename with other widgets in the chooser erases any filename in the widget, and replaces it component with the filename selected. Thus, if I've typed /foo/bar.j into the entry box, the directory of the entire chooser has been changed to /foo. If I now select baz.jpg via any other means, the entry box receives the text /foo/baz.jpg. No doubt I've missed some things, but this is a starting point. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 10:12:05 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: Sven, you've been offered a solution -- just add an entry with tab completion. You may not agree with it, but it's not accurate to say that noone has made a proposal on how such an entry should be integrated with the current dialog. Just stick it on the bottom of the dialog, just above the OK/cancel boxes, and Marc and I will be happy to shut up. This is not about making you and Marc shut up. This is about designing a user interface that works for the majority of users. Whatever we do, there will always be someone complaining. I don't really care who that is. This one seems to be attracting a disproportionate share of complaints. Usually with other controversial interface issues I see a few comments, and then people start to converge. This one is different. In what way is just adding an entry with Tab completion going to ruin the whole thing? If it's there, but isn't used, it isn't going to interfere with anything else, is it? It does indeed interfere with the rest of the dialog, otherwise it would probably have been added a while ago already. But I already explained the problems of this approach in another mail that I sent last night. If I understood correctly, it's a conflict between the use of tab for completion and tab for jumping between widgets? If so, how about using a different keystroke for completion (escape or ctrl-tab, for example)? Perhaps another approach would be for the integrated text input to be initially hidden, but with a More button that makes it visible. The state of the More button is saved, so that the next time the dialog is popped up it has the same components as it did before. And why is it so important that there be a concept for the entire dialog beyond what works best for people? The problem (to me, and I daresay to Marc) is very simple -- there's no obvious way to simply enter a pathname with a simple form of completion that's only activated on demand. A file dialog without this is just plain fatally flawed. The problem is to find out what works best for people. Trying to decide this in an argument among developers is very certainly going to fail. The problem is that there's no one method that works best for people. People like Marc and I find the old dialog much more suited to our needs than the new one. Make it a configuration option, if you like. No, I don't like configuration options, I hate them. And it would also not have to be me who adds it but the GTK+ developers. We are certainly not going to fiddle with the internals of the GtkFileChooser widget. Obviously the problem is a GTK issue, not a GIMP issue. My first experience with the new configuration dialog was absolutely brutal. I couldn't believe that I was being presented with a file dialog that had no text entry box (I spent a while exploring it to try to find the button that would give me the entry box), and given the way I jumble everything together, searching around in a list entry is hopeless (I have about 1000 files in one directory; I know a lot of the filenames by memory, but being forced to do a linear search through that many files is simply absurd). I more or less stopped using the GIMP altogether for a while; I used Cinepaint or xv (!) despite it being obsolete in many ways where I could, and otherwise started a new instance of the GIMP each time I had to use it, because dealing with the file dialog was so hopeless. Eventually after poking around Google I found the ctrl-L hack, but it's still very clumsy compared to the simplicity of a text entry box. I agree that the Ctrl-L is clumsy and I would like it to be removed (of course after it has been completely obsoleted). But you don't really need Ctrl-L to use the dialog. I am sorry that you made your first experiences with the new dialog with the early versions that were indeed rather akward to use. Two problems with this: 1) There's no visual cue that typing in a filename will do anything. 2) The secondary popup is very annoying (either it's going to pop up under the mouse, in which case it's going to obscure other parts of the dialog, or it isn't going to have focus for those of us who use focus strictly follows mouse). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 23 Jun 2005 00:09:06 +0200 [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) writes: Lots of people have. Sorry but I haven't seen a detailed and complete proposal yet. If you can point me to one, please do. Here's one: add a text entry box at the bottom of the screen, and use a different key (say, shift-tab) for completion. Attach this label to the entry box: Filename: (to complete, type shift-tab) I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? What is the current key navigation behaviour? cursor keys? I don't really need cursor keys when I do tab completion, and when I need them, I could easily use my mouse to click. Oh well. I had the impression all along this discussion. You basically have no clue on how the new dialog works. That doesn't shed a good light on the new dialog but it also shows that you are rather ignorant. I think I asked you and everyone else to actually try to work with the dialog. I guess I will have to sit down and write a manual since you obviously haven't understood how it works. I could just as easily say that you have no clue how Marc or I work -- please keep the personal attacks out of it. You did ask Marc to try to work with the new dialog, he complied, and found it didn't help him. Or, put difefretly: in what ways would a tetx entry with completion conflict with being able to use the file dialogs other features with the mouse (and then: with the keyboard). I have already explained that in all details. See my other mail in this thread in case you missed earlier explanations. As best as I can tell, the only substantive issue is the fact that the tab key, if used for completion, would conflict with the tab key, as used to jump around the other widgets. I propose using a different key sequence -- shift-tab -- for completion. If a number of users complain about usability issues, askign them to make scientific studies before their complaints can be taken seriously is just plain idiotic. What counts is reality, and the current file dialogs, wether they worked in studies or not, fail this for quite a number of people. Marc, it is you who's being idiotic here. You state that there are a number of people. What number? How large is that number compared to the number of happy users? We can hardly decide anything unless we know the answer to these questions. I've seen quite a number of people -- Marc, Alastair Robinson, Bill Kendrick, Jernej Simoncic, Joao S. O. Bueno Calligaris, Michael Thaler, and myself -- complain more or less vociferously about this, for what appears to be more or less the same reason. Alan Horkan appears to have at least some complaints about it, Dennis Bjorklund appears to be defending it mildly, and you're defending it strongly. So by my count, we have Oppose/strongly oppose 7 Mildly oppose 1 Mildly support 1 Strongly support 1 Is this proof? No. Perhaps the majority of GIMP/GTK users who are not on the list strongly prefer the new dialog. However, my experience on the net suggests that if there were other people on the list who strongly support the new dialog that at least a few of them would have popped up by now. What's more, the complaints are all very specific, and are focused on exactly the same issue -- the lack of a text entry box for a filename. Nobody here is complaining about anything else. Isn't that at least enough reason to take a closer look at the issue? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
From: Sven Neumann [EMAIL PROTECTED] Date: Wed, 22 Jun 2005 00:18:34 +0200 (3) Don't try to advertise the old GtkFileSelection dialog as being the solution that we should revert too. I didn't. I did advertise the way the old file selection dialog used it's text entry as the solution for me (and others with similar complaints). So far noone has made a proposal on how such an entry should be integrated with the current dialog. So I don't have much chance but to assume that what you have in mind is basically the behaviour of the old dialog. Perhaps you aren't suggesting to revert to it code-wise, but I haven't yet seen a detailed proposal on how an entry with Tab completion is supposed to work without bringing back the problems we had with the old dialog. I certainly wouldn't want to miss the current key-navigation behaviour. But perhaps you can offer a viable alternative? Such an alternative would have to be a concept for the whole dialog. Just adding an entry with Tab completion is going to ruin the whole thing. Sven, you've been offered a solution -- just add an entry with tab completion. You may not agree with it, but it's not accurate to say that noone has made a proposal on how such an entry should be integrated with the current dialog. Just stick it on the bottom of the dialog, just above the OK/cancel boxes, and Marc and I will be happy to shut up. In what way is just adding an entry with Tab completion going to ruin the whole thing? If it's there, but isn't used, it isn't going to interfere with anything else, is it? And why is it so important that there be a concept for the entire dialog beyond what works best for people? The problem (to me, and I daresay to Marc) is very simple -- there's no obvious way to simply enter a pathname with a simple form of completion that's only activated on demand. A file dialog without this is just plain fatally flawed. Make it a configuration option, if you like. Just stick the text entry box with tab completion anywhere on the dialog -- I really don't care where, as long as it's part of the dialog, not some silly pop-up box, and I don't have to do something each time that I want to activate it (since I'm personally going to use the text entry box every time I want to open a file, even one extra keystroke or mouse gesture adds up over time, while if it's a configuration option I only have to do it once). My first experience with the new configuration dialog was absolutely brutal. I couldn't believe that I was being presented with a file dialog that had no text entry box (I spent a while exploring it to try to find the button that would give me the entry box), and given the way I jumble everything together, searching around in a list entry is hopeless (I have about 1000 files in one directory; I know a lot of the filenames by memory, but being forced to do a linear search through that many files is simply absurd). I more or less stopped using the GIMP altogether for a while; I used Cinepaint or xv (!) despite it being obsolete in many ways where I could, and otherwise started a new instance of the GIMP each time I had to use it, because dealing with the file dialog was so hopeless. Eventually after poking around Google I found the ctrl-L hack, but it's still very clumsy compared to the simplicity of a text entry box. Bookmarks are of no use to me because I have a lot of files that I work with whose names I generally know by memory. They don't scale; after you have more than maybe 10-20 of them it runs into the same problem of searching, whereas my memory for my own images is associative (reasonably close to constant time lookup). I'm also absolutely hopeless at maintaining any kind of organization of this kind. Anyone who tells me that I should organize my files differently will be told (politely or otherwise) to fsck off. I've used emacs for over 20 years (hence the preference for a simple filename entry with tab completion), and this form of organization for much longer than that (long before I knew what a computer was), and this way of working is by now completely ingrained into me. I'm a slob who simply dumps things wherever it's convenient. In addition to having to remember where files were, if I were to reorganize everything I'd have to mess around with kimdaba for a while to get everything back to how I have it. I've read some of the stuff on the GNOME mailing lists, and quite frankly I can't believe what I see there (e. g. file dialogs should go away, and everything should be done through the file manager or some such). This is design for its own sake rather than design for what's actually usable. I have half a mind to do a fork of GTK+ just to fix the file dialog. This would really be an insane thing for me to do. I really need to put my very limited free software time into Gutenprint, or at least dcraw, not this. If I'm so exasperated by the file dialog that I
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Date: Mon, 20 Jun 2005 11:14:03 +0200 (CEST) From: Dennis Bjorklund [EMAIL PROTECTED] On Mon, 20 Jun 2005, Marc wrote: One thing is that people, and _many_ people, just want their location entry back, for lots of reasons: discoverability, pastability and so on. But for some reason this simply does not happen. Do you want this only in gimp or in all programs that use the gtk+ widgets and dialogs? Obviously this is a GTK2 issue. Currently not everyone is happy with the new dialog but hopefully it can be improved so most of us are happy in the future. If not, then what do you suggest? Either way you choose someone will be unhappy. Adding a simple file (text) entry box with tab completion (and a preference to turn on autocompletion) would, IMHO, solve virtually all of the problems. People who don't like using text entry boxes wouldn't have to use it. The ctrl-L popup has lots of problems; not only is it not apparent how to get to it (there's nothing that points at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type in the filename -- while having to deal with its quirks -- and then click OK twice). And no, bookmarks are NOT a complete solution to this. I have probably 200 bookmarks in Firefox (for example), and finding the right bookmark in the list takes a while (I have to scan through the list and find the one I want). As far as images go, I currently have about 70 directories with images (65 subdirectories for my digital camera, and some miscellaneous ones). The camera ones have 100-200 each (in a lot of cases I have two copies of each image, one the JPEG file extracted from the raw image and another one converted using my hacked-up dcraw), and a couple of the others have 1000 each. Navigating through all of this is a real pain; the ones I'm most interested in I simply memorize. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP
Date: Mon, 20 Jun 2005 13:59:44 +0200 (CEST) From: Dennis Bjorklund [EMAIL PROTECTED] The ctrl-L popup has lots of problems; not only is it not apparent how to get to it (there's nothing that points at ctrl-L), but it's very clumsy to use (you have to type ctrl-L, type in the filename -- while having to deal with its quirks -- and then click OK twice). No one say that the CTRL-L is any good. It's just a workaround for those of us that are used to tab completion, until we have something better. I hope it can work as explained above in the future. Unless they've changed it further, you still don't have the text entry box visible. and find the one I want). As far as images go, I currently have about 70 directories with images (65 subdirectories for my digital camera, and some miscellaneous ones). Maybe you need one bookmark to the parent and not 65 bookmarks to all subdirectories, I don't really need bookmarks at all for this. I simply want to type /images/dcim/138canon/crw_3888.jpg (to identify a particularly interesting photo of a sunset in Bermuda, for example) without the dialog trying to helpfully (and slowly) autocomplete through all of that mess and without having to open a second, modal dialog (I thought that modal dialogs are supposed to be really bad juju?). Actually, the more common issue I deal with as Gutenprint lead developer is that I print an image named colors4.tif to a file (usually I name it /tmp/b.prn). I then run a command named unprint to generate a .pnm file from the output: unprint /tmp/b.prn /tmp/b.pnm following which I want to inspect that file (to see the effect that changes I've made to the Gutenprint source have made certain changes to the output, without having to waste a lot of ink and paper). The problem here is that colors4.tif lives in /images, so if I open a file from that context, I'm in /images whereas I really want to open a file in /tmp (as you can guess, a file named /tmp/b.pnm can be opened very quickly with 11 keystrokes if the dialog doesn't get in my way). A variation I might do is to look at just one color plane. While working on the Epson Stylus Photo R800 with its red and blue inks, for example, I might want to see the effect that changes in this code have on the red ink generation: unprint -m 100 /tmp/b.prn /tmp/b100.pnm or even for f in 1 2 4 8 100 200 ; do unprint -m $f /tmp/b.prn /tmp/b$f.pnm to get individual PNM's of each color plane separately (needless to say, I don't retype that command each time; I use ctrl-p in bash for that purpose). Since /tmp is usually full of all kinds of garbage, scrolling around in there in the new dialog isn't much fun. I sometimes use Cinepaint (taking the hit in extra memory consumption from having both the GIMP and Cinepaint running at the same time) to view these files just because the GTK2 dialog is so unwieldly for my purpose. Again: adding a simple text entry box for the filename, with tab completion but not autocompletion, would entirely solve my problem here! Navigating through all of this is a real pain; the ones I'm most interested in I simply memorize. Right, and I make bookmarks of the places I use the most. Anyway, what I said was just that going back to the old dialog removes the bookmark feature that I use a lot. So no matter if you use the new or old dialog one of us will be unhappy. Not that going back seems to be an option, but if it was I would be against it. I have no problem with bookmarks, but I just don't think they're a panacea. The reason I mentioned bookmarks is that the various bug reports, mailing list discussions, etc. seem to promote bookmarks heavily. For my purpose (at least with the GIMP) they're not useful. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [EMAIL PROTECTED]: Re: [Gimp-developer] FAQ (-: sooner or later :-) KDEification of GIMP]
From: Sven Neumann [EMAIL PROTECTED] Date: Mon, 20 Jun 2005 00:40:37 +0200 If you want details then exactly as in gtk+-1.0 should suffice, because that dialog simply worked. No extra window, no slow extra popups that you have to wait for, no fancy and distracting _hiliting_, no stealing of the current selection etc. etc. Basically I want to be able to blindly enter paths as I could with gimp-1.0, press enter and presto - saved or loaded, with no other die effects. Perhaps you should stop looking at the dialog and just blindly enter paths. It works surprisingly well. Did this change in GTK 2.6? In GTK 2.4, I tried doing precisely that. I typed ctrl-O while in an image named colors4.tif; I tried to type skier.tifenter and got another copy of colors4.tif. I don't much mind blindly entering paths, as long as I can see what I'm typing in case I make a mistake. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 48 Bit Tiff for the Gimp
From: Dr. George W. Oprisko [EMAIL PROTECTED] Date: Tue, 31 May 2005 07:30:16 +0800 Hello everyone ! I am an old systems engineer, who began on IBM1130's in 71. Started with Unix Version 7 in 81. Lots of C later C++. I made my living creating user interfaces with the X11R6 widget toolset. I need 48 bit Tiff to manipulate my thousands of photos from the current trip around the world. I stopped here in Shenzhen, China to make a few bucks, to pay my way on to Europe. The University has been good to me, and this year I will be teaching operating systems and Industrial Automation and Systems Engineering. You might want to try Cinepaint (cinepaint.sourceforge.net). It's based on an old version of the GIMP, but it does CMYK and high bit depths. I also need sane-backends to recognize my Nikon 5000 ED scanner, but that is not so critical since VueScan works. I have a Coolscan V. I need to get back in touch with the maintainer about this. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gutenprint 5.0.0-beta4
Welcome to Gutenprint 5.0.0-beta4! Please read these release notes carefully. Gutenprint, formerly named Gimp-Print, is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and 10.3) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. The package has been renamed in order to clearly distinguish it from the GIMP. While this package started out as the Print plugin for the GIMP, it has expanded into a collection of general purpose printer drivers, and the Print plugin for the GIMP is now only a small (but important) piece of the package. Furthermore, the name Gutenprint recognizes Johannes Gutenberg, the inventor of the movable type printing press. Finally, the word guten means good in German. Gutenprint 5.0.0-beta3 is the third beta prerelease of Gutenprint 5.0. It is based on the Gimp-Print 4.3 series that has been in development for over two years, and includes many improvements over the very popular 4.2 series. This release is not considered to be a fully stable release (there are still various things in flux, and it has not undergone the extensive testing that is required to declare a release stable), but we've been using it and we believe that it will be useful for many purposes. Gutenprint currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line, or the GIMP 2.0 or 2.1. You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes, in particular the Exceptions and Workarounds, for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gutenprint provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gutenprint as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar) and 10.3 (Panther) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. * Major changes between Gutenprint 5.0.0 beta 3 and Gutenprint 5.0.0 beta 4: 1) The Foomatic data generator and ijsgutenprint (the Ghostscript driver) now works correctly and supports the full range of options. However, due to Foomatic limitations, additional steps may be required to install the data and generate correct PPD files. Please read these instructions carefully if you decide to use Foomatic with Gutenprint 5.0.0-beta4. * The Foomatic driver is now named gutenprint-ijs.5.0. When you use foomatic-compiledb, foomatic-combo-xml or foomatic-ppdfile, you must specify the driver name appropriately. This permits installation of multiple releases of Gutenprint on the same system. * Before installing Gutenprint 5.0.0-beta4, you must manually remove any existing Foomatic option files. This is because the Foomatic utility to load data kits (foomatic-kitload) does not remove obsolete data
Re: [Gimp-developer] [Patch] Speed up blending code
From: Daniel Egger [EMAIL PROTECTED] Date: Sun, 27 Feb 2005 16:03:14 +0100 this is my suggested patch for getting the speeds improvements as mentioned in the other thread by having a thread-local PRNG initialized with a seed from the still existing blend tool local RNG. It looks bigger than it is because I took the liberty to remove the nasty special casing on the existence of the RNG inside the innermost loop because we now have it outside already. There seems to be more room for obvious optimisations in the loops. Also I would recommend splitting the two cases into two separate functions to make the code easier to read, and remove more conditionals. PS: If this is okay, I'd do exactly the same for the gray blending stuff... In addition to being very slow, this will also yield noisy results. There are a lot of dither algorithms that are both much faster and yield better results. While you may not need full-blown Floyd-Steinberg or EvenTone dithering for this purpose (and they're hard to use in a multi-threaded fashion), a simple dither matrix is fast, free of most artifacts, trivial to parallelize (you're only reading from the matrix, so no serialization is necessary), and reasonably low noise. In Gutenprint we have several precomputed matrices, designed for 1:1, 2:1, and 4:1 aspect ratios. You would need only a 1:1 ratio matrix. Also, our matrices are large (about 64K elements each, since they need 16 bit resolution), but you wouldn't need anything that big. There's a very simple iterated matrix that can generate any desired power of 2 matrix size (which makes for even faster lookup), but it does suffer from patterning. That may not matter for this purpose, since the steps are very small. We use the same matrix for all color channels, but offset the starting address for each channel to decorrelate the channels. Let me know if you're interested. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Patch] Speed up blending code
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 27 Feb 2005 17:29:52 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: We use the same matrix for all color channels, but offset the starting address for each channel to decorrelate the channels. Let me know if you're interested. Yes, we are interested. I'd really like to get rid of the random number generator in the gradient blend code. It is simply way too slow and gradient blends are a rather frequent operation. OK. The code Daniel posted shouldn't be too hard to convert. The only thing it needs is to have the absolute row and column, to index into the matrix. Please have a look at the current code in CVS (will take a day for anoncvs to catch up). It is a lot more readable and should allow for easy replacement of the RNG by a dither matrix. Will I be able to compile it against a current (stable) GIMP installation? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 06 Feb 2005 14:48:03 +0100 Hi, Carol Spears [EMAIL PROTECTED] writes: i am curious to see what changes having gtk+-2.6 bring to poor gimp. many of the problems with the 2.4 fileselector get shoved off because of this great thing called gtk+-2.6. can we see a screen shot or even several of the new things? There are no changes in the GTK+-2.6 fileselector that would be visible on a screenshot. What has been improved is that a couple of keybindings have been added and some of the focus problems have been eliminated. These changes improve usability of the file chooser a lot and I think that it can now really be called an improvement over the old GtkFileSelection widget. But of course you will disagree with me. I thought it was supposed to allow actually typing in a filename? The really bad point of the 2.4 file selector is that (at least as far as I can see) it only allows selecting a file, not typing the pathname (at least, I don't see any text entry box!) -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 06 Feb 2005 14:57:59 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: I thought it was supposed to allow actually typing in a filename? The really bad point of the 2.4 file selector is that (at least as far as I can see) it only allows selecting a file, not typing the pathname (at least, I don't see any text entry box!) The GTK+ 2.4 file-chooser already allows you to type in a filename after you press Ctrl-L. In GTK+-2.6 however you just start typing and navigate to the file using the typeahead feature of the treeview. You will only sometimes need to use the Ctrl-L popup. That's terribly obvious :-( If the entry box isn't visible, how is anyone to know that you can actually do this? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 06 Feb 2005 16:19:14 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: That's terribly obvious :-( If the entry box isn't visible, how is anyone to know that you can actually do this? You can do that in all treeviews (at least all treeviews that set a search column). This is something that the user has to be told once but since it's available all over the place, that shouldn't be much of a problem. Every other file dialog I've ever seen has a visible entry for typing in a filename. It's not clear to me why there's any advantage at all to not having it visible. It just seems like a gratuitous incompatibility. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 05 Feb 2005 15:16:56 +0100 Hal V. Engel [EMAIL PROTECTED] writes: I have also tried installing GTK 2.4 on SuSE 9.1 without success. I have not tried 2.6 yet. SuSE 9.1 comes with GTK 2.2.4. Many things stop working when GTK 2.4 is installed and it appears that many applications would need to be rebuilt to get things working again. You are doing something wrong then. The GTK+-2.x series provides binary backward compatibility. Applications compiled against older versions of glib/pango/gtk+ will continue to work after an upgrade. There's no need to recompile anything. And this is not just a myth, it definitely works. I am running a GNOME desktop where almost everything was built against gtk+-2.4.x. As promised, upgrading to gtk+-2.6 didn't introduce any problems whatsoever. This doesn't mean that there's necessarily a problem with GTK+ per se, but it does seem to be a bit tricky to compile GTK on SUSE 9.1. In particular, take a look at the .srpm's from the SUSE distribution to see if there are any patches included, and make sure to apply those to the 2.6 tarballs. SUSE is a great distribution, but they do have a somewhat unfortunate habit of making changes that don't always preserve compatibility. I ran across an example recently with a (small) change they made to Qt and an accompanying change to KDE that would have made it impossible to run their KDE RPM's against Qt built from Trolltech's sources. Not saying that that's the case here, but it should be investigated. There could be plenty of other reasons why, of course. But it isn't FUD for people to report that they're having problems compiling and running GTK 2.6 against a particular distribution. Multiple people reporting the same thing suggests there's an issue, but doesn't pinpoint where it is. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
BTW, I just dropped a note to James Ogley (maintainer of usr-local-bin) to see if he has any plans to upgrade his stuff to gtk 2.6. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Sven Neumann [EMAIL PROTECTED] Date: Sat, 05 Feb 2005 18:36:29 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: There could be plenty of other reasons why, of course. But it isn't FUD for people to report that they're having problems compiling and running GTK 2.6 against a particular distribution. Multiple people reporting the same thing suggests there's an issue, but doesn't pinpoint where it is. I am only asking that you show us what problems exactly you have when building gtk+, so that we can help you to solve them. Saying that there are a lot of problems doesn't help at all and is what I would consider spreading FUD. We are trying to move GIMP development along and we will need to use GTK+-2.6 to make this happen. So it should be our goal to make sure that all developers update glib and gtk+. Telling them that this update will cause problems, but not saying what problems these are, doesn't help anyone. It's been a while since I tried it (when GIMP 2.2 came out), so I don't remember for certain what happened. It may have even been something getting confused about /usr vs. /usr/local (in which case it wouldn't be a GTK problem at all), but I honestly don't remember. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Hal V. Engel [EMAIL PROTECTED] Date: Sat, 5 Feb 2005 17:46:17 -0800 I probably should have said that I believed that the problems I had=20 with GTK 2.4 were likely caused by the RPMs I was using (user local=20 bin) as I had not tried building it myself. So this is a SuSE 9.1=20 specific problem. There have been some rather lengthly discussions=20 about this on a SuSE forum that I frequent and some users are able to=20 install this using these RPMs with no problems and others encounter=20 significant problems. It appears to be about 50/50 odds. No one=20 seems to know why. =20 Interesting. I had no problem with the usr-local-bin RPM's for GTK 2.4. BTW, are you running KDE? One thing that comes to mind is that by default in SUSE KDE installs a GTK theme; you can try turning that off by creating a file (zero length is fine) in your home directory named .no-qtrc-to-gtkrc-mapping (no quotes, of course). As it happens, I'd really like to run GTK 2.6, if for no other reason than the horrible browser dialog in 2.4, and perhaps it's worth trying again. Also I was not asking that you stop moving forward as I specificly said=20 in my earlier note to not worry about my problem and to go forward. I=20 will try building 2.6 from source in the next few days and if I run=20 into a problem I will ask for assistance. Agreed -- I consider Sven's note to be an FYI and I certainly don't think that my comment should have been interpreted as asking Sven not to do this. It was just a comment since I noticed other people using SUSE 9.1 having problems with this. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] CVS HEAD dependency on glib-2.6 / gtk+-2.6
From: Hal V. Engel [EMAIL PROTECTED] Date: Fri, 4 Feb 2005 13:24:30 -0800 --nextPart10261261.yohHSzoVkz Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Thursday 03 February 2005 23:27, Tino Schwarze wrote: snip =20 Just for your consideration: I failed to install GTK 2.6 on a SuSE=20 9.1 machine. A lot of weir things happened (fonts were not being found,=20 gdm crashed, some unresolved symbol XineramaIsActive etc.). I had to=20 remove GTK 2.6 and GLIB 2.6, to get a usable system again. =20 I'm not a developer, so this is not an objection, just a note. =20 Bye, Tino. I have also tried installing GTK 2.4 on SuSE 9.1 without success. I=20 have not tried 2.6 yet. SuSE 9.1 comes with GTK 2.2.4. Many things=20 stop working when GTK 2.4 is installed and it appears that many=20 applications would need to be rebuilt to get things working again. I=20 am considering installing SuSE 9.2 as it comes with GTK 2.4. Wish=20 there was a better way to deal with these libraries. But again don't=20 stop moving forward on my account. I was able to install GTK 2.4 from usr-local-bin.org, but they don't have 2.6 up at this time. I recall having a lot of problems trying to compile either 2.4 or 2.6. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Wed, 19 Jan 2005 09:32:15 -0800 From: William Skaggs [EMAIL PROTECTED] Hi Raphael, glad to hear from you. Although I am a bit late to the party, here are my 2 cents: I think that the jpeg plug-in should automatically rotate the image when opening it without marking it as dirty. The default setting should be to do that automatically without asking, both for interactive and non-interactive mode. Let me try to explain why... In an ideal world I agree that this would be the right answer. What concerns me is that in this less-than-ideal world, many people are likely to have images with incorrect exif data, including anybody who edited a rotated exif jpeg in GIMP 2.0 or 2.2 and then resaved it as jpeg. It's hard to get a fix on how large a population this is, but I bet if we impose a solution on them that rotates their images without giving them any way to prevent it, we'll be subjecting ourselves to some angry bug reports. Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? Raphael's proposal sounds right on the money to me. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Thu, 20 Jan 2005 01:32:44 + From: Alastair M. Robinson [EMAIL PROTECTED] Hi Robert, Robert L Krawitz wrote: Won't they have (already be having) exactly the same problem with any other EXIF-aware viewer or editor? I doubt anyone who's encountered this issue opening files in other programs will have twigged that GIMP caused it :) Probably not, but with correct EXIF behavior it should behave the same as any other EXIF-aware apps. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif continued
Date: Thu, 13 Jan 2005 12:29:15 -0800 From: William Skaggs [EMAIL PROTECTED] On loading an exif-jpeg file, it (1) calls gimp_metadata_store_exif(), and (2) extracts the orientation from the exif and, if it is not top-left, queries the user whether to rotate the image. I know I've been making a nuisance of myself about this, but PLEASE at least provide a way to turn this query off. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
From: Daniel Egger [EMAIL PROTECTED] Date: Mon, 10 Jan 2005 17:44:41 +0100 On 10.01.2005, at 16:52, Jakub Steiner wrote: Unless I'm being told untruth about the losslessness (soundss great, doesn't it?), the metaphor of not messing around with negatives isn't appropriate. It depends very much on how clever the tools are regarding the EXIF information; if an image is rotated the EXIF information must be at least passed trhough to the new file if not even changed appropriately. Gthumb for one application (have the authors fixed this?) truncated the EXIF data when doing a lossless transformation so this was very much for the trashcan I for one have been bitten seriously by this and since then keep the images as an umodified original from the camera except for the filename. There's a good reason *right there* not to trust software that does any transformation on a master file. I'm not accusing the authors of exiftran of being sloppy, but the possibility of a latent bug does exist (and it's much greater than the possibility of a latent bug in cp or the like -- and when I do backups, I do verify them carefully, and use quality memory and the like!). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Sat, 8 Jan 2005 11:24:49 -0800 From: Akkana Peck [EMAIL PROTECTED] Sven Neumann writes: Assuming your camera adds EXIF info, are you seriously telling me that you do not run 'exiftran -a -i' on each and every image you ever shoot and instead use GIMP to rotate them? Add another voice to all the others saying No, I leave my originals untouched, and only edit copies. Unfortunately, thus far you and I are the only ones taking this position. I can't speak for every single photographer in the world, but as a matter of general principle, you don't mess with your negatives. The one thing I do to them is chmod 400 so I don't accidentally write over them. However, I use kimdaba (which is EXIF-aware) to index them. If I want to edit a particular image, I'll read it into the GIMP (which I can do from right-click in kimdaba), save it elsewhere (that's why the chmod 400), and then start editing it. If a particular application isn't EXIF-aware, tough on it. The ones I care about are kimdaba, the GIMP, and Photoprint, when it's ready (which one of the Gimp-Print developers is working on). Having to dismiss a completely irrelevant warning every time I want to edit a digital photograph is simply annoying. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
From: Hal V. Engel [EMAIL PROTECTED] Date: Sat, 8 Jan 2005 14:09:29 -0800 You can add me to the list. I also leave my originals alone. As you=20 say this is just good photographic practice. I have negatives that=20 are almost 70 years old that are in nearly new condition that I got=20 from my fathers photo collection before he died and I have my own=20 collection of negatives and slides that goes back about 45 years. All=20 have been carefully stored and are only touched to make=20 copies (digital now days). My brother is a professional=20 photographer and he also leaves his digital originals alone and only=20 edits copies. I am sure that there are others on this list that also=20 agree but have not said so on the list. In any case I don't see any=20 reason to not do the same with digital originals.=20 It occurred to me that there's another reason not to change so much as a single bit of images: the ability to verify that an original is indeed an original. Some cameras, such as the Canon EOS 1D Mark II, are capable of signing the image, so that it can be verified that the image is unmodified. See http://consumer.usa.canon.com/ir/controller?act=ModelFeaturesActfcategoryid=139modelid=9808#f3. Changing the image in the slightest -- including a lossless rotation -- would destroy this signature. Someone with this camera who needs to be able to verify photographs (perhaps because they're being used as evidence in court) could not use exiftran. Someone may want to preserve that signature, while still editing the photograph and saving it under a different name. The basic point here is that changes to the original digital file are *irreversible*, no matter how minor one thinks they may be. Photographers don't like making even the smallest irreversible changes to their master images, for good reason. I've given a specific reason, in addition to the general reason. Please don't do anything that makes life difficult for photographers who wish to perfectly preserve their originals! -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
From: Sven Neumann [EMAIL PROTECTED] Date: Thu, 06 Jan 2005 18:49:17 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: My policy is to never muck with the original -- PERIOD. Yes, I could always make copies, but that would use more disk space. This is a standard photographic policy. You don't muck with your negatives. Well, that's your point of view then and you have to live with the consequences. I should think any serious photographer would take the point of view that you never mess with your negatives... Do you have any other suggestion for preserving the rotation information? The obvious question is: if the rotation information isn't important, why does the camera even bother with it, as opposed to doing the rotation inside the camera? Why does EXIF even have a rotation tag if it's useless? One reason that comes to mind is to study the lighting after the fact; knowing what the original rotation was can be helpful in some cases. You are completely right. The camera should do the orientation and EXIF should have an orientation flag that refers to the original orientation. Unfortunately early digital cameras were not able to do the rotation. Nowadays there's really no good reason for this behaviour. That's all well and good, but why force your viewpoint on other people? ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Wed, 5 Jan 2005 07:47:10 -0800 From: William Skaggs [EMAIL PROTECTED] Robert Krawitz wrote: 4) When the exif specifies that an image is rotated, the plug-in pops up a query asking the user whether to rotate it into standard alignment. I thought it was better to ask rather than do it automatically, because there are probably a substantial number of existing images that have been edited without having their exif information properly updated (for example, by earlier versions of GIMP). When an image is saved with exif, the orientation is set to top-left, as the exif specifications require. (See bug #121810) I'd suggest making this a preference. If someone's careful about maintaining their images (or hasn't edited them before), they'll get very annoyed by having to answer this question every time they open an EXIF file that's rotated. Wouldn't earlier versions of the GIMP have destroyed the EXIF data? That would be a reasonable thing to do: Rotate images if exif says so?: _Always _Never _Ask each time. But we have a high threshold nowadays for adding new preferences, so this is something that probably won't happen until it's clear that a lot of people want it. Something that forces me to do an extra gratuitous step for loading every portrait I ever shoot is a massive pain in the butt however you slice it. Another way of handling this would be to show the message, but have a check box Don't show this message again. Firefox has this for a lot of the security warnings (like warning you if you fill in a form that's posted over the net). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg-exif development summary
Date: Tue, 4 Jan 2005 09:53:01 -0800 From: William Skaggs [EMAIL PROTECTED] 2) The jpeg plug-in now pretty closely adheres to the instructions in the exif specifications concerning which fields should be altered by an image-editing program. There are a couple of fields remaining that I haven't yet figured out how to set properly. There is now a file called exif-handling.txt in devel-docs that summarizes my understanding, based on the exif specifications, of how an image editor is supposed to handle the exif data in a file. Of course we need not take the specifications as gospel (among other things, they specify that a proper EXIF file must have a file name in 8.3 format, ending in .JPG!), but they should serve as a good default. Adobe at least had an excuse with PPD files 10 years ago. There's no excuse for 8.3 any more. 4) When the exif specifies that an image is rotated, the plug-in pops up a query asking the user whether to rotate it into standard alignment. I thought it was better to ask rather than do it automatically, because there are probably a substantial number of existing images that have been edited without having their exif information properly updated (for example, by earlier versions of GIMP). When an image is saved with exif, the orientation is set to top-left, as the exif specifications require. (See bug #121810) I'd suggest making this a preference. If someone's careful about maintaining their images (or hasn't edited them before), they'll get very annoyed by having to answer this question every time they open an EXIF file that's rotated. Wouldn't earlier versions of the GIMP have destroyed the EXIF data? 2) Exif is not relevant only to jpeg: it can appear in TIFF and Raw files, and there are draft standards for including it in PNG and other file types. I would like to extract the generic parts of the exif handling code for jpeg-exif.c and place it into a new library for generic file-handling code, libgimpfile, which we have discussed creating some time ago (see bug #139354). The file jpeg-exif.c will still however need to exist, because the exif specifications require some different fields for compressed (jpeg) vs uncompressed (tiff) exif files. FYI, Canon raw (.crw) files have an embedded JPEG file, but the EXIF information is stored in both the raw file and in a thumbnail (.thm) file with the same basename. The .thm file is actually a JPEG file with embedded EXIF data. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --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 http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-print with 2.2.0?
___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] gimp-print with 2.2.0?
Date: Mon, 20 Dec 2004 12:16:37 +1300 From: Jonty [EMAIL PROTECTED] Is there a problem using gimp-print 5.0.0 with gimp 2.2, or is this a configure problem? checking for gimpprint-config... /usr/bin/gimpprint-config checking for GIMP-PRINT - version = 4.2.0... *** GIMP-PRINT header files (version 5.0.0) do not match *** library (version 4.2.1) The Print plugin distributed with the GIMP is based on the Gimp-Print 4.2 API, since we (Gimp-Print) didn't get to our 5.0 release in time for the GIMP. Therefore, what you should do is compile the GIMP without a Print plugin and then build the Gimp-Print package to get your print plugin. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Why not allow the name to be configurable?
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 12 Dec 2004 18:05:46 +0100 Alan Horkan [EMAIL PROTECTED] writes: I have to ask why reject such patches? Because IMO the name is important. If we allow the name to be changed easily, our users will not any longer know what software they are using. Contributors will be lost because they will look for the Foo project instead of the GIMP project. It would also make it way too easy for anyone who wants to make some quick money out of The GIMP. We must not allow people to change the name by means of a simple configure option and let them benefit from our hard work. Changing the source code and documentation is the easiest part of it. The hard part is changing the web site, references all over the net, etc. I speak here from ongoing experience -- the Gimp-Print project is in the process of renaming to Gutenprint. Changing the source took Roger Leigh perhaps a week or so, but the web site, hosting, etc. are still moving along very slowly, and we have a lot of work to do. This is probably the primary reason that 5.0 wasn't released perhaps a month ago. If a project as big as Mozilla Firefox allows it name to be changed, why would it be an issue for the gimp? For Firefox having the name configurable is part of the business plan. I can't find any such note in the GIMP's business plan. Heck, I can't even find the plan. Firefox had a little legal problem on their hands, and didn't have much choice. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP 2.2
From: Sven Neumann [EMAIL PROTECTED] Date: 06 Sep 2004 17:52:20 +0200 a while ago we decided for a feature freeze for GIMP 2.2 that should have taken effect last week. I haven't enforced this feature freeze yet because there's been some good hacking going on recently and I think we definitely wanted to have these features in 2.2. With the 2.1.4 release, we've reached a point where the new stuff (GimpProgress, GimpPreview) seems to be rather well working so we could declare a feature freeze right now. I do think however that we should give us a little bit more time and try to get the following done during the next weeks: - add more plug-in previews - try to make the previews scale with the dialog - implement color management as was discussed earlier - fix unit handling and resize / scale dialogs - allow for better layer positioning / alignment - integrate the metadata editor that Raphael is working on - finish and fix whatever is unfinished or broken I would suggest we attempt to get a 2.2 prerelease out by the end of this month or early in october. Given the fact that the tree is fairly stable, we should then be able to deliver 2.2.0 by the end of october. Please comment on this proposal if you disagree with it or think there are important features missing that you are already working on. I'd like to get a decision on what to do with the print plugin. We (Gimp-Print) are in 5.0 beta, and I'd like for the GIMP 2.2 to use a 5.0-based plugin rather than a 4.2-based one. The Gimp-Print source tree has a GIMP 2.x-based plugin. There has been discussion about transferring ownership to the GIMP, and if this is going to happen it should be done soon. If it's going to stay in the Gimp-Print tree, it needs a maintainer, since the people who have been doing it aren't really GIMP experts nor UI programmers in general. Particularly if there is to be color management in the GIMP, we need to look at this carefully. Doing 8 bit-8 bit color transformations prior to printing will yield quality problems that could be solved with 8 bit-16 bit transformations, as Gimp-Print can handle 16 bit input. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 5.0.0-beta2
Welcome to Gimp-Print 5.0 Beta 2! Please read these release notes carefully. Gimp-Print 5.0.0-beta2 is the second beta prerelease of Gimp-Print 5.0. It is based on the 4.3 series that has been in development for over two years, and includes many improvements over the very popular 4.2 series. This release is not considered to be a fully stable release (there are still various things in flux, and it has not undergone the extensive testing that is required to declare a release stable), but we've been using it and we believe that it will be useful for many purposes. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and 10.3) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. Gimp-Print currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line, or the GIMP 2.0 or 2.1. You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes, in particular the Exceptions and Workarounds, for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gimp-Print provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar) and 10.3 (Panther) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. The README file included with this package provides full instructions on building and installing Gimp-Print. These release notes contain the following sections: 1) Changes from 5.0.0-beta1 to 5.0.0-beta2 2) Overall changes from 4.2 to 5.0. 3) List of supported printers 4) Printer-specific notes * Major changes between Gimp-Print 5.0.0 beta 1 and 5.0.0 beta 2: 1) Color generation has been adjusted to improve tonality. The result should be more definition in the highlights and shadows and overall lighter tone without reducing maximum density. This has been tested on some Epson printers, but has not been comprehensively tested. Please report any issues you may find. Note that this change invalidates any profiles generated for earlier versions of Gimp-Print. It is likely that additional changes will be made prior to 5.0 final release. 2) Printing direct to CD on Epson printers that support it now works. In addition, a choice of center hole size (16 mm or 43 mm) is now offered. A fine adjustment is provided to permit control over positioning of the image on the CD. This fine adjustment setting is not available in the Foomatic interface at present. It is likely that this support will be further enhanced prior to final release of 5.0. 3) Additional dye sublimation printers (Canon CP-220 and CP-330, Olympus P-200 and P-400) are
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Aug 2004 12:53:25 +0200 Hi, Robert L Krawitz [EMAIL PROTECTED] writes: GIMP has all this already, why would you want to deal with units in a library such as gimp-print? Two reasons: 1) Gimp-Print covers more than just the GIMP -- there's also the CUPS driver, the Ghostscript IJS driver, and Foomatic, in addition to a few third party apps. I suggest to leave it up to the application that uses gimp-print then. Any application that uses units in it's user interface will have a framework to deal with units. If you add your own framework to gimp-print you are only making things more complex. Right. The problem is how the application determines whether a particular parameter is a measurement or just an arbitrary floating point number. The only piece of framework that Gimp-Print's going to have is a new parameter type that's a unit rather than a dimensionless floating point or integer number. How the application deals with that is up to it. Basically it sounds like we're in reasonable agreement here. 2) The dimension type tells the user interface to treat this parameter specially (display it in units of the user's choice). Any length parameter in GIMP is measured in pixels and if there's resolution information, the user is given the opportunity to use arbitrary units to specify it. The underlying code still sees nothing but pixels. I don't see why the underlying code (in this case gimp-print) would have to know about this. That's an issue for the plugin to deal with. Gimp-Print deals entirely in points (1/72), and it's up to the application to translate that into units useful for people. In the future we may extend Gimp-Print to allow other fundamental units of measure, because 1/72 may not be fine enough. This can be done compatibly (make the default be 1/72, and provide a way for an application to specify a different base unit). But that's neither here nor there right now. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
From: Sven Neumann [EMAIL PROTECTED]
Date: 15 Aug 2004 02:39:20 +0200
Robert L Krawitz [EMAIL PROTECTED] writes:
Right. The problem is how the application determines whether a
particular parameter is a measurement or just an arbitrary floating
point number. The only piece of framework that Gimp-Print's going to
have is a new parameter type that's a unit rather than a
dimensionless floating point or integer number. How the application
deals with that is up to it. Basically it sounds like we're in
reasonable agreement here.
Yes, sounds like it. Perhaps it would be easier to speak in terms of
code snippets...
From the libgimpprint standpoint, it's simply a matter of adding
STP_PARAMETER_TYPE_DIMENSION, along with the appropriate bounds and
defaults members to stp_parameter_t.
typedef enum
{
STP_PARAMETER_TYPE_STRING_LIST, /*! Single string choice from a list. */
STP_PARAMETER_TYPE_INT, /*! Integer. */
STP_PARAMETER_TYPE_BOOLEAN, /*! Boolean. */
STP_PARAMETER_TYPE_DOUBLE,/*! Floating point number. */
STP_PARAMETER_TYPE_CURVE, /*! Curve. */
STP_PARAMETER_TYPE_FILE, /*! Filename (NYI, need to consider security). */
STP_PARAMETER_TYPE_RAW, /*! Raw, opaque data. */
STP_PARAMETER_TYPE_ARRAY, /*! Array. */
STP_PARAMETER_TYPE_DIMENSION, /*! Linear dimension. */
STP_PARAMETER_TYPE_INVALID/*! Invalid type (should never be used). */
} stp_parameter_type_t;
That's an issue for the plugin to deal with. Gimp-Print deals
entirely in points (1/72), and it's up to the application to
translate that into units useful for people.
That's fine. As long as there's a clearly specified value, we can deal
with that.
Fine.
--
Robert Krawitz [EMAIL PROTECTED]
Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print --http://gimp-print.sourceforge.net
Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] upadting the print plug-in [was: preparing GIMP 2.2]
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Aug 2004 11:15:38 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: The only API change we're looking at right now is adding dimension-valued parameters. These are like numerical parameters, except that programs should present them in the appropriate units, such as inches, mm, points, furlongs, or whatnot. The short-term reason for this is to allow precise registration of CD's. We could either make the change and then hand it off, or we could hand it off and you could make the change. Since the only real implication of this is for the UI, and it sounds like you're going to overhaul the UI, perhaps we should hand it off first. GIMP has all this already, why would you want to deal with units in a library such as gimp-print? Two reasons: 1) Gimp-Print covers more than just the GIMP -- there's also the CUPS driver, the Ghostscript IJS driver, and Foomatic, in addition to a few third party apps. 2) The dimension type tells the user interface to treat this parameter specially (display it in units of the user's choice). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] preparing GIMP 2.2
From: Sven Neumann [EMAIL PROTECTED] Date: 09 Aug 2004 00:10:48 +0200 I think it's about time to start to discuss what features we still want to get into GIMP 2.2. We are targetting a feature freeze by the end of the month and a release shortly after, so it's probably about time... I'd like to collect a list of changes what we want to see being done for 2.2. We will need people to pick up these tasks and finish them in the next weeks. I will make a start by listing some of the things that I think would be great to finish for 2.2. Please add your wishes and/or take responsibility for some of these tasks. If you want to go into detail about a task that is listed below, please create a new thread for it so we can use this thread for collecting ideas. Gimp-Print 5.0 isn't going to be in final release at that point, but it should be at beta-2 by then, and we've been putting a lot of bug fixes into our tree. I don't think it's as stable as 4.2 yet, but it's not far shy. We should be completely API-frozen at that point. We need to work out handoff of the plugin, as discussed. The only API change we're looking at right now is adding dimension-valued parameters. These are like numerical parameters, except that programs should present them in the appropriate units, such as inches, mm, points, furlongs, or whatnot. The short-term reason for this is to allow precise registration of CD's. We could either make the change and then hand it off, or we could hand it off and you could make the change. Since the only real implication of this is for the UI, and it sounds like you're going to overhaul the UI, perhaps we should hand it off first. I'll be away this week, so don't expect any replies from me until next Sunday or so. Color management This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks. Please copy [EMAIL PROTECTED] on appropriate discussion on this topic. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 5.0.0 beta1
Welcome to Gimp-Print 5.0 Beta 1! Please read these release notes carefully. Gimp-Print 5.0.0-beta1 is the first beta prerelease of Gimp-Print 5.0. It is based on the 4.3 series that has been in development for over two years, and includes many improvements over the very popular 4.2 series. This release is not considered to be a fully stable release (there are still various things in flux, and it has not undergone the extensive testing that is required to declare a release stable), but we've been using it and we believe that it will be useful for many purposes. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and 10.3) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. Gimp-Print currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line, or the GIMP 2.0 or 2.1. You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gimp-Print provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar) and 10.3 (Panther) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. The README file included with this package provides full instructions on building and installing Gimp-Print. * Major changes between Gimp-Print 5.0.0 alpha 3 and 5.0.0 beta 1: 1) We have made several changes to the color generation to yield better results and fix problems. The brightness and contrast controls now function quite differently from before. With RGB or CMY input, the brightness control now adjusts the luminance using an exponential function, and so does not change the black and white points (RFE 619299) or the color (hue and saturation). This yields more expected output when printing to a page. The behavior with grayscale input is equivalent. With CMYK and raw input, however, the brightness control is applied on a per-channel basis. Normally these controls will not be used with CMYK input. In addition, the brightness and contrast controls are now applied separately from the gamma adjustment. Furthermore, the brightness, contrast, and saturation adjustments are made prior to HSL adjustment, and gamma correction after that adjustment. HSL and gamma adjustments are considered to be printer adjustments while brightness, contrast, and saturation are considered to be user adjustments. Consistent with this, the gamma adjustment has been made optional. Finally, color-black generation is now done correctly for RGB and whitescale inputs. 2) An experimental Print plugin for the GIMP 2.0 is now provided.
Re: [Gimp-developer] Bad news about piecewise curves in the Print plugin
From: Sven Neumann [EMAIL PROTECTED] Date: 30 May 2004 12:44:05 +0200 Hi, Robert L Krawitz [EMAIL PROTECTED] writes: Unfortunately, the gtkcurve widget doesn't allow setting the control points of the curve, only setting a dense curve (gtk_curve_set_vector). There may be a back door way of doing it, but that carries obvious hazards. The GtkCurve widget is basically deprecated and scheduled for removal from GTK+. I would suggest that if you need such a widget you simply copy the code and change the namespace. You can then add the API you need. That's good to know. Thanks. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Bad news about piecewise curves in the Print plugin
Unfortunately, the gtkcurve widget doesn't allow setting the control points of the curve, only setting a dense curve (gtk_curve_set_vector). There may be a back door way of doing it, but that carries obvious hazards. There's also no official interface for extracting the control points. The upshot may wind up being that we supply only the dense curve interface to the GIMP plugin. That would be unfortunate. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] static libgimpprintui
Cc: [EMAIL PROTECTED] From: Roger Leigh [EMAIL PROTECTED] Date: Mon, 24 May 2004 01:18:30 +0100 Robert L Krawitz [EMAIL PROTECTED] writes: From: Roger Leigh [EMAIL PROTECTED] Date: Sun, 23 May 2004 14:03:36 +0100 Does anyone know how (for the Debian packaging) I could build it statically? configure allows --enable-shared=lib1,lib2 and --enable-static=lib1,lib2,... but this doesn't work as I'd like: if you say you want a library built one way, it builds every other library the opposite way. For example, if I do --enable-static=gimpprintui, every other library is dynamic only. What I'd like is everything built both dynamically and statically, except for libgimpprintui, which should be static only. I'd like to do that or link print with the static version. The reason for this is that I don't want two extra packages (libgimpprintui1 and libgimpprintui-dev) unless there's actually a use for them, and I don't believe there is at present. Why would it force a separate package? If the library is shared, it needs to be in a separate library package, and the headers and static library need to go in a development package. If it's static-only, I can just link it with the plugin and not package any libraries at all. This isn't strictly required AFAIK, but is the recommended practice, since if the library is packaged with a program, it makes it harder for other packages to depend on it, since you force the user to have the program it is packaged with installed, whether they want it or not (e.g. including GTK+ in the GIMP package). (The point is moot for the 1.2 plugin, since GIMP 1.2 is not available in Debian any longer, but the same might need to apply to the new libgimpprintui, at least initially.) So I think I've finally figured out how to factor the GIMP plugin. This may be of interest to the GNOME and KDE folks, also. Bottom line: the GIMP folks should own src/gimp (the GIMP-specific code), and we should own libgimpprintui (which should be renamed libgimpprint-gtk2 for the gtk2 version). The advantage of this is that we can upgrade the plugin to take advantage of any new features in Gimp-Print (profiles, what have you) without GIMP users having to even recompile the plugin. For this to work, obviously libgimpprintui *must* be dynamic. So what do we need to do for this to be practical? 1) I need to finish what I'm doing, which is what I proposed last week (and nobody took me up on), to clean up the queue-handling stuff. For coding I'm probably 50-75% there. I created a new CVS branch for this. 2) We need to define exactly what the interface is between the GIMP and libgimpprintui (i. e. the stpui layer). This should be a very thin layer, certainly much thinner than libgimpprint and possibly even thinner than what it is now. We may even want to not expose the libgimpprint layer at all to the plugin. Part of this is making the stpui_plist_t opaque, like we've done for the various classes in libgimpprint. Whatever we do, I don't think we're far away here. 3) Roger and/or Jody need to finish their libgimpprintui2/libgimpprint-gtk2 port. If we do this right, then we can change libgimpprint to our heart's content and the GIMP plugin will go merrily on its way, without ever having to be recompiled or relinked. When the GIMP supports 16 bits, only the plugin needs to change, and that would be owned by the GIMP. If we add color management, then as long as we don't rely on the GIMP for any of that there should be no problem. Then when we go to 5.2 or even 6.0 or whatever GIMP users shouldn't have to worry about an upgrade. The KDE and GNOME folks may find this kind of thing interesting. For example, if KDE wants to offer Kimp-Print as an alternate (richer) printing KPart that isn't limited by what PPD files can describe, but can take advantage of Gimp-Print's functionality, they could write their libkimpprint and do the same kind of thing. What do folks think? -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] static libgimpprintui
From: Sven Neumann [EMAIL PROTECTED] Date: 25 May 2004 11:19:10 +0200 your post (and other mails on the gimp-print-devel list) make me believe that there isn't much hope for a stable gimp-print API to appear during the next weeks. Is that right? This means that we have to change our plan to ship gimp-2.2 with an updated print plug-in. It also means that we need to apply the latest user interface changes to the print plug-in also. So far we haven't touched it since it was scheduled for replacement. The core API's pretty close, but we're probably not quite ready to go beta. However, we're not that far off, either. What's your plan for 2.2? This also brings up a problematic point about libgimprint-gtk2. Such a library that includes the complete GUI will make it impossible for us to have a print plug-in with a user interface that is consistent with the rest of the GIMP UI. Of course you could adapt our user interface guidelines (which are basically the HIG with some twists) but we could always change our mind on this with the next GIMP release (just like we just did, GIMP-2.2 will look different than GIMP-2.0). Also other projects using this library might have other ideas about the look and feel. So you can't possibly get it right for everyone unless you use lots of style properties to make every aspect of the GUI themable. Good point. I hadn't thought about that aspect of it; I was looking at it from the Gimp-Print side. Perhaps it would be better to not have the actual user interface in a gimpprint library. If you want to make it easy to write a GTK2 GUI on top of libgimpprint, then you could provide a model on top of libgimpprint that people can easily write a view for. This library could provides GtkListStores for any selection the user needs to make, it could provide a preview widget to position the image on the paper. Basically it would just nicely wrap the libgimpprint API and make it more GTK+ friendly. That would be a possibility. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: [Gimp-print-devel] static libgimpprintui
From: Sven Neumann [EMAIL PROTECTED] Date: 25 May 2004 10:54:00 +0200 Robert L Krawitz [EMAIL PROTECTED] writes: If we do this right, then we can change libgimpprint to our heart's content and the GIMP plugin will go merrily on its way, without ever having to be recompiled or relinked. When the GIMP supports 16 bits, only the plugin needs to change, and that would be owned by the GIMP. If we add color management, then as long as we don't rely on the GIMP for any of that there should be no problem. Then when we go to 5.2 or even 6.0 or whatever GIMP users shouldn't have to worry about an upgrade. I doubt that you can foresee any changes that might be needed in the future so I am not completely sharing your optimistic view on this. But in general it seems like the right thing to do. Nevertheless I'd like to have a look at the proposed libgimpprint-gtk2 API before it's finalized. Could you please post a header file here? Certainly we'll do so if/when we do this (it was a proposal). My hope is that the GIMP isn't going to have a lot of changes that would require changes to this hypothetical libgimpprint-gtk2. For example, if you were to support floating point channel values, the plugin could convert those to 16-bit unsigned integers. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gimp Print --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: Gimp-Print 5.0.0-alpha3
Welcome to Gimp-Print 5.0 Alpha 3! Please read these release notes carefully. Gimp-Print 5.0.0-alpha3 is the third alpha release (technology preview) in the line that will eventually lead to Gimp-Print 5.0. It is based on the 4.3 series that has been in development for two years, and includes many improvements over the very popular 4.2 series. This release is not considered to be a fully stable release (there are still various things in flux, and it has not undergone the extensive testing that is required to declare a release stable), but we've been using it and we believe that it will be useful for many purposes. Gimp-Print is a suite of printer drivers that may be used with most common UNIX print spooling systems, including CUPS, lpr, LPRng, or others. These drivers provide high quality printing for UNIX (including Macintosh OS X 10.2 and 10.3) and Linux systems that in many cases equal or exceed proprietary vendor-supplied drivers in quality and functionality, and can be used for demanding printing tasks requiring flexibility and high quality. This software package includes the Print plug-in for the GIMP and Ghostscript and CUPS drivers, as well as Foomatic data. Gimp-Print currently contains over 200 drivers supporting in excess of 600 printer models. The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the 1.2 line (more recent versions of the GIMP, such as 1.3 and 2.0, are not supported at present). You may need to install packages named gimp-devel, gtk-devel, and glib-devel (or similar equivalents) on many systems. This plug-in will work with any printing system, and offers a comprehensive user interface to control all aspects of the printing process. The CUPS driver requires CUPS 1.1.15 or higher. You may need to install a package named cups-devel or similar on many systems. Please the rest of the release notes for full details on installation, as there is an important caveat. CUPS is the printing system used on Macintosh OS X 10.2 and above, and many other systems use it. The combination of CUPS and Gimp-Print provides a flexible, general purpose printing system capable of producing the highest quality output with any of the printers supported by this package. We strongly recommend using CUPS with Gimp-Print as a general-purpose printing solution. The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher. It uses the IJS package included with these versions of Ghostscript to create a driver that may be built much more easily than traditional Ghostscript drivers. The options for this driver are very complex, and it is normally used with the Foomatic driver integration system. Users of Macintosh OS X 10.2 (Jaguar) and 10.3 (Panther) can use this package, as the printing system is based on CUPS. For ease of installation, a pre-built package with installer is normally supplied a few days after the release of the source package. We highly recommend that OS X users use the pre-built package rather than attempt to build it themselves. NOTE: This package will not work with any version of OS X 10.0 and 10.1 (such as 10.1.5), as those systems do not use CUPS as their printing system. This is NOT going to be fixed; you must upgrade to at least OS X 10.2 in order to use this package. The reason why is that OS X 10.2 and above use CUPS as the basis of the printing system. OS X 10.0 and 10.1 use a different system that would require a separate driver, and we do not plan to write that driver. The README file included with this package provides full instructions on building and installing Gimp-Print. * Major changes between Gimp-Print 5.0.0 alpha 2 and 5.0.0 alpha 3: 1) Borderless printing now works correctly in the native CUPS driver. In previous releases it printed garbage. Note that while borderless printing works correctly in CUPS, the actual prints don't come out perfectly borderless in all cases. 2) A problem manifesting itself as unprinted horizontal stripes within a page has been fixed. 3) A number of crash problems in the Print plugin have been fixed, and potential crash problems in the core library have been fixed. 4) The CUPS driver now prints correctly at 1440x1440 DPI on certain Epson printers. Previously it rendered at 2880x1440, which in addition to being slower could also cause incorrect results on certain types of material. 5) A minor compliance issue in the CUPS PPD files is fixed. 6) Boolean options are handled correctly in the Foomatic data. 7) escputil now returns ink levels correctly on all Epson printers. In addition, it is more robust on printers that it previously worked correctly on. 8) The header files have been reorganized; all header files intended for use by either client programs or modules (such as family drivers) have
