Re: 1.1.19-installation fails
On Mon, Apr 10, 2000 at 12:26:46AM +0200, [EMAIL PROTECTED] wrote: Distributing the .mo files means you need gnu gettext on your system anyway, so I do not really see the point. You have to have gettext, indeed, but you don't have to have the tools! That's a big difference. gettext itself is a part of glibc2 and if Maybe you are not aware that glibc2 is installed only on a minority of operating systems. you compile GIMP for libc5 it'll be autotically linked into the binaries, so if you don't want to compile GIMP you don't need gettext. That means that we won't be able to use the native gettext implementation, but always build our own libintl. There is just one problem with this approach: gimp does not yte know that this is the case, i.e. it will try to use the native gettex implementation. Just curious: which one? It's very hard to believe, sort of braindamage... Do you read gimp-developers? Sorry if I told you something that ain't right. Would you please tell me WHAT of the information I gave you has been wrong to give me a change to correct my mind (maybe even other sosurces)? Do you read your mail? -- -==- | ==-- _ | ---==---(_)__ __ __ Marc Lehmann +-- --==---/ / _ \/ // /\ \/ / [EMAIL PROTECTED] |e| -=/_/_//_/\_,_/ /_/\_\ XX11-RIPE --+ The choice of a GNU generation | |
CVS access
Hi, First of all I'm not subscribed to this list so Cc me the replies, please. I'm a member of the official Polish GNU Translation Team and I was doing polish translation since GIMP version 0.99-something. The question is: how I can get write access to CVS "po*" trees? Or should I just send gimp*.pl.po to this list (~100kB of gzipped data :) ? thanks in advance and best regards, Pawel -- Pawel Dziekonski | Wroclaw University of Technology [EMAIL PROTECTED] | Molecular Modelling Lab http://ozon.ch.pwr.wroc.pl/dzieko | Poland
BUG: gdyntext is dead
Hello, since 1.1.17 (maybe before and maybe the gimp version is unrelated to the problem) the gdyntext-plugin produces no result. Oh it produces a new but just too small layer with the necessary parasites -- but the text isn't visible. I have tested: o gimp-1.0.4 with gdyntext-1.4.1 that goes well in the past so this looks like some changes in the environment o gimp-1.1.1[789] with the packaged gdyntext and the actual gdyntext 1.4.4 dircet from the authors website o disable the ttf-fontserver (xfsft-1.1.6) xset -fp tcp/localhost:7100 xset fp rehash o running gdyntext with "-DDEBUG" enabled gives GDT: space width = 2 GDT: 34x 5 A: 4 D: 1 [Hallo Welt!] GDT: MH:5 LH:4 My system: linux-2.2.1[14] xfree86-3.3.5 glibc-2.1.2 gcc-2.95.[12] xfsft-1.1.6 only for ttf -- x-fonts and typ1 through the X-Server gtk+-1.2.7 The (script-fu gimp_text_get_extends ...) given on the console shows a resonable behaviour. Yours Uwe Koloska -- mailto:[EMAIL PROTECTED] http://rcswww.urz.tu-dresden.de/~koloska/ ---- right now the web page is in german only but this will change as time goes by ;-)
Export behaviour for fully transparent backgrounds
Goal: Make an image with a transparent background for your web-page, clip-art, etc. Issue: PNG file size is bloated by losslessly saving "invisible" data. . Acquire image, . Select the backdrop, leaving the subject of the picture untouched, . ensure the drawable has an Alpha channel, . Erase or Clear the selection, . save as PNG. Thing is, gimp does erase/clear by setting the alpha component to fully transparent, but doesn't touch the other channels. So you can load up that image again, move the alpha channel back to opaque, and the background you erased comes back in full detail. This isn't a bug, as png is a lossless format, but saving all that detail which you intended to discard is a feature that does increase your file size. Solution? Perhaps just a footnote in the manual and the help page for the PNG save-filter. Or maybe semi-lossy filter to optionally run upon export, which replaces the data in these invisible pixels with more compressible stuff. The "GIMP That's Smarter Than You Are" (sponsored by the Corporation for Using Technology to Further Human Inferiority Complexes) could detect this fairly trivially, and ask if you really meant to be saving that stuff. The semi-lossy filter could be as simple as this mathmap[1] filter: if alpha(origVal(xy)) == 0 then rgba:[0,0,0,0] else origVal(xy) end although it's imaginable that some color which matched the non-invisible parts of the image would be more compressible than 0,0,0. A more complex "lossy filter" would require intimate knowledge of the export format, and (now I'm starting to stray into the jpeg thread) could do things like the "jpeg-blur" mentioned recently. I do like the neatness of the idea of being able to select which parts of the image may have their quality sacfiriced to achieve better compression, while the subject of the image retains most of its quality, but I feel like that problem might get rather tricky and the returns in practice may be fairly small... [1] MathMap plug-in: http://www.complang.tuwien.ac.at/~schani/mathmap/ A plug-in which lets you rapidly make a variety of filters. Good fun and useful in developing your own filters and effects. -- Kevin Turner [EMAIL PROTECTED] | OpenPGP encryption welcome here
Re: Export behaviour for fully transparent backgrounds
On Tue, Apr 11, 2000 at 02:58:38AM +0200, Sven Neumann wrote: Hi, On Mon, Apr 10, 2000 at 05:20:03PM -0700, Kevin Turner wrote: Goal: Make an image with a transparent background for your web-page, clip-art, etc. Issue: PNG file size is bloated by losslessly saving "invisible" data. IMHO, this should be handled completely inside the PNG plug-in. Why? Nick.
