gimp-print-devel

Re: [Gimp-print-devel] What direction should we be headed?

[Hrafnkell E. <he...@kv...>]

I think the project should provide the lowest layer of a printing
system to any project that wants to use it. This meens accepting
a bitmap, dithering it and generating the neccesary printer commands.
Ghostscript, gnome-print, kde-print (if it exists) and other projects
can all use it.
Communication to different front ends would go through small glue 
libraries.

-- 
//-----------------------//-------------------------------------------------
//  Hrafnkell Eiriksson  // 
//  he...@kv...        // 
//  TF3HR                //  "Blessed are they who go around in circles,
//                       //   for they shall be known as Wheels"        

[Gimp-print-devel] Stylus Color 800

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

Does anyone here have access to a Stylus Color 800?  Someone reported
problems on the Help forum.

Also, is anyone else here monitoring the forums?

-- 
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] What direction should we be headed?

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

I want to take a look at the direction in which we're headed.  I'm not
saying anything's wrong, per se, I just want to see where we fit in
with all the other free printing projects.

To the best of my knowledge, we're the only free printing system that
currently fully supports "photo-quality" (defined as variable dot size
and/or 6+ color inks) printers.  Ghostscript, via Uniprint, supports
most of the Epson printers, but I don't believe that the Uniprint
driver handles variable dot sizes.  There's an separate Photo 700/EX
driver I've seen for Ghostscript, but the output quality leaves quite
a lot to be desired (Regis sent me a sample from it).

However, I don't believe that we necessarily have the best rendering
technology.  I haven't seen rinkj output yet, but I've heard more than
enough good things about it.  There are some fancy rendering schemes
in various Ghostscript drivers (including that 700 driver I mentioned
above), although since I haven't seen their output I don't know how
good they are.

In other directions, GNOME (and presumably KDE) are moving ahead with
print projects.  These are intended to be more comprehensive solutions
to the general problem of printing under Linux (and other Unix
systems).  Chema can tell us more about Gnome-Print.  We should also
contact the KDE people to find out what they're up to.  There's also
PDQ, which doesn't try to address printer issues per se, but simply
tries to provide a general interface.

So that basically leaves us focusing on Gimp-specific issues, and on
high quality, low cost printers (particularly Epson right now,
although hopefully we'll have some luck with other vendors).  Cheap,
good printers is an interesting place to be, since these printers are
important for the desktop.

We're obviously not providing a complete soup-to-nuts printing
solution right now.  I don't think that that's necessarily what we
should be doing; we don't have the resources to do that, and GNOME and
KDE may be better placed to do that.  But it does leave me thinking
about where we should go from here.  What do other people think?
Should we move more toward supplying rendering for high end devices as
GNOME and KDE's print projects come on line, or should we be doing
something else?

-- 
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] Epson stuff

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

I fixed a major bug in the vertical positioning stuff.  Everyone who
prints in color should grab this one.

I also retuned the ink constants for the 870.  I really think that a
ratio of .25 for light/dark works much better (the transition is less
abrupt), and I think the dot sizes are also a bit smaller than we had
them set for before (I changed them to 1.0/.667/.5).  It also got rid
of most of the yellow cast, which suggested that the cyan and magenta
had been too light before (i. e. the light inks were getting credit
for more cyan/magenta than they were really supplying).

Also, I bumped down the k_lower setting for variable dot size
printers.  I figure it's OK to use black at lower levels, since the
dots are smaller, and the results seem to bear this out.

The settings I'm now using:

Print mode: 1440x720 softweave
Dither mode: random Floyd-Steinberg
Image type: photo
Gamma: 1.2
Density: 1.5
Saturation: 1.1
Red: 101
Blue: 101

If anything, the remaining yellow cast in the light-medium grays
suggests that this may not be quite far enough.

1440x720 softweave works much better than 1440x720 enhanced.  That
surprises me.  What's also surprising is that 720 high quality has
some gross flaws.

I'm seeing slight, but noticeable, banding, at 5 lines/mm (120
lines/in., or 6 vertical spaces), with 1440x720 softweave.  What's
more interesting is that there is very slight vertical banding visible
under an 8x loupe, at about 15 lines/mm (my loupe has a scale), or 400
lines/in (close to 360 dpi).  This is much more noticeable (and
coarser) at 720 high quality.  I don't know what's happening here.
This too goes away at 1440 enhanced.

Finally, there's a noticeable red cast in some dark grays (9-11 on the
gray scale target in the PDI test image).  Perhaps the correct
light/dark ratio is different for for cyan and magenta.  Perhaps it's
in part due to the slight red and blue adjustment I made, and the
elevated saturation.

It's a bit too bright right now; the dimples in the golf balls are
somewhat blown out.

It probably goes without saying, but this effort makes the EX look
crude by comparison.  It won't stand up to inspection by a loupe, but
with few exceptions it will stand up to visual inspection.

I printed the image at 480 dpi, which was the most I could do on a
piece of letter size paper.  720 dpi would probably be a better choice
for this kind of test.

On another note, I've taken a quick look at the rinkj code, but I
haven't done anything with it yet.    The abstractions are quite
different from those used by gimp-print, and there's going to be a lot
of fiddling required to make it all play together.  Currently, rinkj
doesn't support variable dot size printers and 6-color inks, which
we'll ultimately need to do.

-- 
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] Epson printing to the edge

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

   Date: Sat, 13 May 2000 22:57:33 +0100
   From: Thorsten Schnier <tho...@sc...>

   Robert L Krawitz wrote:
   > 
   > I've fixed up the Epson code to print to the top edge and close
   > (~5/16") to the bottom.  Printing to the bottom probably will not work
   > in microweave or 360 dpi.
   > 
   > Could someone using Ghostscript (for whom this really matters) please
   > test it?

   Don't know if this is the reason, but positioning from gimp is now very
   good, vertical is close to perfect, horizontally I still get about a mm
   off, but that might be caused by feed, and even if not it is certainly
   tolerable.

That's exactly what I was expecting.  Thanks for checking it out.

-- 
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] Positioning code (interface) cleanup

[Thorsten S. <tho...@sc...>]

Robert L Krawitz wrote:

> Could you fix this in gimp_main_window.c also?  Mitch or Steve, could
> you check this out?

New diff attached containes changes to both gtk_main_window.c (same as
yesterday) and gimp_main_window.c. I only get the gtk version to show in
the menue, so I didn't test it, but it compiles OK.
 
> 
> I'm in the middle of hacking this code extensively, so that for a lot
> of printers (in softweave mode, at any rate) it should be possible to
> print very close to the edges of the paper.  There will be some
> quality degradation near the top and the bottom (it won't be able to
> do the full interleaving that it does in the middle of the page, so
> there will be some bandin).  It won't fix the horizontal positioning
> problem, although in my experience it's hard to get the paper in
> EXACTLY the right spot from time to time.

