[Gimp-developer] jobs for the boys: RIP coders wanted

2003-11-04 Thread Austin Donnelly
Hi GIMPers,

I know this is a little off-topic, but it's definitely interesting to anyone
looking for a job in the pre-press software industry.

Ben Hobbs (from Idealpeople, a recruitment firm) is looking for people with
experience of RIPs, and other pre-press issues.  I've put a message from him
below.

Thanks,
Austin

---
Hi Austin,

I have been enjoying your explanations on FM Screening and dithering, They
have helped me understand one of our specs a great deal more, Thanks.

We have recently set up a division (me) to focus exclusively on recruitment
for the pre-press/print technology industry and are finding it hard to come
by candidates.

We are currently after:

* RIP Coder with experience of Colour Management (ICC Profiles etc...) -
Australia Permanent position with full help in re-location, work permit and
immigration issues.

* Screening Consultant for a RIP company in Europe

* RIP Coders for a UK based company (London)

Do you know anyone who would be interested in any of these positions, If so
then please let me know!

Basically we are interested in all coders with experience of RIP's, PCL and
digital print technologies overall.  This is really very appreciated, its
actually been very refreshing for me trying to source these vacancies.  The
help people have given me I have not seen in any other area of software
development, Oh and we are particularly interested in Linux guys for the
Australian role.

Regards,
Ben Hobbs
Idealpeople


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Gimp 1.3.22

2003-11-04 Thread Sven Neumann
Hi,

Tor Lillqvist [EMAIL PROTECTED] writes:

   and also libgimpbase/gimpwin32-io.h
 
 That probably should be added to libgimbase/Makefile.am's EXTRA_DIST?
 The EXTRA_HEADERS macro doesn't seem to be used for anything in the
 generated Makefile?

I don't think EXTRA_HEADERS is a valid automake macro at all.

I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it
used only in the GIMP source tree or is it supposed to be installed so
external plug-ins can use it as well? Anyway, it should certainly be
added to libgimpbase_1_3_la_SOURCES.

Tor, will you take care of this? Can you remove the empty
EXTRA_HEADERS line from libgimpmodule/Makefile.am while you are on it?


Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] Re: GimpDialog API change

2003-11-04 Thread David Odin
On Tue, Nov 04, 2003 at 12:28:09PM +0100, Michael Natterer wrote:
 Hi,
 
 As you may know, GimpDialog from libgimpwidgets badly needs an
 API change for GIMP 2.0.
 
 The relevant bugzilla entry:
 http://bugzilla.gnome.org/show_bug.cgi?id=125143
 
 The plan is to just remove our own action_area API and use GtkDialog's
 one, which involves making use of the dialog's response signal
 instead of connecting to each button's clicked.
 
 The old API is just way too complicated and does things nobody
 really needs. The new stuff boils down to one function:
 
 /**
  * gimp_dialog_new:
  * @title:The dialog's title which will be set with
  *gtk_window_set_title().
  * @role: The dialog's @role which will be set with
  *gtk_window_set_role().
  * @parent:   The @parent widget of this dialog.
  * @flags:The @flags (see the #GtkDialog documentation).
  * @help_func:The function which will be called if the user presses F1.
  * @help_id:  The help_id which will be passed to @help_func.
  * @...:  A %NULL-terminated @va_list destribing the
  *action_area buttons.
  *
  * Creates a new @GimpDialog widget.
  *
  * This function simply packs the action_area arguments passed in ...
  * into a @va_list variable and passes everything to gimp_dialog_new_valist().
  *
  * For a description of the format of the @va_list describing the
  * action_area buttons see gtk_dialog_new_with_buttons().
  *
  * Returns: A #GimpDialog.
  **/
 GtkWidget *
 gimp_dialog_new (const gchar*title,
  const gchar*role,
  GtkWidget  *parent,
  GtkDialogFlags  flags,
  GimpHelpFunchelp_func,
  const gchar*help_id,
  ...);
 
 
 Of course there will be a _valist() variant.
 
 I'll start hacking this today but would like to get some ACKs or EEKs
 before I start porting the plug-ins (which have many many GimpDialogs).
 
  You have my bless on this. As I've said I can help you converting some
of the plug-ins.

DindinX

-- 
[EMAIL PROTECTED]
#include ctype.h
b;main(c,v)char**v;{for(c=0;v[1][c];c++){**v=v[1][c];putchar(islower(**v)?
97+(**v-97*2+v[2][(c-b)%strlen(v[2])])%26:(b++,**v));}putchar(10);}
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] GimpDialog API change

