gimp-print-devel

Re: [Gimp-print-devel] New UI stuff

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

   Date: Wed, 24 May 2000 19:07:51 -0700
   From: "S. Miller" <sm...@rn...>

   I think providing an image size widget would scratch both itches. 
   Adding the image size to the top/left offset should get you to where you
   want to put the next image.  That would leave the right/bottom numbers
   as 'margins'.  If no one has any objections, I'll put this on my todo
   list.  It will be a while before I get that far down, so there's plenty
   of time for feedback or yelling _NO!_.

Having image size would be useful.  I think that there should also be
an option to specify margins vs. distance from origin?

Re: [Gimp-print-devel] New UI stuff

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

Robert L Krawitz wrote:
> 
>    Date: Wed, 24 May 2000 11:48:43 +0200
>    From: Sven Neumann <neu...@un...>
> 
>    I haven't seen the new UI yet, but IMO there should be an UI element
>    that allows you to specify the size of the output directly.  Not by
>    setting a scaling value or by fiddling around with offsets, but by
>    setting the size using a pair of GimpSizeEntries.
> 
> I agree.  We could always lock the ratio at first.
> 
>    BTW: IMHO specifying the offsets from each corner makes more sense
>         then to refer to the top/left corner for all offset values.
>         To be honest, that's what I thought the current dialog was
>         doing, which proves that it's not that intuitive.
> 
> Hmm.  I think this is a matter of what you're trying to do.  In my
> case, I'm trying to fit a lot of very small prints (at 19.5% scaling)
> on one page, so I need to know precise dimensions from the origin.  In
> other cases, the other behavior might work better.
> 
I think providing an image size widget would scratch both itches. 
Adding the image size to the top/left offset should get you to where you
want to put the next image.  That would leave the right/bottom numbers
as 'margins'.  If no one has any objections, I'll put this on my todo
list.  It will be a while before I get that far down, so there's plenty
of time for feedback or yelling _NO!_.

Steve
-- 
-----------------------------------------
Madness takes its toll.  Please have exact change.
------------------------------------------

[Gimp-print-devel] The new matrix

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

...is really good.  Not perfect, but seriously good.  There are a few
quasi-linear artifacts, as I mentioned, but it's a whole lot smoother
than error diffusion.  Interestingly enough, the pattern looks like
error diffusion artifacts, but on a much finer scale than what we're
used to.

One problem I'm having, though, that perhaps someone can figure out is
that ordered dither performs very poorly on the EX (single dot size,
light inks).  The transition region is very splotchy, not the
(relatively) smooth transition that happens with error diffusion.
I've changed the adaptive dithering to cut over in the range of
1/2-1/8 rather than 1/128-0 as with the old (iterated-2) matrix.
There's a slightly funky region in that transition zone, but it's not
too visible.

On the 870, adaptive dithering also works well, except that a
transition range of 1/8-1/32 works best (not surprising; there are
more dots with that kind of printer).  Ordered dithering is somewhat
grainy in general; error diffusion works well, although the artifacts
are visible in very pale areas.

BTW, I'm beginning to believe that Jean-Marc is correct about the
ratios of the inks and drop sizes, based on what I'm seeing printing
as a 600 (which is compatible with the EX) vs. an EX vs. an 870.  I
don't have a good insight into how to fix the problems of sharp
transitions in colors.tif and the yellow cast, though.  Jean-Marc, do
you have any ideas about those problems?

Also, I'm going to be away from Friday through Monday -- it's Memorial
Day here in the US, and we're going up to the mountains in New
Hampshire for the weekend.

-- 
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] Update to print-dither.c

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

   Date: Wed, 24 May 2000 19:07:07 +0200
   From: Thomas Tonino <tt...@bi...>

   I changed behaviour for invert_x and invert_y. They just shift the
   matrix a little now. These matrices do not work when taking 65536-value
   as the lowest values are hand picked and the software buils from there.
   The high values have less beautiful spacing.

   Prints are less grainy now, but invert_x and invert_y really need to
   shift the matrix by 1/2 size. The 127 I put is is not a good
   approgimation for 199/2, but it will work.