Yeah, the horizontal might easily be caused by that. I wonder if we need
a flag to let the user chose narrow or wide margins, (plus changes in
the support code and the interface) ? 


> 
>    I've changed a few variable names to make the distinction between
>    printable area and paper area more clear; I've left vars.left and
>    vars.top relative to the edges of the printable area (this is correct,
>    isn't it? Meaning 0 / 0 means the image is located against the top left
>    of the printable area? )
> 
> Just make sure it doesn't break anything that relies on it.

>From the reading of the source of the interface, my impression is that
the printer drivers use vars.left and vars.top to locate the image, and
interpret these values as relative to the printable area. If this is
correct, I shouldn't have broken anything. 


thorsten


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

-- 
----------------------------------------------------------------------- 
                                                       Thorsten Schnier
                                    
                                             School of Computer Science
                                               University of Birminghan
                                                                       
                                               
T.S...@cs...   
                                                   tho...@sc...

[Gimp-print-devel] gimp_get_data

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

How exactly does gimp_get_data work?  I want to change all the fixed
length strings in the vars structure to char * (to save space in the
binary and to enable arbitrarily long strings), but then I notice this
pesky little call to gimp_get_data if RUN_WITH_LAST_VALS is used.

-- 
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] Epson printing to the edge

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

   Date: Sat, 13 May 2000 11:40:21 +0200
   From: Ron van Ostayen <R.A...@Wb...>

   Top margin: 0.5 mm !!
   Bottom margin: 7.0 mm

I presume this is what you want.  We may be able to get closer to the
bottom on some of the new printers, although apparently Epson says it
will lose quality (I think what happens is that if it knows the exact
page length it can hold the paper by the metal pizza wheel rollers
near the end and get very close to the bottom of the paper, but the
printer can't hold the alignment too well there).

   Left margin: 3.2 mm
   Right margin: 3.7 mm

   Robert, the rendering times have improved considerably also.
   Quality 0: 16.0 s (was 28.0 s)
   Quality 2: 66.7 s (was 102.6 s)
   Apart from inlining some routines, did you find any other speed
   improvements?

Some relatively minor stuff, but I guess it adds up.

Re: [Gimp-print-devel] Epson printing to the edge

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

   From: sh...@al...
   Date: Fri, 12 May 2000 23:48:44 -0400

   I finally got the gs driver running on my system here.  I couldn't figure
   out why it worked from within the Gimp but not GS, but, after closer
   inspection, I found that I had set the Quality to 4, which was 720 DPI
   Highest Quality, not 720 DPI Softweave, which I thought I had been
   using.  When I changed the Quality to 2, it worked fine.

I've had an idea for a while about a verify_parameters() printer
call.  This would ensure that the options the user selected are valid
for the printer.  In the GUI, this gets handled pretty well since the
GUI gets the available options from the printer.  Ghostscript doesn't
do this.

   I don't know why Quality=4 didn't work, but at least it explains
   why I was getting inconsistent results.

The 750 actually only prints at 360 dpi.  The driver currently can't
handle more than four passes per row.  720 dpi highest quality would
be 8 passes.  So you need to use quality of 2 (720 softweave), 3 (720
high quality), or 6 (1440x720 softweave).

-- 
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] ESP 870 results

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

Karl Heinz Kremer wrote:
>
> And just in case you were wondering where to get it:
>   ftp://ftp.photodisc.com/pub/test_targets/
> 
> I was able to unpack it using the unpacker from Aladdin Systems:
>   http://www.aladdinsys.com/

Yep, got it OK.

Ta

Dave

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

[Gimp-print-devel] Dithering patents

[Thomas T. <tt...@bi...>]

For those who  didn't notice yet: It looks like the author of the
'eventone' screening algorithm has granted a general licence for GPLd
software.

Kudos to Ralph Levien for doing this. The 'eventone' algorithm is the
second link on http://www.levien.com/patents.html .


Thomas

Re: [Gimp-print-devel] Epson printing to the edge

[Ron v. O. <R.A...@Wb...>]

Robert L Krawitz wrote:
> 
> I've fixed up the Epson code to print to the top edge and close
> (~5/16") to the bottom.  Printing to the bottom probably will not work
> in microweave or 360 dpi.
> 
> Could someone using Ghostscript (for whom this really matters) please
> test it?

I've tested it on my ESC900 + gs6.21.
Quality settings 0 and 2 both produce exactly the same layout.
(Papersize: a4)

Top margin: 0.5 mm !!
Bottom margin: 7.0 mm

Left margin: 3.2 mm
Right margin: 3.7 mm

Robert, the rendering times have improved considerably also.
Quality 0: 16.0 s (was 28.0 s)
Quality 2: 66.7 s (was 102.6 s)
Apart from inlining some routines, did you find any other speed
improvements?

Ron van Ostayen

R.A...@Wb...
Laboratory of Tribology
Department of Mechanical Engineering
University of Technology Delft

Re: [Gimp-print-devel] Epson printing to the edge

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

> I've fixed up the Epson code to print to the top edge and close
> (~5/16") to the bottom.  Printing to the bottom probably will not work
> in microweave or 360 dpi.
> 
> Could someone using Ghostscript (for whom this really matters) please
> test it?

It prints as close to the top of the page as my eye can see.

Eric

Re: [Gimp-print-devel] Epson printing to the edge

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

> I've fixed up the Epson code to print to the top edge and close
> (~5/16") to the bottom.  Printing to the bottom probably will not work
> in microweave or 360 dpi.
> 
> Could someone using Ghostscript (for whom this really matters) please
> test it?

I'll try to give it a whirl.

I finally got the gs driver running on my system here.  I couldn't figure
out why it worked from within the Gimp but not GS, but, after closer
inspection, I found that I had set the Quality to 4, which was 720 DPI
Highest Quality, not 720 DPI Softweave, which I thought I had been
using.  When I changed the Quality to 2, it worked fine.

I don't know why Quality=4 didn't work, but at least it explains
why I was getting inconsistent results.

Eric

[Gimp-print-devel] Epson printing to the edge

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

I've fixed up the Epson code to print to the top edge and close
(~5/16") to the bottom.  Printing to the bottom probably will not work
in microweave or 360 dpi.

Could someone using Ghostscript (for whom this really matters) please
test 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] First experiences with an 870

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

   Date: Sat, 13 May 2000 03:20:47 +0100
   From: Charles Briscoe-Smith <cp...@de...>

   If Eric isn't able to do this, I'm willing to give it a go sometime.
   I think it would be best to co-ordinate with Ben Gertzfield
   <ch...@de...> since he maintains the Debian gimp packages.
   Since /usr/lib/gimp/1.1/plug-ins/print already exists in gimp1.1,
   either gimp-print should be included in that package in place of the
   print plugin currently in gimp1.1, or a separate package would have to
   divert (or possibly replace, but that's rather ugly so I'd rather not)
   the gimp1.1 print plugin.  (There's little point packaging it for gimp
   1.0 even if it compiles with it; gimp 1.0 users want stability...)

Well, 3.1.4 is probably at least as stable as the plugin in gimp 1.0
(version 2.0.2), and it supports far more printers at much higher
quality.  It could be thought of as a midlife kicker.

   BTW, I noticed that gimp-print puts its printrc in ~/.gimp rather than
   ~/.gimp-1.1.  Why's that?  (In preparation for gimp v1.2, perhaps?)

Not on my system, it doesn't.  It asks the gimp where to find its .rc file.

   > See above about the tiny dots.  It might also be (barely) noticeably
   > different in things with very sharp transitions or very fine lines.

   I tried a picture of a cactus.  The 1440x720DPI softweave gives
   better-defined results than 720DPI softweave in the case of a light
   cactus needle against a dark background.  For a dark needle on a light
   background, there was nothing to choose between the two.

That's not altogether surprising.

   Something that I thought might be useful would be interpolation.
   The dither routine could be supplied with the row before the current
   position and the row after, and could interpolate the colour of its
   current location from the surrounding pixels.  This might be desirable
   when scaling up an image a lot, so that the low resolution of the original
   image does not cause ugly pixellation in the printed output.  This would
   have to be an option, of course, since it would only be appropriate for
   some kinds of images, like photos.

I've thought about this.  It would require a major change in the
architecture -- give the dithering routine a line, and have the
dithering routine call back into the driver.  That's a good
architecture, but it would take a fair bit of work.  Besides, it would
probably be very slow.  I don't know if Raph's code requires something
like that; if it did, it would be a good impetus for it.

   The 360DPI mode is little light with density 1.0 and 720DPI microweave
   is a little dark, but it's quite close.  The microweave modes are still
   really bitty.  The driver doesn't seem to be using variable sized dots
   when in microweave mode.  Still, as you say, there's no reason to use
   these modes on the 870.

Right.  What I should do is flush that on the 870 (or for that matter
on almost all of the new printers).

   > I have the same problem (kernel 2.2.10).  What kernel are you running?

   2.2.14.  Is USB likely to be faster?  I don't remember what USB's transfer
   rate is supposed to be.  The machine has a USB port, and, IIRC, Linux
   2.2.15 does USB.

No idea.

   > That's an attempt to correct for the starting vertical position thing
   > you noted below.  I don't have that quite right.

   This patch seems to fix it; the comment says how I think it does so:

It's also obsolete (or will be, as soon as I check in my latest
stuff).  I've figured out how to print all the way to the top edge and
to about the bottom 5/16".  I could probably even closer if I tried.
I've been spending all evening testing it and writing yet more test
cases.  It's painful.  It may not work absolutely correctly for 360
dpi and microweave (particularly the bottom of the page).  I'll
probably check it in tonight even if it isn't 100% tested; it's useful
enough so it's worth getting out there.  The Ghostscript users will be
very happy about this.

   I've spent a day or two so far teasing apart the weave code, and I'm
   *pretty* sure I know more about how it works than when I started...
   It's hairy stuff, though.  It's going to take a while longer before I
   understand it.

It's going to be even worse after tonight.

   The page is rendered to a collection of dots by the dithering code at some
   resolution, e.g. 720x720DPI.  A "row" consists of all the dots output
   by the dither for printing at a single vertical position.  A row may be
   printed in two or more "subpasses" which print dots at the same vertical
   position but different horizontal positions.  I suppose this is needed
   if the printer's "raster image" command doesn't allow a high enough
   horizontal resolution, or if the print head can't print dots as close
   together as we'd like (I know the old dot matrix printers used to ignore
   any dot immediately following another dot on the same pin).  I'll call a
   subpass (or a row if it's printed in only one subpass) a "line": a line
   consists of all the dots printed by a single nozzle during one pass.

That's basically correct.  The other reason to do this is simply to
force more different jets to print the same line.  This reduces
banding.  Typically the jets aren't all of exactly the same size; some
are slightly bigger (darker) and some slightly smaller (lighter).
Using more subpasses uses different jets on the same row, which tends
to average things out.

   A "pass" is a group of lines printed in one sweep of the print head.
   In a pass, each jet on the printhead can be assigned one line, so these
   lines must be spaced the same way as the printhead's jets.  If jets
   at the top of the pass lie outside the image, they are assigned blank
   "phantom rows".  Unused jets at the bottom of the pass don't need phantom
   rows, because of the way the printer's "raster image" commands work.

Correct.

   initialize_weave() creates a data structure which keeps track of the
   weaving pattern for a single page, and destroy_weave() cleans it up
   afterwards.  As each row on the page is dithered (in order, top-to-bottom)
   the row is passed to escp2_write_weave().  This calculates the weave
   parameters for that row, chops the row up into lines as necessary, and
   stashes the lines in the softweave data structure.  When all the lines
   for a given pass are available, escp2_write_weave() advances the paper
   appropriately and prints the pass.

Again, correct.

   initialize_weave() takes parameters:
     jets:           number of nozzles in printhead.
     sep:            separation between nozzles in rows (1/720").
     osample:        number of passes necessary to print a single row
		     (due to the row's resolution being higher than the
		     printer's horizontal resolution).
     v_subpasses:    number of passes in which to print each "osample"
		     pass in order to bring different jets into play.
     v_subsample:    number of dithered rows for each printed row.
		     I'm not sure what this does.  Does it merge rows?
		     Overprint them?  Feed the paper in smaller increments
		     than 1/720"?
     colormode:      one of: monochrome, four-colour or six-colour printing.
     width:          number of bits per pixel.
     linewidth:      number of pixels per row.
     lineheight:     number of rows on the page.
     separationrows: used for calculating paper advance for the 1520/3000.
		     I'm not sure what this does, and I doubt I need to
		     know at the moment.

There are a few more parameters in the stuff I'm about to check in.
Those should be fairly obvious.  The separationrows thing probably
isn't needed in softweave, but I don't have a 1520 or 3000 handy to
test, so I haven't enabled softweave for it.

   Parameters calculated by initialize_weave():

     OVERSAMPLE is the number of lines to be printed on each row.

     VMOD is the number of lines to be printed in the space between each
     pair of jets.  In other words, it's the number of passes the printhead
     makes while spanning any given point on the paper.

     NJETS is the number of jets within whose span we print one line on
     every row as the printhead moves that distance.  That is, a line is
     printed on a given row once for each time NJETS nozzles move past it.
     So, in the space of NJETS nozzles, we have to do a complete weave
     pattern, hitting each row once.  The first NJETS nozzles print each
     row for the first time.  The next NJETS nozzles overprint each of
     those rows to perform the second subpass, the third NJETS nozzles
     print the third subpass, etc.  Thus, we only need consider the first
     NJETS nozzles when working out our weaving pattern; the rest of the
     jets simply trail behind at regular intervals.

Well, except for the phantom row issue.  Also, the stuff that lets me
print to the edge of the page needed some changes to the weave pattern
in those areas of the page in order to work.

     WEAVEFACTOR is the interleave factor, NJETS/SEPARATION rounded up.
     Each pass, WEAVEFACTOR lines get printed below the previously
     lowest-printed line.  (This is a guess; I don't understand it yet.)

That's right.  It's also the source of some problems.  It makes it
impossible to go to an x8 weave pattern on (32, 8) printers (32 jets,
8 separation), and it prevents the 440 from printing at any kind of
improved weave pattern.

   > The problem is that the Gimp hits plugins with a SIGKILL (kill -9)
   > whenever you hit cancel, so there's no opportunity to clean up (Sven,
   > are you listening?)

   I've tried fixing this; here's the patch.  It works by spawning a
   "monitor" process whose purpose is to spawn lpr and then watch its parent
   process (the plugin).  If the parent sends SIGUSR1 to the monitor process,
   the print job was successful, so the monitor quits.  If the plugin dies
   before sending SIGUSR1, the monitor kills off lpr, thus cancelling the
   print job.

I won't put that one in tonight, but it's a good idea.  What's
SIGNULL, though?  I don't think it's POSIX.  Actually, you should get
a Sourceforge account and I'll add you as a developer.

   [The yellow colouring of the pictures I printed]
   > Did that seem specific to the camera?

   I haven't really tried enough image sources to be able to tell.  I'll try
   some scanned photos sometime.

I got that from my 870, also, so I think it's genuine.

   > The driver is very well tuned for the 700 (I previously had an EX).

   Ben uses Windows and the Windows driver with his 700.  The prints we
   did for him were from the 870 with gimp-print.  What I meant to say
   (apparently unsuccessfully) was that (Photo 870 + gimp-print) makes better
   prints than (Photo 700 + Windows driver), which seems to be a good result,
   since the 700 is relatively recent.  I also know first-hand that (Photo
   870 with gimp-print) is considerably better than (Colour 3000 with Windows
   driver), which is also a good result, but probably not a surprising one.

I would hope so.  For that matter, I would hope that people prefer
output from the 700 with gimp-print over a 3000 from Windows.  The
light inks really help.

   I'll append the patch for clipping the image to the page size that I
   mentioned in my previous email.  In landscape mode, 3.1.4 with this
   patch seems to print images upside down...  But as far as I can tell,
   vanilla 3.1.2 did the same thing.

If you're willing to get a Sourceforge account, let me add you as a
developer, and make the change on the other drivers (ps, pcl, and
Canon), go ahead.  It's not my favorite idea, but I must admit that it
would save some headaches in some cases.

-- 
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] First experiences with an 870

[Charles Briscoe-S. <cp...@de...>]

On Mon, May 08, 2000 at 08:39:33PM -0400, Robert L Krawitz wrote:
> BTW, since you're a Debian developer and there are a number of people
> here interested in how to package this up for Debian, how would you
> like to become a developer on this project?  If you'd like to, just
> get yourself an account on sourceforge.net and drop me a note.  We
> need someone to create .deb's (as well as rpm's).

If Eric isn't able to do this, I'm willing to give it a go sometime.
I think it would be best to co-ordinate with Ben Gertzfield
<ch...@de...> since he maintains the Debian gimp packages.
Since /usr/lib/gimp/1.1/plug-ins/print already exists in gimp1.1,
either gimp-print should be included in that package in place of the
print plugin currently in gimp1.1, or a separate package would have to
divert (or possibly replace, but that's rather ugly so I'd rather not)
the gimp1.1 print plugin.  (There's little point packaging it for gimp
1.0 even if it compiles with it; gimp 1.0 users want stability...)

BTW, I noticed that gimp-print puts its printrc in ~/.gimp rather than
~/.gimp-1.1.  Why's that?  (In preparation for gimp v1.2, perhaps?)

> That [CVS 4th May] should be pretty good, although the 3.1.4 release might be
> slightly better (or it might not).

I've updated from CVS, but I haven't really tested it yet.

> See above about the tiny dots.  It might also be (barely) noticeably
> different in things with very sharp transitions or very fine lines.

I tried a picture of a cactus.  The 1440x720DPI softweave gives
better-defined results than 720DPI softweave in the case of a light
cactus needle against a dark background.  For a dark needle on a light
background, there was nothing to choose between the two.

Something that I thought might be useful would be interpolation.
The dither routine could be supplied with the row before the current
position and the row after, and could interpolate the colour of its
current location from the surrounding pixels.  This might be desirable
when scaling up an image a lot, so that the low resolution of the original
image does not cause ugly pixellation in the printed output.  This would
have to be an option, of course, since it would only be appropriate for
some kinds of images, like photos.

>    1"x1.6":
>    360DPI:                 3sec       7sec
>        Dark, grainy, too magenta, but fast.
> 
> Try a density of 1.0 here.
> 
>    720DPI microweave:      6sec       34sec
>        Much, much too dark.  The printer dumped so much ink on this one
>        that the photo paper actually went slightly soggy, something I
>        never expected to see (although it didn't actually soak through to
>        the back).
> 
> Again, try a density of 1.0 here, and don't bother using this mode.

The 360DPI mode is little light with density 1.0 and 720DPI microweave
is a little dark, but it's quite close.  The microweave modes are still
really bitty.  The driver doesn't seem to be using variable sized dots
when in microweave mode.  Still, as you say, there's no reason to use
these modes on the 870.

>    720DPI softweave:       6sec       24sec
>        Good.  Bidirectional printing, so it was pretty fast, and I'm
>        surprised this didn't affect the print quality.  When I print a
>        more complex full A4-width image in this mode, the printer pauses
>        at the end of each pass, presumably waiting for more data.  It looks
>        like the parallel protocol is the bottleneck in this mode.  I tried
>        setting the parport to ECP and EPP mode, and giving Linux the DMA
>        channel for this one, but wasn't able to speed it up any.
> 
> I have the same problem (kernel 2.2.10).  What kernel are you running?

2.2.14.  Is USB likely to be faster?  I don't remember what USB's transfer
rate is supposed to be.  The machine has a USB port, and, IIRC, Linux
2.2.15 does USB.

> That's an attempt to correct for the starting vertical position thing
> you noted below.  I don't have that quite right.

This patch seems to fix it; the comment says how I think it does so:

==============================================================================
--- print-escp2.c.orig	Thu May 11 01:02:20 2000
+++ print-escp2.c	Thu May 11 01:03:01 2000
@@ -1002,8 +1002,14 @@
        * would happen in softweave mode.  The divide by 10 is to convert
        * lines into points (Epson printers all have 720 ydpi);
        */
+      /*
+       * (-5) instead of (+5) to effectively reduce the nozzle count by
+       * one; in softweave mode, we start printing with the bottom-most
+       * nozzle which is (nozzles - 1) * nozzle_separation distant from
+       * the top nozzle.
+       */
       int extra_points = (escp2_nozzles(model) *
-			  escp2_nozzle_separation(model) + 5) / 10;
+			  escp2_nozzle_separation(model) - 5) / 10;
       top += extra_points;
     }
 
