gimp-print-devel

Re: [Gimp-print-devel] Width and Height OK with stc740

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

   Date: Fri, 18 Feb 2000 20:55:12 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   One other thing that I noticed is that the location of the image on=20
   the page seems to be off: I placed the image on various places, and
   it looks like if I place it about halfway across the page horizontally
   it ends up on the right edge (I'm still using the small penguin, the
   image is about half an inch each side, so this is definitely not
   correct).

Does this happen in both 720 and 1440 dpi modes?  I have a suspicion
that it's specific to 720, and that 1440 will work correctly.

(Needless to say, it needs to be fixed in any event, but I have a
theory about what's going on and I'd like to test it first).

Re: [Gimp-print-devel] OUTPUT_GRAY != (!OUTPUT_COLOR)

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

   Date: Sat, 19 Feb 2000 12:41:29 +0000
   From: Dave Hill <da...@mi...>

   if (output_type == OUTPUT_COLOR && ydpi > 360 && !use_softweave)

   I think this needs to be changed!

It does.  Thanks.

-- 
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] Can Stylus print closer than 23mm to top of page?

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

   Date: Sat, 19 Feb 2000 16:28:42 +0800
   From: Nick Urbanik <ni...@vt...>

   Robert L Krawitz wrote:

   > Any suggestions on how to persuade my printer
   >    to start printing closer to the top of the page?
   >
   > Are you using one of the softweave modes?  There's a known problem
   > with that; the page edges aren't being calculated correctly.

   I'm using the 720 dpi Microweave mode.  Is that a softweave mode?
   What do you suggest I do?  Where do I start?  I'm using version
   3.05.

No the (very slow) microweave mode is not a softweave mode.  Do you
mean that the printer feeds 23 mm before starting to print?

-- 
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] Width and Height OK with stc740

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

   Date: Fri, 18 Feb 2000 20:55:12 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   One other thing that I noticed is that the location of the image on=20
   the page seems to be off: I placed the image on various places, and
   it looks like if I place it about halfway across the page horizontally
   it ends up on the right edge (I'm still using the small penguin, the
   image is about half an inch each side, so this is definitely not
   correct).

So that suggests we're still off by a factor of 2 in horizontal
placement (or that we're adding two things together).

-- 
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] Unprint (was Re: Width and Height OK with stc740)

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

> I had a think about this overnight and came up with two things:-
> 
> First, don't bother with the pcl-unprint in the CVS,

:)  I just started to make modifications to it about 3 minutes ago...

I wasn't sure if you were still working on it or not.

> When I find the problem with decoding CMYK output then I will
> submit it.

Care to elaborate?
 
> Second, I wonder if it is a useful thing to do to combine all
> three unprint programs into one?

I think so.  I think it will save us work in the long run.  Now that the
base functionality is in place, all of the extra features should be common
to all types of printers.

> Is the work involved justified given that they're only test tools?

They're useful tools, though.  I think it's justified, not because the
tools themselves are important, but because I think the work required
will actually be less than maintaining separate tools.

Eric

[Gimp-print-devel] Unprint (was Re: Width and Height OK with stc740)

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

Eric wrote:

> Yeah.  Now that unprint is actually working (at least some of
> the time) I'd like to merge unprint with canon-unprint and
> pcl-unprint.  I want to solicit comments from Andy and Dave
> before doing this, though.

I had a think about this overnight and came up with two things:-

First, don't bother with the pcl-unprint in the CVS, I've revised
it extensively since then to make it work with colour output and
to tidy it up a bit. The original was hacked together to
save me paper when I was trying to fathom out the dithering bug.
When I find the problem with decoding CMYK output then I will
submit it.

Second, I wonder if it is a useful thing to do to combine all
three unprint programs into one? Is the work involved justified
given that they're only test tools?

Just my 5p (UK pence) worth.

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] OUTPUT_GRAY != (!OUTPUT_COLOR)

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

Just a quick note.

Since Robert's change to add OUTPUT_GRAY_COLOR, note that
OUTPUT_GRAY and !OUTPUT_COLOR are not the same anymore.

Make sure that you check for (output_type == OUTPUT_GRAY) for
mono output and (output_type != OUTPUT_GRAY) for colour (sic)
output.

I am submitting print-pcl.c to fix this, but I notice also that
in print-escp2.c, there is on line 915:-

if (output_type == OUTPUT_COLOR && ydpi > 360 && !use_softweave)

I think this needs to be changed!

Dave

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

Re: [Gimp-print-devel] Can Stylus print closer than 23mm to top of page?

[Nick U. <ni...@vt...>]

Robert L Krawitz wrote:

> Any suggestions on how to persuade my printer
>    to start printing closer to the top of the page?
>
> Are you using one of the softweave modes?  There's a known problem
> with that; the page edges aren't being calculated correctly.

I'm using the 720 dpi Microweave mode.  Is that a softweave mode?  What do you
suggest I do?  Where do I start?  I'm using version 3.05.

--
Nick Urbanik, Dept. of Electrical & Communications Engineering
Hong Kong Institute of Vocational Education (Tsing Yi)
email: ni...@vt..., ni...@io...
Tel:   (852) 2436 8660, (825) 2436 8492   Fax: (852) 2436 8643
pgp ID: 7529555D fingerprint: 53 B6 6D 73 52 EE 1F EE EC F8 21 98 45 1C 23 7B

Re: [Gimp-print-devel] Width and Height OK with stc740

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

>    just under the calculation of the skip factor, and the Graphic2.prn file
>    then unprints very nicely.  In fact, the image looks so good (in terms of
>    pixel placement), it really calls attention to how badly I'm approximating
>    the colors.  I really should fix that...
> 
> That's going to be a lot of work, I suspect.

Improving it should be easy.  Making it perfect would be a lot of work.
I think I'm going to code in some routines that would allow you to specify
ink colors in LAB coordinates.  I won't actually commit any numbers, but,
if you did happen to have a set of LAB coordinates for the inks, it would
make it easy to try them.

> I don't think that the long init string or remote mode section has
> anything to do with it, since we don't print that.  As for the ESC(D
> command, that's anybody's guess.  I think we need to try printing with
> and without that command present in various modes to see what happens.

I'll make up some files and ask my wife to try to print them this weekend.

> BTW, could you check in your latest unprint when you get a chance?

:)  Ok.  The only difference is that one line, but, I can commit it.  I think
it would be better if I code it a little more elegantly first, though.

Eric

[Gimp-print-devel] 740 printing

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

I ran some tests with the cvs I downloaded at 1830 MST.  720 dpi
microweave no longer works, just ejcts pages in both single and variable
dot sizes.  Softweave works in single dot size but ejects paper in
variable dot size.  Same with 720 dpi high quality.  I had the image
centered in the dialog, but it prints far to the left side and slightly
below center on the page.  360 dpi no longer works either.

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

Re: [Gimp-print-devel] Width and Height OK with stc740

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

On Fri, Feb 18, 2000 at 08:36:02PM -0500, Robert L Krawitz wrote:
> BTW, could you check in your latest unprint when you get a chance?
> If we get even halfway decent printing on the 740 (the bits come out
> in the right place), I want to do the release this weekend or at
> latest Monday, to get the code out there.

I had a minute today and I tried my test image a few time on different
places on the page with 720 dpi softweave: It worked most of the time -
I got a perfect picture. However, a few times the printer behaved like
before: Just spitting out the blank page. Is it possible that something
with the vertical/horizontal motion commands is wrong? It could also be
that I still had some bytes in the queue or in the driver from the last
job that were send to the printer and screwing up the job. I should be
able to do some more testing tomorrow. I did not test any of the other
modes, and I only used the variable dot size.=20