Yup, that really makes a difference.  It's still not as smooth as
error diffusion in dense regions, but it's very good.  We may be able
to change the adaptive limit.

I'm actually using the 257 matrix, not either of the 199's.

Also, I fixed one bug in the black vs. CMY code (actually two
buglets); both of them involve the use of ints for values that are
always unsigned.  There may be other overflow/sign flip problems
around.  The 720 dpi output still doesn't look right at the high
density I'm using 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] New UI stuff

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

   Date: Wed, 24 May 2000 14:20:04 +0200
   From: Sven Neumann <neu...@un...>

   At some point the driver should definitely allow to print multiple 
   images on one sheet of paper. There should be a GUI to position the
   images and it shouldn't be necessary to work around the lack of such 
   an option as you describe it above. 

   How hard would it be to make the driver print multiple 
   (non-overlapping) images in one pass? Adding the GUI shouldn't be 
   too hard and might turn out to be an interesting thing to hack on.

It occurred to me after I sent my reply this morning that you might
have been talking about n-up printing, which certainly should be
supported.  The low-level driver itself doesn't support this, but the
GUI could do it.  The interaction between the driver and the image
goes through an Image layer (see print.h).  That layer can do whatever
hackistry is required to do this.

-- 
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] Committed Debianisation files

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

[I tried to send this yesterday, but got a bounce saying that
mail1.sourceforge.net had rejected the message with "user unknown"...]

Hi,

I just committed a debian/ directory to CVS.  Let me know if there's
any problem with it.  I'll commit my "cancel" fix once I've separated
out my other unrelated hacks.

Incidentally, I gave up trying to understand the existing softweave
algorithm, and have devised a new weaving method instead.  I'm going to
see if my new one sheds light on the existing one (they might even be
equivalent), and see if I can code it up.  If I can do that, I'll try
fixing the "separate initial and final passes" quality bug.

Also, I got a USB cable, built a USB-enabled kernel, and got it working!
(Just created a /dev/usbprinter0 char special with major 180, minor 0,
and pointed lpd at it.)  USB seems to be faster than parport printing,
although I've still noticed the printer pause between passes.  I need
to do some speed trials on it sometime to see objectively if it is
any quicker.

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"

[Gimp-print-devel] Committed sighandler ("cancel") patch

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

[Another one that got bounced yesterday.]

My second commit; this time some code to handle the Gimp's SIGKILL and
kill off lpr cleanly.

Should I mail here whenever I commit stuff, or can people get CVS commit
messages mailed to them automatically?

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"

[Gimp-print-devel] Update to print-dither.c

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

I changed behaviour for invert_x and invert_y. They just shift the
matrix a little now. These matrices do not work when taking 65536-value
as the lowest values are hand picked and the software buils from there.
The high values have less beautiful spacing.

Prints are less grainy now, but invert_x and invert_y really need to
shift the matrix by 1/2 size. The 127 I put is is not a good
approgimation for 199/2, but it will work.


Thomas

Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Mike P. <mi...@UD...>]

On Sat, 20 May 2000, Michael Sweet wrote:

> Miguel de Icaza wrote:
> > ...
> > The "dump to ghostscript, process, send to printer" solution is
> > exactly what I believe to be fully broken for Unix to succeed on the
> > desktop.  We have the infrastructure now to do things right, and I
> > want to do this.
> 
> What's broken is LPD, and the sooner we eliminate LPD from the scene
> the better.

LPD/R doesn't even appear to have a coherent specification.  At
least when I tried to implement an lpr client, I couldn't get the
result processed by all lpd servers I had access to (problem was I
don't know how many bytes were to be printed...)  I don't remember
all the details, but it was ugly...

Also, the idea that upon restart, lpd must send all prints before
it accepts new prints bit us a couple of times.

Mike

Re: [Gimp-print-devel] An introduction to gnome-print (fwd)

[Mike P. <mi...@UD...>]

> OK, here's where I think we disagree tactically.  Much of our effort
> has been going into improving quality and support for specific
> printers (particularly the latest Epson offerings -- the reason for
> that is that HP and Canon have not been forthcoming with
> information).  The fact that I printed a test image this morning on an
> Epson Stylus Photo 870 and got something that really looks a lot like
> a photograph (I'd say that the quality equals a marketing print that
> Epson themselves made from a 1200) testifies to that.
> 
....
> I want people who have Epson 800's and 600's and 700's and 740's to
> get good output.  I also want people who want to be able to produce
> photographic quality output from Linux to be able to do so NOW, not
> two years down the road when gnome-print is complete.  I think that
> that's just as critical, because people won't wait for everything to
> catch up.

This is why I am interested in gimp-print.  For those of us
interested in electronic "darkroom work" on a hobbiest basis, the
time has finally come where we can afford to buy reasonably priced
equipment.  I'd like to be able to use this equipment under Linux
so I don't have to suffer the silliness of Windows (For instance:
the Windows Canon printer driver will only print 30MB files or
less).

I don't actually own a photo quality printer - I'm still looking at
getting better scans from an Epson 1200 Perfection.  When I'm happy
with the scans, then I'll get a printer...

Seems to me that you can continue to develop the dithering
algorithms and whatnot and roll the resulting code into any number
of printing systems (ghostscript, gnome-print, etc) - depending on
what most people are using.

> that eventually the Gimp will print through something like
> gnome-print, which will package everything up for CUPS.  At that
> point, the core of gimp-print might be a back end driver within CUPS.

yes...and after watching what everyone on this list is talking
about, very little of your efforts will be wasted.

Mike

Re: [Gimp-print-devel] New UI stuff

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

T.S...@cs... wrote:

> Without the first change, you cannot position a print, say, one cm from
> the left paper edge without knowing the size of the margins (which are
> printer dependend and subject to change, as we've just seen with the top
> margin).

Does this require any changes in the printer drivers, eg setting left left/top
border?
 
> Interpreting the right/bottom as measures towards right/bottom edges
> seems much more intuitive to me; but of course I might be in the
> minority here. The difference is: I interpret the values as 'borders',
> you interpret them as 'coordinates'. With the old interface, you can
> deduce the size of the image from the coordinates, but to get the
> distance from the right paper edge, you have to know the paper size (and
> margins). Now it is the other way 'round.

I seem to be part of the minority - at least I always understood the
right/bottom values as they are now...

Andy

-- 
Andy Thaller
TU Muenchen, Physikdepartment E11       Tel: ++49 (0)89 289 12860
James Franck Str.                       Fax: ++49 (0)89 289 12842
85748 Garching   //  Germany            email:  th...@ph...

[Gimp-print-devel] One glitch at 720...

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

I noticed an odd glitch with colors.tif at 720 dpi: the very darkest
areas have no black at all (it's all CMY).  At 1440 there's no
problem.  I'm using a density of 1.7.  Probably an arithmetic overflow
somewhere.

-- 
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] Possible optimization

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

   Date: Wed, 24 May 2000 08:39:30 -0400
   From: Michael Sweet <mi...@ea...>
   CC: gim...@so...

   Robert L Krawitz wrote:
   > ...
   > The idea is to check if there's anything other than pure black or
   > white when the color conversion is done.  If there isn't, the fast
   > black dither routine is used.
   > 
   > Similarly, if a line is entirely white, we don't dither that line at
   > all, but simply zero fill it.

   This probably won't help too much for the GIMP plug-in, but will be
   helpful for a CUPS/Ghostscript driver (where you are likely to get
   areas of all-white or all-black)

True, I try to think of it all as one source base.  As I've said
before, the best way to involve me in GUI design is to take anything I
say and invert it :-)

   What we do in our drivers is skip (0) any white areas; for error-
   diffusion dithers you also have to look at the current error value
   (add it in to the ink value) to make sure you aren't missing a dot
   that needs to be output.  This can happen right inside the dither,
   as well as a quick check for CMYKcm = 0 for an entire line.

Actually, as it happens the driver doesn't print anything that's a
zero (in any color plane) in the ink value, anyway, even if the error
diffusion says to do so.

   > Another option we could consider is to fast path pure black or white
   > pixels during the dither routine.  We already compute the max and
   > min value for each pixel; if the max and min are equal and either 0
   > or 65535, we use the fast path.

   I'm not sure if that would help; if printers (and media) could handle
   100% ink then this would be easy; otherwise I think you'll end up
   dithering anyways...

Actually, after the recent big discussion about density vs. 65535, I
should know better.  If the max and min are equal and either 0 or
greater than or equal to the density, we use the fast path.

Re: [Gimp-print-devel] New UI stuff

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

   Date: Wed, 24 May 2000 14:20:04 +0200
   From: Sven Neumann <neu...@un...>

   At some point the driver should definitely allow to print multiple 
   images on one sheet of paper. There should be a GUI to position the
   images and it shouldn't be necessary to work around the lack of such 
   an option as you describe it above. 

That isn't what I need to do -- I need to do them sequentially (print
one image, inspect it, print another one -- I get 25 images to a page,
I might be able to get 30 now).

   How hard would it be to make the driver print multiple 
   (non-overlapping) images in one pass? Adding the GUI shouldn't be 
   too hard and might turn out to be an interesting thing to hack on.

A montage, you mean?  Wouldn't that best be handled within the Gimp
itself (via an appropriate plugin)?

-- 
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] Possible optimization

[Michael S. <mi...@ea...>]

Robert L Krawitz wrote:
> ...
> The idea is to check if there's anything other than pure black or
> white when the color conversion is done.  If there isn't, the fast
> black dither routine is used.
> 
> Similarly, if a line is entirely white, we don't dither that line at
> all, but simply zero fill it.

This probably won't help too much for the GIMP plug-in, but will be
helpful for a CUPS/Ghostscript driver (where you are likely to get
areas of all-white or all-black)

What we do in our drivers is skip (0) any white areas; for error-
diffusion dithers you also have to look at the current error value
(add it in to the ink value) to make sure you aren't missing a dot
that needs to be output.  This can happen right inside the dither,
as well as a quick check for CMYKcm = 0 for an entire line.

You can also optimize the dither for each color plane, e.g. if C,
M, Y, or K is 0, then don't bother dithering.  This might yield a
modest performance gain even with the print plug-in.

> Another option we could consider is to fast path pure black or white
> pixels during the dither routine.  We already compute the max and
> min value for each pixel; if the max and min are equal and either 0
> or 65535, we use the fast path.

I'm not sure if that would help; if printers (and media) could handle
100% ink then this would be easy; otherwise I think you'll end up
dithering anyways...

-- 
______________________________________________________________________
Michael Sweet, Easy Software Products                  mi...@ea...
Printing Software for UNIX                       http://www.easysw.com

Re: [Gimp-print-devel] New UI stuff

[Sven N. <neu...@un...>]

Hi,

>    BTW: IMHO specifying the offsets from each corner makes more sense
> 	then to refer to the top/left corner for all offset values. 
> 	To be honest, that's what I thought the current dialog was 
> 	doing, which proves that it's not that intuitive.
> 
> Hmm.  I think this is a matter of what you're trying to do.  In my
> case, I'm trying to fit a lot of very small prints (at 19.5% scaling)
> on one page, so I need to know precise dimensions from the origin.  In
> other cases, the other behavior might work better.

At some point the driver should definitely allow to print multiple 
images on one sheet of paper. There should be a GUI to position the
images and it shouldn't be necessary to work around the lack of such 
an option as you describe it above. 

How hard would it be to make the driver print multiple 
(non-overlapping) images in one pass? Adding the GUI shouldn't be 
too hard and might turn out to be an interesting thing to hack on.


Salut, Sven 

[Gimp-print-devel] Possible optimization

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

This optimization would drastically improve printing speed in cases
where the page is basically all black or white, but there are a few
regions of color.

The idea is to check if there's anything other than pure black or
white when the color conversion is done.  If there isn't, the fast
black dither routine is used.

Similarly, if a line is entirely white, we don't dither that line at
all, but simply zero fill it.

Another option we could consider is to fast path pure black or white
pixels during the dither routine.  We already compute the max and min
value for each pixel; if the max and min are equal and either 0 or
65535, we use the fast path.

This might cause some confusion with error diffusion, but it might
also give sharper edges.  Basically, I'm very concerned about the
rendering time.

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

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

   Date: Tue, 23 May 2000 23:35:04 -0400
   From: Michael Sweet <mi...@ea...>
   CC: F.v...@in..., gim...@so...

   Robert L Krawitz wrote:
   > ...
   > There's little we can do about the bottom margin; the printer simply
   > can't hold the paper down there.

   That depends on the printer; some of them *can* print down to the
   bottom 3mm, with the right commands.  I'll have to check the Level 1
   docos to see if I can contribute the changes required for this...

Whaddayaknow?  It works just fine on the 870.  It's just under 4 mm
from the bottom of the page.  It might be possible to push it even
closer.

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

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

   Date: Wed, 24 May 2000 11:48:43 +0200
   From: Sven Neumann <neu...@un...>

   I haven't seen the new UI yet, but IMO there should be an UI element 
   that allows you to specify the size of the output directly.  Not by
   setting a scaling value or by fiddling around with offsets, but by
   setting the size using a pair of GimpSizeEntries. 

I agree.  We could always lock the ratio at first.

   BTW: IMHO specifying the offsets from each corner makes more sense
	then to refer to the top/left corner for all offset values. 
	To be honest, that's what I thought the current dialog was 
	doing, which proves that it's not that intuitive.

Hmm.  I think this is a matter of what you're trying to do.  In my
case, I'm trying to fit a lot of very small prints (at 19.5% scaling)
on one page, so I need to know precise dimensions from the origin.  In
other cases, the other behavior might work better.

-- 
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] Canon Bubble Jets

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

   From: Stephan Buchert <sc...@st...>
   Date: Wed, 24 May 2000 18:06:59 +0900

   - ink type "Photo/Color" (=CMYKcm) produces structures in "colors.tif"
   which shouldn't be there and the gray bar at bottom is not gray. Since
   I updated only "print-canon.c" in my gimp-print-3.1.4, this result may
   be outdated in light of recent progress in other code of gimp-print.

You need to update everything, not just that one file.

-- 
Robert Krawitz <rl...@al...>      http://www.tiac.net/users/rlk/

Tall Clubs International  --  http://www.tall.org/ or 1-888-IM-TALL-2
Member of the League for Programming Freedom -- mail lp...@uu...
Project lead for The Gimp Print --  http://gimp-print.sourceforge.net

"Linux doesn't dictate how I work, I dictate how Linux works."
--Eric Crampton

[Gimp-print-devel] Re: Yet another attempt at 'black'

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

   Date: Wed, 24 May 2000 08:30:34 +0200
   From: Thomas Tonino <tt...@bi...>

   If you see this at lower densities, it may wel be interference of the
   matrix with itself. It is still fairly regular. I'm trying to add more
   randomness as density increases, but this doesn't work right yet. In any
   case, the matrix is an open target for improvement.

This is at very low density, probably well under 1%.

   Now that I write this, it makes sense. Coming soon, but don't wait for
   it: changing the matrix is a simple plug in after all - and given the
   quality we achieved now shouldn't throw that many things off.

Could you commit it in print/quickmatrix257.h or the equivalent?  That
way it will get tested.

   How do people feel towards matrixec with clustered dots of some kind? We
   do not test laser printers yet, but coarser stuff would also come in
   handy if you need to photocopy your prints.

That's an interesting thought.  I don't think anyone currently
optimizes for output that is to be photocopied.

   The lower density gets divided by 2 dependent on BITS in escp2.c. I
   assume BITS means whether we have a CMYK or CcMmYK printer, and the idea
   is to prevent black from landing in areas that are still printed with
   mainly light ink.

No, bits refers to variable dot size.  The idea's actually the
opposite -- to use black earlier if small black dots are available.

Re: [Gimp-print-devel] Epson stuff

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

   Date: Tue, 23 May 2000 23:35:04 -0400
   From: Michael Sweet <mi...@ea...>
   CC: F.v...@in..., gim...@so...

   Robert L Krawitz wrote:
   > ...
   > There's little we can do about the bottom margin; the printer simply
   > can't hold the paper down there.

   That depends on the printer; some of them *can* print down to the
   bottom 3mm, with the right commands.  I'll have to check the Level 1
   docos to see if I can contribute the changes required for this...

Yes, you can.  It's the ESC(S command, which we already send.  It
might just be a matter of changing the margins in the printer list in
print-escp2.c.

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

[<T.S...@cs...>]

Robert L Krawitz wrote:
> 
> I find the new way of presenting the image position very confusing.
> It's evidently being presented as the distance from each edge (rather
> than from the (top,left) origin as before).  It doesn't give me any
> feedback on what the size of the image is, so I can't (for example)
> simply space the image over by one image width.
> 
> --


There are two changes: 
- measures are relative to the paper edge rather than printable edge, 
- bottom/right are measured towards bottom/right rather than top/left.

Without the first change, you cannot position a print, say, one cm from
the left paper edge without knowing the size of the margins (which are
printer dependend and subject to change, as we've just seen with the top
margin).

Interpreting the right/bottom as measures towards right/bottom edges
seems much more intuitive to me; but of course I might be in the
minority here. The difference is: I interpret the values as 'borders',
you interpret them as 'coordinates'. With the old interface, you can
deduce the size of the image from the coordinates, but to get the
distance from the right paper edge, you have to know the paper size (and
margins). Now it is the other way 'round.

Maybe the problem is more with the size dialog, which doesn't give a
feedback of the actual size? If we add that, we would have a clean
separation of positioning and sizing.

There might be another problem adding to the issue: Steve has reported
that if he positions an image against the right (printable) edge, it
gets clipped, so something is wrong somewhere. This, of course, would
make the interface look more confusing than it is. Unfortunately, I
cannot reproduce the problem. 

What do other people think ?

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
> 
> _______________________________________________
> Gimp-print-devel mailing list
> Gim...@li...
> http://lists.sourceforge.net/mailman/listinfo/gimp-print-devel

Re: [Gimp-print-devel] New UI stuff

[Sven N. <neu...@un...>]

Hi,

> I find the new way of presenting the image position very confusing.
> It's evidently being presented as the distance from each edge (rather
> than from the (top,left) origin as before).  It doesn't give me any
> feedback on what the size of the image is, so I can't (for example)
> simply space the image over by one image width.

I haven't seen the new UI yet, but IMO there should be an UI element 
that allows you to specify the size of the output directly.  Not by
setting a scaling value or by fiddling around with offsets, but by
setting the size using a pair of GimpSizeEntries. 

I suggest you use a dialog for scaling and positioning similar to 
the GIMP's Canvas Resize dialog. If you show interest in reusing the 
positioning widget from the bottom of the dialog, we might consider 
moving the code into libgimp. As there is already the GAP plug-in 
using it, it would make sense to share the code.

BTW: IMHO specifying the offsets from each corner makes more sense
     then to refer to the top/left corner for all offset values. 
     To be honest, that's what I thought the current dialog was 
     doing, which proves that it's not that intuitive.


Salut, Sven

[Gimp-print-devel] Canon Bubble Jets

[Stephan B. <sc...@st...>]

FYI, recently I inquired about support of gimp-print for the Canon
BJC8200 and offered help with testing. After action by Andy Thaller,
who updated print-canon.c, there is now usable support for this
printer model.

A few details:

- 600x600 DpI and 1200x1200 DpI resolutions, ink type "Black/Color"
(=CMYK), and hybrid FS dithering give good results (300x300 DpI and
other dithering algorithms are possibly also ok, but I didn't try
yet).

- ink type "Photo/Color" (=CMYKcm) produces structures in "colors.tif"
which shouldn't be there and the gray bar at bottom is not gray. Since
I updated only "print-canon.c" in my gimp-print-3.1.4, this result may
be outdated in light of recent progress in other code of gimp-print.

- I'm still struggling with a recommendation for "gamma", "density"
etc settings. Also positioning seems partially problematic.

More will hopefully follow in a few days.

Thanks and regards,

Stephan