==============================================================================

>    I guess the weave normally starts printing with the bottom nozzle.
>    Assume we're advancing the paper by x each pass, the nozzle separation
>    is s, and assume that x > s.  We can instead start printing with the top
>    nozzle and advance the paper by (x - s) until the weave has expanded to
>    use all nozzles, then start advancing by x as before.
> 
> The difficulty is that in some of the high resolution modes that
> assumption is incorrect (in some cases, it advances by as little as
> one row sometimes -- the actual advance varies).  If you want to play
> with this, check out the test program 'escp2-weavetest'.  This (in
> combination with run-weavetest) is a regression test for the weave
> code, that checks a whole bunch of invariants very carefully.  It's
> really hard to get it all right, but if you want to take a crack at
> it, please do (it would be a really worthwhile contribution).  Right
> now it does something that works correctly, at the cost of losing the
> top and bottom of the sheet.

I've spent a day or two so far teasing apart the weave code, and I'm
*pretty* sure I know more about how it works than when I started...
It's hairy stuff, though.  It's going to take a while longer before I
understand it.

Here's some of what I understand so far, mostly my understanding of
your terminology.  Please correct me if I'm wrong:

The page is rendered to a collection of dots by the dithering code at some
resolution, e.g. 720x720DPI.  A "row" consists of all the dots output
by the dither for printing at a single vertical position.  A row may be
printed in two or more "subpasses" which print dots at the same vertical
position but different horizontal positions.  I suppose this is needed
if the printer's "raster image" command doesn't allow a high enough
horizontal resolution, or if the print head can't print dots as close
together as we'd like (I know the old dot matrix printers used to ignore
any dot immediately following another dot on the same pin).  I'll call a
subpass (or a row if it's printed in only one subpass) a "line": a line
consists of all the dots printed by a single nozzle during one pass.

A "pass" is a group of lines printed in one sweep of the print head.
In a pass, each jet on the printhead can be assigned one line, so these
lines must be spaced the same way as the printhead's jets.  If jets
at the top of the pass lie outside the image, they are assigned blank
"phantom rows".  Unused jets at the bottom of the pass don't need phantom
rows, because of the way the printer's "raster image" commands work.

initialize_weave() creates a data structure which keeps track of the
weaving pattern for a single page, and destroy_weave() cleans it up
afterwards.  As each row on the page is dithered (in order, top-to-bottom)
the row is passed to escp2_write_weave().  This calculates the weave
parameters for that row, chops the row up into lines as necessary, and
stashes the lines in the softweave data structure.  When all the lines
for a given pass are available, escp2_write_weave() advances the paper
appropriately and prints the pass.

initialize_weave() takes parameters:
  jets:           number of nozzles in printhead.
  sep:            separation between nozzles in rows (1/720").
  osample:        number of passes necessary to print a single row
                  (due to the row's resolution being higher than the
                  printer's horizontal resolution).
  v_subpasses:    number of passes in which to print each "osample"
                  pass in order to bring different jets into play.
  v_subsample:    number of dithered rows for each printed row.
                  I'm not sure what this does.  Does it merge rows?
                  Overprint them?  Feed the paper in smaller increments
                  than 1/720"?
  colormode:      one of: monochrome, four-colour or six-colour printing.
  width:          number of bits per pixel.
  linewidth:      number of pixels per row.
  lineheight:     number of rows on the page.
  separationrows: used for calculating paper advance for the 1520/3000.
                  I'm not sure what this does, and I doubt I need to
                  know at the moment.

Parameters calculated by initialize_weave():

  OVERSAMPLE is the number of lines to be printed on each row.

  VMOD is the number of lines to be printed in the space between each
  pair of jets.  In other words, it's the number of passes the printhead
  makes while spanning any given point on the paper.

  NJETS is the number of jets within whose span we print one line on
  every row as the printhead moves that distance.  That is, a line is
  printed on a given row once for each time NJETS nozzles move past it.
  So, in the space of NJETS nozzles, we have to do a complete weave
  pattern, hitting each row once.  The first NJETS nozzles print each
  row for the first time.  The next NJETS nozzles overprint each of
  those rows to perform the second subpass, the third NJETS nozzles
  print the third subpass, etc.  Thus, we only need consider the first
  NJETS nozzles when working out our weaving pattern; the rest of the
  jets simply trail behind at regular intervals.

  WEAVEFACTOR is the interleave factor, NJETS/SEPARATION rounded up.
  Each pass, WEAVEFACTOR lines get printed below the previously
  lowest-printed line.  (This is a guess; I don't understand it yet.)

I'll try to write down more as I understand it.

> It's not possible to reverse feed.  At least, it isn't documented, and
> I've never seen a Windows print file that suggested that it is.

I don't know where I got the idea that it was.  I'll have to generate
some print files from the Epson driver and see what they get up to.
If the initial print position is (as it appears to be) hard up against
the top of the page, there would be little reason to back up anyway,
except for the sake of simplicity.

> The problem is that the Gimp hits plugins with a SIGKILL (kill -9)
> whenever you hit cancel, so there's no opportunity to clean up (Sven,
> are you listening?)

I've tried fixing this; here's the patch.  It works by spawning a
"monitor" process whose purpose is to spawn lpr and then watch its parent
process (the plugin).  If the parent sends SIGUSR1 to the monitor process,
the print job was successful, so the monitor quits.  If the plugin dies
before sending SIGUSR1, the monitor kills off lpr, thus cancelling the
print job.

This also has the nice effect that if the plugin crashes, the print job
will be cancelled.

==============================================================================
--- print.c.orig	Wed May 10 18:13:16 2000
+++ print.c	Wed May 10 18:14:32 2000
@@ -293,6 +293,18 @@
 #endif
 
 /*
+ * 'usr1_handler()' - Make a note when we receive SIGUSR1.
+ */
+
+static volatile int usr1_interrupt;
+
+static void
+usr1_handler (int signal)
+{
+  usr1_interrupt = 1;
+}
+
+/*
  * 'run()' - Run the plug-in...
  */
 
@@ -318,6 +330,10 @@
 #ifndef GIMP_1_0
   GimpExportReturnType export = EXPORT_CANCEL;    /* return value of gimp_export_image() */
 #endif
+  int		ppid = getpid (), /* PID of plugin */
+		opid,		/* PID of output process */
+		cpid,		/* PID of control/monitor process */
+		pipefd[2];	/* Fds of the pipe connecting all the above */
 
   INIT_LOCALE ("gimp-print");
 
@@ -531,7 +547,62 @@
 
       if (plist_current > 0)
 #ifndef __EMX__
-	prn = popen (vars.output_to, "w");
+      {
+	/*
+	 * The following IPC code is only necessary because the GIMP kills
+	 * plugins with SIGKILL if its "Cancel" button is pressed; this
+	 * gives the plugin no chance whatsoever to clean up after itself.
+	 */
+	usr1_interrupt = 0;
+	signal (SIGUSR1, usr1_handler);
+	if (pipe (pipefd) != 0) {
+	  prn = NULL;
+	} else {
+	  cpid = fork ();
+	  if (cpid < 0) {
+	    prn = NULL;
+	  } else if (cpid == 0) {
+	    /* LPR monitor process.  Printer output is piped to us. */
+	    opid = fork ();
+	    if (opid < 0) {
+	      /* Errors will cause the plugin to get a SIGPIPE.  */
+	      exit (1);
+	    } else if (opid == 0) {
+	      dup2 (pipefd[0], 0);
+	      close (pipefd[0]);
+	      close (pipefd[1]);
+	      execl("/bin/sh", "/bin/sh", "-c", vars.output_to, NULL);
+	      exit (1);
+	    } else {
+	      /*
+	       * If the print plugin gets SIGKILLed by gimp, we kill lpr
+	       * in turn.  If the plugin signals us with SIGUSR1 that it's
+	       * finished printing normally, we close our end of the pipe,
+	       * and go away.
+	       */
+	      close (pipefd[0]);
+	      while (usr1_interrupt == 0) {
+	        if (kill (ppid, SIGNULL) < 0) {
+		  /* The print plugin has been killed!  */
+		  kill (opid, SIGTERM);
+		  waitpid (opid, &dummy, 0);
+		  close (pipefd[1]);
+		  exit (0);
+	        }
+	        sleep (5);
+	      }
+	      /* We got SIGUSR1.  */
+	      close (pipefd[1]);
+	      exit (0);
+	    }
+	  } else {
+	    close (pipefd[0]);
+	    /* Parent process.  We generate the printer output. */
+	    prn = fdopen (pipefd[1], "w");
+	    /* and fall through... */
+	  }
+	}
+      }
 #else
       /* OS/2 PRINT command doesn't support print from stdin, use temp file */
       prn = (tmpfile = get_tmp_filename ()) ? fopen (tmpfile, "w") : NULL;
@@ -566,7 +637,11 @@
 
 	  if (plist_current > 0)
 #ifndef __EMX__
-	    pclose (prn);
+	  {
+	    fclose (prn);
+	    kill (cpid, SIGUSR1);
+	    waitpid (cpid, &dummy, 0);
+	  }
 #else
 	  { /* PRINT temp file */
 	    char *s;
==============================================================================

[The yellow colouring of the pictures I printed]
> Did that seem specific to the camera?

I haven't really tried enough image sources to be able to tell.  I'll try
some scanned photos sometime.

>    And thanks for all the work you (all) have already done on gimp-print!
>    I mentioned above that a friend (a newspaper photographer) had asked
>    for some images printed.  He has a Photo 700 (and no ink at present) and
>    uses Windows (NT I think).  After seeing the prints gimp-print produced,
>    he said he wanted a new printer.  Congratulations!
> 
> The driver is very well tuned for the 700 (I previously had an EX).

Ben uses Windows and the Windows driver with his 700.  The prints we
did for him were from the 870 with gimp-print.  What I meant to say
(apparently unsuccessfully) was that (Photo 870 + gimp-print) makes better
prints than (Photo 700 + Windows driver), which seems to be a good result,
since the 700 is relatively recent.  I also know first-hand that (Photo
870 with gimp-print) is considerably better than (Colour 3000 with Windows
driver), which is also a good result, but probably not a surprising one.

I'll append the patch for clipping the image to the page size that I
mentioned in my previous email.  In landscape mode, 3.1.4 with this
patch seems to print images upside down...  But as far as I can tell,
vanilla 3.1.2 did the same thing.

Cheers,

--
Charles Briscoe-Smith             <URL:http://www.debian.org/%7Ecpbs/>
PGP2:  1024/B35EE811  74 68 AB 2E 1C 60 22 94  B8 21 2D 01 DE 66 13 E2
"You think that's air you're breathing now?" -- Morpheus, "The Matrix"


==============================================================================
diff -ur orig/print-escp2.c ./print-escp2.c
--- orig/print-escp2.c	Sat May 13 02:07:03 2000
+++ ./print-escp2.c	Sat May 13 02:11:16 2000
@@ -893,6 +893,10 @@
   colormode_t colormode = COLOR_CCMMYK;
   int		separation_rows = escp2_separation_rows(model);
   int		use_glossy_film = 0;
+  int		first_row = 0,		/* First row used in image */
+		num_rows,		/* Number of rows used in image */
+		clip_row_start = 0,	/* First pixel used on each row */
+		clip_row_length;	/* No. of pixels used on each row */
 
   if (!strcmp(media_type, "Glossy Film"))
     use_glossy_film = 1;
@@ -1122,11 +1126,46 @@
     left = page_width - x - out_width;
   }
 
-  if (left < 0)
-    left = (page_width - out_width) / 2;
+  first_row = 0;
+  clip_row_start = 0;
 
-  if (top < 0)
-    top  = (page_height - out_height) / 2;
+  if (landscape) {
+    num_rows = image_width;
+    clip_row_length = image_height;
+  } else {
+    num_rows = image_height;
+    clip_row_length = image_width;
+  }
+
+  if (left < 0) {
+    left = -left;
+    clip_row_start = left * clip_row_length / out_width;
+    clip_row_length -= clip_row_start;
+    out_width -= left;
+    left = 0;
+  }
+
+  if (top < 0) {
+    top = -top;
+    first_row = top * num_rows / out_height;
+    num_rows -= first_row;
+    out_height -= top;
+    top = 0;
+  }
+
+  {
+    int extra = left + out_width - page_width;
+    if (extra > 0) {
+      clip_row_length -= extra * clip_row_length / out_width;
+      out_width -= extra;
+    }
+
+    extra = top + out_height - page_height;
+    if (extra > 0) {
+      num_rows -= extra * num_rows / out_height;
+      out_height -= extra;
+    }
+  }
 
  /*
   * Let the user know what we're doing...
@@ -1210,10 +1249,7 @@
     v->density = 1.0;
   v->saturation *= printer->printvars.saturation;
 
-  if (landscape)
-    dither = init_dither(image_height, out_width, v);
-  else
-    dither = init_dither(image_width, out_width, v);
+  dither = init_dither(clip_row_length, out_width, v);
   dither_set_black_levels(dither, 1.5, 1.5, 1.5);
   dither_set_black_lower(dither, .4);
   if (use_glossy_film)
@@ -1255,16 +1291,17 @@
     }	    
   dither_set_density(dither, v->density);
 
+  in  = malloc(clip_row_length * image_bpp);
+  out = malloc(clip_row_length * out_bpp * 2);
+
+  errdiv  = num_rows / out_height;
+  errmod  = num_rows % out_height;
+  errval  = 0;
+  errlast = -1;
+
   if (landscape)
   {
-    in  = malloc(image_height * image_bpp);
-    out = malloc(image_height * out_bpp * 2);
-
-    errdiv  = image_width / out_height;
-    errmod  = image_width % out_height;
-    errval  = 0;
-    errlast = -1;
-    errline  = image_width - 1;
+    errline  = first_row + num_rows - 1;
     
     for (x = 0; x < out_height; x ++)
     {
@@ -1274,10 +1311,10 @@
       if (errline != errlast)
       {
         errlast = errline;
-	Image_get_col(image, in, errline);
+	Image_get_clipped_col(image, in, errline, clip_row_start, clip_row_length);
       }
 
-      (*colorfunc)(in, out, image_height, image_bpp, cmap, v);
+      (*colorfunc)(in, out, clip_row_length, image_bpp, cmap, v);
 
       if (v->image_type == IMAGE_MONOCHROME)
 	dither_fastblack(out, x, dither, black);
@@ -1303,21 +1340,10 @@
         errline --;
       }
     }
-    if (use_softweave)
-      escp2_flush(weave, model, out_width, left, ydpi, xdpi, prn);
-    else
-      escp2_free_microweave();
   }
   else
   {
-    in  = malloc(image_width * image_bpp);
-    out = malloc(image_width * out_bpp * 2);
-
-    errdiv  = image_height / out_height;
-    errmod  = image_height % out_height;
-    errval  = 0;
-    errlast = -1;
-    errline  = 0;
+    errline  = first_row;
     
     for (y = 0; y < out_height; y ++)
     {
@@ -1327,10 +1353,10 @@
       if (errline != errlast)
       {
         errlast = errline;
-	Image_get_row(image, in, errline);
+	Image_get_clipped_row(image, in, errline, clip_row_start, clip_row_length);
       }
 
-      (*colorfunc)(in, out, image_width, image_bpp, cmap, v);
+      (*colorfunc)(in, out, clip_row_length, image_bpp, cmap, v);
 
       if (v->image_type == IMAGE_MONOCHROME)
 	dither_fastblack(out, y, dither, black);
@@ -1355,11 +1381,11 @@
         errline ++;
       }
     }
-    if (use_softweave)
-      escp2_flush(weave, model, out_width, left, ydpi, xdpi, prn);
-    else
-      escp2_free_microweave();
   }
+  if (use_softweave)
+    escp2_flush(weave, model, out_width, left, ydpi, xdpi, prn);
+  else
+    escp2_free_microweave();
   free_dither(dither);
 
  /*
diff -ur orig/print.c ./print.c
--- orig/print.c	Sat May 13 02:07:03 2000
+++ ./print.c	Sat May 13 02:06:41 2000
@@ -1205,6 +1205,22 @@
 }
 
 void
+Image_get_clipped_col(Image image, unsigned char *data, int column,
+                      int start, int length)
+{
+  Gimp_Image_t *gimage = (Gimp_Image_t *) image;
+  gimp_pixel_rgn_get_col(&(gimage->rgn), data, column, start, length);
+}
+
+void
+Image_get_clipped_row(Image image, unsigned char *data, int row,
+                      int start, int length)
+{
+  Gimp_Image_t *gimage = (Gimp_Image_t *) image;
+  gimp_pixel_rgn_get_row(&(gimage->rgn), data, start, row, length);
+}
+
+void
 Image_progress_init(Image image)
 {
   image = image;
diff -ur orig/print.h ./print.h
--- orig/print.h	Sat May 13 02:07:03 2000
+++ ./print.h	Sat May 13 02:07:34 2000
@@ -152,6 +152,10 @@
 extern const char *Image_get_pluginname(Image image);
 extern void Image_get_col(Image image, unsigned char *data, int column);
 extern void Image_get_row(Image image, unsigned char *data, int row);
+extern void Image_get_clipped_col(Image image, unsigned char *data,
+                                  int column, int start, int length);
+extern void Image_get_clipped_row(Image image, unsigned char *data,
+                                  int row, int start, int length);
 extern void Image_progress_init(Image image);
 extern void Image_note_progress(Image image, double current, double total);
 
==============================================================================

Re: [Gimp-print-devel] Positioning code (interface) cleanup

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

   Date: Fri, 12 May 2000 19:28:04 -0700
   From: "S. Miller" <sm...@rn...>

   I will give it (the gtk version) a shot when I can (my parents are
   visiting from out of town this weekend, so it will likely be next
   week).  Robert, can you give me a hint on how to apply a patch in cvs? 
   I haven't done that before.

Do you have the patch program?  Update your sandbox to the latest
version, save his patch to a file, and type

patch -p0 < file

If you don't get any errors, you're in good shape.

Re: [Gimp-print-devel] Positioning code (interface) cleanup

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

Robert L Krawitz wrote:
> 
>    Date: Sat, 13 May 2000 00:05:06 +0100
>    From: Thorsten Schnier <tho...@sc...>
> 
>    I had a look at the positioning code in gtk_main_window.c and found a
>    few problems. The calculation of the values for "right" and "bottom" was
>    wrong, and the non-printable areas got ignored.
> 
> Could you fix this in gimp_main_window.c also?  Mitch or Steve, could
> you check this out?
> 
I will give it (the gtk version) a shot when I can (my parents are
visiting from out of town this weekend, so it will likely be next
week).  Robert, can you give me a hint on how to apply a patch in cvs? 
I haven't done that before.

Thorsten, can you email me any further changes you'd like?  I'm tracking
down a few remaining segv's resulting from a switch to a notebook
version of the gui, and would like to avoid making the same changes
multiple times.  I think I'm very close on the notebook version.

Steve
-----------------------------------------
Einstein discovered that time and space are interchangeable
when he showed up three miles late for a meeting.
------------------------------------------

[Gimp-print-devel] eLinux.com

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

This is a company that sells "Everything and Anything for Linux."
Page 44 of their current catalog, which has printers, reads "The GIMP
print plug-in, when used with your Epson printer, gives you better
image quality.  Call us to find out how to get this plug-in."

Curious, I called, and the salesperson gave me the plug-in registry.
I immediately identified myself, and their marketing director asked me
to email her.

This could be handy for everyone -- they could sell more high-end
printers if there are better drivers; Epson could do likewise; we
could expand our user base; and they might be in a better position to
put pressure on the printer vendors to be more forthcoming with
information.

I'll keep everyone posted as things develop.

-- 
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] Positioning code (interface) cleanup

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

   Date: Sat, 13 May 2000 00:05:06 +0100
   From: Thorsten Schnier <tho...@sc...>

   I had a look at the positioning code in gtk_main_window.c and found a
   few problems. The calculation of the values for "right" and "bottom" was
   wrong, and the non-printable areas got ignored. 

Could you fix this in gimp_main_window.c also?  Mitch or Steve, could
you check this out?

   And I've added a second frame in the preview which shows the edges of
   the printable area inside the paper.

That sounds like a good idea.

   Unfortunately, though I think the values calculated are correct, the
   print does not quite end up at the correct place, it seems too low by
   about 3mm and left by about 1mm (on my 440, with 360dpi setting). But
   there was some discussion about problems with the softweave code
   positioning, so I guess that might be the reason.

I'm in the middle of hacking this code extensively, so that for a lot
of printers (in softweave mode, at any rate) it should be possible to
print very close to the edges of the paper.  There will be some
quality degradation near the top and the bottom (it won't be able to
do the full interleaving that it does in the middle of the page, so
there will be some bandin).  It won't fix the horizontal positioning
problem, although in my experience it's hard to get the paper in
EXACTLY the right spot from time to time.

   I've changed a few variable names to make the distinction between
   printable area and paper area more clear; I've left vars.left and
   vars.top relative to the edges of the printable area (this is correct,
   isn't it? Meaning 0 / 0 means the image is located against the top left
   of the printable area? )

Just make sure it doesn't break anything that relies on it.

   I don't quite understand how the plugin decides between gimp_main_window
   and gtk_main_window, I've patched only the one that it is using in my
   case, but if required the other one should be straightforward. 

It registers twice with the Gimp, and picks gimp or gtk toolkits based
upon which one is called.

   There is some code in there that prevents people from moving the image
   (partially) outside the printable area, I wonder if this is desirable /
   required? Would it make more sense to allow partial clipping ? Would the
   print code cope with negative offsets?

There was some discussion about this not too long ago.  I'm not too
keen on it.  I think that if you want to clip output, it should be
done at the application level so you know exactly what's going to get
printed out.

-- 
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] Positioning code (interface) cleanup

[Thorsten S. <tho...@sc...>]

Hi,

I had a look at the positioning code in gtk_main_window.c and found a
few problems. The calculation of the values for "right" and "bottom" was
wrong, and the non-printable areas got ignored. 

The following patch fixes that, the values of 'right', 'left', 'top' and
'bottom' are now calculated with respect to their respective paper
edges. (In other words, if you set 'right' to 3, the right edge of your
print should end up 3 inches from the right edge of the paper). Clicking
'center' now also results in correct values for all sides.

I've also done some code cleanup, e.g. at a couple of places values were
calculated more than once.

And I've added a second frame in the preview which shows the edges of
the printable area inside the paper.

Unfortunately, though I think the values calculated are correct, the
print does not quite end up at the correct place, it seems too low by
about 3mm and left by about 1mm (on my 440, with 360dpi setting). But
there was some discussion about problems with the softweave code
positioning, so I guess that might be the reason.

I've changed a few variable names to make the distinction between
printable area and paper area more clear; I've left vars.left and
vars.top relative to the edges of the printable area (this is correct,
isn't it? Meaning 0 / 0 means the image is located against the top left
of the printable area? )

I don't quite understand how the plugin decides between gimp_main_window
and gtk_main_window, I've patched only the one that it is using in my
case, but if required the other one should be straightforward. 

There is some code in there that prevents people from moving the image
(partially) outside the printable area, I wonder if this is desirable /
required? Would it make more sense to allow partial clipping ? Would the
print code cope with negative offsets?

One thing that still would be very useful is the use of units as
configured in Gimp instead of inches; but I first have to find out how
to do that (and in a way that it does not break older gimps).


regards

thorsten



----------------------------------------------------------------------- 
                                                       Thorsten Schnier
                                    
                                             School of Computer Science
                                               University of Birminghan
                                                                       
                                               
T.S...@cs...   
                                                   tho...@sc...

[Gimp-print-devel] Ghostscript woes

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

I've been having a terrible time with the Ghostscript driver lately.  I
can't quite figure it out.  Printing an image from the Gimp produces a
nice looking print.  Printing the same image with the same settings via
the ghostscript driver compiled from the same source just fills the page
full width with a black bar with vertical colored stripes.

It looks like the lower heads are actually printing the image, although at
a scale maybe four times larger than the Gimp, and the upper heads are
over-printing it with the bar.  I didn't want to waste the ink to print a
whole page with that, so it's also possible that it's just the top of the
page that's crap.

Is anyone actively using the current Ghostscript driver?  With gs 5.10?
With an ESP 750?  Successfully?

As always, the main problem is finding enough time to debug this.  I should
have some this evening, but not much after tonight.

Eric

Re: [Gimp-print-devel] ESP 870 results

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

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

>    Date: Fri, 12 May 2000 11:02:51 +0100
>    From: Dave Hill <da...@mi...>
> 
>    Robert L Krawitz wrote:
>    > 
>    > I printed the PDI target full size just now, using a piece of Epson
>    > photo paper rather than the cheap third party stuff I've been using.
>    > It isn't perfect by any means, but overall it blows all of my other
>    > test prints clear out of the water, including some samples I was sent
>    > from an ESC 660 (using gimp-print and Windows).
> 
>    Sorry, I must have missed something here. What is "the PDI target"?
> 
> That big test shot that Karl pointed us at.


And just in case you were wondering where to get it:
  ftp://ftp.photodisc.com/pub/test_targets/

I was able to unpack it using the unpacker from Aladdin Systems:
  http://www.aladdinsys.com/

Re: [Gimp-print-devel] ESP 870 results

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

   Date: Fri, 12 May 2000 11:02:51 +0100
   From: Dave Hill <da...@mi...>

   Robert L Krawitz wrote:
   > 
   > I printed the PDI target full size just now, using a piece of Epson
   > photo paper rather than the cheap third party stuff I've been using.
   > It isn't perfect by any means, but overall it blows all of my other
   > test prints clear out of the water, including some samples I was sent
   > from an ESC 660 (using gimp-print and Windows).

   Sorry, I must have missed something here. What is "the PDI target"?

That big test shot that Karl pointed us at.