Re: [Gimp-developer] Size entry widgets..
On Wednesday, 27 Mar 2002, Øyvind Kolås wrote: * My workflow for posters that will be printed on a laser printer is: - make a new grayscale image with the same size ratio as A4/A3 - fullfil the design - scale the image up to the full res of the 'printable area' - manually newsprintifying, dithering etc. the image down to 1bit Warning: the newsprint plugin does nothing to avoid moire artefacts other than offer an antialias option. It doesn't use supercells to reduce rounding errors. Therefore, if you're using it to produce 1-bit output (and hence can't use antialiasing) then you should expect poor quality output. The newsprint plugin is suitable for producing (eg) silk-screens for t-shirt designs, or special effects, but not for printed flyers, in my opinion. Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
RE: [Gimp-developer] amp photoshop curves
On Friday, 29 Mar 2002, regis rampnoux wrote: You can load the files with the plug-ins amp4gimp which is in the registery. (I found yesterday a bug but you can use it ...) There is no save option at this moment. If the amp format is simple enough, why don't we just make it the default format for Gimp curves too? Austin ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: amp photoshop curves
[EMAIL PROTECTED] (2002-04-04 at 1143.34 +0100): If the amp format is simple enough, why don't we just make it the default format for Gimp curves too? The problem I see is that it means not under GIMP people control (basicaly about improving, I doubt the format would change). For example, when moving to 16 bits or other modes, I do not see PS AMP 256 entries LUT or GIMP 17 entry curves as the way to go. It sounds absurd to work in such high mode and then limit other things to brute approximations. Or think about supporting extra channels, AMP only supports one or three channels. Leaving room for improvement should be taken into account. I think it is better to write an external converter (uum, it already exists :] ) than support two formats or discard current (is there any gimp2amp?) and then try to workaround problems in the future. GSR ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Curves files
On 04-Apr-2002 Guillermo S. Romero / Familia Romero wrote: example, when moving to 16 bits or other modes, I do not see PS AMP 256 entries LUT or GIMP 17 entry curves as the way to go. It sounds absurd to work in such high mode and then limit other things to brute approximations. I have a question about this limitation: why the Gimp spline curves is limited to 17 entries and the procedure gimp-curves-spline use a 32 items array of points? May be it is not the same goal but that is the difference? -- regisr http://regisr.regix.com/ portail photo http://www.regix.net magazine http://www.regix.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
Roger Leigh [EMAIL PROTECTED] writes: so should we speak of gnu-bsd-mpl-qpl-artistic/linux ? or, as gpl softwares number is greater than gnu/fsf ones, should we speak of gpl/linux ? A distribution is much more than an operation system. If you just look at the core components that make up the OS (I'm sure that there will be plenty of contention regarding what these are ;-) then you have a Linux kernel, and GNU tools. looking at what the mandrake basesystem package requires as minimal system : util-linux (swapon, mount, ...), e2fsprogs, lilo, initscripts, console-tools, chkconfig, SysVinit, bdflush, kernel, losetup, net-tools, modutils, procps, psmisc, rpm, sysklogd, are all linux specific tools. only fileutils, grep, findutils, glibc're a gnu project part. there's other small gnu packages requires (time, textutils, sh-utils...) but they're less important than previous ones. Most of the other programs are not essential--a bare bones system will be mostly GNU stuff. looking at the above, this is *very*, *very* mitigated When talking about the kernel, `Linux' is appropriate, but when talking about the /operating system/ as a whole `GNU/Linux' is more accurate, nope since gnu tools (yet an important part of the os) are'nt the essential part. neither is the bsd tools part. neither're gpl linux specific tools, ... this is why i think linux and gnu/linux are equivalent (that is they're equally mis-naming conventions) on a technical point. on an ethic point, gnu/linux win since it hold a reference to the gnu project and the fsf work. on an historic point, linux win since everybody knows or had heard about linux. but gnu/linux is rarer, despite rms advertising campaing. don't misunderstand me: i respect a lot stallman's work; contrary to many (mis-educated?) people, i don't see him as a fanatic; i see him as the man who pushes the communauty in the right direction. but on the gnu/linux point, the situation isn't as clear as he claims it is. why not forcing gnu/atheos, gnu/freebsd (for the ports part), ... this is NOT coherent with forcing gnu/linux. especially since you could replace the kernel with Hurd or BSD and from the POV of the user (or programmer) there would be little noticeable change but the GNU part would still be there. nope, you would get a lot of bsd stuff in the os core ... The GNU tools are the actual part the user (and programmer) will interact with, be it bash, grep, gcc or glibc. depending of the view point. as a packager[1] and a developper, i massively use gnu tools : compilation chain (binutils, glibc, gcc), emacs (development, mail, newsgroups, diary, ...) but not only them : i also uses gnus and various others packages for emacs, rpm, the kernel, windowmaker, screen, but for an end user, kde or gnome're far important blocks of the os... and're not part of the gnu project _despite_ they're gpl. one cannot account {g,}ui as basic os componant. then, yes glibc is a big part, but as important to bootstrap the systems as the sysv infrastructure (init, boot scripts, ...), packaging infrastructure (rpm/urpmi or dpkg/apt), system maintenance tools (reiserfsprogs, e2fsprogs, jfs-utils, util-linux, ...). there'sn't just a majority: the gnu part is as important as other componants of the os :-) [1] as gimp packager for mandrake, i'll have to package gimp-1.3.x for contribs in not so many time ... :-) -- Still untested beyond 'it compiles' (davej) ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP_HOST
Can anyone tell me how I would supply the GIMP_HOST environment for a gimp-perl server. I am trying to execute a script that call's the server, but am getting a protocol error. From information that I have located it looks as if I need to set the auth in the GIMP_HOST. The following is the error message that I am getting. protocol error (1) at /usr/lib/perl5/site_perl/5.6.0/i386-linux/Gimp/Net.pm line 66 ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
That depends a whole lot on what is in a bare bones system, does it not? I feel confident that I can build an entire bare bones system without having any programs in this system being from GNU packages. The GNU percentage depends highly on what the distribution provider puts into it. Since I deal mostly in 'bare bones' systems such as firewalls and tightened machines, the GNU percentage is very low. I would venture to say I have significantly more programs of other origin than GNU. Therefore, my definition of bare bones systems is opposite what yours is. Linux is Linux, what's added on after that is a varying figure. my two bytes on the subject, David Roger Leigh wrote: [...] A distribution is much more than an operation system. If you just look at the core components that make up the OS (I'm sure that there will be plenty of contention regarding what these are ;-) then you have a Linux kernel, and GNU tools. Most of the other programs are not essential--a bare bones system will be mostly GNU stuff. When talking about the kernel, `Linux' is appropriate, but when talking about the /operating system/ as a whole `GNU/Linux' is more accurate, especially since you could replace the kernel with Hurd or BSD and from the POV of the user (or programmer) there would be little noticeable change but the GNU part would still be there. The GNU tools are the actual part the user (and programmer) will interact with, be it bash, grep, gcc or glibc. Just my tuppence, Roger ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GNU/Linux vs. Linux
Actually, his name is Linus Torvalds =) He got the X because of the X at the end of Unix. First he was planning to call it FreaX or something, as in FreeX and Freaks =) Just a bit of information, so that his name wouldn't be mistaken for his OS =) Have a nice day -Nas On Fri, 2002-04-05 at 01:46, Branko Collin wrote: What is our stand on using the name Linux or the name GNU/Linux. For those who do not know: the OS Linux was built by Linux Torvalds in 1991. -- branko collin [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer