gimp-print-devel

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

Andy Thaller wrote:

> Ok, I tried it.. To check things out I'm not yet folding the output but
> leaving things as they are. this should give me two pictures the left being
> the lsb and the right the  msb. however, only the first line of the dithering
> output actually contains any pixels. To illustrate this, I've put the input
> and output on http://www.ph.tum.de/~thaller/gimp-print/

Ok, found it - dither_black is the wrong function, dither_black4 does the right
thing. However, dither_cmyk also doesn't use more than 2 levels, right?
Anyway, I'm happy it works for 4 black levels - I've put the output on the page
mentioned above so you can have a look :-)

Andy.

Re: [Gimp-print-devel] dot sizes and raster transfers

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

Robert L Krawitz <rl...@al...> said: 

>    From: sh...@al...
>    Date: Tue, 08 Feb 2000 21:16:55 +0900
> 
>    That's not entirely true.  The printer is initialized to expect a
particular
>    bit depth with the "ESC ( e" command.  When the command is called
with
>    0x10, the printer is put in multibit mode, with lower numbers
it's single
>    bit.  I expect there's some register in the printer that gets set
to
>    remember the bit depth.
> 
> I lied.  I checked in the fix.  Karl Heinz, could you retest this?


Not before tonight. I'll let you know what I find. Just to make sure
I test the right thing: What did you change, and what do you want me
to test? Softweave or Microweave?

Karl Heinz

Re: [Gimp-print-devel] dot sizes and raster transfers

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

   From: sh...@al...
   Date: Tue, 08 Feb 2000 21:16:55 +0900

   That's not entirely true.  The printer is initialized to expect a particular
   bit depth with the "ESC ( e" command.  When the command is called with
   0x10, the printer is put in multibit mode, with lower numbers it's single
   bit.  I expect there's some register in the printer that gets set to
   remember the bit depth.

I lied.  I checked in the fix.  Karl Heinz, could you retest this?

Re: [Gimp-print-devel] dot sizes and raster transfers

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

   From: sh...@al...
   Date: Tue, 08 Feb 2000 21:16:55 +0900

   That's not entirely true.  The printer is initialized to expect a particular
   bit depth with the "ESC ( e" command.  When the command is called with
   0x10, the printer is put in multibit mode, with lower numbers it's single
   bit.  I expect there's some register in the printer that gets set to
   remember the bit depth.

Oh!  That may be why things aren't working right...I won't have a
chance to fix it 'till tonight.

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

