gimp-print-devel

Re: [Gimp-print-devel] release? and how to contact printer companies

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

   Date: Wed, 16 Feb 2000 09:48:13 +0100
   From: Andy Thaller <And...@Ph...>

   Maybe the marketing people are really better concerning strategic
   decissions and we should concentrate on them. Perhaps we should
   start with designing a note to send to them? But what about the
   already reverse engineered code? Any legal problems to be expected?

What reverse engineered code?

-- 
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] [dq@altern.org: Paper limits & Wrong back drawings]

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

------- Start of forwarded message -------
Date: Wed, 16 Feb 2000 02:20:52 -0800
To: rl...@al...
Subject: Paper limits & Wrong back drawings
From: Daniel <dq...@al...>

Hello Robert,

really great stuff you're doing with the Print plugin for Gimp. Thanks!

Here are some errors I spotted on my Epson Photo 700. I tried also to provide workarounds or solutions :-)

a) You restrict the maximum paper size in print-escp2.c for the Photo 700 to 8.5" x 11". That's wrong! The width (8.5") is correct, but the length should be at least 14", so as to cover both the Legal, and more important to me, also the A4 paper size.
The actual line to change is now:
length_limit = 11 * 72;
and should be:
length_limit = 14 * 72;

b) Many problems related to monochrome printing were already solved. But I found this issue:
While using Gimp, I created some random black lines on a transparent background. When printing my "artwork", I got a nice rectangular block completely filled with black ink. That was not what I was expecting!
Workaround: Instead of using a transparent background, I switched to a white background.

I hope to read you soon.

Bye,
DQ (dq...@al...)
------- End of forwarded message -------

Re: [Gimp-print-devel] release? and how to contact printer companies

[Andy T. <And...@Ph...>]

Robert L Krawitz wrote:

> I also happened to be talking about this project with my manager at
> work, and he suggested that we might get more results talking with the
> marketing folks rather than the tech support people, since the
> marketing people would have more to gain than the tech support people
> here.

Good point, at least considering my experiences with a german canon support
tech. Asking him if I could get documentation of the control sequences he told
me there isn't any such thing like control sequences for the BJC-6000 since it
is a windows GDI (Graphics Device Interface - so much he knew ;-) und thus
doesn't have any control sequences (what he was propably referring to was the
lacking of builtin FONTS what makes the printer unable to receive plain text).
Another tech answering my second mail to canon support only told me about the
NDA and the fact that it's very unlikely they'd give out _any_ information,
even under NDA to private persons since they did so in the past and especially
in the linux sector it turned out to nothing. At this point I gave up trying
to conversate with canon techs - they sell really good hardware but the suport
I received was worse than bad.

Maybe the marketing people are really better concerning strategic decissions
and we should concentrate on them. Perhaps we should start with designing a
note to send to them? But what about the already reverse engineered code? Any
legal problems to be expected?

Andy.

Re: [Gimp-print-devel] Tests with Stylus 640

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

> > BTW, I put an image on http://www.tiac.net/users/rlk/Graphic2.prn that
> > is a Photo 750 output from Windows.  Unprint currently gives a lot of
> > errors.
> 
> Actually it appears to be a rather low resolution family photo.

Scratch that.  It is a family photo, but the resolution isn't that low.
There was a bug in unprint that was causing pixels to be put in slightly
the wrong place, resulting in what appeared to be large scale pixelization.

With the current unprint, it unprints rather well.  Yet, I'm at a loss to
explain the two vertical bars that appear on the image.

If you run this through unprint -u, to unweave the softweaving you can see
the origin of these features more clearly.  On some passes, there is a
single pixel wide vertical bar.  The position of the bar is not the same in
each pass, resulting in a multi-pixel wide vertical bar when the data is
woven.

I don't know if this is a bug in unprint, or due to some undocumented
command effect that I haven't taken into account.  Anyone have any ideas?

