gimp-print-devel

[Gimp-print-devel] Canon Driver

[Andy T. <th...@ph...>]

Just committed my newest version of the canon driver which should now support
the models
    BJC 1000
    BJC 2000
    BJC 3000
    BJC 6000
    BJC 6100
    BJC 7000 (except 7color)
    BJC 7100 (except 7color)

I invite everyone to test the driver extensively, play with density and gamma
values and send reports to me.

I know the colors are looking quite terrible at the moment, but first of all
I'd like to get reports if the various models do print at all. The driver
seems to work fne with my bjc6000 - so much I can say.

May the development release come :-)

Andy.

Re: [Gimp-print-devel] autoconf

[<sh...@al...>]

> It doesn't work for me.  Perhaps I have an old version of autoconf?
> 
> [2(rlk)||{!600}<rlkppp>/mnt/sandbox/gimp-print/print]
> $ autoconf
> [2(rlk)||{!601}<rlkppp>/mnt/sandbox/gimp-print/print]
> $ ./configure 
> loading site script /usr/local/share/config.site
> Processing GNUstep site configuration
> creating cache ./config.cache
> ./configure: line 526: syntax error near unexpected token `AM_INIT_AUTOMAKE(p
> rint,'

Did you run "aclocal" first?

I'll write a build script tonight to simplify this a bit.

Eric

[Gimp-print-devel] development release?

[Robert L K. <rl...@al...>]

I think it's time we start thinking about what should go into the
3.1.0 development release.  I'd like to do one as soon as we have
something with sufficient functionality over 3.0.5 so that people
would like to play with it, even though it won't be solid.

My thought is that we need the following in order to do this:

1) A fully working configure script.

2) Some documentation.

Once we get either Canon or newer Epson printers at least limping, it
seems to me that we've made the functionality bar.

Anyone have any strong feelings on this?  We should release sooner, we
should wait longer...?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] autoconf

[Robert L K. <rl...@al...>]

It doesn't work for me.  Perhaps I have an old version of autoconf?

[2(rlk)||{!600}<rlkppp>/mnt/sandbox/gimp-print/print]
$ autoconf
[2(rlk)||{!601}<rlkppp>/mnt/sandbox/gimp-print/print]
$ ./configure 
loading site script /usr/local/share/config.site
Processing GNUstep site configuration
creating cache ./config.cache
./configure: line 526: syntax error near unexpected token `AM_INIT_AUTOMAKE(print,'
./configure: line 526: `AM_INIT_AUTOMAKE(print, 3.1.0, no-define)'
[2(rlk)||{!602}<rlkppp>/mnt/sandbox/gimp-print/print]
$ autoconf
[2(rlk)||{!603}<rlkppp>/mnt/sandbox/gimp-print/print]
$ !./
./configure 
loading site script /usr/local/share/config.site
Processing GNUstep site configuration
loading cache ./config.cache
./configure: line 526: syntax error near unexpected token `AM_INIT_AUTOMAKE($PACKAGE,'
./configure: line 526: `AM_INIT_AUTOMAKE($PACKAGE, $VERSION, no-define)'
[2(rlk)||{!604}<rlkppp>/mnt/sandbox/gimp-print/print]
$ autoconf --help
Usage: autoconf [-h] [--help] [-m dir] [--macrodir=dir]
       [-l dir] [--localdir=dir] [--version] [template-file]
[2(rlk)||{!605}<rlkppp>/mnt/sandbox/gimp-print/print]
$ autoconf --version
Autoconf version 2.13

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] autoconf

[Robert L K. <rl...@al...>]

   From: sh...@al...
   Date: Fri, 04 Feb 2000 00:07:00 +0900

   I have to apologize.  I accidently trounced on Makefile.in and Makefile
   during my commission.  These are generated files when using autoconf.  If
   we want to stick to using autoconf, then, these files should probably
   be removed from the repository entirely, since they will be generated on
   the fly from Makefile.am and configure.in.

Well, that was my fault originally, since I'm the one who put 'em in
there in the first place.  Thanks for taking care of this.

   This stuff still needs work as not all bits of it are as elegant as they
   should be.

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Thu, 03 Feb 2000 15:57:18 +0100
   From: Andy Thaller <th...@ph...>

   Robert L Krawitz wrote:

   > I'd actually prefer something like this for other reasons, anyway --
   > this would allow someone to define "virtual" printers that are really
   > just sets of options.  So someone could define a "printer" that has
   > settings appropriate for highest quality printing, another one for
   > quick and dirty proofing, others for various groups of settings known
   > to work for particular images...

   Good point! I'll love this :-)

Sounds like this might be good as part of the GUI rewrite.

[Gimp-print-devel] autoconf

[<sh...@al...>]

Ok, I've made my first attempt at getting autoconf working.  I committed
several files which may be sufficient to compile print and unprint
using autoconf.  Hopefully I didn't screw anything up too badly.

I have to apologize.  I accidently trounced on Makefile.in and Makefile
during my commission.  These are generated files when using autoconf.  If
we want to stick to using autoconf, then, these files should probably
be removed from the repository entirely, since they will be generated on
the fly from Makefile.am and configure.in.

This stuff still needs work as not all bits of it are as elegant as they
should be.

Let me know if (when?) you have problems.

Eric

Re: [Gimp-print-devel] Recents commits

[Andy T. <th...@ph...>]

Robert L Krawitz wrote:

>  Actually, that's a good point.  It is appropriate for the binary to
> deal with it.  I wasn't thinking too clearly, and reacted out of annoyance.

Annoying - that's the word I was looking for ... ;-)

> I'd actually prefer something like this for other reasons, anyway --
> this would allow someone to define "virtual" printers that are really
> just sets of options.  So someone could define a "printer" that has
> settings appropriate for highest quality printing, another one for
> quick and dirty proofing, others for various groups of settings known
> to work for particular images...

Good point! I'll love this :-)

Andy.

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Thu, 03 Feb 2000 09:54:15 +0100
   From: Andy Thaller <th...@ph...>

   Thanks for implementing this, I've changed the code a bit to
   account for the inktype setting and it works wonderful with the BJC
   driver. (so far I can only see this from the debug messages but I'm
   longingly waiting for the photo printhead I've ordered....)

Does the multiple droplet stuff work (have you tried it)?

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Thu, 03 Feb 2000 09:46:02 +0100
   From: Andy Thaller <th...@ph...>

   Robert L Krawitz wrote:

   > This sort of nonsense is confusing everyone.  Someone tried to
   > give me a patch to use "lpc status all" rather than "lpc status"
   > because that's what his lpc needs.  This needs to be part of the
   > configuration process.

   I can't quite agree with this. I don't know what's true for other
   distributions than my SuSE. All I can say is you can choose between
   the bsd-style printing spooler and the plp spooler. To account for
   the unfortunate difference in the lpc-syntax there'd have to be
   shipped two binaries of the print-plugin if lpc-args are determined
   at configuration time. Of cource the choise to activate this paging
   stuff as default and having it deactivated optionally was not
   really ideal in the first place. Nevertheless the binary has to
   deal with the differences, IMHO.

Actually, that's a good point.  It is appropriate for the binary to
deal with it.  I wasn't thinking too clearly, and reacted out of annoyance.

   If we really don't want to do it the way I've inroduced with my
   work-around, we can still consider to supply an
   environment-variable PRINT_PLUGIN_LPC_OPTIONS - you name it - which
   is checked for by the print-plugin. Although a sort of "Preferences
   Dialog" would be much more sexy this solution would do for the time
   being.

   Perhaps we should leave the current track in long distance terms:
   Instead of offering all available printers the lpc command gives us
   we could have a setup dialog for adding/removing printers. The user
   can choose an appropriate description for the printer which will
   show up in the main printing dialog (being much more descriptive
   than /etc/printcap-names) and associates a file or print-command
   with it (this way we could also either print to various fixes
   filenames or invoke the FileChooser depending on what the user
   prefers). The dialog can still support the user by offering
   installed printers but the strong dependency from the lpc command
   would vanish. Of course, this is just musing and open to
   discussion, which is most certainly needed ;-)

I'd actually prefer something like this for other reasons, anyway --
this would allow someone to define "virtual" printers that are really
just sets of options.  So someone could define a "printer" that has
settings appropriate for highest quality printing, another one for
quick and dirty proofing, others for various groups of settings known
to work for particular images...

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Wed, 02 Feb 2000 21:02:57 -0700
   From: "S. Miller" <sm...@rn...>
   CC: th...@ph..., gim...@so...

   Since I'm new to both this project and open source development, can
   anyone help with cvs?  I don't seem to have ssh1 (is there someplace
   that I can get it aside from ftp.cs.hut.fi, which appears to be down?),
   so I tried anonymous just to get the tree downloaded.  Following the
   instructions, I got rejected:

   steve> cvs
   -d:pserver:ano...@cv...:/cvsroot/gimp-print
   login
   (Logging in to ano...@cv...)
   CVS password: 
   cvs [login aborted]: authorization failed: server
   cvs.gimp-print.sourceforge.net rejected access

   Help?

As a developer, you shouldn't use anonymous access.  The correct
command to use is:

export CVS_RSH=ssh
cvs -dsm...@cv...:/cvsroot/gimp-print co CVSROOT

You do need ssh installed on your system, though -- rsh will not
work.  You can get freessh from www.freessh.org.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Recents commits

[<sh...@al...>]

> Since I'm new to both this project and open source development, can
> anyone help with cvs?  I don't seem to have ssh1 (is there someplace
> that I can get it aside from ftp.cs.hut.fi, which appears to be down?),

I recommend using the OpenSSH version.  It's free.  Go to www.openssh.com.

> so I tried anonymous just to get the tree downloaded.  Following the
> instructions, I got rejected:
> 
> steve> cvs
> -d:pserver:ano...@cv...:/cvsroot/gimp-print
> login
> (Logging in to ano...@cv...)
> CVS password: 
> cvs [login aborted]: authorization failed: server
> cvs.gimp-print.sourceforge.net rejected access

<shrug>  Did you type a password?

Eric

Re: [Gimp-print-devel] Recents commits

[Andy T. <th...@ph...>]

Robert L Krawitz wrote:

>    Date: Wed, 02 Feb 2000 17:28:40 +0100
>    From: Andy Thaller <th...@ph...>
>
>    I'm coming to a point where I'd need the possibility to choose the
>    installed ink cartridges in the GUI: my BJC can be equipped either
>    with a K/CMY combination or Kcm/CMY heads. Other printers allow
>    choosing between K and CMY, etc, so generalizing this would make
>    sense for me. I'm not too familiar with GTK so if someone offers to
>    change the dialog appropriately I'd concentrate on further
>    bjc-support.
>
> I went and did it, but I called it "Ink Type" rather than "Print
> Head".  This would be useful for other things, such as Luminos inks
> for Epson printers.  Luminos inks are special archival inks that are
> available for some printers.  They have different characteristics from
> Epson inks.  I'm about to check it in.

Thanks for implementing this, I've changed the code a bit to account for the
inktype setting and it works wonderful with the BJC driver. (so far I can only
see this from the debug messages but I'm longingly waiting for the photo
printhead I've ordered....)

Andy.

Re: [Gimp-print-devel] Recents commits

[Andy T. <th...@ph...>]

Robert L Krawitz wrote:

> This sort of nonsense is confusing everyone.  Someone tried to give me
> a patch to use "lpc status all" rather than "lpc status" because
> that's what his lpc needs.  This needs to be part of the configuration
> process.

I can't quite agree with this. I don't know what's true for other
distributions than my SuSE. All I can say is you can choose between the
bsd-style printing spooler and the plp spooler. To account for the unfortunate

difference in the lpc-syntax there'd have to be shipped two binaries of the
print-plugin if lpc-args are determined at configuration time. Of cource the
choise to activate this paging stuff as default and having it deactivated
optionally was not really ideal in the first place. Nevertheless the binary
has to deal with the differences, IMHO.

If we really don't want to do it the way I've inroduced with my work-around,
we can still consider to supply an environment-variable
PRINT_PLUGIN_LPC_OPTIONS - you name it - which is checked for by the
print-plugin. Although a sort of "Preferences Dialog" would be much more sexy
this solution would do for the time being.

Perhaps we should leave the current track in long distance terms: Instead of
offering all available printers the lpc command gives us we could have a setup

dialog for adding/removing printers. The user can choose an appropriate
description for the printer which will show up in the main printing dialog
(being much more descriptive than /etc/printcap-names) and associates a file
or print-command with it (this way we could also either print to various fixes

filenames or invoke the FileChooser depending on what the user prefers). The
dialog can still support the user by offering installed printers but the
strong dependency from the lpc command would vanish. Of course, this is just
musing and open to discussion, which is most certainly needed ;-)

Andy.

Re: [Gimp-print-devel] Recents commits

[S. M. <sm...@rn...>]

Since I'm new to both this project and open source development, can
anyone help with cvs?  I don't seem to have ssh1 (is there someplace
that I can get it aside from ftp.cs.hut.fi, which appears to be down?),
so I tried anonymous just to get the tree downloaded.  Following the
instructions, I got rejected:

steve> cvs
-d:pserver:ano...@cv...:/cvsroot/gimp-print
login
(Logging in to ano...@cv...)
CVS password: 
cvs [login aborted]: authorization failed: server
cvs.gimp-print.sourceforge.net rejected access

Help?

Steve
-- 
-----------------------------------------
Just because I have a short attention span
doesn't mean I
------------------------------------------

[Gimp-print-devel] Printing stuff

[Robert L K. <rl...@al...>]

I came across your site today.  I haven't had a chance to take a look
at much of anything yet, but it looks interesting in light of a
project I'm working on.

I am currently leading a project to enhance the Print plugin for the
Gimp called, naturally enough, gimp-print.  We're using SourceForge to
host our project.  We currently have nine developers signed up, and
we're working on a variety of things.  The plugin was originally
written by Mike Sweet of Easy Software (easysw.com), who brought it up
to release 2.0; I did the 3.0 release myself, and our team is working
on the 3.1 development branch leading up to a 3.2 stable release.  The
Gimp 1.2 will probably have the current stable release (3.0.5).

Currently this plugin consists of a GUI, a variety of printer drivers
(for Postscript, and a variety of Epson, HP, and just recently added
Canon inkjets), and a selection of dithering engines.  In 3.0, I
started work on separating the front end GUI from the drivers and
dithering engine, with the intention of eventually making the Print
plugin be a thin glue layer between the Gimp and a more general
Linux/Unix printing system.  Henryk Richter wrote a prototype
GhostScript driver for Epson Stylus printers based on this. work.

We're continuing along these lines in 3.1.  Henryk's prototype
identified some problems with 3.0 that we've been fixing along the
way.  It's quite clear that the drivers, rendering engine, and even
the GUI don't belong in the Gimp; they belong in a driver layer, and
it's also clear that the user interface cannot be entirely
printer-independent, since different printers have different
capabilities that must be presented to the user.

Anyway, if you'd like to check out what we're up to, please visit our
home page at http://gimp-print.sourceforge.net.  We don't have a
3.1-based release just yet, because we've been concentrating a lot on
infrastructure and haven't yet gotten around to stabilizing things
enough to merit a real development release yet.  However, we'd
certainly like to share ideas and code (we're GPL) with anyone else
working on improving the printing situation.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] http://opensource.corel.com/printlib.html

[Robert L K. <rl...@al...>]

This is an "Application Printing Services API".  It's a bit sparse
right now, but it's worth a check.

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Wed, 02 Feb 2000 17:28:40 +0100
   From: Andy Thaller <th...@ph...>

   I'm coming to a point where I'd need the possibility to choose the
   installed ink cartridges in the GUI: my BJC can be equipped either
   with a K/CMY combination or Kcm/CMY heads. Other printers allow
   choosing between K and CMY, etc, so generalizing this would make
   sense for me. I'm not too familiar with GTK so if someone offers to
   change the dialog appropriately I'd concentrate on further
   bjc-support.

I went and did it, but I called it "Ink Type" rather than "Print
Head".  This would be useful for other things, such as Luminos inks
for Epson printers.  Luminos inks are special archival inks that are
available for some printers.  They have different characteristics from
Epson inks.  I'm about to check it in.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] Recents commits

[Robert L K. <rl...@al...>]

   Date: Wed, 02 Feb 2000 17:28:40 +0100
   From: Andy Thaller <th...@ph...>

   the BJC6000 much more sanely. Except for the still missing left
   image offset the driver should work - as soon as the latter is done
   we can put up a notice about canon-support in the webpages. BTW:
   the new dithering stuff works fine with the canon driver :-)

Good work!

   Another change fixes the lpc-related bug haunting my box ever since
   I'm using the print-plugin: The plp-lpc tool has some paging
   functionality which prints the message "Press RETURN to continue or
   'b' for back one page or 'q' to quit:" after each page leading to
   some quite funny printer entries and extraordinarily wide dropdown
   boxes ;-)

This sort of nonsense is confusing everyone.  Someone tried to give me
a patch to use "lpc status all" rather than "lpc status" because
that's what his lpc needs.  This needs to be part of the configuration
process.

   I'm coming to a point where I'd need the possibility to choose the
   installed ink cartridges in the GUI: my BJC can be equipped either
   with a K/CMY combination or Kcm/CMY heads. Other printers allow
   choosing between K and CMY, etc, so generalizing this would make
   sense for me. I'm not too familiar with GTK so if someone offers to
   change the dialog appropriately I'd concentrate on further
   bjc-support.

It wouldn't be too hard, but it would break compatibility with the
current printrc format (well, I guess we could simply append it to the
end of the current format, but that would be ugly...).  We really need
to think about this, because it's going to come up with other
printers, too...

   The new parameter could be PrintHead and if '*_parameters()'
   returns a NULL pointer the dropdown box could be omitted. Any
   objections, comments or volunteers?

I'm not opposed, just pointing out an ugliness.

[Gimp-print-devel] Epson stuff

[Robert L K. <rl...@al...>]

I took out the fancy 8-byte ESC(c command and replaced it with the
conventional 4-byte variant.  This might help people with 740's.
Could someone give it a try?

Also, would people on this list like to receive CVS commit messages?
I'm receiving them myself, but it occurred to me that people might
like to know what's going on without actually having to take updates.

[Gimp-print-devel] Re: Gimp-print-devel digest, Vol 1 #14 - 5 msgs

[Dave H. <da...@mi...>]

Robert L Krawitz <rl...@al...> wrote

>    Date: Wed, 02 Feb 2000 00:29:37 +0800
>    From: Nick Urbanik <ni...@vt...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
> 
>    >   But I have
>    >    already run into a problem compiling 3.05.  I've only briefly scanned
>    >    the list archives, so perhaps this has already been answered, but I get
>    >    an error in print.c regarding libgimp/gimpintl.h missing. I did a find
>    >    from / and it isn't anywhere.  I have 1.04 installed.  Is this a new
>    >    file or is something else going on?
> 
>    I mentioned this problem with RH Linux 6.1 on Intel PIII.
> 
>    > If you put -DGIMP_1_0 on the build command line you supposedly can
>    > build it under 1.0, but 1.1 is better for this.
> 
>    Putting -DGIMP_1_0 did not solve the problem of libgimp/gimpintl.h
>    missing.  P.S.  As I mentioned in my previous email, I used an
>    edited version of Makefile.standalone (patch was in previous
>    email).
> 
> Trust me, it will, one of these days :-)
> 
>    Hoping one day to be able to get printing working properly.
> 
> I haven't played with the 1.0 support myself; it's entirely possible
> it's broken, unfortunately...
> 

The 1.0 support is still working in the CVS I downloaded today! Check
in print.c at line 64 for the line:-

#ifdef GIMP_1_0

The code that follows this ifdef only includes libgimp/gimpintl.h if
GIMP_1_0 is NOT defined on the command line when compiling.

The line in my Makefile.standalone reads:-

OPTLEVEL = -O6 -funroll-all-loops -Wall -DGIMP_1_0

and it compiles fine with GIMP 1.0.4.

Dave Hill

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Recents commits

[Andy T. <th...@ph...>]

I've just committed some changes to the canon-driver allowing it to initialize

the BJC6000 much more sanely. Except for the still missing left image offset
the driver should work - as soon as the latter is done we can put up a notice
about canon-support in the webpages. BTW: the new dithering stuff works fine
with the canon driver :-)

Another change fixes the lpc-related bug haunting my box ever since I'm using
the print-plugin: The plp-lpc tool has some paging functionality which prints
the message "Press RETURN to continue or 'b' for back one page or 'q' to
quit:" after each page leading to some quite funny printer entries and
extraordinarily wide dropdown boxes ;-)

I'm coming to a point where I'd need the possibility to choose the installed
ink cartridges in the GUI: my BJC can be equipped either with a K/CMY
combination or  Kcm/CMY heads. Other printers allow choosing between K and
CMY, etc, so generalizing this would make sense for me. I'm not too familiar
with GTK so if someone offers to change the dialog appropriately I'd
concentrate on further bjc-support.

The new parameter could be PrintHead and if '*_parameters()' returns a
NULL pointer the dropdown box could be omitted. Any objections, comments or
volunteers?

Andy.

[Gimp-print-devel] Joined the list

[Dave H. <da...@mi...>]

Hi

Just a note to say that I have joined the gimp-print-devel
list and the gimp-print project on Sourceforge.

My name is Dave Hill and I am a Unix Sysadmin in real life. I
am currently "resting" after a 4 year contract so I get some
time to play with my Linux box.

Although an engineer by education, I was a programmer for
a number of years, but not in C. Therefore I tend to write
code that may not use all the esoteric features of C, but
usually works!

I use a HP Deskjet 600C printer with the Gimp print plugin,
hence my joining the project. I am interested in improving the
HP printer support and making sure that it doesn't get too
badly broken by other changes!!

Are there any other HP printer users on the list?

I have found that a great source of HP information is the
ghostscript driver "hpdj" by Martin Lottermoser, see
ftp://ftp.sbs.de/pub/graphics/ghostscript/pcl3

Regards
Dave Hill

-- 
Dave Hill, Kempston, Bedford UK		da...@mi...
Sicth munce ago, I cutn't evun spel enjuneer, and now I are one!

[Gimp-print-devel] Important commit on the dithering stuff

[Robert L K. <rl...@al...>]

I've just made an important change to print-util.c (and minor changes
to print-escp2.c and print-pcl.c).  In place of the mishmash of
constants in print-util, I created a struct (dither_t) that contains
all the constants.  It looks like this:

typedef struct dither
{
  int error[ERROR_ROWS][NCOLORS][MAX_CARRIAGE_WIDTH*MAX_BPI+1];
  int cbits;
  int lcbits;
  int mbits;
  int lmbits;
  int ybits;
  int lybits;
  int kbits;
  int k_lower;
  int k_upper;
  int lc_level;
  int lm_level;
  int ly_level;
  int c_randomizer;
  int m_randomizer;
  int y_randomizer;
  int k_randomizer;
  int nc_l;
  int nc_log;
  int *c_transitions;
  int *c_levels;
  int nlc_l;
  int nlc_log;
  int *lc_transitions;
  int *lc_levels;
  int nm_l;
  int nm_log;
  int *m_transitions;
  int *m_levels;
  int nlm_l;
  int nlm_log;
  int *lm_transitions;
  int *lm_levels;
  int ny_l;
  int ny_log;
  int *y_transitions;
  int *y_levels;
  int nly_l;
  int nly_log;
  int *ly_transitions;
  int *ly_levels;
  int nk_l;
  int nk_log;
  int *k_transitions;
  int *k_levels;
} dither_t;

Currently, this is essentially static in nature, but there's no reason
that each printer driver couldn't set it up as appropriate.  This is
necessary to allow different printers to share the same dithering
routine.

It printed something out correctly on my printer, so I know it works
perfectly :-)  Seriously, this change was pervasive enough so that
something's almost surely not right somewhere, so take a look at it if
you suspect anything.  Or, if you're close to having something
working, you might not want to take this update quite yet.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

Re: [Gimp-print-devel] CANON BJC 6000

[Robert L K. <rl...@al...>]

   Date: Tue, 01 Feb 2000 16:15:40 +0100
   From: Andy Thaller <th...@ph...>

   BTW: Can I set the density and gamma value for each color and media
   type seperately or is there only one global for all?

There's currently only one density and gamma value, but there's no
reason they couldn't vary for each color.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

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

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton