Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
From: Lourens Veen [EMAIL PROTECTED] Date: Tue, 27 Nov 2001 08:12:27 +0100 Last thingy, about professional use of Gimp, isn't this a bit of a chicken-and-egg thing? I can't imagine anyone using a program that doesn't do CMYK, serious halftoning and easy font work (with the added note that my X server crashes regularly on TrueType fonts rendered larger than 100 px or so) for professional print graphics. Having worked together with those professionals quite a bit lately I think Gimp needs to be quite a bit better still. I can imagine professional use of a program without any of these things these days (the font stuff is most likely to be an issue). A lot of printers that get professional use have Mac/Windows drivers that take exclusively RGB data. A more serious issue is the lack of color matching, so that there's no guarantee that what shows on the screen will match what's on the page. -- Robert Krawitz [EMAIL PROTECTED] http://www.tiac.net/users/rlk/ 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/stp -- 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] Suggestion: Active bug list
Hi all. Branko's talk of a bug week got me thinking recently, and I just noticed that one of the few mails which got left in my gimp-developer mailbox (usually RFCs followups, but not in this case) was a mail that Sven sent to the list in June with a list of active 1.2 bugs (the thread was 1.2 Bug Hunting). There were about 10 of the highest-priority bugs, with a 1-line description and a link to bugzilla. Personally it got me lookign at bugzilla (a habit that has since lapsed), and looking at the thread it seemed to lead to the resolution of a fair few bugs. Do people think that doing this on a regular (say monthly) basis would be a good idea? And if so, who would do it? (note that I'm not volunteering - it's just something I was thinking about :) I could be persuaded to, perhaps - or maybe some of the people who've done a bit more with bugzilla might consider it? Just an idea - I don't know if people think it would be a good idea... -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Suggestion: Active bug list
Hi all. Branko's talk of a bug week got me thinking recently, and I just noticed that one of the few mails which got left in my gimp-developer mailbox (usually RFCs followups, but not in this case) was a mail that Sven sent to the list in June with a list of active 1.2 bugs (the thread was 1.2 Bug Hunting). There were about 10 of the highest-priority bugs, with a 1-line description and a link to bugzilla. Personally it got me lookign at bugzilla (a habit that has since lapsed), and looking at the thread it seemed to lead to the resolution of a fair few bugs. Do people think that doing this on a regular (say monthly) basis would be a good idea? And if so, who would do it? (note that I'm not volunteering - it's just something I was thinking about :) I could be persuaded to, perhaps - or maybe some of the people who've done a bit more with bugzilla might consider it? Just an idea - I don't know if people think it would be a good idea... Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Active bug list
Hi, Dave Neary [EMAIL PROTECTED] writes: Branko's talk of a bug week got me thinking recently, and I just noticed that one of the few mails which got left in my gimp-developer mailbox (usually RFCs followups, but not in this case) was a mail that Sven sent to the list in June with a list of active 1.2 bugs (the thread was 1.2 Bug Hunting). There were about 10 of the highest-priority bugs, with a 1-line description and a link to bugzilla. Personally it got me lookign at bugzilla (a habit that has since lapsed), and looking at the thread it seemed to lead to the resolution of a fair few bugs. Do people think that doing this on a regular (say monthly) basis would be a good idea? And if so, who would do it? (note that I'm not volunteering - it's just something I was thinking about :) I could be persuaded to, perhaps - or maybe some of the people who've done a bit more with bugzilla might consider it? yeah, sure go ahead. Creating reasonable bugzilla queries and posting the result would definitely not hurt. It might help to get more people working with Bugzilla. Bugzilla is a great tool but using it for a large project like The GIMP requires a reasonable amount of maintainance work. Let alone the fact that someone needs to fix the bugs... Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Professional use of Gimp (was: Developers and users (was: Bug week like thing for GIMP?))
On Tuesday 27 November 2001 13:10, Robert L Krawitz wrote: snip I can imagine professional use of a program without any of these things these days (the font stuff is most likely to be an issue). A lot of printers that get professional use have Mac/Windows drivers that take exclusively RGB data. A more serious issue is the lack of color matching, so that there's no guarantee that what shows on the screen will match what's on the page. Yes, but then we're still talking about printers here. The colour posters I designed were printed as well (on a digital press as they called it, which from what I gather is just an industrial strength printer), but that only goes up to A3, and the colours aren't that good (especially the orang bits came out a bit faded). All the other stuff my university printed for the anniversary was four-colour printed, which means CMYK. The website at http://www.bobs.co.uk/print/4colourProcess.html suggests that most stuff is CMYK too. Anyway, we're getting off-topic here. Perhaps I was wrong and CMYK isn't that important as you can always convert to it from RGB in Photoshop. But then you still need to have Photoshop. Colour matching is a problem anyway, because you'd need to tune your monitor as well. With xgamma and the gimp-print drivers I managed to match my monitor and printed output reasonably well, perhaps good enough for an amateur like me, but I guess a professional would like WYSIWYG colour-wise. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug week like thing for GIMP?
While we're at it -- why does GIMP 1.3 suddenly have a lot of new tools (Select by color, Adjust brightness, etc.) that you can find in the other menus too, sometimes just as easy? (The icons look a lot like the same for me, and IMHO they're mostly clutter :-) ) Is there any way to remove them for the user that I've missed? 1) GIMP 1.3 is not yet intended for users 2) the menus are still being reworked ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
I think the problem we have here is that there's quite a big difference between the developers and the users of the program. The people who make open source racing games probably do that because they like to play racing games as well. The average Gimp developer seems to do it because they like to write image manipulation software, things like writing filters and scripts and stuff, not necessarily because they like making digital art. Allow me to correct some impressions... Very little has happened recently in the way of scripts or filters; saying that gimp developers concentrate on that is ridiculous. I think you seriously overestimate the amount of developers working on it. The few that do make regular contributions are more than swamped with their ambitious primary goal of making it cleaner and easier to hack. (Look through the ChangeLog for the past 12 months - only Mitch and Sven are at all regular contributors). Also, the fact is that the codebase has really outgrown the developer power to support it; it needs cleaning and restructuring so a developer can go in, see a sane structure in place, and change what needs to be changed easily. This is extremely dull work (for me anyway) and we're lucky we have a couple guys that love the program enough to put the huge amount of time into fixing it. When they do get around to making user-centered choices, they tend to do a good job IMHO. But they are few, and thier task is large - its not all thats on their plate. And that the maintainers won't accept contributions that don't help the users in some way. Most of the work being done right now doesn't help the user one little bit, but should help developers make it easier to help users in the future. Putting a restriction like this in place would result in complete stagnation of the tree simply because nobody has the time to learn all the stuff needed to go in and hack right now. It makes difficult tasks impossible. Some things won't happen for a while. For example, take CMYK support (or other colorspace support for that matter). To do this successfully requires an internal representation thats different throughout. A lot of work has been done towards this goal (changing spots to use GimpColor, or separating out colorspace operations from the UI for instance), but a lot remains as well. The idea is to hopefully get it into 2.0. At our current release cycle, thats probably 5 years out. Some things are happening currently, but take awhile for the underlying technology to stabilize. The CVS HEAD branch has some primitive direct support of fonts through PangoFT2, which produces great looking fonts not dependant on an X server. However, its not a drop-in replacement, and the PangoFT2 interface is still changing in response to developer requests. When this other project stabilizes, I expect you'll see much more on the font support front in gimp. I think the current regular developers (both of them) as well as the occasional contributors are all doing great things for the program. They find time to respond to most feature requests submitted through gnome bugzilla. If you have specific, well thought out ways of progressing gimp along without radical change to everything, please do submit your feature request. Things do get implemented this way, and coders do pay attention. Well, thats it for my armchair developer counter-rant :) Seth Burgess [EMAIL PROTECTED] __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Sorry that it took so long, Simon ;) Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) 1. colour matching for photos is a don't care. Ok, this is a blatant lie, however, exact colours are not that much of a concern for photos. Much more important are logo colours (most companies have pretty strict definitions of these). If a photo doesn't exactly match the screen colours (which screen colours, anyways) this is often not a reason to not use gimp. If a logo colour can't be reproduced, however, it keeps Gimp from being used. 2. Logo colours are not CMYK. Yupp. Logo colours might not be representable in CMYK at all (gold etc...). Even if, you often (but not always) want seperate planes for important colours. Most uses of spot colours want the concept of an indexed channel, i.e. a channel where each value represents a different palette colour. No bleeding with image contents. Gimp's channels can be used instead, which is not that perfect for all uses, but exists and at least photoshop doesn't offer a better solution ;) They also allow gradients of a single spot colour, which indexed channels wouldn't allow. Wether all this makes them easier or harder to use is something to explore. 3. You don't print from within the gimp. At least you don't print brochures from within the Gimp. You use gimp for artwork, often the logos, but you obviously don't set text using the Gimp. You instead import images into some layout program (quark xpress ;). I was told that the principal reason for bad quality of gimp images within quarkxpress is that quarkxpress imports gimp's rgb tiffs like garbage. I was told that loading the rgb data into photoshop, associating sRGB with it (changing _nothing_ else) improved the quality very much, making the results reproducable on printers. Without absolute colours, they look different. 4. Cheap CMYK vs. RGB makes a difference. Many programs also seem to have problems (looks like shit) with RGB data, not because it isn't associated with a colourspace, but because it's RGB. Cheaply (formula) converted CMYK data seems to help a lot here. That CMY has an additional K is of no concern - users don't sue this additional level of freedom, Things like trapping are handled by other programs or by very expensive photoshop plug-ins. 5. Logos are done by overlays. At least one method of using spot colours is to create them as seperate channels. Tiff/Eps are reportadly able to save additional channels in a way that a program can read them sensibly. The spot colour planes are then laid over the other graphics. For this to work a mask is necessary, since channels range from white (not transparent) to channel colour, at leats in quarkxpress. It seems that traditional masks are not what's called for - instead you want a path saved in the tiff/eps file (don't ask me wether that is possible). This clipping path is then used for the overlay - gimp can't create this kind of paths, nor can it save it. CONCLUSIONS - THE 60% WAY TO CMYK If one were so bold as to draw some conclusions, they would probably be very similar to these: 1. Enhance the tiff/eps save plug-ins to do cheap RGB-CMYK conversion. This would work around conversion problems in other programs. 2. Associate sRGB or any other colourspace with the saved data in tiff/eps. It doesn't matter wether it's true or not, just give programs something to depend on. 3. Educate users about channels and what they can be used for - on this Systems I was frequently confronted with users who were unhappy with the gimp because it didn't allow them to do things as easily as under photoshop. Often(!) I was able to get exactly the same results, with a much easier and faster sequence than the one that user used with Photoshop. This could be a start, to work around bugs in other programs. Also relatively cheap, unlike the following: 4. Find out wether saving paths as paths as opposed to masks is really required to do overlays in common layout programs. If yes: 4a. enhance the path tool to be able to work with generic paths (holes, multipart etc.). 4b. enhance the tiff/eps plug-ins to be able to save these paths together with channels. 4b. (optional) make tiff/eps save images together with their channels in the same file. 5. Implement indexed channels, or somethign else that makes handling spot colours easier. An easy way is to use one channel for each spot colour. Finished. I certainly
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Mitch, Sven.. when you have time.. Can you make a to do for developers that want to help? Already done. See TODO.xml Seth __ Do You Yahoo!? Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month. http://geocities.yahoo.com/ps/info1 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
On Tuesday, 27 Nov 2001, [EMAIL PROTECTED] ( Marc) (A.) (Lehmann ) wrote: Anyways, I had some conversation with two graphics designers about CMYK problems and the Gimp at the Systems, and I think it might be worthwhile to read the following sometimes true observations. Remember, they are hearsay ;) [observations snipped] Wow! Marc Lehmann has written an email that's actually useful and well-thought out! His 60% CMYK makes sense to me. Now all I need is the time to implement it. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Hi, Rebecca J. Walter [EMAIL PROTECTED] writes: Mitch, Sven.. when you have time.. Can you make a to do for developers that want to help? http://developer.gimp.org/gimp-todo.html it's generated from TODO.xml as found in the source tree. Doesn't cover everything that needs to be done, but it should give people an idea what areas need work. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Hmm .. this is a pretty cool writeup. :) On Tue, Nov 27, 2001 at 03:10:15PM +0100, Marc A. Lehmann wrote: [...] CONCLUSIONS - THE 60% WAY TO CMYK If one were so bold as to draw some conclusions, they would probably be very similar to these: [...] 3. Educate users about channels and what they can be used for - on this Systems I was frequently confronted with users who were unhappy with the gimp because it didn't allow them to do things as easily as under photoshop. Often(!) I was able to get exactly the same results, with a much easier and faster sequence than the one that user used with Photoshop. Can you remember any specific examples of this? It would help show us where the gimp's channels and layers setup does things better in some sense. Malcolm -- Tolkien is hobbit-forming. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Suggestion: Active bug list
On Tue, 27 Nov 2001, Sven Neumann wrote: Dave Neary [EMAIL PROTECTED] writes: Personally it got me lookign at bugzilla (a habit that has since lapsed), and looking at the thread it seemed to lead to the resolution of a fair few bugs. Do people think that doing this on a regular (say monthly) basis would be a good idea? And if so, who would do it? (note that I'm not volunteering - it's just something I was thinking about :) I could be persuaded to, perhaps - or maybe some of the people who've done a bit more with bugzilla might consider it? yeah, sure go ahead. Creating reasonable bugzilla queries and posting the result would definitely not hurt. It might help to get more people working with Bugzilla. Bugzilla is a great tool but using it for a large project like The GIMP requires a reasonable amount of maintainance work. Two weeks ago, I added a list of useful Bugzilla queries at the bottom of the download page for the developers' version of the Gimp: http://www.gimp.org/devel_ver.html The links allow you to see the list of open bugs or wish lists, for all versions or only for the stable or unstable versions. The bug reports in which the version number is unspecified are assumed to be related to one of the stable versions. Once you have the result of the query, you can easily sort it by clicking on the column headers in the results page (personally, the first thing I did with Bugzilla was to click the Change Columns link, add the Changed Date and Reporter columns, and then sort by date). When I have some spare time, I will also try to add more specific queries (Windows only, all OSs but Windows, Linux only, ...). For the curious who have an account on wilber, these links are generated semi-automatically from a set of definitions that can be found in the file /gimp00/web-gimp/defines/links_bugs.def. Let alone the fact that someone needs to fix the bugs... Very true. You are doing a great job. ;-) -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thingfor GIMP?)
On Tue, 2001-11-27 at 15:30, Sven Neumann wrote: Hi, Rebecca J. Walter [EMAIL PROTECTED] writes: Mitch, Sven.. when you have time.. Can you make a to do for developers that want to help? http://developer.gimp.org/gimp-todo.html it's generated from TODO.xml as found in the source tree. Doesn't cover everything that needs to be done, but it should give people an idea what areas need work. This list is AWESOME! So.. all the developers out there who are bored, GET HACKING! The list is even rated by difficulty. It is awesome! YAY SVEN AND MITCH! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Tuesday 27 November 2001 14:50, Seth Burgess wrote: snip Allow me to correct some impressions... Very little has happened recently in the way of scripts or filters; saying that gimp developers concentrate on that is ridiculous. Sorry, my bad. Jargon problem it seems. In Gimp, scripts and filters are Perl and Scheme programs that do things to the image via the Gimp API, which is not really what I meant. I'm no Gimp expert, but what I meant was the whole drawing engine part, ie memory management, brush strokes, layers, etc. Attached to it are the scripts and filters, and on top of that is the GUI, right? I think you seriously overestimate the amount of developers working on it. The few that do make regular contributions are more than swamped with their ambitious primary goal of making it cleaner and easier to hack. (Look through the ChangeLog for the past 12 months - only Mitch and Sven are at all regular contributors). Okay, so I misjudged the state of development Gimp is in. I remember trying to find out some time ago how hard it would be to contribute things to Gimp, but I gave up pretty soon. In another thread Rebecca Walter suggested creating a TODO for developers that want to help. I'd like to suggest they make a HOWTODO, because even if you want to help, you have this 15MB pile of source in front of you and not much of an idea of where to start. Some time ago I read the documentation that comes with GEGL, which is quite a lot of code too with a weird pseudo-language as an added bonus, but it's much easier to understand the structure of the code if you have a nice doc that explains what's what. Also, the fact is that the codebase has really outgrown the developer power to support it; it needs cleaning and restructuring so a developer can go in, see a sane structure in place, and change what needs to be changed easily. This is extremely dull work (for me anyway) and we're lucky we have a couple guys that love the program enough to put the huge amount of time into fixing it. Amen. This wasn't an attempt to put down Sven, Mitch or any of the other developers. I'm a computer science student and I can certainly appreciate the amount of work that's being put into Gimp. What I didn't realize was that Gimp isn't at all ready for new, user-oriented features at the moment. When they do get around to making user-centered choices, they tend to do a good job IMHO. But they are few, and thier task is large - its not all thats on their plate. And that the maintainers won't accept contributions that don't help the users in some way. Most of the work being done right now doesn't help the user one little bit, but should help developers make it easier to help users in the future. Putting a restriction like this in place would result in complete stagnation of the tree simply because nobody has the time to learn all the stuff needed to go in and hack right now. It makes difficult tasks impossible. You're right, this is nonsense. Some things won't happen for a while. For example, take CMYK support (or other colorspace support for that matter). To do this successfully requires an internal representation thats different throughout. A lot of work has been done towards this goal (changing spots to use GimpColor, or separating out colorspace operations from the UI for instance), but a lot remains as well. The idea is to hopefully get it into 2.0. At our current release cycle, thats probably 5 years out. Well if you use GEGL for 2.0 it shouldn't be hard as GEGL has been designed from the start with different colourspaces in mind. I like GEGL quite a lot actually, apart from the we don't need no C++ thing which I understand but disagree with. However, that discussion is closed, and let's keep it that way. snip - better fonts are coming up I think the current regular developers (both of them) as well as the occasional contributors are all doing great things for the program. They find time to respond to most feature requests submitted through gnome bugzilla. If you have specific, well thought out ways of progressing gimp along without radical change to everything, please do submit your feature request. Things do get implemented this way, and coders do pay attention. I have a few things in the back of my head (layer trees, a 4x4 matrix for every layer to encode transformations, etc.) but I think those are better suited for GEGL an Gimp 2.0. Lourens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Professional use of Gimp (was: Developers and users (was: Bug week like thing for GIMP?))
On Tue, Nov 27, 2001 at 02:33:22PM +0100, Lourens Veen wrote: Yes, but then we're still talking about printers here. The colour posters I designed were printed as well (on a digital press as they called it, which from what I gather is just an industrial strength printer), but that only goes up to A3, and the colours aren't that good (especially the orang bits came out a bit faded). All the other stuff my university printed for the anniversary was four-colour printed, which means CMYK. The website at http://www.bobs.co.uk/print/4colourProcess.html suggests that most stuff is CMYK too. My housemate works for one of the larger prepress firms in the country. From what she's said to me, I feel safe in stating that virtually all commercial printing is CMYK, CMYK plus one or two spot colors, or one, two, or three spot colors alone. Spot colors are virtually always drawn alone (the graphics program is not expected to generate spot layers from an RGB source). Doing CMS-based color matching is probably hopeless: there are too many patents and trade secrets in this area that we will have virtually no chance of negotiating licenses that will not interfere with the GPL. Using channels as a substitute for spot layers is not entirely acceptable because channels are always above all layers of the image. This may not always be desirable. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thingfor GIMP?)
Okay, so I misjudged the state of development Gimp is in. I remember trying to find out some time ago how hard it would be to contribute things to Gimp, but I gave up pretty soon. In another thread Rebecca Walter suggested creating a TODO for developers that want to help. I'd like to suggest they make a HOWTODO, because even if you want to help, you have this 15MB pile of source in front of you and not much of an idea of where to start. Some time ago I read the documentation that comes with GEGL, which is quite a lot of code too with a weird pseudo-language as an added bonus, but it's much easier to understand the structure of the code if you have a nice doc that explains what's what. Yes, this would be nice, but the problem is finding someone to write it. Do we have any volunteers? Anyone who could outline a basic process for conquering some of the projects on Sven's to do list? Other than that, come join us on #gimp on irc.gimp.org sometime. You can learn a lot by listening there and maybe start getting your claws into the code a little more. My challenge of the moment is figuring out how to understand the strings. :-) I'm no coder so sometimes I get confused to death. But the channel is a good place to find out what is going on. Mitch and Sven are even there a lot. :-) bex ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Speaking of: what happened to GIMP News and Kernel Cousin GIMP?
As the subject says: what happened to GIMP News and Kernel Cousin GIMP? These were great (if somewhat irregular) sources of information. What happened to them? I prefer reading through Kernel Cousins to reading through mailing list archives. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Lourens Veen wrote: Last thingy, about professional use of Gimp, isn't this a bit of a chicken-and-egg thing? I can't imagine anyone using a program that doesn't do CMYK, serious halftoning and easy font work (with the added note that my X server crashes regularly on TrueType fonts rendered larger than 100 px or so) for professional print graphics. Having worked together with those professionals quite a bit lately I think Gimp needs to be quite a bit better still. eh I work as a webdesigner in an Amsterdam based 'top tier' New Media company. I do little in the way of print graphics thus this may be a bit off-topic... But, all my work is done in GNU/Linux in GIMP, whilst my co-workers use Macs and photoshop 5.x/6.x. The _one_ thing with we find to be a hassle wrt. GIMP is the fact that we can't share documents painlessly. There is a psd-save hack for GIMP, but the hack only saves in psd 4.0 and doesn't keep text layers dynamic. The Best Thing(tm) that could happen for us, is that a PHOTOSHOP plug-in be released that can read xcf into photoshop. CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf plugin might be easier? just my 0.02 avi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Fwd: [Gimp-developer] Suggestion: Active bug list]
Hi all, Apologies - I accidentally took this off-list for a couple of mails. Returning to the list now. Cheers, Dave. Dave Neary wrote: Raphael Quinet wrote: Well, the easiest way to do that is to use one of the existing queries for open bugs and click on the Sev or Pri column headings in order to sort them by severity or priority. Then you can look at the first ones in each list and select those that appear to be the most important. There is no way to do this fully automatically because the priorities and severities are not always assigned in a consistent way (depends on who looks at the bugs and what they have in mind at that time). Hmmm... the idea I was trying to get at before was that it would be useful to send a top 10 to the list, since (as you no doubt know) the majority of developers haven't been using zilla (including myself), and probably wouldn't go regularly to one spot to check bugs. But if Mohammed won't go to the mountain... By mailing the 10/15 most critical bugs on a monthly basis to the list, I think people will be more likely to fix them. I know that I was when Sven last posted his trawl through outstanding bugs. It also has the benefit of connecting the very useful bugzilla to the most commonly used mailing list frequently, and getting people following those links. I think that the mail aspect of this is extremely important, and one message saying there are links to queries here (with a URL) isn't enough to get people using zilla in the long term (IMHO). What do you think? Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Speaking of: what happened to GIMP News and Kernel Cousin GIMP?
Hello Branko, [EMAIL PROTECTED] (2001-11-27 at 1640.22 +0100): As the subject says: what happened to GIMP News and Kernel Cousin GIMP? These were great (if somewhat irregular) sources of information. What happened to them? I prefer reading through Kernel Cousins to reading through mailing list archives. The GIMP News is alive and well at the bottom of wgo. You must scroll however. carol ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Tue, Nov 27, 2001 at 02:10:47PM +0100, Avi Bercovich wrote: CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf plugin might be easier? I don't know of any GIMP developer willing to spend the $$$ to get the SDK for Photoshop. -- I love catnip mice. It's why I chew their heads off. They're good for breakfast. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Fwd: [Gimp-developer] Suggestion: Active bug list]
On Tue, 27 Nov 2001, Dave Neary wrote: By mailing the 10/15 most critical bugs on a monthly basis to the list, I think people will be more likely to fix them. I know that I was when Sven last posted his trawl through outstanding bugs. It also has the benefit of connecting the very useful bugzilla to the most commonly used mailing list frequently, and getting people following those links. I think that the mail aspect of this is extremely important, and one message saying there are links to queries here (with a URL) isn't enough to get people using zilla in the long term (IMHO). I see... But unfortunately it would be difficult to mail the top 10 bugs to this list every month. The first problem is technical: I don't have the time to set up such a thing. The second problem is related to the information that would be sent: some bugs have a summary (title) that is not very easy to understand, so sending that to the list would not always be sufficient. By the way, I just updated the page containing the links to some Bugzilla queries and I added three new links that allow you to find the list of open bugs that are not enhancements (so you only get the real bugs). Try it from: http://www.gimp.org/devel_ver.html -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On Tue, 27 Nov 2001, Avi Bercovich wrote: eh I work as a webdesigner in an Amsterdam based 'top tier' New Media company. I do little in the way of print graphics thus this may be a bit off-topic... But, all my work is done in GNU/Linux in GIMP, whilst my co-workers use Macs and photoshop 5.x/6.x. The _one_ thing with we find to be a hassle wrt. GIMP is the fact that we can't share documents painlessly. There is a psd-save hack for GIMP, but the hack only saves in psd 4.0 and doesn't keep text layers dynamic. The Best Thing(tm) that could happen for us, is that a PHOTOSHOP plug-in be released that can read xcf into photoshop. CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf plugin might be easier? But who would write it? One of the goals of many Gimp developers is to create a useful image manipulation so that people do not _need_ to use Photoshop (or other proprietary programs). Writing an XCF plugin for Photoshop would certainly by nice for some users, but is probably not on the top priority of any Gimp developer. Regarding dynamic text layers, there would still be a probem even if someone wrote an XCF plugin for Photoshop. In Photoshop, these layers would not be visible as text layers anyway, because text is handled in a very different way in both programs, so the dynamic text created in one program could not be edited with the other one. At best, the meta-information (gimp parasite) generated by the dynamic text plug-in could be hidden somewhere in Photoshop so that it would be preserved if the XCF file is saved again by Photoshop, but the results would probably not be very useful. -Raphael ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
On 27 Nov 2001, at 10:39, Kelly Martin wrote: On Tue, Nov 27, 2001 at 02:10:47PM +0100, Avi Bercovich wrote: CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf plugin might be easier? I don't know of any GIMP developer willing to spend the $$$ to get the SDK for Photoshop. Maybe I am mistaken about this, but it would seem that Adobe offers the Photoshop SDK and the Photoshop file format specifications for free download at http://partners.adobe.com/asn/developer/gapsdk/PhotoshopSDK.html. I have only download the file format specs myself, I don't know what's in the SDK. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Fwd: [Gimp-developer] Suggestion: Active bug list]
Raphael Quinet wrote: I see... But unfortunately it would be difficult to mail the top 10 bugs to this list every month. The first problem is technical: I don't have the time to set up such a thing. The second problem is related to the information that would be sent: some bugs have a summary (title) that is not very easy to understand, so sending that to the list would not always be sufficient. I guess it would only take a few minutes for someone to do it manually - I'll volunteer for a couple of months (starting December) and see how it's being taken after that. If people start saying But those're the same bugs you posted last month! I'll be able to say Well, duh, they need fixing or something a bit more politic. But if it's getting no response at all, a couple of months would be enough of a trial run... By the way, I just updated the page containing the links to some Bugzilla queries and I added three new links that allow you to find the list of open bugs that are not enhancements (so you only get the real bugs). Try it from: http://www.gimp.org/devel_ver.html Cool :) Cheers, Dave. -- David Neary, E-Mail [EMAIL PROTECTED] Palamon Technologies Ltd. Phone +353-1-634-5059 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Kelly Martin wrote: On Tue, Nov 27, 2001 at 02:10:47PM +0100, Avi Bercovich wrote: CMYK, halftoning etc. would be nice indeed, but possibly a Photoshop xcf plugin might be easier? I don't know of any GIMP developer willing to spend the $$$ to get the SDK for Photoshop. what $$$ are you referring to?? http://partners.adobe.com:80/asn/developer/gapsdk/PhotoshopSDK.html Although I haven;t got a windows/macos box handy to check the contents of the zip files, I would hazard a guess that you'll find the stuff one needs to build plug-ins inside of them. ttfn, avi ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Thoughts on CMYK, and getting it without implementing it.
Hi, 2. Associate sRGB or any other colourspace with the saved data in tiff/eps. It doesn't matter wether it's true or not, just give programs something to depend on. Well, actually this would be true. sRGB is defined using the phosphors standartised for HDTV and used for monitors. And as gimp does no colour management except for a gamma correction on display we can ass assume that the image is in sRGB colourspace. (Well, sRGB is the implied colourspace on Windows(TM) if you don't set enything specific.) Jens ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] XCF support added to ImageMagick
I just thought I'd let you folks know that I just checked support for reading (writing will come later) XCF files to the ImageMagick library (http://www.imagemagick.org). Right now you'd need to get it via CVS, BUT it will be part of the standard 5.4.1 distribution due on Friday. Leonard Member, ImageMagick Studio ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developers and users (was: Bug week like thing for GIMP?)
Branko Collin writes: Maybe I am mistaken about this, but it would seem that Adobe offers the Photoshop SDK and the Photoshop file format specifications for free download at http://partners.adobe.com/asn/developer/gapsdk/PhotoshopSDK.html. Yep. Except that they don't document the newest brush (and presumanly other) formats. At least not last time I checked, which admittedly was maybe half a year ago. (I don't even remember exactly what the new exciting thing in the newest Photoshop brush format was that got me interested; presumably it was something like GIMP's pixmap brush pipes.) --tml ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Gimp 2?
So... Is anyone actively working on GIMP 2? ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2?
On Tue, 2001-11-27 at 22:48, Laramie Leavitt wrote: So... Is anyone actively working on GIMP 2? Well.. YES. Since 1.3 is the path to GIMP 2 and a lot of people are working there butts off on 1.3.. I would say that is a BIG HUGE YES! No one can even think about GIMP 2 until GIMP 1.3 is made as GIMP 1.3 makes GIMP hackable. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2?
On Tue, Nov 27, 2001 at 02:48:33PM -0700, Laramie Leavitt wrote: Is anyone actively working on GIMP 2? Insofar as there is activity on GIMP 1.4, yes. Kelly ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp 2?
On Tue, 27 Nov 2001, Kelly Martin wrote: On Tue, Nov 27, 2001 at 02:48:33PM -0700, Laramie Leavitt wrote: Is anyone actively working on GIMP 2? Insofar as there is activity on GIMP 1.4, yes. Kelly Is anyone working on it insofar as it relates to GEGL and all that? If I understand this correctly, Gimp 2 will use an entirely different internal engine. The plug-ins will likely not work, and numerous other changes will render Gimp 2 as an entirely new entity with little in common with Gimp, really... So, why not work on Gimp 1.3 and Gimp 2 in parallel? Laramie ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