2003-11-04 Thread David Neary
Hi Mitch,

Michael Natterer wrote:

snip

 GtkWidget *
 gimp_dialog_new (const gchar*title,
  const gchar*role,
  GtkWidget  *parent,
  GtkDialogFlags  flags,
  GimpHelpFunchelp_func,
  const gchar*help_id,
  ...);

This looks good to me.

 I'll start hacking this today but would like to get some ACKs or EEKs
 before I start porting the plug-ins (which have many many GimpDialogs).

One question... do you think it would be worthwhile to make the
API change, document what needs to be done to change from the old
API to the new, and then have a number of people work on porting
the plug-ins? Each plug-in in itself would probably be a small
job, but the lot of them might take you a while.

Would this be worthwhile? I would certainly do a few plug-ins,
are there others who would be able to help out here?

Cheers,
Dave.

-- 
   David Neary,
   Lyon, France
  E-Mail: [EMAIL PROTECTED]
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


[Gimp-developer] ANNOUNCE: Gimp-Print 4.3.23

2003-11-04 Thread Robert L Krawitz
Gimp-Print 4.3.23, released November 4, 2003, is a development
release of this package.  Like all development releases, this version
is considered unstable and should only be used by those individuals
tolerant of the likelihood of problems.  Individuals desiring a stable
release of Gimp-Print should use the latest 4.2 release.

Gimp-Print is a suite of printer drivers that may be used with most
common UNIX print spooling systems, including CUPS, lpr, LPRng, or
others.  These drivers provide high quality printing for UNIX
(including Macintosh OS X 10.2 and newer) and Linux systems in many
cases equal to or better than proprietary vendor-supplied drivers, and
can be used for many of the most demanding printing tasks.

This software includes the Print plug-in for the Gimp, and Ghostscript
and CUPS drivers, including Foomatic data.

The Print plugin for the Gimp requires the Gimp 1.2 (later versions of
the Gimp are not supported).  You may need to install a package named
gimp-devel or the like on many distributions.

The CUPS driver requires CUPS 1.1.15 or higher.  You may need to
install a package named cups-devel or the like on many
distributions.  We strongly recommend using CUPS with Gimp-Print as a
general-purpose printing solution.

We do not currently recommend using Foomatic, as the Foomatic data
generator included with Gimp-Print offers very limited capabilities.
This will be fixed in a future release.  The Foomatic data will work
with either Foomatic 2.x or 3.x.  Foomatic 3.x has additional
capabilities that this package detects and takes advantage of.

The IJS-based GhostScript plugin driver requires GNU Ghostscript 6.53
or later, ESP Ghostscript 7.05 or later, or APFL GhostScript 7.04 or
later.

Users of Macintosh OS X 10.2 and above can use this package, as the
printing system is based on CUPS, which is supported by Gimp-print.
Note that Macintosh OS X 10.0 and 10.1 (including 10.1.5) cannot use
this package.

Please read the README file for full instructions on installing this
package.


Gimp-Print 4.3.23 contains the following major changes over Gimp-Print
4.3.22:

1) A failure to compile with gcc 2.x that was introduced in 4.3.22 as
   part of making inlining work correctly in gcc 3.x has been fixed.

2) The Epson driver now allows a choice of weave patterns.  Depending
   upon the printer, paper type, and/or resolution you may find that a
   weave pattern other than the default works better.

-- 
Robert Krawitz [EMAIL PROTECTED]  

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail [EMAIL PROTECTED]
Project lead for Gimp Print   --http://gimp-print.sourceforge.net

Linux doesn't dictate how I work, I dictate how Linux works.
--Eric Crampton
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer


Re: [Gimp-developer] Re: Gimp 1.3.22

2003-11-04 Thread Tor Lillqvist
Sven Neumann writes:
  I am not sure about the purpose of libgimpbase/gimpwin32-io.h. Is it
  used only in the GIMP source tree or is it supposed to be installed so
  external plug-ins can use it as well? 

I assume it is to be used only in the source tree.

  Anyway, it should certainly be added to libgimpbase_1_3_la_SOURCES.
  Can you remove the empty EXTRA_HEADERS line from
  libgimpmodule/Makefile.am while you are on it?

Sure, done.

--tml


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer