Re: Instructions needed
I want to unsubscribe from the gimp-developer list (am still on the user list) but I cant remember how :-( It will be of a great help if a kind soul would mail me the instructions so that I can unsubscribe. I hope this will help you. bye. FUJITA Yuji [EMAIL PROTECTED] http://www.wl.me.titech.ac.jp/~yuji/yuji-pubkey.asc Hi! This is the ezmlm program. I'm managing the [EMAIL PROTECTED] mailing list. This is a generic help message. The message I received wasn't sent to any of my command addresses. --- Here are the ezmlm command addresses. I can handle administrative requests automatically. Just send an empty note to any of these addresses: [EMAIL PROTECTED]: Receive future messages sent to the mailing list. [EMAIL PROTECTED]: Stop receiving messages. [EMAIL PROTECTED]: Retrieve a copy of message 12345 from the archive. DO NOT SEND ADMINISTRATIVE REQUESTS TO THE MAILING LIST! If you do, I won't see them, and subscribers will yell at you. To specify [EMAIL PROTECTED] as your subscription address, send mail to [EMAIL PROTECTED]. I'll send a confirmation message to that address; when you receive that message, simply reply to it to complete your subscription. --- Below this line is a copy of the request I received. Return-Path: [EMAIL PROTECTED] Received: (qmail 80351 invoked from network); 28 Jan 2000 11:49:20 - Received: from hoy.hss.titech.ac.jp (HELO hoy.wl.me.titech.ac.jp) (131.112.30.21) by scam.xcf.berkeley.edu with SMTP; 28 Jan 2000 11:49:20 - Received: (qmail 21507 invoked from network); 28 Jan 2000 11:50:29 - Received: from localhost (127.0.0.1) by localhost with SMTP; 28 Jan 2000 11:50:29 - To: "gimp-developer-sc.949060124.alemjcdioaebajacffae-yuji=wl.me.titech.ac.jp."@xcf.berkeley.edu, [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: ezmlm response From: FUJITA Yuji [EMAIL PROTECTED] In-Reply-To: [EMAIL PROTECTED] References: [EMAIL PROTECTED] X-Mailer: Mew version 1.94b15 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: [EMAIL PROTECTED] Date: Fri, 28 Jan 2000 20:50:28 +0900 Sender: Fujita yuji [EMAIL PROTECTED] X-Dispatcher: imput version 990323(IM111) Lines: 0
Re: 1.1.19-installation fails
Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Bill Sebok Computer Software Manager, Univ. of Maryland, Astronomy Internet: [EMAIL PROTECTED] URL: http://www.astro.umd.edu/~wls/
Re: 1.1.19-installation fails
On Thu, 6 Apr 2000, "William L. Sebok" [EMAIL PROTECTED] wrote: Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. Hmmm... What he meant is slightly different, but close... When running the "configure" script, it runs some tests to detect what is on your system. Some of these tests are derived from the contents of the file aclocal.m4 that you can find in the top-level directory of the Gimp sources. The file aclocal.m4 is assembled (when the package is rebuilt) from a collection of *.m4 files provided by various packages. One of them is gettext.m4, which contains the tests for checking if gettext is present on your system. The problem is that the tests are verifying if your system has a working version of "msgfmt", "xgettext" and some other tools, but it does not check for the presence of "msgmerge". So it is wrong to assume that "msgmerge" is present if the tests for gettext are successful. Some Linux distributions as well as all versions of Solaris come with "msgfmt" but not with "msgmerge". I think that the only solution is to add a new test with AC_PATH_PROG or something similar in configure.in. -Raphael
Re: JPEG correction (was Re: Gimp Wishes)
On Thu, Apr 06, 2000 at 01:20:50AM +0200, Marc Lehmann wrote: As such, why save an image if you didn't change it? There is no good reason why a PROFESSIONAL graphic designer should be doing it, but lots of us are mere amateurs :) JPEG works one tile at a time. The same behaviour I observe in one image will be true on average for individual tiles, so if I alter only one half of an image (or only touch up one word) and save with the same quality as the original, the untouched tiles will be mostly unharmed. A classic example (which I won't distribute because it's obviously illegal) is a re-touched Matrix JPEG from the movie site, altered to replace Keanu with Windy Miller from the old UK television shows. By fiddling carefully with JPEG settings we can get the "right" setting to make the hacked version look like the original, without additional artifacts in the unaltered portions of the image. Looks great! Given that the problem is unsolvable in theory and almost impossible even to approximate in practise, I believt hat such a automatic detection scheme will fool people into thinking that saving at the same quality wouldn't destroy their image. I don't want that, people shouldn't be using JPEG for works in progress or as a common format moving between packages or ANYTHING like that, and I agree that we don't want to give them false expectations. The problem here is that different encoders have different notions of "quality settings", and in most cases you can only approximate the quality setting of another encoder (quality settings are just a quick way to describe a 8x8 matrix, and setting up that matrix is very much decoder-dependent) I think Marc and I agree on the realities of this situation, I just wanted to make clear that "lossy" re-saving doesn't necessarily cause any damage to the image. But that's NO REASON to be doing it, and no reason for Gimp to encourage it either. That was a public service announcement from the lossy compression posse Nick.
Re: 1.1.19-installation fails
On Thu, Apr 06, 2000 at 11:05:10AM -0400, "William L. Sebok" [EMAIL PROTECTED] wrote: Marc Lehmann [EMAIL PROTECTED] says: The problem is that gettext itself does the detection (and so the only solutioon would be to rpelace the gettext.m4 macros by our own versions). I only get the results. You mean the gnu version of gettext itself does the detection of msgmerge. The problem is that the gnu version of gettext (and msgfmt) is not the only such version. In particular, there is a Solaris gettext and msgfmt but no msgmerge. I know (that's why I also do not understand why the .mo files, which are os/architecture dependent, should be distributed with the gimp). The problem is: gimp uses gnu gettext for detection of msgfmt/msgmerge etc.. (regardless of which version is installed on the target system). It is difficult to change this except by re-writing that part, and it does not try to detect availability of a compatible msgmerge. Obviously, I am not keen on re-implementing the whole gettext package just for perl (I had to re-implement most of it already, since it cannot be extended to other languages). :( So I am for a working-but-maybe-not-compliant-to-the-undocumented-gettext solution, but it is difficult to achieve that :( The current (soon-to-be-checked-in) solution to this problem will be to disable any automatic po updates (which requires msgmerge). If translators want an updated pot or po file, they have to "make -C po update-po" themselves (or run po/update.sh) manually. (Which was how it was done a long time ago) -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
Color Quantization
The aim of GIMP is not only to be as good as Photoshop but become better than this program. So it would be fine to implement features that even commercial programs don't have. The common color quantization algorithms have many disadvantages, but there is a very new called Spatial Color Quantization (http://www-dbv.informatik.uni-bonn.de/quant/) that is better than all other methods. Is there anyone who has enough time to implement this very good algorithm. Martin
Improved Export behaviour for non-alpha backgrounds
I'd like to propose a change to Export behaviour, or possibly to the Merge Visible Layers feature, depending on what other developers think about the following: 1. Create new image with pink background 2. Add layer, draw picture of bird 3. Save as PNG = Result is an RGBA PNG, 121Kb 4. Flatten, Save again = Result is RGB PNG, 105Kb The trouble is that "Merge Visible Layers", which is currently recommended for any multi-layer image saved to a transparency capable image file format, adds an alpha layer to resulting layer, even if the lowest visible layer was a non-transparent background. I don't think altering Merge Visible Layers is the right thing to do, there would doubtless be a number of surprises waiting if I did it. Instead, I propose to change Export to recommend "Flatten" when it notices that the bottom layer has no alpha channel AND is visible, when it would current recommend "Merge Visible". This will improve compression ratios for PNG, TGA etc., as well as increasing available colors for GIF and colormapped PNG. Comments? Objections? Nick.