One other thing that I noticed is that the location of the image on=20
the page seems to be off: I placed the image on various places, and
it looks like if I place it about halfway across the page horizontally
it ends up on the right edge (I'm still using the small penguin, the
image is about half an inch each side, so this is definitely not
correct).

I'll let you know what I find out tomorrow.

Karl Heinz

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

Re: [Gimp-print-devel] Print plugin 3.0.6 bug report

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

   Date: Fri, 18 Feb 2000 20:02:57 +0100
   From: "Stefan K. Berg" <sf...@co...>

   This smaller picture prints OK in microweave mode though, where the
   previous picture created an all black output but in the right size.

Hmm.  That makes no sense at all to me.  I'll probably need to see the
big one.

-- 
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] Width and Height OK with stc740

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

   From: sh...@al...
   Date: Sat, 19 Feb 2000 02:41:36 +0900

   > You'll note that the ESC(/ command
   > is starting the lines at different horizontal positions (offset 0, 1,
   > 2, and 3).

   Ah, this was the crucial piece of information which I missed.  Now all is
   clear.

   Well, almost...

   Currently, unprint is calculating a "skip factor", which says how
   many pixels to move over to the right for each pixel printed.  I
   added the line:

     skip*=2;

   just under the calculation of the skip factor, and the Graphic2.prn file
   then unprints very nicely.  In fact, the image looks so good (in terms of
   pixel placement), it really calls attention to how badly I'm approximating
   the colors.  I really should fix that...

That's going to be a lot of work, I suspect.

   But, my question is, is this simple hack correct?  Do we just want to double
   the skip factor under all conditions, or, just certain conditions?  I really
   think this information has to be in the ESCP2 file somewhere.  Either in
   the long init string, in the remote mode section, or the ESC(D.

I don't think that the long init string or remote mode section has
anything to do with it, since we don't print that.  As for the ESC(D
command, that's anybody's guess.  I think we need to try printing with
and without that command present in various modes to see what happens.

BTW, could you check in your latest unprint when you get a chance?
If we get even halfway decent printing on the 740 (the bits come out
in the right place), I want to do the release this weekend or at
latest Monday, to get the code out there.

-- 
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] Print plugin 3.0.6 bug report

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

   Date: Thu, 17 Feb 2000 07:43:20 +0100
   From: "Stefan K. Berg" <sf...@co...>

   Hopefully this is the right place to report this. When using a recent CVS
   image of Gimp with the 3.0.6 print plugin I get weird behavior on my Epson
   Stylus Color 800.

   When printing a picture in microweave mode, I get a completely black square.
   If I print the same picture in highest quality, the printer makes a few
   horisontal movements and then just starts feeding paper.