I don't have time to study this right now.  Maybe tomorrow.  At the moment,
I'm going to work on the "bug in unprint" assumption, since that's easier
to handle, but I have a hard time imagining a bug that would cause this
particular effect.

Eric

[Gimp-print-devel] release? and how to contact printer companies

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

Is there anyone who would object to a 3.1.0 release, say, tomorrow
(Wednesday) night?

Remember, this is not a production release; we're talking about an
initial development release here.  I think there's enough new stuff in
here (real autoconf/make, some Canon support, positioning boxes,
Ghostscript driver) that people could do something useful with it, and
we could get some more interest out there.

I also happened to be talking about this project with my manager at
work, and he suggested that we might get more results talking with the
marketing folks rather than the tech support people, since the
marketing people would have more to gain than the tech support people
here.

-- 
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] Image corruption

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

   Date: Tue, 15 Feb 2000 19:23:19 -0500
   From: Robert L Krawitz <rl...@al...>

   Well, this is very interesting; I have the same problem printing the
   same image on my EX in grayscale, so it sure looks like a real bug in
   the grayscale dithering.  I'll look at it.

What was going on is that around the time I split out the dithering
functions, I changed all of them to switch direction each row, to
create a more even dither.  However, when I fixed the dither_black
functions, I left out one place where I had to increment by
(direction) rather than by 1.

-- 
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] Image corruption

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

   Date: Tue, 15 Feb 2000 19:23:19 -0500
   From: Robert L Krawitz <rl...@al...>

   Well, this is very interesting; I have the same problem printing the
   same image on my EX in grayscale, so it sure looks like a real bug in
   the grayscale dithering.  I'll look at it.

Got it.  A fix is committed.  The multi-layer grayscale was also
broken.

-- 
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] Image corruption

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

Well, this is very interesting; I have the same problem printing the
same image on my EX in grayscale, so it sure looks like a real bug in
the grayscale dithering.  I'll look at 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

[Gimp-print-devel] Re: Patch for print plugin

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

   Date: Tue, 15 Feb 2000 14:18:37 +0100
   From: Aaron Optimizer Digulla <di...@un...>

   On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote:

   >    Here is a patch for the print plugin. The patch fixes an anoyance
   >    with the print dialog: If you have lots of printers (we have about
   >    50 here), it takes *several minutes* to open. Fix: Just use lpstat
   >    -d -v (just list the names of the printers instead of checking if
   >    they are enabled; the information is discarded anyway). Later, when
   >    it becomes clear that we can use that info, we can reenable it
   >    again (including some kind of caching and a progress report which
   >    shows that Gimp is still doing something).

   Ok, then only the second word (for) seems to be stable (the third
   always seems to be the printer name). Any other systems around ?

On our specific systems, yes.  I don't trust that something else won't
be different.  If you can test on Linux with a wide variety of
different print systems (there are quite a few out there), different
versions of Solaris and AIX, and if there's a BSD system running a
SysV spooler, and demonstrate that it works on all of them, I will
accept the patch.  Otherwise, I won't accept this.

   > In the longer run, a more general solution to the printing problem is
   > needed.

   I agree. But the patch should be included nonetheless because it makes
   printing with Gimp possible :-)

It helps you, but at the risk of breaking other people and hence
regressing from 3.0.6 and 2.0 (== Gimp 1.0).  As the maintainer of the
plugin, I consider this patch too high risk to accept.  As I said,
though, if you can arrange for system testing and prove that it works
on all of them without being overly convoluted, I will consider
accepting it, but not otherwise.

-- 
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] Re: Gimp 1.0.4 build works OK

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

   Date: Tue, 15 Feb 2000 23:30:11 +0000
   From: Dave Hill <da...@mi...>

   The print plugin now compiles OK against GIMP 1.0.4 without
   modifying the Makefile, your trick with GIMP_*_VERSION works.

Thanks (and thanks for finally fixing that silly file bug).

[Gimp-print-devel] Gimp 1.0.4 build works OK

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

Robert,

The print plugin now compiles OK against GIMP 1.0.4 without
modifying the Makefile, your trick with GIMP_*_VERSION works.

Dave

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

[Gimp-print-devel] Submitted print.c, print-pcl.c and pclunprint.c

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

I have submitted my first attempt at a pcl unprint program
as "pclunprint.c". It only works for Mono, 2 level dither
uncompressed output (i.e. Deskjet 500) at the moment. It
converts the output file into a pnm file that you can look at.

I have just changed print.c so the File: printer is properly
initialised, saved in the printrc file and retrieved. You no
longer have to keep resetting the %%$)** sliders each time.

I also added the "left margin" fix from a while ago to print-pcl.c,
it stops the "pclunprint" program from saying the margin is -180!

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] Re: Patch for print plugin

[Aaron O. D. <di...@un...>]

On Tue, Feb 15, 2000 at 08:09:37AM -0500, Robert L Krawitz wrote:

>    Here is a patch for the print plugin. The patch fixes an anoyance
>    with the print dialog: If you have lots of printers (we have about
>    50 here), it takes *several minutes* to open. Fix: Just use lpstat
>    -d -v (just list the names of the printers instead of checking if
>    they are enabled; the information is discarded anyway). Later, when
>    it becomes clear that we can use that info, we can reenable it
>    again (including some kind of caching and a progress report which
>    shows that Gimp is still doing something).
> 
> That patch AS IS isn't going to work.  On my system (using
> PrintPro/CUPS), lpstat -d -v prints out in a slightly different
> format:
> 
> $ lpstat -d -v
> system default destination: epson
> device for epson: parallel:/dev/lp0
> device for epson-big: parallel:/dev/lp0
> device for foo: /tmp/out
> device for null: /dev/null

Ok, then only the second word (for) seems to be stable (the third always seems
to be the printer name). Any other systems around ?

> Note that it uses "device" rather than "system".  If you want to
> figure out how to make it work in general, go ahead -- it's a
> reasonable idea for 3.0.
> 
> In the intermediate term, we're considering getting rid of all of this
> stuff and using some kind of printer definition dialog, partly because
> we haven't found any robust programmatic way of determining the list
> of printers on the system and partly because it's reasonable for users
> to want to define virtual printers with different combinations of
> settings.  Something like that's likely to make it into 3.2 (after
> having been in 3.1 for a while) as part of a general overhaul of the
> UI.
> 
> In the longer run, a more general solution to the printing problem is
> needed.

I agree. But the patch should be included nonetheless because it makes
printing with Gimp possible :-)