Robert L Krawitz <rl...@al...> said: 
[ ... ]
> 
>    So the "remote mode" is entered using ESC ( R, and it is left
again
>    with ESC NUL. Does somebody know what SN and LD stands for?
> 
> Nope.  However, it doesn't sound like paper feeding is your problem
--
> the paper feeds OK, and responds to the vertical feed commands, but
it
> doesn't actually *do* anything.

At least not much... I now that paper feeding is not the problem,
I just wanted to see if I can find this paper feeding sequence in
the strange init string and therefore reduce the "strangeness" of
the string a bit. 

When I get home tonight I will see if I can get a small test file
out of the Windows driver that I can then feed to parse-escp2.

Karl Heinz

Re: [Gimp-print-devel] dot sizes and raster transfers

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

> In microweave or softweave mode?

I'm working exclusively in microweave mode at the moment.  It seems to be
the simpler case.

> In microweave mode it isn't using multibit at all.

Oh, really?  Then something is pretty snafu.

> I thought I had fixed the softweave code (and I know
> I've tested it) to use ESCi in multibit mode.  ESC. will not do
> multibit stuff; there's no way to express it.

That's not entirely true.  The printer is initialized to expect a particular
bit depth with the "ESC ( e" command.  When the command is called with
0x10, the printer is put in multibit mode, with lower numbers it's single
bit.  I expect there's some register in the printer that gets set to
remember the bit depth.

Eric

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

   Date: Tue, 08 Feb 2000 13:01:01 +0100
   From: Andy Thaller <th...@ph...>

   Ok, I tried it.. To check things out I'm not yet folding the output
   but leaving things as they are. this should give me two pictures
   the left being the lsb and the right the msb. however, only the
   first line of the dithering output actually contains any pixels. To
   illustrate this, I've put the input and output on
   http://www.ph.tum.de/~thaller/gimp-print/

   Can you imagine, what's wrong?

Don't have any idea offhand; I'd need to see your code.

Re: [Gimp-print-devel] dot sizes and raster transfers

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

   From: sh...@al...
   Date: Tue, 08 Feb 2000 20:19:50 +0900

   Ok, another ESCP2 question.

   There are two ways to transfer raster data.  "ESC i" and "ESC .".

   "ESC i" explicitly specifies the number of bits per pixel.  "ESC ." does
   not.  Is it kosher to use "ESC ." while printing in multibit mode?
   I had assumed that "ESC ." implied 1 bit per pixel, and that "ESC i" was
   required for multi-bit pixels, but, the current CVS version of the driver
   is using "ESC ." even in multi-bit format.  Seems a little fishy to me.

In microweave or softweave mode?  In microweave mode it isn't using
multibit at all.  I thought I had fixed the softweave code (and I know
I've tested it) to use ESCi in multibit mode.  ESC. will not do
multibit stuff; there's no way to express 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] web site

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

   Date: Tue, 08 Feb 2000 10:19:29 +0100
   From: Andy Thaller <th...@ph...>


   --------------626A3721BCFF66802C734415
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   Robert L Krawitz wrote:

   > I updated the web site a bit; added more printers, cleaned up the
   > formatting of the printer list, added trademarks, and added some meta
   > tags.

   Very good - I love seeing the canon printers there :-)
   However, I'd prefer not having the 5100,5500,6500,8200,and 8500 models listed
   at the moment since they are still miles from being supported even
   rudimentarily. I've only included them in the source to have a reminder
   lateron.
   I'd change the webpage myself but I don't want to fiddle with it without
   disussing this.

OK, I removed 'em.

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

   Date: Mon, 7 Feb 2000 22:45:17 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I also read more in the Programming Guide and found on page 24
   a description of the command transfer sequences that should be
   used when "talking" to a 740 or 900. This also refers to the
   "secret" ESC (R command. The manual just says that these commands=20
   are "... not inclued in the ESC/P Reference manual."

Yeah, I think that that's some of the NDA stuff.

   They are using these commands to set up the print job and to=20
   terminate the job:

   1.1 Enter Remote Mode		ESC ( R
   1.2 Set Paper Feed Sequence	SN
   1.3 Exit Remote Mode		ESC NUL
   1.4 Initialization		ESC @
   1.5 Set graphics Mode		ESC ( G
   1.6 Set Unit			ESC ( U
   =2E..
   print job
   =2E..
   7.1 Initialize Printer		ESC @
   7.2 Select Paper Feed Sequence	ESC ( R
				   LD
				   ESC NUL

   So the "remote mode" is entered using ESC ( R, and it is left again
   with ESC NUL. Does somebody know what SN and LD stands for?

Nope.  However, it doesn't sound like paper feeding is your problem --
the paper feeds OK, and responds to the vertical feed commands, but it
doesn't actually *do* anything.

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

Ok, I tried it.. To check things out I'm not yet folding the output but
leaving things as they are. this should give me two pictures the left being
the lsb and the right the  msb. however, only the first line of the dithering
output actually contains any pixels. To illustrate this, I've put the input
and output on http://www.ph.tum.de/~thaller/gimp-print/

Can you imagine, what's wrong?

Andy.

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

   Date: Mon, 7 Feb 2000 19:55:03 -0500
   From: Karl Heinz Kremer <kh...@kh...>


   --tKW2IUtsqtDRztdT
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: quoted-printable

   On Mon, Feb 07, 2000 at 07:42:54PM -0500, Robert L Krawitz wrote:
   > OK, I checked in the fix.  I also checked in something else that might

   No difference. OK, one little difference: Your init code prints something
   one the page: I get two lines
   284.4
   @EJL=20
   at the top of the page. But other than that neither the number of
   separations nor the nozzles did change anything. My information is
   also that the 740 has 48 nozzles, so I tried the 32, but changed
   it back after I saw that it did also not work.

   Regarding the init string: I would remove it again. As I said before,
   I tried it with an image generated with the Windows driver after I
   removed the "junk" at the beginning of the file and the image printed
   identical to the one with the init sequence.

   The 760 seems to require such a string, the 740 does not.

OK, I #ifdef'ed it out.

Karl (or somebody), could you try grafting any unknown headers you
find in the Windows output onto the plugin's output and see what
happens?  Another alternative would be to use the parse-escp2 perl
script in the source to analyze the Windows output (for a small output
file!) and send it on to the list.

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

   Date: Mon, 07 Feb 2000 19:00:20 -0700
   From: "S. Miller" <sm...@rn...>

   I can also add individual color gamma correction widgets while I'm
   redoing that part.  Should this be for all printers, or just cannon?  I
   haven't got far enough for anything to be even set in mud yet, so if
   anyone has any suggestions or requests, I'm all ears.

That should be for everything.

-- 
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] dot sizes and raster transfers

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

Ok, another ESCP2 question.

There are two ways to transfer raster data.  "ESC i" and "ESC .".

"ESC i" explicitly specifies the number of bits per pixel.  "ESC ." does
not.  Is it kosher to use "ESC ." while printing in multibit mode?
I had assumed that "ESC ." implied 1 bit per pixel, and that "ESC i" was
required for multi-bit pixels, but, the current CVS version of the driver
is using "ESC ." even in multi-bit format.  Seems a little fishy to me.

Eric

Re: [Gimp-print-devel] web site

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

Robert L Krawitz wrote:

> I updated the web site a bit; added more printers, cleaned up the
> formatting of the printer list, added trademarks, and added some meta
> tags.

Very good - I love seeing the canon printers there :-)
However, I'd prefer not having the 5100,5500,6500,8200,and 8500 models listed
at the moment since they are still miles from being supported even
rudimentarily. I've only included them in the source to have a reminder
lateron.
I'd change the webpage myself but I don't want to fiddle with it without
disussing this.

Andy.

Re: [Gimp-print-devel] [Fwd: Printing from GIMP]

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

On Tue, Feb 08, 2000 at 12:36:18PM +0900, sh...@al... wr=
ote:
> <shrug> It could be any number of things.  This post is so vague it's
> hard to tell.  For all I know, he could be generating an ESCP2 file and
> running it through a postscript interpretter he's set up as a filter.
> That can't be a good thing.  I don't know anything about SO or WP8, I rar=
ely
> use non-free software if I can avoid it, but somehow I doubt they are
> generating raw printer data files the way the gimp does.

Both StarOffice and WP are creating PostScript, so you could be right
with the ESC/P2 through GhostScript idea. However, depending on which
print filter he's using it is very likely that it would just pass this
on as raw data. APS is doing this.

Karl Heinz

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

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

Karl Heinz Kremer wrote:
> 
> The only think I know about it is that xscanimage from Sane uses it.
> This is also the only place I've ever seen the widget.
> 
> Karl Heinz
> 
> --
OK, I'll hunt down the source for it (I only downloaded the binary
distro).  For now its probably low priority anyway.  I looked at it in
glade, and couldn't figure out what it is supposed to do, as it had some
sort of spline fitted curves.  I thought gamma was the exponent for a
nonlinear remap.

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

Re: [Gimp-print-devel] [pam.roberts@virginnet.co.uk: [linux-usb] Epson Stylus Color 760]

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

On Mon, Feb 07, 2000 at 07:28:17PM -0500, Robert L Krawitz wrote:
> In light of all this weirdness we're seeing, I'm beginning to wonder
> if this is our problem after all.  The printout someone sent me from a
> 750 contained exactly this string, also.  I'm going to stick it in;
> perhaps you could try it after I commit this?

Here's the init string from print-escp2.c:

fprintf(prn, "\000\000\000\033\001@EJL 1284.4\n@EJL     \n");

After thinking about this a little bit I guess that @EJL stands
for Epson Job Language (like PJL), the 1284.4 looks like=20
IEEE 1284 (no idea what the .4 stands for), which means that
the printer is programmed into a bidirectional mode.=20

I also read more in the Programming Guide and found on page 24
a description of the command transfer sequences that should be
used when "talking" to a 740 or 900. This also refers to the
"secret" ESC (R command. The manual just says that these commands=20
are "... not inclued in the ESC/P Reference manual."

They are using these commands to set up the print job and to=20
terminate the job:

1.1 Enter Remote Mode		ESC ( R
1.2 Set Paper Feed Sequence	SN
1.3 Exit Remote Mode		ESC NUL
1.4 Initialization		ESC @
1.5 Set graphics Mode		ESC ( G
1.6 Set Unit			ESC ( U
=2E..
print job
=2E..
7.1 Initialize Printer		ESC @
7.2 Select Paper Feed Sequence	ESC ( R
				LD
				ESC NUL

So the "remote mode" is entered using ESC ( R, and it is left again
with ESC NUL. Does somebody know what SN and LD stands for?

This "command transfer sequence" table is probably also interesting
to find out which commands should be used to accomplish certain tasks.

Karl Heinz

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

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

On Mon, Feb 07, 2000 at 07:00:20PM -0700, S. Miller wrote:
> Taking the last part first, I found a very brief reference to it in
> Pennington's "GTK+/Gnome Application Development".  But there was no
> discussion of it's features or interface.  If someone can point me in
> the right direction, this would definitely go great in an 'advanced
> settings' type window.

The only think I know about it is that xscanimage from Sane uses it.
This is also the only place I've ever seen the widget.

Karl Heinz

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

Re: [Gimp-print-devel] [Fwd: Printing from GIMP]

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

> This appeared on the comp.os.linux.setup newsgroup this evening.  I was
> gonna answer, but I don't really know the answer.  I'm guessing this is
> from the 2.? version that went with Gimp 1.0.4.  If anyone can provide
> info, I'll forward it on.
> 
> From: rra...@ao...llllllll (RRALICIA)
> Newsgroups: comp.os.linux.setup
> Subject: Printing from GIMP
> Date: 08 Feb 2000 00:58:08 GMT
> 
> I'm having trouble printing from Gimp. I can print fine from other apps(Star
> Office, Corel WP8, etc) I can choose my printer (Epson Stylus Color 500) but
> when I try to print, all I get is pages and pages of gibberish
> Rob

<shrug> It could be any number of things.  This post is so vague it's
hard to tell.  For all I know, he could be generating an ESCP2 file and
running it through a postscript interpretter he's set up as a filter.
That can't be a good thing.  I don't know anything about SO or WP8, I rarely
use non-free software if I can avoid it, but somehow I doubt they are
generating raw printer data files the way the gimp does.

Eric

Re: [Gimp-print-devel] [Fwd: Printing from GIMP]

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

   Date: Mon, 07 Feb 2000 19:16:28 -0700
   From: "S. Miller" <sm...@rn...>

   This is a multi-part message in MIME format.
   --------------ADAC830138A1A325D1C6D65A
   Content-Type: text/plain; charset=us-ascii
   Content-Transfer-Encoding: 7bit

   This appeared on the comp.os.linux.setup newsgroup this evening.  I was
   gonna answer, but I don't really know the answer.  I'm guessing this is
   from the 2.? version that went with Gimp 1.0.4.  If anyone can provide
   info, I'll forward it on.

It's supposed to be possible to compile 3.0.5 for Gimp 1.0 by
#define'ing GIMP_1_0 on the command line/print.c (sorry I'm
incoherent, I'm in a bit of a hurry right now...)

   --------------ADAC830138A1A325D1C6D65A
   Content-Type: message/rfc822
   Content-Transfer-Encoding: 7bit
   Content-Disposition: inline

   From: rra...@ao...llllllll (RRALICIA)
   Newsgroups: comp.os.linux.setup
   Subject: Printing from GIMP
   NNTP-Posting-Host: ladder05.news.aol.com
   X-Admin: ne...@ao...
   Date: 08 Feb 2000 00:58:08 GMT
   Organization: AOL http://www.aol.com
   Message-ID: <200...@ng...>
   Path: news2.starnetinc.com!chicago-news-feed1.bbnplanet.com!news.gtei.net!uwm.edu!vixen.cso.uiuc.edu!uchinews!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!newsfeed.cwix.com!cyclone-east.rr.com!news.rr.com!news-east.rr.com!portc05.blue.aol.com!audrey04.news.aol.com!not-for-mail
   Xref: news2.starnetinc.com comp.os.linux.setup:8407

   I'm having trouble printing from Gimp. I can print fine from other apps(Star
   Office, Corel WP8, etc) I can choose my printer (Epson Stylus Color 500) but
   when I try to print, all I get is pages and pages of gibberish
   Rob

   --------------ADAC830138A1A325D1C6D65A--


   _______________________________________________
   Gimp-print-devel mailing list
   Gim...@li...
   http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

[Gimp-print-devel] web site

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

I updated the web site a bit; added more printers, cleaned up the
formatting of the printer list, added trademarks, and added some meta
tags.

-- 
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] dithering for variable drop size, color adjustments

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

> Taking the last part first, I found a very brief reference to it in
> Pennington's "GTK+/Gnome Application Development".  But there was no
> discussion of it's features or interface.  If someone can point me in
> the right direction, this would definitely go great in an 'advanced
> settings' type window.

Glade has support for it.  You might want to mess with it and see what
it produces.

I happen to like Glade, although it seemed a bit limited when I tried it
last, which was, gee, maybe almost a year ago.  Then again, I hate UI
programming with a passion.  Isn't supporting --long-argument options
enough?  :)

Eric

[Gimp-print-devel] [Fwd: Printing from GIMP]

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

This appeared on the comp.os.linux.setup newsgroup this evening.  I was
gonna answer, but I don't really know the answer.  I'm guessing this is
from the 2.? version that went with Gimp 1.0.4.  If anyone can provide
info, I'll forward it on.

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

Re: [Gimp-print-devel] dithering for variable drop size, color adjustments

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

Robert L Krawitz wrote:
> About the best thing you could do is recompute the lookup table when
> your print function is called.  In fact, calling compute_lut() from
> inside print.c is really silly; it should be called from inside the
> print function, and I may just change this.  There are already
> intensity controls for each of the colors; adding gamma controls isn't
> hard, but it is tedious.
> 
> It would really make sense to put the LUT in the variables block,
> actually, and save it in the printrc.  The LUT (unlike the color map)
> is really part of the printer definition, not of the image.  In fact,
> it would arguably make sense to put the color mapping stuff in the
> image code, rather than the print functions, so that the image code
> does the translation to RGB or RGBA.
> 
> If you want to expose them, you'll have to hack the UI code in
> print.c, which is ugly.  You should probably discuss this with Steve
> Miller <sm...@rn...>, who's working on the GUI.
> 
> I'm beginning to think that we should consider redoing the printrc
> file format some time during this development cycle.  We've already
> added stuff to it, and it's rather ugly.  The "obvious" thing to do is
> to come up with an XML definition here; we can then easily add stuff
> later, and people can edit printer definitions with their favorite
> browser (hint: transfer functions!).
> 
> I think GTK actually has a pretty nice gamma curve widget.  It's not
> really documented anywhere, but I think SANE uses this (hint hint,
> somebody :-) ).  This would be a real win for us.
> 
Taking the last part first, I found a very brief reference to it in
Pennington's "GTK+/Gnome Application Development".  But there was no
discussion of it's features or interface.  If someone can point me in
the right direction, this would definitely go great in an 'advanced
settings' type window.

I can also add individual color gamma correction widgets while I'm
redoing that part.  Should this be for all printers, or just cannon?  I
haven't got far enough for anything to be even set in mud yet, so if
anyone has any suggestions or requests, I'm all ears.

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