gimp-print-devel

Re: [Gimp-print-devel] development release?

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

> I would also like to toss in the notion of using C++ for some of this,
> which would facilitate custom popups by deriving them from a base
> class.  If everyone hates this, I'll keep using C, but please give it
> some thought.

My personal opinion, which should carry little actual weight here, is that
C++ adds little important functionality over C.  In other words, there's
little that C++ can do that I can't do with pointers and structures, so,
why bother?

It's an old debate.  I don't see it being resolved anytime soon.

Eric

Re: [Gimp-print-devel] development release?

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

>    BTW: what happens to the driver-selection dropdown when there are too many
>    printer drivers in it? Will it wrap? Or simply exceed the screen?
> 
> That's a good question.  Hopefully gtk does the right thing :-)
> 
> --
Having finally figured out cvs and getting a local tree, I started
looking at print.c to see if I could figure out how to redo the gui.  I
have some initial thoughts, including one relating to the above
question, that I'd like some comments on.  Should there be some sort of
popup (from a button on the main dialog) that allows the user to add or
delete printers from a list he or she could use?  That way the list of
all printers could be in a scrolled list, and the user would only have
to look at a list of those he has.  Second, with the numerous
combinations of features available for different printers, I think it
might be better to put some of the parameters in a different popup,
called "advanced" or something on that line.  This would allow different
popups to be shown for vastly differing printers.  It would also hide
ugly details from those who really don't care what the gamma correction
value is, as long as it is reasonable.  I would like to control the
features widgets display according to some sort of capability matrix. 
The main objective of all this is to keep the main dialog simple and
clean.

I would also like to toss in the notion of using C++ for some of this,
which would facilitate custom popups by deriving them from a base
class.  If everyone hates this, I'll keep using C, but please give it
some thought.

Steve

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

[Gimp-print-devel] No Success with STC 740 so far ... which printers are working?

[Karl H. K. <kh...@kh...>]

Just did some quick testing with the latest CVS version and my
stc 740. The only difference is that the pages that are produced
are not completely blank anymore: I see thin lines every three
or for inches when printing in 360dpi mode.=20

Which Epson printers are working right now? I'm trying to understand
the differences between the printers, and maybe there is something
obvious ... So if everybody with a working Epson printer could=20
please send me a short note with information about which modes
are working.=20

Karl Heinz

--=20
Karl Heinz Kremer                                      kh...@kh...
                                                http://www.khk.net
                                                     ICQ: 41190739

Re: [Gimp-print-devel] autoconf

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

> 1) It didn't put my library directory (/usr/local/Libraries) on the
>    build line.  It's working for me because I have LD_LIBRARY_PATH
>    set, but this isn't right.

Well, autoconf does have limits.  It can't scour your whole system for
libs in random places.  It can accept flags, though.  I can set up a libdir
conf flag for the configure script.

> 2) It didn't find my Gimp plugins directory
>    (/usr/local/Libraries/gimp/1.1/plug-ins).

Same as above.

This will have to wait until tomorrow, though.  It's late and I'm tired.
And hungry.  Someone stole my dinner...

Eric

Re: [Gimp-print-devel] Another Epson Simulator

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

> I just found another "Epson Simulator": It's a ESC/p2 to Sun
> raster converter. It can be found on the GhostScript UPD home
> page:
> 
> http://xilinx.e-technik.uni-rostock.de/ma/gunther/gs/

Scheeshz, talk about reinventing the wheel...

Well, I still like mine better, despite the fact that his probably works...:)
I think mine does more extensive error checking.  It looks like his expects
a sane escp2 file as input.  I'm working on the assumption that all input
is highly suspect and quite likely broken.  It will be good to compare the two.

I had contacted Gunther Hess previously about his work, but he never
mentioned this in his mail.  He seemed rather busy, and I don't think he
has worked on any of this stuff recently.

Eric

[Gimp-print-devel] Another Epson Simulator

[Karl H. K. <kh...@kh...>]

I just found another "Epson Simulator": It's a ESC/p2 to Sun
raster converter. It can be found on the GhostScript UPD home
page:

http://xilinx.e-technik.uni-rostock.de/ma/gunther/gs/

There is a link to the source file upd/escp2ras.c - just
download it and to a make escp2ras. 

I have no idea how good it is, just one more tool to debug
the files with.

Karl Heinz

[Gimp-print-devel] vertical motion

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

Ok, another ESCP2 question.

I've got a file produced by a few days old CVS gimp-print set for the ESP750
720 DPI that when run through parse-escp2 has the following head:

00000000  1b  @ 
00000002  1b  (  G 01 00 01 
00000008  1b  (  U 05 00 02 02 01 a0 05 
00000012  1b  (  K 02 00 00 02 
00000019  1b  U 00 
0000001c  1b  (  i 01 00 00 
00000022  1b  (  e 02 00 00 10 
00000029  1b  (  C 04 00 f0 1e 00 00 
00000032  1b  (  c 08 00 00 00 00 00 10 1d 00 00 
0000003f  1b  (  V 04 00 00 00 00 00 
00000048  1b  (  S 08 00 01 01 00 00 01 01 00 00 
00000055  1b  (  v 04 00 8e ff 00 00 

My question is about the last line.  If I'm reading that correctly, it
translates to "move the printer head down 90.87 inches".  What's up
with that?  Am I missing something?  I don't have 90 inch paper!

Eric

Re: [Gimp-print-devel] development release?

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

   Date: Fri, 04 Feb 2000 08:10:16 +0100
   From: Andy Thaller <th...@ph...>

   Robert L Krawitz wrote:

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

   I could add the canon bjc1000, bjc2000, bjc3000, bjc6100, bjc7000
   and bjc7100 immediatley but without the chance for testing or
   finetuning. The latter isn't even done for the bjc6000. Apart from
   this, I'm perfectly in favour with a soon development release - we
   really need test reports from various environments.

My thought is that we're better off release noting the fact that the
other printers are untested and that the bjc6000 isn't tuned and
doesn't do the variable drop size stuff (or whatever Canon calls it)
yet.

   BTW: what happens to the driver-selection dropdown when there are too many
   printer drivers in it? Will it wrap? Or simply exceed the screen?

That's a good question.  Hopefully gtk does the right thing :-)

-- 
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 12:44:54 +0900

   > 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?

Ah.  No, I did not.  That worked much better.  However, there were a
couple of problems:

1) It didn't put my library directory (/usr/local/Libraries) on the
   build line.  It's working for me because I have LD_LIBRARY_PATH
   set, but this isn't right.

2) It didn't find my Gimp plugins directory
   (/usr/local/Libraries/gimp/1.1/plug-ins).

gcc  -g -O2  -o print  print-canon.o print-escp2.o print-pcl.o print-ps.o print-util.o print.o -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm -lgimp -lgimpui -lm -lgtk -lgmodule -lglib -lgdk 
[2(rlk)||{!652}<rlkppp>/mnt/sandbox/gimp-print/print]
$ make -n install
make  install-exec-am install-data-am
make[1]: Entering directory `/mnt/sandbox/gimp-print/print'
:
/bin/sh ./mkinstalldirs /usr/local/Tools//
list='unprint'; for p in $list; do \
  if test -f $p; then \
    echo "  /usr/bin/ginstall -c  $p /usr/local/Tools///`echo $p|sed 's/$//'|sed 's,x,x,'|sed 's/$//'`"; \
     /usr/bin/ginstall -c  $p /usr/local/Tools///`echo $p|sed 's/$//'|sed 's,x,x,'|sed 's/$//'`; \
  else :; fi; \
done
:
/bin/sh ./mkinstalldirs /plug-ins
list='print'; for p in $list; do \
  if test -f $p; then \
    echo "  /usr/bin/ginstall -c  $p /plug-ins/`echo $p|sed 's/$//'|sed 's,x,x,'|sed 's/$//'`"; \
     /usr/bin/ginstall -c  $p /plug-ins/`echo $p|sed 's/$//'|sed 's,x,x,'|sed 's/$//'`; \
  else :; fi; \
done

Here's my config.log:

This file contains any messages produced by compilers while
running configure, to aid debugging if configure makes a mistake.

configure:564: checking for a BSD compatible install
configure:617: checking whether build environment is sane
configure:674: checking whether make sets ${MAKE}
configure:713: checking for working aclocal
configure:726: checking for working autoconf
configure:739: checking for working automake
configure:752: checking for working autoheader
configure:765: checking for working makeinfo
configure:784: checking for mawk
configure:784: checking for gawk
configure:816: checking for gcc
configure:929: checking whether the C compiler (gcc  ) works
configure:945: gcc -o conftest    conftest.c  1>&5
configure:971: checking whether the C compiler (gcc  ) is a cross-compiler
configure:976: checking whether we are using GNU C
configure:985: gcc -E conftest.c
configure:1004: checking whether gcc accepts -g
configure:1047: checking for a BSD compatible install
configure:1100: checking whether ln -s works
configure:1171: checking for gtk-config
configure:1206: checking for GTK - version >= 1.0.5
configure:1307: gcc -o conftest -g -O2 -I/usr/X11R6/include -I/usr/lib/glib/include   conftest.c -L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXext -lX11 -lm  1>&5
configure:1392: checking for main in -lX11
configure:1407: gcc -o conftest -g -O2   conftest.c -lX11   1>&5
/usr/i486-linux/bin/ld: cannot open -lX11: No such file or directory
configure: failed program was:
#line 1400 "configure"
#include "confdefs.h"

int main() {
main()
; return 0; }
configure:1435: checking for main in -lXext
configure:1450: gcc -o conftest -g -O2   conftest.c -lXext   1>&5
/usr/i486-linux/bin/ld: cannot open -lXext: No such file or directory
configure: failed program was:
#line 1443 "configure"
#include "confdefs.h"

int main() {
main()
; return 0; }
configure:1478: checking for main in -lgdk
configure:1493: gcc -o conftest -g -O2   conftest.c -lgdk   1>&5
configure:1522: checking for main in -lglib
configure:1537: gcc -o conftest -g -O2   conftest.c -lglib  -lgdk  1>&5
configure:1565: checking for main in -lgmodule
configure:1580: gcc -o conftest -g -O2   conftest.c -lgmodule  -lglib -lgdk  1>&5
configure:1608: checking for main in -lgtk
configure:1623: gcc -o conftest -g -O2   conftest.c -lgtk  -lgmodule -lglib -lgdk  1>&5
configure:1651: checking for main in -lm
configure:1666: gcc -o conftest -g -O2   conftest.c -lm  -lgtk -lgmodule -lglib -lgdk  1>&5
configure:1695: checking how to run the C preprocessor
configure:1716: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1775: checking for ANSI C header files
configure:1788: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1855: gcc -o conftest -g -O2   conftest.c -lm -lgtk -lgmodule -lglib -lgdk  1>&5
configure:1882: checking for unistd.h
configure:1892: gcc -E  conftest.c >/dev/null 2>conftest.out
configure:1920: checking for working const
configure:1974: gcc -c -g -O2  conftest.c 1>&5
configure:1995: checking for off_t
configure:2028: checking for size_t
configure:2062: checking for 8-bit clean memcmp
configure:2080: gcc -o conftest -g -O2   conftest.c -lm -lgtk -lgmodule -lglib -lgdk  1>&5
configure:2098: checking return type of signal handlers
configure:2120: gcc -c -g -O2  conftest.c 1>&5
configure:2141: checking for strtol
configure:2169: gcc -o conftest -g -O2   conftest.c -lm -lgtk -lgmodule -lglib -lgdk  1>&5

[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 -ds...@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