gimp-print-devel

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

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

   From: David Yerger <da...@st...>
   Date: Sun, 20 Feb 2000 14:21:44 -0500

   PROGRESS!!!!
   With freshly grabbed & compiled stuff from CVS ~1:00 PM Sunday EST:

   900 driver:
   360 dpi WORKS
   720 Microweave WORKS

Those are "back compatibility" mode.  What's the quality like?

   720 Softweave - blank pages
   720 High Quality - blank pages
   1440x720 Softweave - nothing comes out? have to 2xcheck

That's unfortunate.  We need to understand the difference between the
900 and the 740 in this regard, because at this point I have reason to
believe that the 740 prints correctly in softweave modes (of which all
three above are).

1) Could you try to print a small image in the top left corner of the
   page (left=0, top=0), using 720 softweave?

2) At line 1053 of print-escp2.c, you will find the following:

      fwrite("\033(D\004\000\100\070\170\050", 9, 1, prn);

   Try removing this line.

3) At line 1016, you will find this:

      if (escp2_has_cap(model, MODEL_6COLOR_MASK, MODEL_6COLOR_YES))

   Try changing it to

      if (1)

4) You will find this at line 628:

  /* 13: Stylus Color 900 */
  /* Dale Pontius thinks the spacing is 3 jets??? */
  /* No, Eric Sharkey verified that it's 2! */
  (MODEL_PAPER_LARGE | MODEL_IMAGEABLE_NEW | MODEL_INIT_440
   | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
   | MODEL_VARIABLE_4 | MODEL_MAKE_XRES(360)
   | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(96) | MODEL_MAKE_SEPARATION(2)),

   Try changing the MODEL_MAKE_NOZZLES(96) to MODEL_MAKE_NOZZLES(32).

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

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 19 Feb 2000 19:49:53 +0100
>    From: "Stefan K. Berg" <sf...@co...>
> 
>    Robert L Krawitz wrote:
>    >
>    > In print-escp2.c, look for this:
>    >
>    >   /* 4: Stylus Color 800 */
>    >   (MODEL_PAPER_SMALL | MODEL_IMAGEABLE_600 | MODEL_INIT_600
>    >    | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
>    >    | MODEL_VARIABLE_NORMAL | MODEL_MAKE_XRES(720)
>    >    | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(64) | MODEL_MAKE_SEPARATION(8)),
>    >
>    > It's around line 584 on the current mainline.  Try change
>    >
>    > MODEL_MAKE_NOZZLES(64)
>    >
>    > to
>    >
>    > MODEL_MAKE_NOZZLES(48)
>    >
>    > or if that doesn't work
>    >
>    > MODEL_MAKE_NOZZLES(32)
>    >
>    > If that helps, then my information about how many nozzles the 800 has
>    > is incorrect (which is possible).
> 
>    Just tried this with the mainline code, but the behavior really doesn't
>    change. Still just numerous paper feeds.
> 
> Could you try a couple of other things?
> 
> 1) Try changing MODEL_MAKE_NOZZLES(64) to MODEL_MAKE_NOZZLES(24).
> 
> 2) At line 2447, the following appears:
> 
>               fprintf(prn, "\033.%c%c%c%c", 1, 8 * 5, 5,
> 
> Please change the "8 * 5" to "5" (not in quotes, of course).
> 
> 3) At line 2407, the following appears:
> 
>       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES))
> 
> Please change it to
> 
>       if (escp2_has_cap(model, MODEL_1440DPI_MASK, MODEL_1440DPI_YES) &&
>           ydpi > 720)
> 
> Let me know if anything changes in softweave mode.

Yes indeed, this time I get output of about the right size but it looks very
garbled. I've scanned the output of 720 DPI Softweave mode, which you will
find at http://home.swipnet.se/consultron/scan1.gif (96 kB). The black ink has
bled through my inkjet paper. Also, the printer made some strange noises when
printing this - a quiet but noticable "whooshing" sound from time to time.

Setting MODEL_HASBLACK_NO without applying your modifications above did 
nothing, I still got paper feeds. Setting MODEL_HASBLACK_NO with the above
changes gave me rows of color each with different distances of each other
but never less than 0.5 inch apart.

Re: [Gimp-print-devel] ESC(D command

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

> 1) ESP750, 1440 DPI:	00000083  1b  (  D 04 00 40 38 78 28 
> 2) ESP750,  720 DPI:	00000083  1b  (  D 04 00 40 38 78 28 
> 3) ESP900,  360 DPI:	0000008a  1b  (  D 04 00 40 38 28 28 (grayscale)
> 4) ESP900,  720 DPI:	0000008a  1b  (  D 04 00 40 38 28 50 (grayscale)
> 5) ESP900, 1440 DPI:	0000008a  1b  (  D 04 00 40 38 28 50 (grayscale)
> 
> Somebody with one of these printers is just going to have to play with
> this command and see what happens.  I'll forward the message with the
> print files separately.

I got my wife on the 'net, and with a talk session going in on window and
a shell in another, I sent files to the printer and had her interpret the
results.

I used the Graphic2.prn file, and used beav to modify the file before
sending it to the printer.  First we printed the original file unmodified.
Then I removed the ESC(D command entirely, then I changed 78 28 to 28 50,
then I sent the command with all four bytes 0, and finally we printed the
original again, to guage changes in the printer itself due to warming up.

The result was that all the images seemed to be identical, within the
variation of the two prints of the original.

That's all that time would allow.

I have to run.  I have to shlep back across the country tomorrow.  Luckily
it's a rather narrow country.

Eric

Re: [Gimp-print-devel] Re: Unprint

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

> When I pcl-unprint a CMYK PCL file, the black is "smudged", i.e.
> there is unwanted black getting in somewhere. I assumed I had
> made a coding mistake.

Why don't you check in the code you have so far and then we can all
take a look at it.  Code doesn't need to be "bug-free" to get checked
in.  If it compiles, runs, and produces output, that's good enough for
a commission.

Eric

[Gimp-print-devel] Re: Unprint

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

Eric Wrote:
> Dave Hill Wrote:
> >
> > When I find the problem with decoding CMYK output then I will
> > submit it.
> 
> Care to elaborate?
> 

When I pcl-unprint a CMYK PCL file, the black is "smudged", i.e.
there is unwanted black getting in somewhere. I assumed I had
made a coding mistake.

I've just done some recompiling of pcl-unprint to output either
the CMY part or the K part, and it looks rather like the
problem is not in pcl-unprint, but in dither_cmyk().

I tried with the output of print-2.0.2 and the CMY part
contains no black at all, but in all the 3.x versions back to
20000131, the CMY part contains black smears or shadows (the
K part is fine).

Robert - help!

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] stc740 success

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

I tried a new round of tests when I got home this evening, and
positioning seems to be working great.  I then tried a more or less full
size print of a scanned (at 450 dpi) photo, printed at 1440x720 on
coated paper.  The results were not as good as I expected.  Dithering in
a blue sky was grainy, and greens did not fare well at all.  Otherwise,
it looked OK, although some adjustments in contrast and saturation would
help.  Some experimentation is probably needed to find good default
values fro all the sliders across a variety of scene types.

I also found is that it is way too easy to tell the printer to print off
the page, which results in a bunch of blank paper being thrown around. 
Is this something we could try to pick up in the gui and enforce a limit
before it gets to the driver?  At the moment its kind of late, and I'm
not quite sure how to go about it.

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

[Gimp-print-devel] Re: gimp_image_get_resolution/gimp_image_get_unit/release timetable

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

   cc: gim...@sc...
   From: Sven Neumann <neu...@un...>
   Date: Sat, 19 Feb 2000 23:35:17 +0100

   > Well, thus far we've had very little trouble supporting 1.0.  Even the
   > configure script works properly.  1.0 is still the stable release of
   > the Gimp.

   I really don't understand your development cycle. We are approaching the 
   1.2 release but you insist on keeping the code that is going to ship with 
   1.2 compatible with 1.0. At the same time you start a new unstable branch
   heading towards a future you know nothing about yet. Why don't you put some 
   effort into making the print plugin that ships with 1.2 a nice and 
   featureful one? Adding new printers and other sophisticated stuff is 
   probably a bad idea, but overworking the UI and supporting resolution info 
   are things that should be addressed right now.

Well, we're at least nominally in feature freeze for 1.2.  I've seen
more than enough projects boondoggle because people try to add more
stuff in at the last minute and thereby delay things that I don't want
to cause that to happen here.  If we can ship 3.2 to high enough
quality standards sufficiently far in advance of Gimp 1.2 that's fine;
if not, I don't want to destabilize things further.

There has been a lot of talk on this list about not wanting to make
major changes to further slow down 1.2.  I happen to agree with that
position.  Gimp 1.2 needs to ship (IMHO), even if it isn't perfect, so
we can clear the decks for 1.3.  And while the print stuff is a
plugin, it's close enough to core functionality (every bit as much as,
say, .tif or .psd) that it needs to be responsible.

Despite this, if the gimp release management team were to announce
that the Gimp 1.2 release is now scheduled for August (6 months), I
would change my plans and aim for a 3.2 (or 4.0) release for early
summer or thereabouts, with the GUI rewrite and all that.  But that's
not the announced state of affairs right now; it's claimed to be a
fairly short term affair.

I didn't initially plan on 1.0 compatibility at all.  However, as soon
as the driver hit the street, a lot of people started asking about
1.0, and someone submitted a simple patch that worked.  Whatever's
going on in Gimp development land notwithstanding, there was a lot of
demand to print to 3 year old printers (as opposed to the 5 year old
printers that 2.0 supported).  The Stylus Photo EX is now 2
generations behind the times, but right now it's about the only even
remotely photo quality printer that works, and there are a lot of them
around, and people really want that.  If it's going to be another 6
months to a year before Gimp 1.2 comes out, then we really do need to
support 1.0 with the new printers and the UI improvements that we
already have.  If we're a month away, then 1.0 support is less
critical, but there's also no time to do serious UI work.

As for the matter of what's featureful, I guess it depends.  If you
have an Epson Stylus 740 or a Canon printer that isn't supported with
the current release, I would venture to say that that functionality is
a lot more important than the resolution info stuff, which after all
does have an easy workaround and which I'm not even convinced is
really that critical from anything other than a consistency
standpoint.  We really need core printers like the Stylus Color 740
and the Canon BJC series to work, and having really good printers like
the Stylus Photo 1200 (or better yet, the 1270) work will go a long
way to boosting the Gimp as a high quality graphics tool.  There are
already enough complaints that Linux doesn't support modern hardware,
and those really need to be addressed or the Gimp will be useless for
people who really want to do high end stuff such as photo
manipulation.

Spinoffs such as the Ghostscript driver are probably even more
important, for exactly the same reason.

Certainly the vast majority of comments we've received concern
operation of specific printers rather than specific UI features, and
the UI features I've heard the most about are things like CMY gamma
(individual channels) and such that really matter for printing.

What WOULD help us get to 3.2 faster would be for more people here to
check out 3.1 and the UI changes we've already made and give us
feedback on that, and for the Gimp team itself to give us a schedule
to help us plan our release timeframe.  Better yet, why doesn't
someone who wants this resolution stuff that badly code it up and
submit it, or join our project?

-- 
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] new 740 results

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

   Date: Sat, 19 Feb 2000 14:18:33 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I just run a test with all modes: Everything is working as far as the
   actual printing is concerned. The only problem is that the 720 softweave
   modes have a problem with the image placement. This is true for both
   variable and single dot size.

OK, I just checked in what I think will fix this and get the printout
about 3/8" closer to the top of the page.

-- 
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] new 740 results

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

Re: [Gimp-print-devel] new 740 results

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

   Date: Sat, 19 Feb 2000 14:18:33 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   I just run a test with all modes: Everything is working as far as the
   actual printing is concerned. The only problem is that the 720 softweave
   modes have a problem with the image placement. This is true for both
   variable and single dot size.

Well, looks like we're pretty close 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] Print plugin 3.0.6 bug report

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

   Date: Sat, 19 Feb 2000 20:19:58 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   I checked the specifications on Epson's site, and according to them the
   configuration is 128 black nozzles (32 x 4, staggered) and 64 color nozzles x
   3
   (C/M/Y). Your initial assumption seems right, if they're telling the truth.
   :)

Could you try changing the MODEL_HASBLACK_YES to MODEL_HASBLACK_NO and
see if that helps you?

-- 
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] new 740 results

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

   Date: Sat, 19 Feb 2000 12:12:36 -0700
   From: "S. Miller" <sm...@rn...>

   I don't have time to run a very complete set of tests, but 720 and 1440
   softweave with variable dot size are working (as is 360 dpi).  The 720
   dpi modes do seem to be doubling the distance from the edge, so
   yesterday I was probably trying to print off the edge. Today I shrunk
   the image so I could tell.  1440 put the image where I told it to, at
   least at a quick glance.

OK, I'll see what I can figure out 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] Width and Height OK with stc740

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

   Date: Sat, 19 Feb 2000 11:16:05 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   On Sat, Feb 19, 2000 at 10:18:48AM -0500, Robert L Krawitz wrote:
   > One last thing -- could you try printing it at position 2"/2"?
   > Evidently my theory's correct about the horizontal position, but I'm
   > surprised the vertical position is off.  I want to make sure that it's
   > really off by a factor of 2 and there's not a 1" border somehow
   > getting in there.

   OK, here's what I get with 2/2":
   720 dpi: Image is printed at position 4 1/8" from left edge and 3 1/4" down
   1440 dpi:                             2 1/8" from left edge and 3 1/4" down

So the 1 1/4" from the top is a constant; the horizontal position is
off by a factor of 2.

Re: [Gimp-print-devel] new 740 results

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

I just run a test with all modes: Everything is working as far as the
actual printing is concerned. The only problem is that the 720 softweave
modes have a problem with the image placement. This is true for both
variable and single dot size.

Karl Heinz

On Sat, Feb 19, 2000 at 12:12:36PM -0700, S. Miller wrote:
> I don't have time to run a very complete set of tests, but 720 and 1440
> softweave with variable dot size are working (as is 360 dpi).  The 720
> dpi modes do seem to be doubling the distance from the edge, so
> yesterday I was probably trying to print off the edge. Today I shrunk
> the image so I could tell.  1440 put the image where I told it to, at
> least at a quick glance.
>=20
> Steve
> --=20
> -----------------------------------------
> Just because I have a short attention span
> doesn't mean I
> ------------------------------------------
>=20
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

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

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

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 19 Feb 2000 17:34:45 +0100
>    From: "Stefan K. Berg" <sf...@co...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
>    >
>    >    Date: Thu, 17 Feb 2000 07:43:20 +0100
>    >    From: "Stefan K. Berg" <sf...@co...>
>    >
>    >    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).
> 
>    Uhm, unless I'm doing something wrong here then I beg to differ -
>    just got a fresh copy of the mainline and I still get the same
>    results. Same thing for the print-3.0-branch, but maybe your
>    correction hasn't been checked in yet.
> 
> So you're not getting any printout in softweave mode (720 highest
> quality)?
> 
> In print-escp2.c, look for this:
> 
>   /* 4: Stylus Color 800 */
>   (MODEL_PAPER_SMALL | MODEL_IMAGEABLE_600 | MODEL_INIT_600
>    | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
>    | MODEL_VARIABLE_NORMAL | MODEL_MAKE_XRES(720)
>    | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(64) | MODEL_MAKE_SEPARATION(8)),
> 
> It's around line 584 on the current mainline.  Try change
> 
> MODEL_MAKE_NOZZLES(64)
> 
> to
> 
> MODEL_MAKE_NOZZLES(48)
> 
> or if that doesn't work
> 
> MODEL_MAKE_NOZZLES(32)
> 
> If that helps, then my information about how many nozzles the 800 has
> is incorrect (which is possible).

I checked the specifications on Epson's site, and according to them the
configuration is 128 black nozzles (32 x 4, staggered) and 64 color nozzles x
3
(C/M/Y). Your initial assumption seems right, if they're telling the truth.
:)

[Gimp-print-devel] new 740 results

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

I don't have time to run a very complete set of tests, but 720 and 1440
softweave with variable dot size are working (as is 360 dpi).  The 720
dpi modes do seem to be doubling the distance from the edge, so
yesterday I was probably trying to print off the edge. Today I shrunk
the image so I could tell.  1440 put the image where I told it to, at
least at a quick glance.

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

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

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 19 Feb 2000 17:34:45 +0100
>    From: "Stefan K. Berg" <sf...@co...>
>    CC: gim...@li...
> 
>    Robert L Krawitz wrote:
>    >
>    >    Date: Thu, 17 Feb 2000 07:43:20 +0100
>    >    From: "Stefan K. Berg" <sf...@co...>
>    >
>    >    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).
> 
>    Uhm, unless I'm doing something wrong here then I beg to differ -
>    just got a fresh copy of the mainline and I still get the same
>    results. Same thing for the print-3.0-branch, but maybe your
>    correction hasn't been checked in yet.
> 
> So you're not getting any printout in softweave mode (720 highest
> quality)?
> 
> In print-escp2.c, look for this:
> 
>   /* 4: Stylus Color 800 */
>   (MODEL_PAPER_SMALL | MODEL_IMAGEABLE_600 | MODEL_INIT_600
>    | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
>    | MODEL_VARIABLE_NORMAL | MODEL_MAKE_XRES(720)
>    | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(64) | MODEL_MAKE_SEPARATION(8)),
> 
> It's around line 584 on the current mainline.  Try change
> 
> MODEL_MAKE_NOZZLES(64)
> 
> to
> 
> MODEL_MAKE_NOZZLES(48)
> 
> or if that doesn't work
> 
> MODEL_MAKE_NOZZLES(32)
> 
> If that helps, then my information about how many nozzles the 800 has
> is incorrect (which is possible).

Just tried this with the mainline code, but the behavior really doesn't
change. Still just numerous paper feeds.

[Gimp-print-devel] Printer list and File printer again.

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

Right, let's have another go!

The printer list *is* sorted (in "output_to" order, i.e. sorted
on the lp/lpr command!) because there is a call to qsort() in
get_system_printers(), *but* the File printer is not sorted in
the list, it always appears first.

So, my previous fix broke things by trying to bsearch() a list
that was nearly sorted! It worked for me because all my printers
are lower case names, so "File" was still found first.

I have now put the bsearch() call back the way it was, but
checked for the "File" printer explicitly first!

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

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

   Date: Sat, 19 Feb 2000 17:34:45 +0100
   From: "Stefan K. Berg" <sf...@co...>
   CC: gim...@li...

   Robert L Krawitz wrote:
   > 
   >    Date: Thu, 17 Feb 2000 07:43:20 +0100
   >    From: "Stefan K. Berg" <sf...@co...>
   > 
   >    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).

   Uhm, unless I'm doing something wrong here then I beg to differ -
   just got a fresh copy of the mainline and I still get the same
   results. Same thing for the print-3.0-branch, but maybe your
   correction hasn't been checked in yet.

So you're not getting any printout in softweave mode (720 highest
quality)?

In print-escp2.c, look for this:

  /* 4: Stylus Color 800 */
  (MODEL_PAPER_SMALL | MODEL_IMAGEABLE_600 | MODEL_INIT_600
   | MODEL_HASBLACK_YES | MODEL_6COLOR_NO | MODEL_720DPI_DEFAULT
   | MODEL_VARIABLE_NORMAL | MODEL_MAKE_XRES(720)
   | MODEL_1440DPI_YES | MODEL_MAKE_NOZZLES(64) | MODEL_MAKE_SEPARATION(8)),

It's around line 584 on the current mainline.  Try change

MODEL_MAKE_NOZZLES(64)

to

MODEL_MAKE_NOZZLES(48)

or if that doesn't work

MODEL_MAKE_NOZZLES(32)

If that helps, then my information about how many nozzles the 800 has
is incorrect (which is possible).

My Stylus Photo EX only has 32 pins, so I had to change the 64 to 32
to print, but when I did that it printed correctly.  Of course, I
don't have an 800, so I can't test it for real...

Nothing has been checked into the 3.0 branch yet.

   (With the current mainline, all my printers are gone from the print
   dialog - I don't have lpstat installed. The configuration doesn't
   pick up on lpc, for some reason. Not a complaint, just for your
   information.)

We do have problems in this area.  It's something we're thinking about
how to address.

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

   Done that, take a new look at the URL above.

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 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).

Uhm, unless I'm doing something wrong here then I beg to differ - just got a
fresh copy of the mainline and I still get the same results. Same thing for
the print-3.0-branch, but maybe your correction hasn't been checked in yet.

(With the current mainline, all my printers are gone from the print dialog - I
don't have lpstat installed. The configuration doesn't pick up on lpc, for some
reason. Not a complaint, just for your information.)

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

Done that, take a new look at the URL above.

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

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

On Sat, Feb 19, 2000 at 10:18:48AM -0500, Robert L Krawitz wrote:
> One last thing -- could you try printing it at position 2"/2"?
> Evidently my theory's correct about the horizontal position, but I'm
> surprised the vertical position is off.  I want to make sure that it's
> really off by a factor of 2 and there's not a 1" border somehow
> getting in there.

OK, here's what I get with 2/2":
720 dpi: Image is printed at position 4 1/8" from left edge and 3 1/4" down
1440 dpi:                             2 1/8" from left edge and 3 1/4" down

>=20
>    BTW: How's the scaling supposed to work? The PPI setting does work, but
>    the % setting IMHO does not. If I specify 100%, I assume that the image
>    is printed in the size I've specified in the Image Scale dialog. Is my
>    assumption wrong?
>=20
> Yup, but you're not alone here.  The scale factor is relative to the
> page size, not the Image Scale.  Someone on the gimp-developer list
> commented on the fact that we ignore the Image Scale size.  I think we
> need a third sizing mode that scales relative to the image scale.

This third scaling method seems like a good idea. What I do now is get the
native resolution from gimp and then just set the PPI accordingly. This is
one step that should not be necessary.

Karl Heinz


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

Re: [Gimp-print-devel] 740 printing

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

   Date: Fri, 18 Feb 2000 19:32:47 -0700
   From: "S. Miller" <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.

OK, try it again.  I'm trying to back out all of the new-style
commands from 360 and 720 microweave.  This should have no effect on
Karl's positioning problem.

-- 
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] 740 printing

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

   Date: Fri, 18 Feb 2000 19:32:47 -0700
   From: "S. Miller" <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.

Try printing in both 720 micro and 360 with the image in the upper
left corner (at top=0, left=0).  It's possible that the problem is
simply that you're running off the page.

-- 
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: Sat, 19 Feb 2000 09:51:33 -0500
   From: Karl Heinz Kremer <kh...@kh...>

   On Sat, Feb 19, 2000 at 09:17:53AM -0500, Robert L Krawitz wrote:
   > 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.

   720dpi softweave (variable dot size):
	   I'm printing a 1"x1" image at position 1"/1"
	   -> it prints in the correct size, but about 2 1/4 " down
	      and 2 1/8" from the left edge

   1440 dpi (variable dot size):
	   Same image, same position
	   -> it prints in the correct size, but about 2 1/4" down
	      and 1 1/8" from the left edge.

   So if I ignore the 1/8", the horizontal position of the 1440dpi image
   is correct.=20

One last thing -- could you try printing it at position 2"/2"?
Evidently my theory's correct about the horizontal position, but I'm
surprised the vertical position is off.  I want to make sure that it's
really off by a factor of 2 and there's not a 1" border somehow
getting in there.

   BTW: How's the scaling supposed to work? The PPI setting does work, but
   the % setting IMHO does not. If I specify 100%, I assume that the image
   is printed in the size I've specified in the Image Scale dialog. Is my
   assumption wrong?

Yup, but you're not alone here.  The scale factor is relative to the
page size, not the Image Scale.  Someone on the gimp-developer list
commented on the fact that we ignore the Image Scale size.  I think we
need a third sizing mode that scales relative to the image scale.

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

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

On Sat, Feb 19, 2000 at 09:17:53AM -0500, Robert L Krawitz wrote:
> 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.

720dpi softweave (variable dot size):
	I'm printing a 1"x1" image at position 1"/1"
	-> it prints in the correct size, but about 2 1/4 " down
	   and 2 1/8" from the left edge

1440 dpi (variable dot size):
	Same image, same position
	-> it prints in the correct size, but about 2 1/4" down
	   and 1 1/8" from the left edge.

So if I ignore the 1/8", the horizontal position of the 1440dpi image
is correct.=20

BTW: How's the scaling supposed to work? The PPI setting does work, but
the % setting IMHO does not. If I specify 100%, I assume that the image
is printed in the size I've specified in the Image Scale dialog. Is my
assumption wrong?

Karl Heinz

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