>    *** gimp-1.1.16/plug-ins/print/print.c~	Mon Jan 31 03:32:25 2000
>    --- gimp-1.1.16/plug-ins/print/print.c	Tue Feb  8 15:51:56 2000
>    ***************
>    *** 3146,3152 ****
>      #endif /* LPC_COMMAND */
> 
>      #ifdef LPSTAT_COMMAND
>    !   if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
>        {
> 	 char name[17];	
> 
>    --- 3146,3152 ----
>      #endif /* LPC_COMMAND */
> 
>      #ifdef LPSTAT_COMMAND
>    !   if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
>        {
> 	 char name[17];	
> 
>    ***************
>    *** 3153,3159 ****
> 	 while (fgets(line, sizeof(line), pfile) != NULL &&
> 		plist_count < MAX_PLIST)
> 	 {
>    !       if (sscanf(line, "printer %s", name) == 1)
> 	   {
> 	   strcpy(plist[plist_count].name, name);
> 	   sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
>    --- 3153,3159 ----
> 	 while (fgets(line, sizeof(line), pfile) != NULL &&
> 		plist_count < MAX_PLIST)
> 	 {
>    !       if (sscanf(line, "system for %[^:]s:", name) == 1)
> 	   {
> 	   strcpy(plist[plist_count].name, name);
> 	   sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);

-- 
Dipl. Inf. (FH) Aaron "Optimizer" Digulla
"(to) optimize: Make a program faster by
improving the algorithms rather than by       
buying a faster machine."                     

Re: [Gimp-print-devel] stc740 results (15-Feb-2000)

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

I don't know what exactly the PostScript mode of the plugin does,
but would it help to generate a PS file from my test image and 
then feed that to GS? What I'm asking is would be using a plugin
generated PS file better than just some PS file? Would be be able
to find a pixel in the PS file and identify the same pixel in 
the bitmap output?

Karl Heinz

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

>    Date: Tue, 15 Feb 2000 07:43:41 -0500
>    From: Karl Heinz Kremer <kh...@kh...>
> 
>    I run two test jobs this morning: The 720dpi/softweave/variable
dot
>    size job looks the same as before, if I run the same job with
fixed
>    dot size then I get the "blank page" behavior: Printer does some
>    vertical movement, makes some sounds and then spits out the page 
>    without any horizontal head movement or ink on the paper.
> 
> grr...OK, I'm going to back out that "fix" for now...
> 
> I suppose it would be worthwhile running something through gs with
the
> appropriate upp file to see exactly what IT does.
> 
> -- 
> 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] stc740 results (15-Feb-2000)

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

I run two test jobs this morning: The 720dpi/softweave/variable dot
size job looks the same as before, if I run the same job with fixed
dot size then I get the "blank page" behavior: Printer does some
vertical movement, makes some sounds and then spits out the page 
without any horizontal head movement or ink on the paper.

Karl Heinz

[Gimp-print-devel] Re: Patch for print plugin

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

   Date: Tue, 15 Feb 2000 13:50:27 +0100
   From: Aaron Optimizer Digulla <di...@un...>

   Here is a patch for the print plugin. The patch fixes an anoyance
   with the print dialog: If you have lots of printers (we have about
   50 here), it takes *several minutes* to open. Fix: Just use lpstat
   -d -v (just list the names of the printers instead of checking if
   they are enabled; the information is discarded anyway). Later, when
   it becomes clear that we can use that info, we can reenable it
   again (including some kind of caching and a progress report which
   shows that Gimp is still doing something).

That patch AS IS isn't going to work.  On my system (using
PrintPro/CUPS), lpstat -d -v prints out in a slightly different
format:

$ lpstat -d -v
system default destination: epson
device for epson: parallel:/dev/lp0
device for epson-big: parallel:/dev/lp0
device for foo: /tmp/out
device for null: /dev/null

Note that it uses "device" rather than "system".  If you want to
figure out how to make it work in general, go ahead -- it's a
reasonable idea for 3.0.

In the intermediate term, we're considering getting rid of all of this
stuff and using some kind of printer definition dialog, partly because
we haven't found any robust programmatic way of determining the list
of printers on the system and partly because it's reasonable for users
to want to define virtual printers with different combinations of
settings.  Something like that's likely to make it into 3.2 (after
having been in 3.1 for a while) as part of a general overhaul of the
UI.

In the longer run, a more general solution to the printing problem is
needed.

   *** gimp-1.1.16/plug-ins/print/print.c~	Mon Jan 31 03:32:25 2000
   --- gimp-1.1.16/plug-ins/print/print.c	Tue Feb  8 15:51:56 2000
   ***************
   *** 3146,3152 ****
     #endif /* LPC_COMMAND */

     #ifdef LPSTAT_COMMAND
   !   if ((pfile = popen(LPSTAT_COMMAND " -d -p", "r")) != NULL)
       {
	 char name[17];	

   --- 3146,3152 ----
     #endif /* LPC_COMMAND */

     #ifdef LPSTAT_COMMAND
   !   if ((pfile = popen(LPSTAT_COMMAND " -v -d", "r")) != NULL)
       {
	 char name[17];	

   ***************
   *** 3153,3159 ****
	 while (fgets(line, sizeof(line), pfile) != NULL &&
		plist_count < MAX_PLIST)
	 {
   !       if (sscanf(line, "printer %s", name) == 1)
	   {
	   strcpy(plist[plist_count].name, name);
	   sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);
   --- 3153,3159 ----
	 while (fgets(line, sizeof(line), pfile) != NULL &&
		plist_count < MAX_PLIST)
	 {
   !       if (sscanf(line, "system for %[^:]s:", name) == 1)
	   {
	   strcpy(plist[plist_count].name, name);
	   sprintf(plist[plist_count].v.output_to, LP_COMMAND " -s -d%s", name);

Re: [Gimp-print-devel] stc740 results (15-Feb-2000)

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

   Date: Tue, 15 Feb 2000 07:43:41 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I run two test jobs this morning: The 720dpi/softweave/variable dot
   size job looks the same as before, if I run the same job with fixed
   dot size then I get the "blank page" behavior: Printer does some
   vertical movement, makes some sounds and then spits out the page 
   without any horizontal head movement or ink on the paper.

grr...OK, I'm going to back out that "fix" for now...

I suppose it would be worthwhile running something through gs with the
appropriate upp file to see exactly what IT does.

-- 
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] stc740 results (15-Feb-2000)

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

I run two test jobs this morning: The 720dpi/softweave/variable dot
size job looks the same as before, if I run the same job with fixed
dot size then I get the "blank page" behavior: Printer does some
vertical movement, makes some sounds and then spits out the page 
without any horizontal head movement or ink on the paper.

Karl Heinz

Re: [Gimp-print-devel] stc740: Partial success

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

> I wonder if the ESC. command works differently from the ESCi command
> in this regard...

Well, that's entirely possible.  In one case you're explicitly stating
a dot spacing, in the other, you're relying on the printer having been
initialized with a particular command to set the resolution.  The
documentation doesn't clearly specify which register determines the
printing resolution.  I think it would be pretty easy to screw this up.

Eric

[Gimp-print-devel] layout

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

I finally got tired enough of all the stupid layout bugs so that I
decided to sit down and fix them all (well, there's still one left;
it's possible to overflow the page in dpi mode).  Specifically:

1) It wasn't possible to print to the edge of the page (as defined by
   the printer).

2) The page top/bottom/left/right (particularly bottom and right) in
   the size boxes wasn't displayed accurately (it *had* been coded in
   1/10", because that's the units used to print out the pager --
   really sillyl, that -- now it's all in points, which is more
   reasonable if still not all that precise).

3) The behavior of landscape mode was weird, to say the least.

4) Calculating the size based on scaling was also weird -- in portrait
   mode it just looked at the height of the page vs. the height of the
   image, and in landscape it just looked at width of the page and
   height of the image.  Now it looks at both axes and scales so that
   the larger of the two ratios (widths and heights) is set equal to
   the scale factor.  That seems more intuitive to me, at any rate.
   It avoids flipping between landscape and portrait mode as you
   rescale the image in auto mode (which seems just plain bizarre to
   me).

5) I changed the escp2 stuff so that the distance from the paper edge
   will be identical in softweave and in microweave mode.  Henryk,
   that might not quite be what you intended (it's the opposite of
   what you actually did), but at least microweave and softweave
   should generate stuff that looks consistent.

I might fix the bottom edge in softweave mode tonight, or maybe not.
I'm pretty sure it's leaving more space than it needs to, but I'll
have to experiment to find out what's safe.

-- 
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] More on the 740

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

I've tried changing the code to use the old-style print commands at
single bit depth resolution.  Karl, could you give this a try when you
get a chance?

Re: [Gimp-print-devel] Image corruption

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

I tried linking it against Electric Fence, and nothing was trapped.
That doesn't prove it isn't memory corruption, but it suggests that
something else is going on.

-- 
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] Image corruption

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

   Date: Mon, 14 Feb 2000 14:06:50 +0000
   From: Dave Hill <da...@mi...>

   Yes, the lower right corner is messed up. What seems to happen is that
   a white patch starts to creep in from the right hand side (long edge
   of the paper), starting further to the left each row. Further down,
   a black patch may start to appear from the right, although it sometimes
   goes away again.

Does it come in at a true diagonal or something else?

   >    I think I'm going to have to write a "hp_unprint" program to
   >    save some paper!

   This I have now done, I will submit it. It only handles mono 2-level
   output at the moment, but it's a start!

I'm looking forward to seeing this!

   It looks to me as if this problem is memory corruption. The "black"
   buffer is getting overwritten by something else.

Re: [Gimp-print-devel] stc740: Partial success

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

   From: sh...@al...
   Date: Mon, 14 Feb 2000 19:50:28 +0900

   > I have a suspicion about what else is going on (besides the row
   > spacing) -- I have a vague idea (because of the extra width of
   > these prints) that the column spacing is something other than
   > 1/720" (specifically, 1/360").  If this is the case, we have to
   > treat the 740 and friends as a 360 dpi printer to get 720 dpi the
   > same way we get 1440 dpi out of a 720 dpi printer.

   I don't think this is the case.  The Ghostscript uniprint driver for the
   740 seems to write 720 DPI directly without any funny business.