I reproduced your problem with highest quality mode, and I've fixed in
the 3.0 branch (it was already fixed on the mainline).  However, I
can't reproduce your problem with microweave.  This will be fixed in
3.0.7 along with any other accumulated bugs (there's at least one, and
someone's trying to persuade me to do something else).

   I've uploaded the picture file (1.7 MB) together with a short description to
   http://home.swipnet.se/consultron/print.html (sorry, can't do FTP) in case
   someone would like to look into this. I haven't uploaded the resulting print
   files (3.8 MB & 13.6 MB compressed), but if this helps I'd be happy to.

Could you do this for the microweave test, since I can't reproduce it?

Re: [Gimp-print-devel] Print plugin 3.0.6 bug report

[Stefan K. B. <sf...@co...>]

Robert L Krawitz wrote:
> 
>    Date: Thu, 17 Feb 2000 15:01:18 +0100
>    From: "Stefan K. Berg" <sf...@co...>
> 
>    Robert L Krawitz wrote:
>    >
>    >    Hopefully this is the right place to report this. When using a recent CVS
>    >    image of Gimp with the 3.0.6 print plugin I get weird behavior on my Epson
>    >    Stylus Color 800.
>    >    <...>
>    >
>    >             Is this a regression from earlier behavior?
> 
>    Uhm, well, the previous version of Gimp that I used was the 1.0.4
>    source code release, which compiles and prints just fine. But
>    that's print v. 2.0.2 of course. Sorry that I can't give you any
>    current regression info.
> 
> Do you know if this problem only happens if you try to print something
> hard against the left margin?  In other words, if you move it away
> from the left margin of the page, does it then manage to print?

No, don't see any different results when I move towards or away from the left
margin.

I've used a smaller test picture though, and since the resulting output files
got smaller, I've uploaded them as well -  don't know if it will be of any
use for you.

This smaller picture prints OK in microweave mode though, where the
previous picture created an all black output but in the right size.

See http://home.swipnet.se/consultron/print2.html for details and download.

Re: [Gimp-print-devel] Width and Height OK with stc740

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

> You'll note that the ESC(/ command
> is starting the lines at different horizontal positions (offset 0, 1,
> 2, and 3).

Ah, this was the crucial piece of information which I missed.  Now all is
clear.

Well, almost...

Currently, unprint is calculating a "skip factor", which says how many pixels
to move over to the right for each pixel printed.  I added the line:

  skip*=2;

just under the calculation of the skip factor, and the Graphic2.prn file
then unprints very nicely.  In fact, the image looks so good (in terms of
pixel placement), it really calls attention to how badly I'm approximating
the colors.  I really should fix that...

But, my question is, is this simple hack correct?  Do we just want to double
the skip factor under all conditions, or, just certain conditions?  I really
think this information has to be in the ESCP2 file somewhere.  Either in
the long init string, in the remote mode section, or the ESC(D.

Eric

Re: [Gimp-print-devel] [davidy@stcservices.com: RE: Test Report for Epson Stylus 900]

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

   From: sh...@al...
   Date: Fri, 18 Feb 2000 23:38:11 +0900

   > 1440black.prn still segv's on me

   Well, it unprints successfully now, but the resulting image isn't perfect.
   There's a little ghosting of the tops of the characters slightly to the
   right of the real image.  I won't have time to look into that tonight.

OK.  This could just as easily be a bug in the weave code as in the
simulator; we'll need a real printout to be certain.

Re: [Gimp-print-devel] [davidy@stcservices.com: RE: Test Report for Epson Stylus 900]

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

> 1440black.prn still segv's on me

Well, it unprints successfully now, but the resulting image isn't perfect.
There's a little ghosting of the tops of the characters slightly to the
right of the real image.  I won't have time to look into that tonight.

Eric

Re: [Gimp-print-devel] [davidy@stcservices.com: RE: Test Report for Epson Stylus 900]

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

> 1440black.prn still segv's on me:
> 
> #0  0x8048f2d in update_page (buf=0x804c430 "", bufsize=376, m=188, n=8, 
>     color=0, density=1440) at unprint.c:342
> 342         if (page[y]->line[color]) {
> (gdb) where
> #0  0x8048f2d in update_page (buf=0x804c430 "", bufsize=376, m=188, n=8, 
>     color=0, density=1440) at unprint.c:342

m=188???  That's a lot of heads.

I see what's happened.  It's printing off the edge of the page.  I was
checking to make sure that the first stripe was on the page, but this pass
goes beyond the bottom margin.  The upper parts of the pass are on the page,
but the lower parts are below.  This should be easy enough to fix.

Eric

Re: [Gimp-print-devel] Width and Height OK with stc740

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

   From: sh...@al...
   Date: Fri, 18 Feb 2000 21:58:17 +0900

   The Canon unprinter is in C++ while the other two are in C.  Andy,
   how would you feel about converting this to C?  It doesn't look
   like there's extensive use of C++ functionality in there.
   Converting it to C would be a fairly trivial job, I think, but you
   may have other objections.  If you feel strongly about keeping it
   in C++, then we'll leave it in C++.  Having C code call C++ code is
   possible, if not pretty.

All it requires is an extern "C" declaration around the function
prototype, and it will have C semantics.

Re: [Gimp-print-devel] Width and Height OK with stc740

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

   From: sh...@al...
   Date: Fri, 18 Feb 2000 22:10:51 +0900

   > Eric, when you get a chance, could you fix the simulator to get the
   > shape right (double the width)?

   Uh, ok.  How, though?  Currently, we have pixels sharing the same
   coordinates.  I can certainly space these out at double with width,
   but, one pixel should go to 2x and the other 2x+1.  Which is which?

Well, no, they're not really sharing coordinates.  The horizontal
spacing units set by ESC(U are still multiples of 1440 dpi.  When
printing at 1440 dpi there's already the issue of the pixels not being
spaced at 1 unit (they're spaced 2 units apart); this just extends
that principle, so at 1440 dpi they're spaced 4 units apart and at 720
dpi they're spaced 2 units apart.  You'll note that the ESC(/ command
is starting the lines at different horizontal positions (offset 0, 1,
2, and 3).

-- 
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] Width and Height OK with stc740

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

> Eric, when you get a chance, could you fix the simulator to get the
> shape right (double the width)?

Uh, ok.  How, though?  Currently, we have pixels sharing the same coordinates.
I can certainly space these out at double with width, but, one pixel should
go to 2x and the other 2x+1.  Which is which?

Eric

Re: [Gimp-print-devel] [davidy@stcservices.com: RE: Test Report for Epson Stylus 900]

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

>    From: sh...@al...
>    Date: Fri, 18 Feb 2000 21:34:27 +0900
> 
>    > What is this???
> 
>    What is what?
> 
> This message:
> 
> Segmentation integrity.  (core contained)

Oh, that.  I forgot about that.  It prints that at the end of processing
just before terminating.  I was getting some really strange segmentation
faults where my shell was not printing the fact that the program dumped core.
It just ran the code and it appeared to stop.  I put that in to show that
the program finished everything and terminated without error.  I'll probably
take it out in my next commission.

Eric

Re: [Gimp-print-devel] [davidy@stcservices.com: RE: Test Report for Epson Stylus 900]

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

   From: sh...@al...
   Date: Fri, 18 Feb 2000 21:34:27 +0900

   > What is this???

   What is what?

This message:

Segmentation integrity.  (core contained)

Re: [Gimp-print-devel] Width and Height OK with stc740

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

> Eric wants a single unprint command for all the printers, with runtime
> determination of what it is (either by inspection of the file or by a
> command line switch).  That seems fair enough.  So it will stay
> unprint.c for now.

Yeah.  Now that unprint is actually working (at least some of the time)
I'd like to merge unprint with canon-unprint and pcl-unprint.  I want to
solicit comments from Andy and Dave before doing this, though.

There are a couple of issues.

The Canon unprinter is in C++ while the other two are in C.  Andy, how would
you feel about converting this to C?  It doesn't look like there's extensive
use of C++ functionality in there.  Converting it to C would be a fairly
trivial job, I think, but you may have other objections.  If you feel strongly
about keeping it in C++, then we'll leave it in C++.  Having C code call
C++ code is possible, if not pretty.

The code also looks a little weird to me.  Why are there so many output
files?

pcl-unprint looks a little easier to integrate.


What I've done in unprint.c is to isolate all of the escp2 specific parts
into a single subroutine.  This subroutine is given a file pointer to an
open file, and it reads in the escp2 data.  When it extracts a section
of raster data from the file, it makes a call to a generic routine to store
this data in RAM.  When the escp2 routine returns, the stored image is
organized into a PPM and written out.

I would like to convert pcl-unprint and cannon-unprint to work the same way
as the parse-escp2 subroutine of unprint.  Any comments/objections?

Eric