Re: [Gimp-user] Very few of my posts show on the list...
On Wed, May 25, 2005 at 01:36:09PM +0200, Michael Schumacher [EMAIL PROTECTED] wrote: I'ts not that uncommon for a mailing list to have a queue time of one or two days. And even weeks... This, however, can't be considered normal. IIRC, the mailing list system is slow, but not that slow. Manish Singh should be able to provide details about it (Carol, do you know anything per chance?) A possible reason is that mails with different From: addresses get held for moderation but nobody does moderation (at least, all my mails that had a different From: address than the one subscribed never reached the lists, and I don't assume they have all been deleted by the moderator). So make sure you use the same From: that you used to subscribe (could be envelope-form, but I doubt that). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] lossless jpeg transformations
On Thu, Feb 17, 2005 at 06:02:31PM +0200, Alexander Rabtchevich [EMAIL PROTECTED] wrote: Could it be done via additional menu item: open for the lossless transformations with only few operations active? The operation itself has sense for digital images with portrait orientation. It would be nice to store the original images without data loss but with corrected orientation. I think it makes very little sense to put this into the gimp. The extra work is IMHO just not worth it, a specialized extra application would be more useful. Or a plug-in. The number of (useful, lossless) operations that can be done on jpegs is very limited. By the way, I'm just curious, is it possible to apply different jpeg settings to the different parts of an image? Yes, you can vary quantizazion factors, but i don't think the jpeg library can handle that. The best you can do with respect to such tricks is to use scan scripts to achieve some effects, for example, the image at URLhttp://kaya.schmorp.de/sofia/p1010043.jpg has the monochrome parts first which has the effect of first showing the grayscale image on slow-enough connections. mean if the jpg image haven't undergo transformations affected the whole image, the unaffected parts of the image could be saved as the original compressed data without recompression (at least beyond adjacent points). These pixels could be obtained by the simple comparison with the original file. That would be easy iff the underlying jpeg library supports it, and could be limited to the jpeg plug-in. However, if you only use the ijg jpeg library and take care of not changing the quantization factors you will see that the pixels will already not change, i.e. there will be losless compression. So there is probably little demand for that. It would be far more useful to have a way of knowing the quality the file was saved with (by the ijg library) so it can be saved with the same quantizazion factor again, if possible (i.e. as long as you use the same library to compres/decompress the file). -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP RENAMED and sold on eBay
On Sat, Feb 12, 2005 at 05:59:29PM +0800, steve hudson [EMAIL PROTECTED] wrote: You will be pleased to know the GIMP is making handsome profits for this eBay pirate with no reference to the real name: It might shock you, but it's completey legal, at least in most jurisdictions. The (GPL) license puts some requirements on distribution, but you don't have to mention the terms in the advertising for it, nor must it be distributed for free. free refers to the terms that source code is distributed at no extra charge and with full modification rights, not to the actual price. (see the GPL FAQ at http://www.gnu.org/licenses/gpl-faq.html for more info) It is possible that those two fail to fulfill the licensing requirements, but to know that you must buy the software and check. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: [Gimp-web] Perlotine for Windows?
On Sun, Feb 06, 2005 at 01:13:51AM -0800, Carol Spears [EMAIL PROTECTED] wrote: On Sun, Feb 06, 2005 at 09:55:16AM +0100, Marc A. Lehmann wrote: On Sat, Feb 05, 2005 at 10:32:06PM -0800, Carol Spears [EMAIL PROTECTED] wrote: to do it in a was compatible to gimp. okay. and i responded to the wrong list. other than all of that, i was correct that it was a very nice exchange between developers way back when. Well, indeed, I have some fond memories in this area (also the very productive session with Hans Breuer :). However, it seems the general mood of the mailinglists hasn't improved much since I have escaped. -- The choice of a -==- _GNU_ ==-- _ generation Marc Lehmann ---==---(_)__ __ __ [EMAIL PROTECTED] --==---/ / _ \/ // /\ \/ / http://schmorp.de/ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE ___ Gimp-user mailing list Gimp-user@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP installation on Solaris
On Thu, Sep 02, 2004 at 10:08:30AM +0100, Colin Bannister [EMAIL PROTECTED] wrote: Hello, I've got further with installation of GIMP 2 on Solaris, but have hit a problem in the Gtk installation, message included below. Once again, is anyone using GIMP 2 on Solaris ? I have no idea :) However, regarding this problem: gtkimcontextxim.c:67: parse error before XICCallback The X11 headers on solaris specify the wrong prototype for XIMCallbacks and XICCallbacks. Working around that issue is somewhat ugly. It's quite possible that gtk+ doesn't have such workarounds in place (after all, it's the solaris header files which are broken). You might try using the X11 header files from xfree86 or x.org, they should work. You can also look around on google, as this is a common problem on solaris. It could of course be sth. else, but this has bitten me a number of times when adding x input support to applications. -- The choice of a | -==- _GNU_ | ==-- _ generation Marc Lehmann +-- ---==---(_)__ __ __ [EMAIL PROTECTED] |e| --==---/ / _ \/ // /\ \/ / http://schmorp.de/ --+ -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE| | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] tiff and lzw compression
On Tue, May 11, 2004 at 11:14:38AM -0300, Joao S. O. Bueno [EMAIL PROTECTED] wrote: Is there any reason for this, i.e.: - Is tif/lzw compression excluded from gimp or only from the debian build? only from de debian build. (some others, too, what you meant was not from the original sources). they say it hasn't expired in certains countries (not USA) yet. Anyway, you can either - install the TIFF and GIOF plug-ins from the non free or non us repository (I am not a debian man), build the Gimp yourself from the sources in gimp.org, or contact your favorite debian gimp packager. The only package that might help is gimp-nonfree, but it only contains the gif-plug-in. The tiff plug-in is part of the standard gimp package. If it doesn't do lzw while the original gimp does lzw then you should report it as a bug against the gimp package (apt-get install reportbug; reportbug gimp) and explain why a lzw-enabled plug-in should become part of gimp-nonfree. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Environment settings big images
On Fri, Apr 23, 2004 at 01:50:39PM +1000, David Burren [EMAIL PROTECTED] wrote: i am curious. do you think that if the adobe geniuses could make their software compile on linux, if it would slow it down. No. In fact they've got it to compile on a Unix (ie. MacOS X) and Slightly off-topic, because it relates to photoshop and MacOS X: MacOS X is rather far away from unix (or even posix), and, while the X Window System is not officially unix, it's basically the GUI standard on unix. So, as a matter of fact and a matter of expectancy, they didn't get it to compile on a unix by porting it to macos x. Still, darwin supports a large subset of posix and unix, but when developing apps for it, you don't have to use it, and I suspect that adobe didn't. it runs great. I don't believe it's inherent in the OS that the application is running on. I do think that Photoshop currently does a better job at managing its memory resources, but that's at the appliction level. That could well be true. Unfortunately, it has been difficult so far to actually measure this. There are reports from people claiming photoshop is much faster, and reports that photoshop is slower, or that it depends on the case. I experimented wiht photoshop about 2 years ago, and found it quite a bit less responsive on large images than gimp on gnu/linux on the same machine. One possible reason for the perceived problems could be that gimp requires more tile cache to work efficiently than photoshop (especially multiple undo steps cost a lot of memory), and by default the tile cache size is conservative. However, more exact and espeiclaly reproducible reports are needed to find out wether this is the case, or under what circumstances gimp gets slower. My observations about memory consumption behaviour between the Gimp and Photoshop have been coincidental to that. It's not the reason I started using Photoshop, but it's a pleasant side-benefit. These were certainly very interesting. Also, gimp should certainly not grow unbounded. Maybe you are just hitting a bug somewhere? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] ID nvnv... thanks
Yours ID chigeck -- Thank attachment: onkatvsawkc.exe ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Squaring up an Image - Perspective Transform Changes Sizes
On Thu, Jan 22, 2004 at 12:43:18PM -0700, Steve Strobel [EMAIL PROTECTED] wrote: I tried using the perspective transform to adjust the corners of the image so the section lines would be horizontal and vertical. That's actually correctly doing what the perspective transform is doing (try to imagine a plane with rectangles on it, in an angle towards you). From what you are writing, I'd say he shearing transform is *exactly* what you need, so what kind of problems are you facing when using a shear transform? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Re: [Gimp-developer] Re: Alternative zoom algorithm
On Sat, Jan 17, 2004 at 01:26:09PM +0100, GSR - FR [EMAIL PROTECTED] wrote: what people is used to or the levels for typical images and finaly get my patch encouragingly classified as evil, I think I will stop wasting time and keep my ideas and suggestions to myself. Get used to it, that's how gimp-developer works :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] ESC for cancel in full-screen mode
On Tue, Dec 09, 2003 at 04:12:10PM -0600, Eric Pierce [EMAIL PROTECTED] wrote: However, would you consider removing ESC as a binding to pop you out of full-screen mode? I think F11 is a sufficient (and common) toggle for Well, ESC has a very low probability of being remapped by e.g. a window manager. F11 is far more often mapped to some wm functionality. And the basic problem with your approach that I see is that ESC has the perfect meaning for going out of fullscreen mode. It's the thing users naturally try. F11 is about the last key users will try when they want to get out of full-screen mode. This is important for fullscreen mode because fullscreen mode is often very surprising to users, and they might want to get out. What does anyone else think? At least I think it's not perfect that esc cancels both, but esc canceling both is far preferable over using F11 for leaving fullscreen mode. Many users at our instituta have mapped F11 to open a new shell window for example (using the window manager) or move windows, so fullscreen mode would turn out to be an unpleasant trap. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: GIMP at COMDEX
On Thu, Nov 13, 2003 at 10:34:07PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: and reconfiguration, for example assign some F# keys to some Filters that are going to be used a lot in a row, but probably not in next work session or image. I am fully aware of this since I use this feature myself. The menu editor I proposed should allow you to this almost as quick and a lot more convenient than it is now. We might even allow a shortcut for I am guessing here, but it looks to me as if you are talking of two different things: No menu editor will be almost as quick and more convinient when it goes to dynamically reconfiguring shortcuts. For example, when I use a filter twice in a row it usally gets a shift-f shortcut assigned by me. No dialog can make that faster for me. I guess there are three styles of usages: - mnemonics (i rarely used them under windows, and never under unix) - shortcuts relatively static (get used often by me) - shortcuts, dynamic (get used often by me) As you can see, I am not the mnemonics type, but I am also not the icon type (if I had time I'd donate a text version of the toolbox :). Others might have problems with dynamic shortcuts and need mnemonics to support their style of work. All that is well. And if my type is the absolue minority and people _do_ get confused by dynamic shortcuts (something I personally have never seen evidence of, but I don't deny it's possible existence), then switching it off by default is a sane decision. Howwver, I think the disucssion in the past suffered from the my style is the only style problem on all sides. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP Perl Server under Xvfb
On Tue, Nov 04, 2003 at 12:14:40PM +0100, Sven Neumann [EMAIL PROTECTED] wrote: Xvfb. Additionally, I created two init.d scripts to automate the start/stop of Xvfb and GIMP's Perl Server at start-up/shutdown. Both scripts work great when executed manually, but when actually power cycling the system it only launches Xvfb and GIMP without the Perl Server. You could use GIMP-1.3, It doesn't any longer need an X-Server to run Very true. If you still need 1.2, you could look for a timing problem - Xvfb might take a while to start up. Also try to start it as late as possible. And maybe you rely on env variables (PATH, HOME etc.) that are not set when booting. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] installing gimp-1.2.5-6mdk
On Mon, Oct 27, 2003 at 10:40:23AM +, david [EMAIL PROTECTED] wrote: The second is proving trickier. The second dependency is a perl file called file::Slurp. Last night I cpan'ed the file. I thought No matter how often you download and install File::Slurp, rpm won't take notice of that. You would need a rpm of that perl module, which probably is somewhere near the original rpm, or part of your distribution (mandrake?). not recognised. So I thought sod-it and installed the gimp with --nodeps. It installed ok. The gimp opened ok aswell. But I wonder if the gimp will function ok without file::Slurp? If File::Slurp is installed gimp will use it. It's just that the rpm insists on having a _rpm_ version of File::Slurp. If you install it without rpm and override rpm using --nodeps all should be fine. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Speeding up printing ...
On Sun, Oct 26, 2003 at 01:16:57PM +, Dave selby [EMAIL PROTECTED] wrote: Since Debian compiles for a i386 I have a PIII I have re-compiled Gimp, cupsys-driver-gimpprint libgimpprint1. To my supprise this has made no difference. You can expect a 3-20% performance increase even in good situations only. I don't know what the actual problem is, but if you have a high system time, then maybe the kernel does polling when acessing your printer port, which often costs a lot of cpu time. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] [nq6@hotmail.com: contribution.]
I received this, and, since it's probably meant for a larger forum, forwarded it to the gimp-user mailinglist, [EMAIL PROTECTED] - Forwarded message from Nq6 [EMAIL PROTECTED] - Subject: contribution. From: Nq6 [EMAIL PROTECTED] Date: Tue, 23 Sep 2003 23:54:05 -0300 To: [EMAIL PROTECTED] X-Mailer: Microsoft Outlook Express 6.00.2800.1158 I am to designer graphical and as using I can give my parcel of contribution. 1. Gimp must offer in the program something that it manages of shortcuts, where all the tools and the too much functions. 2. In the main menu of tools, if it must to pressing the one of them with the right button fast option of shortcut. 3. Gimp must more have optimized menus, that do not take much space of the screen and that they can be added to the too much menus. 4. Gimp must invest more in design of the tools and the proper appearance of the Gimp, it as graphical program has that to have an exemplary graphical interface. 5. The lack of shortcuts I wait contact, Yours truly Frederico Arajo Mendes Brazil _ Original Sou designer grfico e como usurio posso dar minha parcela de colaborao. 1. O gimp deve oferecer no programa algo que gerencie de atalhos, onde todas as ferramentas e as demais funes. 2. No menu principal de ferramentas, se deve ao apertar uma delas com o boto direito a opo rpida de atalho. 3. O gimp deve ter menus mais otimizados, que no tomem muito espao da tela e que possam ser agregados aos demais menus. 4. O gimp devem investir mais no design das ferramentas e do prprio visual do Gimp, ele como programa grfico tem que ter uma interface grfica exemplar. 5. A falta de atalhos das ferramentas principais para um profissional chega a ser irritante. Aguardo contato, Atenciosamente Frederico Arajo Mendes Brasil - End forwarded message - -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: CinePaint and Film Gimp
On Tue, Sep 16, 2003 at 10:33:39AM -0500, Michael J. Hammel [EMAIL PROTECTED] wrote: On Mon, 2003-09-15 at 20:58, [EMAIL PROTECTED] wrote: We should also consider that xfree86 currently falls aparts exactly because of the board (and wrecks for quite some time already). Interesting, if clouded, view of this situation. I think I have a very clear view of the innards of xfree86. The board (which is actually made up of the core developers) Was. Just ask them. The president abused his unlimited power to silence everybody and expell most core developers from the board. letting fresh air into the process. The board remains. XFree86 remains. Advances continue. Exactly where has XFree86 fallen apart? Well, I can't argue with you, sicne you are supposing something about the future, on which I disagree. xfree86 is falling apart because developers leave it and no fresh blood is joining. Did you discuss your opinion with any of the core developers or are you just stating the opinion without gathering any facts on the situation first? As a matter of fact I discussed it with quite a few current and previous board members and core developers. I think it's pretty representative. XFree86 might be somewhat exceptional, as a single person holds all the power, but if you look around, that is how boards work usually. And some live fine with them. KDE, GNOME and Debian come to mind. They don't appear to be falling apart either having established definitive goals, target audiences, rules for interaction with outside vendors or even *gasp* establishing release schedules. However, there is a distinctive difference there: There is no need to negotiate with the industry. And since this is your original idea behind a board, these boards are pretty irrelevant. Even worse, you could at least have made your homework and look wether these projects even have a board. That's not the case, so I guess your agrument is (again) not backed up by facts. It doesn't help you to accuse me of not basing my opinions on fact, and I think that's pretty low of you. GCC (one of the largest free software projects) did fine, too, for a very long time. Indeed it has. Of course, it does have the Free Software Foundation (and no less than Stallman himself) as a guiding force behind it. But I That's just plain bullshit (sorry, but what are you trying to achieve with spreading such misinformation??). It's you who is making claims that are badly researched and shed a bad light on what you say. The guiding force behind gcc is purely the developer community. Even if you take the steering committee (which has power and says it guides), it only does so when the community can't make a decision. Neither of these is the FSF. The FSF has absolute power over gcc (the name), but as history has shown, it doesn't have power over gcc (the project). The current state of gcc is *exactly* the result of a board (of the FSF in this case) trying to force decisions. guess that doesn't count as a board in your opinion. Of course not, because it isn't a board. That is independend of my opinion, but a fact. Why do you get this personal? [apache] If by this you mean the board doesn't try to snatch control away from the developers then that's probably true. That's what I meant, yes. Boards are a concept alien to free software projects, since boards work like we decide, you do the work, which might work in corporate structures, but doesn't work at all in free software environments. You see the world as black and white, Marc. Not all boards are so manipulative. Well, if a board doesn't have any power, there is no need to create one in the first place. It serves no purpose if it cannot do anything. But there are many projects who could use an authoritative voice to keep the project moving. That is exactly the problem: an authoritative voice. Gimp already has authoritative voices. If your assumption is that authoritative voices and boards are the same thing, then you are mistaken. And if you think that boards and auth. voices are not the same thing, then it has nothing to do with this discussion. In other words: boards are not necessarily autoritative voices, and you don't need boards to have that. What _are_ your arguments for such an institution? for GNOME, and that project (even without a board, but with an authoritative figure at its helm) has done quite well. So that proves that boards aren't necessary, right? Boards are not even necessarily productive for a project. doesn't work at all in free software environments isn't even close to the truth here. Well, I disagree. The only counterexamples are boards without any power or voice. I wouldn't oppose those and agree they work fine with free software projects. You sound like you speak more from hate of anything that smells of authority than from research of the facts. Obviously I did my homework better than you for example. No, I don't hate boards.
Re: [Gimp-user] Re: CinePaint and Film Gimp
On Fri, Sep 12, 2003 at 03:09:32PM -0500, Michael J. Hammel [EMAIL PROTECTED] wrote: XFree86, Apache, and others all formed boards and/or non-profits to help deal with the situation. I believe its time the GIMP community seriously considered this as well. We should also consider that xfree86 currently falls aparts exactly because of the board (and wrecks for quite some time already). And many other projects live fine without boards, too. GCC (one of the largest free software projects) did fine, too, for a very long time. Apache probably has less problems because they try very hard not do decide things over the heads of other people. Boards are a concept alien to free software projects, since boards work like we decide, you do the work, which might work in corporate structures, but doesn't work at all in free software environments. Non-profit organizations are, on the other hand, often seperated from the project itself (esp. for the Gimp, as the developers feel afaics strongly against handing over the rights to the code to such an organization, which means it would have no rights at all to the gimp). Recently I hear a lot about target audience and have to work with the industry and similar ideas. In my opinion, this has exactly zero relevance. The question to ask is: how would a board/non-profit-org help the _developers_. One can create boards as much as one likes, this won't change nor create a single line of code or code-change. And if it doesn't help the people who write the code (e.g. by getting specifications or the like), then I don't see why such a thing should be founded in the first place. So what are the benefits of a board for the developers? How would that help them? How would such a board counter the frustration on the side of developers that a board exists that has power but no obilgations? Where does it get it's rights from? Who has to submit to it's decisions? How is it elected (if at all)? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: CinePaint and Film Gimp
On Fri, Sep 12, 2003 at 01:40:12PM -0700, Daniel Rogers [EMAIL PROTECTED] wrote: with as well - how to take a loosely organized group and work with outside, commercial groups who have more strict rules for interaction. XFree86, Apache, and others all formed boards and/or non-profits to help deal with the situation. I believe its time the GIMP community seriously considered this as well. it is not mearly being considered. It is happening. I disagree, and think both of you are not talking about the same thing. I know a not-for-profit organization (with no rights to the gimp) is being created, however, that is very far from taking a loosely organized group and work with commercial groups. The planned organization does not take the gimp group to do anything, as far as I can see. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Webpage Help
On Tue, Aug 19, 2003 at 09:33:31PM -0400, Daniel Carrera [EMAIL PROTECTED] wrote: Oh no, you missed the issue. It was not about a whitespace, it was about creating a NEWLINE. There was a whole blank line BELOW the image. Unless... a whitespace could somehow create that newline... maybe it wrapped around? Yupp. whitespace can be a new line, a space, or something else to seperate, as the browser sees fit. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Simple Radial Lines
On Tue, Aug 05, 2003 at 07:00:53PM -0500, Eric Pierce [EMAIL PROTECTED] wrote: I'm not after circles. I'm even lines radiating from the center. Did you see the gif link above? Just like that minus the circle in the middle. You could create a striped gradient fiurst and then use the gradient tool in conical mode. Maybe there are better solutions, but this solution is easily reusable :) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Writing gimp perl batch script
On Wed, Jul 30, 2003 at 03:44:11PM -0500, Michael Dingwall [EMAIL PROTECTED] wrote: Subroutine Gimp::gimp_file_load redefined at /(path to Gimp.pm/Gimp.pm on line 541 This is probably a bug in gimp-perl with the compatibility syntax. Could you try to use object-oriented syntax, i.e. Gimp-file_image_load (... $img-active_drawable; $img-file_save (...); and tell me wether that works? thx. however these warnings keep showing up. I've tried the trace mechanism and it crashes after the gimp_image_load statement. Woaw. How does it crash (I can't reproduce that here)? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] CMYK (was: Diaoppearing freefonts)
On Mon, Jul 14, 2003 at 04:36:39PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: You are only making things worse if you convert from RGB to CMYK Not really... people I talked to said they can perfectly handle that (adjusting colours later in a layout program for example, or simply addign a matching colour profile). On the other hand, many layout programs simply treat files as CMYK, even if they are RGB, which is a lot worse since it cannot be fixed easily. Also, no information is being destroyed, since you had no colour profile in RGB, the simple formula is a good as any other. would have long done. You should really let the printer do the conversion for you. Only the printer knows all the necessary details. Unfortunately, the printer often can't or won't do that, since the printer wants CMYK no matter what. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] xaos and gimp animation
On Wed, Jul 16, 2003 at 02:08:05PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: i need a script to convert x amount of png files into a single xcf file, is that possible ? Writing that script in Script-Fu or Gimp-Perl should be trivial. It might also work to just use a current version of imagemagick and do: convert *.png anim.xcf (maybe add some other switches to set fps etc.) or use another format instead of .xcf and convetr it to xcf by load/save within the gimp. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Scripting for resize
On Wed, Jul 16, 2003 at 06:14:53PM +0200, Sven Neumann [EMAIL PROTECTED] wrote: I'm just new to script-fu and gimp. I was not aware scheme is used for scripting in gimp. I loved that. :D Anyway, I've read the script-fu part of the gimp manual. I have a directory tree with about 1000 for i in '*.png'; do convert -sample 20x20 $i small-$i; done Sticking a ! at the end of the 20x20 will actually do the job. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] TIFF save - problem
On Wed, Jun 18, 2003 at 12:08:03PM +0200, Mariusz Sapinski [EMAIL PROTECTED] wrote: LZW compression in not available due to Unisys pattern enforcement I have'n enforced any Unisys pattern? What's going on? How to repair it? That should read patent instead of pattern. I am not sure wether this is a redhatism. In any case, LZW compression is likely affected by a patent hold by unisys (which will expire this friday in the us, and in one year in europe and japan), and thus either you get a license from unisys (don't bother, too expensive), or get a version of gimp that allows LZW and possibly commit crimes and and decapitated ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Intelligent scaling
On Thu, Jun 05, 2003 at 12:58:12PM +0200, Matthias Brunner [EMAIL PROTECTED] wrote: we have a lot of document scans, all sized 2432x3482 pixels, and and which colour depth? The problem is that the standard scale algorithm renders the document unreadable (some text characters can still be recognised, others not is this because you are scaling in indexed mode maybe? Is there some intelligent scaling process in gimp which takes care of text scans (keeping lines together, preventing distortion of I did a lot of scaling, and the gimp certainly works fine with this kind of job, as long as you allow it to use grayscale and interpolation. It also doesn't add distortion normally. Putting up an example to look at somewhere might be helpful. If the gimp indeed results in bad quality you might look into imagemagick, which allows you to select the filter form (lanczos or mitchell are two that are worth checking out). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] TIFF File Resolution Change
On Thu, Jan 09, 2003 at 01:52:18AM -0600, Kevin Myers [EMAIL PROTECTED] wrote: I think that perhaps this can be accomplished with ImageMagick, but I don't seem to be able to figure out the proper command line parameters. Well, you can't do it with ImageMagick ;) It does read the image in, and, since this is difficult in the general case, I doubt such a program exists. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gimp-Perl
On Thu, Dec 26, 2002 at 08:46:22PM -0600, Greg Oliver [EMAIL PROTECTED] wrote: problems. It appears that someone already has the same issues I have with running Script-Fu from perl (just like the tutorials said I would), but I am wondering if it applies to just scheme based script fu, or plugins as well? It applies to any script-fu plugin, and has (AFAIK) nothing to do with perl. It has worked from time to time, but most of the time, script-fu is broken in one way or another when being called from oter plug-ins. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Script-Fu - Batch Mode Problem
On Thu, Dec 26, 2002 at 07:04:42PM -, [EMAIL PROTECTED] wrote: convert sourcefile -filter mitchell -geometry newgeometry destfile ok, I tried thisand I got an image that was not up to par with what can be done with Adobe's Image ready doing a similiar process. However, with Gimp, I Well, there are also other filters. Quadratic or Cubic should closely emulate gimp's behaviour. But from the script I see that you are using jpegs. I hope you are aware of the fact that jpegs can and do introduce lots of pixel errors? Ok, if script-fu is not meant to be run from the command line without interactionthen why the batch mode option? To run script-fu from the commandline. The fact that script-fu is broken in lots of areas _currently_ does not mean it was designed to be broken ;) OTOH, Simon Budig always explains to me that script-fu was not designed for this kind of thing, and he knows a lot more about it. Based on the documentation I have seen, I should be able to call a script-fu function and everything should work. That is not the case. The script will (hopefully) enable some script-fu expert (not me) to find the problem. Or maybe fix script-fu, if it really is the problem. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gif support
On Mon, Dec 23, 2002 at 01:35:58AM -0800, Joshua Thorin Messer [EMAIL PROTECTED] wrote: Oh, wait when you wrote Currently browsers do not support PNG widely enough to use PNG instead you might have meant Currently The striking majority of browsers, not only IE on Windows. And PNG can't do animations, which are very important. So GIF will need to stay around for some time :( -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gif support
On Mon, Dec 23, 2002 at 11:23:38PM +1300, Thomi Richards [EMAIL PROTECTED] wrote: The striking majority of browsers, not only IE on Windows. And PNG can't do animations, which are very important. So GIF will need to stay around for some time :( which ones exactly? as stated before, mozilla, netscape (the later versions), konqueror, even dillo works with png's. That's a useless game. You can count the number of browsers supporting PNG with one or two hands. Obviously there exist many more browsers. Basically, that follows the all the world is windows and linux-way of thinking, which is just as bad as all the world is ie-way of thinking. Even most versions of the browsers (netscape, konquerer, and my more like links, opera etc.) you cited don't support PNG, or not properly. And probably none of them support MNG. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Gif support
On Mon, Dec 23, 2002 at 11:35:38AM -0500, PL O'Smith [EMAIL PROTECTED] wrote: Actually PNG does do animations and they are called MNG. Actually PNG does NOT do animations, and it's not called MNG ;) Both tiff and jpeg can store jpeg-like and losless images, they are still different. MNG and PNG a much more similar, but still different file format. have several thousand dollars lying around you want to use to pay the GIF owners for using those on your site, PNG pretty much takes care of everything now. Yes, except animations, which, while an understandable decision, is _probably_ the reason for the still widespread usage of GIF. Also, you don't have to pay anything for GIF support, and nobody owns it. The problem are lzw-compressed gifs, which are the most common. Please, read my original post. It makes no sense arguing about sth. I didn't say nor think myself :) My original post stated a fact. You might not like it, I _do_ not like it, it might not even be of practical consequences (who cares for minority platforms), but all that doesn't change it. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] FAQ answers
First of all, please don't quote such a long mail without replying to it. Believe us, we _did_ reeceive the original mail, too ;) On Thu, Dec 19, 2002 at 04:26:26PM -0800, [EMAIL PROTECTED] wrote: *) How does the Xtns/Script-Fu menu differ from the Script-Fu pop-up menu? When I right-click on an image and get the context menu, there is a Script-Fu option at the bottom. That is the Script-Fu pop-up I was referring to. :) Well, they are completey different. Or, put another way: The right-click-menu (image menu) contains operations/plug-ins that work on the active/current image. The filters and script-fu entries use the underlying image as one of their arguments. The Xnts-menu (the whole toolbox, actually) contains effects and plug-ins (and other operations) that work without images (for example, there is no file/save). Most plug-ins in the toolbox or xtns-menu create new images. As a sidenote, the fully artificial distinction between script-fu-plug-ins and other plug-ins confuses a lot of users (the same is true for the xtns menu. I fail to see why a user must memorize that a specific plug-in is wirtten in C, Perl, or script-fu, just to _use_it). All of these should just be moved to their correct location, ending this confusig double-life. -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: New Gimp FAQ: Call for questions
On Thu, Dec 19, 2002 at 03:28:17PM -0500, Carol Spears [EMAIL PROTECTED] wrote: At what point is it better to use The GIMP for batch processing over Image Magick? For one, whenever you want to interactively adjust sth. ImageMagick is a blind flight, with gimp you can more easily change parameters, retry etc.. Also, Gimp might have that effect of the day you really need. In this case ImageMagick simply isn't an option. And the Gimp has _lots_ of effects ;) The same is true for any script or function that is available for the gimp but not ImageMagick. Last not least, ImageMagick can be a memory hog and almost always is extremely slow in everything. Gimp can be a lot faster, and when you have to process 20,000+ images that might save a lot of hours. nicer than Image Magick. I read from someone (jlbec on #gimp) that The GIMP hands saving as png much much better than Image Magick. so i would Well, we'd like to know in what respect ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Re: CMYK separation
On Thu, Oct 10, 2002 at 10:53:39AM -1000, Denis McCauley [EMAIL PROTECTED] wrote: tried it on a friend's computer and apart from CMYK conversion and print preparation it has virtually nothing The Gimp can't do. In the end I bought Somebody please step forward and implement cheap CMYK seperation for the .eps save filter. The biggest problem is that many printshops (er, typesetters, actually) will treat RGB images as CMY0 which obviously destroy them. That's rather cost effective (one gets much without much effort, although it's still missing too much). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Scripted Gimp Protocol 1 error
On Wed, Apr 17, 2002 at 12:03:14AM +, As Signed [EMAIL PROTECTED] wrote: Could anyone please help me get a perl script invoked from HTML via the local server run Gimp? Run the script with -v to see gimp's error message. Protocol error 1 most probably means that gimp couldn't start. Most probably you don't have a valid DISPLAY in your environment. Gtk-WARNING **: cannot open display: Looks very much so. Set DISPLAY to a valid display and gimp will start. ... the above 2 are less valuable as I DON'T want display. Well, but gimp does ;) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] spam
On Mon, Nov 19, 2001 at 07:04:32PM -0500, Geoffrey [EMAIL PROTECTED] wrote: I think spam filtering is basically an end-user problem. There is no way to make lists spam-free, so not large seems fine to me. You can, by only permitting subscribers to post to the list, which many lists do these days.. Which I consider counter-productive. Forcing users to subscribe to a mailinglist just to be able to post doesn'z seem right (for mayn, not all, mailinglists). -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | | ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] pdb error and perl-fu'ing
On Sun, Jul 01, 2001 at 08:20:19PM +0200, [EMAIL PROTECTED] wrote:
some more perl-fu'ing (is there a specific perl-fu mailinglist?)
yes, see gimp.pages.de for details.
Is there anyway to test if a given is a valid gimp image file?
no, and gimp can crash if you feed it garbage. not that often anymore but
it can still happen.
advanced, how do you trap pdb-errors?
just like any other perl exception, using eval { xxx }.
--
-==- |
==-- _ |
---==---(_)__ __ __ Marc Lehmann +--
--==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e|
-=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+
The choice of a GNU generation |
|
___
Gimp-user mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