I wonder if the ESC. command works differently from the ESCi command
in this regard...

-- 
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] Image corruption

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

Robert L Krawitz wrote:
> 
>    Date: Thu, 10 Feb 2000 09:50:35 +0000
>    From: Dave Hill <da...@mi...>
> 
>    Robert L Krawitz wrote:
>    >
>    >    Date: Wed, 09 Feb 2000 14:51:21 +0000
>    >    From: Dave Hill <da...@mi...>
>    >
>    >    I have just tried printing some tests on my HP printer and I'm
>    >    getting an interesting image corruption. Basically, across the
>    >    bottom right of the image, there is a white patch followed by
>    >    a black patch at about 45 degrees.
>    >
>    >    I have gone back through my snapshots and the problem appears
>    >    between 0205 and 0206 - i.e. when the dither stuff was changed/
>    >    split out.
>    >
>    >    Has anyone else seen this?
>    >
>    > I haven't seen any problems on my Epson Stylus Photo EX.  Is your
>    > printer a variable drop size printer or single drop size?
> 
>    Mono Single drop size, using dither_black().
> 
> I can't see any obvious reason for this problem.  Is part of the image
> OK, but part of it messed up?

Yes, the lower right corner is messed up. What seems to happen is that
a white patch starts to creep in from the right hand side (long edge
of the paper), starting further to the left each row. Further down,
a black patch may start to appear from the right, although it sometimes
goes away again.

> 
>    > Oh foo, I think I know what the problem is.  You're probably
>    > seeing it in landscape mode, but portrait mode probably works
>    > fine.
> 
>    No, this was in portrait mode. I then went on to try landscape
>    and it's totally screwed up, you get the required output
>    squashed horizontally into half of the page and junk in the
>    other half!
> 
> What's the shape of the image?  Is it square, rectangular, which side
> is longer, what are the dimensions...

Landscape mode is now working after your change to the calling of
init_dither(). By working, I mean that it now has the same problem
as portrait!

The image I was trying is 190x110 (i.e. wider than it is high). I also
tried a 256x256 grey gradient which also doesn't work.

The effect varies as you change the scaling.

> 
>    I think I'm going to have to write a "hp_unprint" program to
>    save some paper!


This I have now done, I will submit it. It only handles mono 2-level
output at the moment, but it's a start!

It looks to me as if this problem is memory corruption. The "black"
buffer is getting overwritten by something else.

Dave

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