Re: [Gimp-developer] Size entry widgets..

2002-04-04 Thread Austin Donnelly

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

2002-04-04 Thread Austin Donnelly

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

2002-04-04 Thread Guillermo S. Romero / Familia Romero

[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

2002-04-04 Thread regis rampnoux


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

2002-04-04 Thread Thierry Vignaud

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

2002-04-04 Thread Todd Preuss


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

2002-04-04 Thread David Ford

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

2002-04-04 Thread Nasim Shamlou A.

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