Gutenprint - Top Quality Printer Drivers

On Tue, 13 Sep 2005 17:41:34 +0200
Andreas Kemnade <akemnade@...> wrote:


> What are the things which have to be cleaned up?
> Image positioning is a problem. I know how to do it in postscript
> but I don't know yet what the proper way is to do it in gimp-print.
> A way would be to add a BeginPage procedure in the ppd file in
> the dictionary for setpagedevice.

To be more precise: gimp-print should be able to place a square with
coordinates (0,0)-(cd radius *2, cd radius *2) to the right position.

Greetings
Andreas Kemnade

From: Andreas Kemnade <akemnade@...>
   Date: Tue, 13 Sep 2005 17:41:34 +0200

   Hi,

   i have a patch to enable the canon driver to use the cd tray of
   the pixma ip 4000 so that you can print on inkjet printable cds:

   http://auriga.wearlab.de/~andi/canon/pixma-cd.diff

   What are the things which have to be cleaned up?  Image positioning
   is a problem. I know how to do it in postscript but I don't know
   yet what the proper way is to do it in gimp-print.  A way would be
   to add a BeginPage procedure in the ppd file in the dictionary for
   setpagedevice.

Gutenprint is capable of doing this by means of supplying a mask to
the dither code; the Canon driver needs to be modified to use this.
The Epson driver already does this.

   I have modified a ppd for the gs-uniprint driver for the bjc8200 to
   do that (it should also du proper clipping to the cd borders):
   http://auriga.wearlab.de/~andi/canon/pixma-cd.ppd.  To use that
   ppd, you need http://auriga.wearlab.de/~andi/canon/bj8cd06n.upp and
   you'll get a not very nice quality (but that was the reason why
   gimp-print exists).

-- 
Robert Krawitz                                     <rlk@...>

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

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

On Thu, 15 Sep 2005 21:11:24 -0400
Robert L Krawitz <rlk@...> wrote:

>    From: Andreas Kemnade <akemnade@...>
>    Date: Tue, 13 Sep 2005 17:41:34 +0200
> 
>    Hi,
> 
>    i have a patch to enable the canon driver to use the cd tray of
>    the pixma ip 4000 so that you can print on inkjet printable cds:
> 
>    http://auriga.wearlab.de/~andi/canon/pixma-cd.diff
> 
>    What are the things which have to be cleaned up?  Image positioning
>    is a problem. I know how to do it in postscript but I don't know
>    yet what the proper way is to do it in gimp-print.  A way would be
>    to add a BeginPage procedure in the ppd file in the dictionary for
>    setpagedevice.
> 
> Gutenprint is capable of doing this by means of supplying a mask to
> the dither code; the Canon driver needs to be modified to use this.
> The Epson driver already does this.
> 

I'm not sure whether you understand me correctly.
There is a tray with a place where I can put the cd in.
The printer can print everywhere on this tray (and can make it dirty).
With the patch as is, you have to produce an image with some white
area surrounding the cd. That's also what you have to do in windows.
The manual also says that when you don't use the supplied program
to print on cd but use another graphics program, you can make the
tray dirty.
An example file is at http://auriga.wearlab.de/~andi/canon/cd-label.eps
which produces two rings, one near the outer border of the cd
and one near the inner border.

I personally would like be able to just send a rectangle to the printer,
containing the cd image, nothing more and I want the driver to take
care that nothing gets dirty. But I consider this as a second step,
not first priority. For now, I have modified the ppd generated
by gutenprint by hand. That's enough for my personal need for now.

But first I would like to see the ability to select the cd tray
as media source in cvs.
in cvs. And I guess as most maintainers do, you prefer
applying small patches rather than applying big patches.
So I guess it is better to not include features now,
which even the windows driver does not have, to keep the patch
as small as possible.
 So what would you like to see cleaned up in the patch before
you will commit it? Replacing the media_sources-Array with
something model specific?

Greetings
Andreas Kemnade

Date: Fri, 16 Sep 2005 16:10:03 +0200
   From: Andreas Kemnade <akemnade@...>
   Cc: gimp-print-devel@...

   On Thu, 15 Sep 2005 21:11:24 -0400
   Robert L Krawitz <rlk@...> wrote:

   >    From: Andreas Kemnade <akemnade@...>
   >    Date: Tue, 13 Sep 2005 17:41:34 +0200
   > 
   >    Hi,
   > 
   >    i have a patch to enable the canon driver to use the cd tray of
   >    the pixma ip 4000 so that you can print on inkjet printable cds:
   > 
   >    http://auriga.wearlab.de/~andi/canon/pixma-cd.diff
   > 
   >    What are the things which have to be cleaned up?  Image positioning
   >    is a problem. I know how to do it in postscript but I don't know
   >    yet what the proper way is to do it in gimp-print.  A way would be
   >    to add a BeginPage procedure in the ppd file in the dictionary for
   >    setpagedevice.
   > 
   > Gutenprint is capable of doing this by means of supplying a mask to
   > the dither code; the Canon driver needs to be modified to use this.
   > The Epson driver already does this.

   I'm not sure whether you understand me correctly.
   There is a tray with a place where I can put the cd in.
   The printer can print everywhere on this tray (and can make it dirty).
   With the patch as is, you have to produce an image with some white
   area surrounding the cd. That's also what you have to do in windows.
   The manual also says that when you don't use the supplied program
   to print on cd but use another graphics program, you can make the
   tray dirty.

Well, then Gutenprint can do better :-)

   An example file is at
   http://auriga.wearlab.de/~andi/canon/cd-label.eps which produces
   two rings, one near the outer border of the cd and one near the
   inner border.

   I personally would like be able to just send a rectangle to the
   printer, containing the cd image, nothing more and I want the
   driver to take care that nothing gets dirty. But I consider this as
   a second step, not first priority. For now, I have modified the ppd
   generated by gutenprint by hand. That's enough for my personal need
   for now.

It can already send a rectangle.  Why do you need to modify the PPD
file?

   But first I would like to see the ability to select the cd tray as
   media source in cvs.  in cvs. And I guess as most maintainers do,
   you prefer applying small patches rather than applying big patches.
   So I guess it is better to not include features now, which even the
   windows driver does not have, to keep the patch as small as
   possible.  So what would you like to see cleaned up in the patch
   before you will commit it? Replacing the media_sources-Array with
   something model specific?

1) Sascha Sommer expressed interest in maintaining the Canon driver;
   I'd like to give him right of first refusal on this patch.

2) Your proposal is reasonable (to first enable printing to CD and
   then to do the mask).  However, since the driver is fundamentally
   capable of masking the CD off, I would like to have it do this mask
   operation before releasing it.  There's no reason to unnecessarily
   dirty your CD tray, just because the Windows driver isn't smart
   enough to do it right.

-- 
Robert Krawitz                                     <rlk@...>

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

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

Hi,

>    But first I would like to see the ability to select the cd tray as
>    media source in cvs.  in cvs. And I guess as most maintainers do,
>    you prefer applying small patches rather than applying big patches.
>    So I guess it is better to not include features now, which even the
>    windows driver does not have, to keep the patch as small as
>    possible.  So what would you like to see cleaned up in the patch
>    before you will commit it? Replacing the media_sources-Array with
>    something model specific?
>
> 1) Sascha Sommer expressed interest in maintaining the Canon driver;
>    I'd like to give him right of first refusal on this patch.
>

First of all: It is very cool that there is another person working on the 
pixma support. We can definitly need help here.
I think the patch looks ok, apart from maybe a few mior coding style and 
tab/spaces issues. I'll try to fix these before the commit. However the 
coding style should get documented somewhere, or is it already?
Imho we don't need a model specific media_sources-Array for the current 
driver. However this is something to think about when we do some general 
cleanup.

> 2) Your proposal is reasonable (to first enable printing to CD and
>    then to do the mask).  However, since the driver is fundamentally
>    capable of masking the CD off, I would like to have it do this mask
>    operation before releasing it.  There's no reason to unnecessarily
>    dirty your CD tray, just because the Windows driver isn't smart
>    enough to do it right.

I agree here. Andreas, I think the relevant part is in the escp2_print_data 
function in print_escp2.c. There a  cd_mask gets created which is then passed 
to  stp_dither. Doesn't look to difficult to port, it would be nice if you 
could add support for this.

Regards

Sascha

On Fri, 16 Sep 2005 19:15:36 -0400
Robert L Krawitz <rlk@...> wrote:


> 
>    An example file is at
>    http://auriga.wearlab.de/~andi/canon/cd-label.eps which produces
>    two rings, one near the outer border of the cd and one near the
>    inner border.
> 
>    I personally would like be able to just send a rectangle to the
>    printer, containing the cd image, nothing more and I want the
>    driver to take care that nothing gets dirty. But I consider this as
>    a second step, not first priority. For now, I have modified the ppd
>    generated by gutenprint by hand. That's enough for my personal need
>    for now.
> 
> It can already send a rectangle.  Why do you need to modify the PPD
> file?
> 
I'm doing all the magic here to move the image to the right place
and do the clipping:
*PageSize CD/CD: "<</PageSize[595 842]/ImagingBBox null 
/BeginPage {
 10 dict begin
  /cdmittexinit { 731 72 300 div mul } bind def
  /cdmitteyinit { 1167 72 300 div mul } bind def /cdradiusiinit { 225 72 300 div
 mul 
  } bind def /cdradiusainit { 696 72 300 div mul } bind def
  /clipcdinit { cdmittexinit cdmitteyinit translate 0 0 cdradiusiinit 0 360 arc
   0 cdradiusainit cdradiusiinit sub rlineto 1 -1 scale 0 0 cdradiusainit 0 360 
arc clip newpath 1 -1 scale } bind def
   40 72 300 div mul 620 72 300 div mul translate clipcdinit
       cdradiusainit -1 mul dup translate
        end  }  >>setpagedevice"
*CloseUI: *PageSize

There are mainly historic reasons for this way of doing things. First,
I prepended the postscript snippet from above to everything I wanted
to print on cd.
First, the way of printing for me was: postscript file ->imgtops -type png -density 300
-> png file -> bjfilterpixusip4100 (from the properitary japanese driver) -> hexdump -> 
do a sed to do search&replace on it -> hex to binary -> /dev/usb/lp0

Putting the postscript snippet into the ppd file was just
 the easiest way to put it somehow into the driver.
And this was the easiest way to do so without having to understand
all of the media size/margins/imageable area stuff.

But I'll try to understand things to use that masking code.

Greetings
Andreas Kemnade

Note that data workflows in CUPS can be without PostScript and then your 
PostScript code does not get executed. This happens if you print an 
image file (PNG, TIFF, JPG, ...) on a CUPS queue with a CUPS raster 
driver. Then you get the following two filter calls:

       imagetoraster        rastertoprinter
Image ------------>  CUPS  --------------> Canon
                     raster

So your version would work fine with the IJS incarnation of Gutenprint 
because the IJS driver NEEDS PostScript as input. The native CUPS driver 
or printing from the GIMP will not necessarily execute your code.

    Till


Andreas Kemnade wrote:
> On Fri, 16 Sep 2005 19:15:36 -0400
> Robert L Krawitz <rlk@...> wrote:
> 
> 
> 
>>   An example file is at
>>   http://auriga.wearlab.de/~andi/canon/cd-label.eps which produces
>>   two rings, one near the outer border of the cd and one near the
>>   inner border.
>>
>>   I personally would like be able to just send a rectangle to the
>>   printer, containing the cd image, nothing more and I want the
>>   driver to take care that nothing gets dirty. But I consider this as
>>   a second step, not first priority. For now, I have modified the ppd
>>   generated by gutenprint by hand. That's enough for my personal need
>>   for now.
>>
>>It can already send a rectangle.  Why do you need to modify the PPD
>>file?
>>
> 
> I'm doing all the magic here to move the image to the right place
> and do the clipping:
> *PageSize CD/CD: "<</PageSize[595 842]/ImagingBBox null 
> /BeginPage {
>  10 dict begin
>   /cdmittexinit { 731 72 300 div mul } bind def
>   /cdmitteyinit { 1167 72 300 div mul } bind def /cdradiusiinit { 225 72 300 div
>  mul 
>   } bind def /cdradiusainit { 696 72 300 div mul } bind def
>   /clipcdinit { cdmittexinit cdmitteyinit translate 0 0 cdradiusiinit 0 360 arc
>    0 cdradiusainit cdradiusiinit sub rlineto 1 -1 scale 0 0 cdradiusainit 0 360 
> arc clip newpath 1 -1 scale } bind def
>    40 72 300 div mul 620 72 300 div mul translate clipcdinit
>        cdradiusainit -1 mul dup translate
>         end  }  >>setpagedevice"
> *CloseUI: *PageSize
> 
> There are mainly historic reasons for this way of doing things. First,
> I prepended the postscript snippet from above to everything I wanted
> to print on cd.
> First, the way of printing for me was: postscript file ->imgtops -type png -density 300
> -> png file -> bjfilterpixusip4100 (from the properitary japanese driver) -> hexdump -> 
> do a sed to do search&replace on it -> hex to binary -> /dev/usb/lp0
> 
> Putting the postscript snippet into the ppd file was just
>  the easiest way to put it somehow into the driver.
> And this was the easiest way to do so without having to understand
> all of the media size/margins/imageable area stuff.
> 
> But I'll try to understand things to use that masking code.
> 
> Greetings
> Andreas Kemnade
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> Gimp-print-devel mailing list
> Gimp-print-devel@...
> https://lists.sourceforge.net/lists/listinfo/gimp-print-devel
> 
>

On Sat, 17 Sep 2005 09:24:33 +0200
Sascha Sommer <saschasommer@...> wrote:


> 
> I agree here. Andreas, I think the relevant part is in the escp2_print_data 
> function in print_escp2.c. There a  cd_mask gets created which is then passed 
> to  stp_dither. Doesn't look to difficult to port, it would be nice if you 
> could add support for this.
> 
http://auriga.wearlab.de/~andi/pixma-cd2.diff

Questions: Should the magic numbers be configurable (CD_X_OFFSET and CD_Y_OFFSET)?

The treatment of offset in canon_write() seems to be buggy.
To me it looks as if the 5 pixel in one byte stuff seems to be the problem.
The different inks get split. You see it in the output from
your parse_pixma tool.
I tried to fix that in the diff and it seems to work with first tests,
but after a misplaced print on the cd tray I found out that
CD_X_OFFSET should be zero (I have probably
messed with the margins before). So the bug is not important now
if the offsets are not configurable (and I do not understand it fully right now).

Now it works with an unmodified ppd with media source="CD Tray" and Media size="CD 5 inch".

Greetings
Andreas Kemnade

Hi,

On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
> On Sat, 17 Sep 2005 09:24:33 +0200
>
> Sascha Sommer <saschasommer@...> wrote:
> > I agree here. Andreas, I think the relevant part is in the
> > escp2_print_data function in print_escp2.c. There a  cd_mask gets created
> > which is then passed to  stp_dither. Doesn't look to difficult to port,
> > it would be nice if you could add support for this.
>
> http://auriga.wearlab.de/~andi/pixma-cd2.diff
>
> Questions: Should the magic numbers be configurable (CD_X_OFFSET and
> CD_Y_OFFSET)?
>

No idea. Whit your settings the hole is at the wrong position here. 
I'll try to find out why.

> The treatment of offset in canon_write() seems to be buggy.
> To me it looks as if the 5 pixel in one byte stuff seems to be the problem.
> The different inks get split. You see it in the output from
> your parse_pixma tool.
> I tried to fix that in the diff and it seems to work with first tests,
> but after a misplaced print on the cd tray I found out that
> CD_X_OFFSET should be zero (I have probably
> messed with the margins before). So the bug is not important now
> if the offsets are not configurable (and I do not understand it fully right
> now).
>

Looks like the bug is also noticeable when you use the gimp-print plugin.
I'm not sure if your fix always does the right thing when it ignores the 
bitoffset for the 5 pixel in 1 byte compression. There might also be a bug in 
the current use of canon_shift_buffer where the most right pixels get 
ignored.

I tryed to fix this in the attached patch. However it does not make the code 
cleaner and I'm not sure if it is always correct.

Regards

Sascha

On Thursday 22 September 2005 22:41, Sascha Sommer wrote:
> Hi,
>
> On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
> > On Sat, 17 Sep 2005 09:24:33 +0200
> >
> > Sascha Sommer <saschasommer@...> wrote:
> > > I agree here. Andreas, I think the relevant part is in the
> > > escp2_print_data function in print_escp2.c. There a  cd_mask gets
> > > created which is then passed to  stp_dither. Doesn't look to difficult
> > > to port, it would be nice if you could add support for this.
> >
> > http://auriga.wearlab.de/~andi/pixma-cd2.diff
> >
> > Questions: Should the magic numbers be configurable (CD_X_OFFSET and
> > CD_Y_OFFSET)?
>
> No idea. Whit your settings the hole is at the wrong position here.
> I'll try to find out why.
>

Hm, how did you print the label? I now found out that when printing directly 
from gimp everything is fine, but when I print from some kde app the margins 
are wrong. Even though the numbers are correct in the ppd.
Maybe it would be better to have the CD_X_OFFSET and Y_OFFSET absolute, not 
relative to the margins.

Also note that your patch is not freeing the cd_mask memory.

Regards

Sascha

> > The treatment of offset in canon_write() seems to be buggy.
> > To me it looks as if the 5 pixel in one byte stuff seems to be the
> > problem. The different inks get split. You see it in the output from
> > your parse_pixma tool.
> > I tried to fix that in the diff and it seems to work with first tests,
> > but after a misplaced print on the cd tray I found out that
> > CD_X_OFFSET should be zero (I have probably
> > messed with the margins before). So the bug is not important now
> > if the offsets are not configurable (and I do not understand it fully
> > right now).
>
> Looks like the bug is also noticeable when you use the gimp-print plugin.
> I'm not sure if your fix always does the right thing when it ignores the
> bitoffset for the 5 pixel in 1 byte compression. There might also be a bug
> in the current use of canon_shift_buffer where the most right pixels get
> ignored.
>
> I tryed to fix this in the attached patch. However it does not make the
> code cleaner and I'm not sure if it is always correct.
>

Applied.

Sascha

On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
> On Sat, 17 Sep 2005 09:24:33 +0200
>
> Sascha Sommer <saschasommer@...> wrote:
> > I agree here. Andreas, I think the relevant part is in the
> > escp2_print_data function in print_escp2.c. There a  cd_mask gets created
> > which is then passed to  stp_dither. Doesn't look to difficult to port,
> > it would be nice if you could add support for this.
>
> http://auriga.wearlab.de/~andi/pixma-cd2.diff
>
> Questions: Should the magic numbers be configurable (CD_X_OFFSET and
> CD_Y_OFFSET)?
>
> The treatment of offset in canon_write() seems to be buggy.
> To me it looks as if the 5 pixel in one byte stuff seems to be the problem.
> The different inks get split. You see it in the output from
> your parse_pixma tool.
> I tried to fix that in the diff and it seems to work with first tests,
> but after a misplaced print on the cd tray I found out that
> CD_X_OFFSET should be zero (I have probably
> messed with the margins before). So the bug is not important now
> if the offsets are not configurable (and I do not understand it fully right
> now).
>
> Now it works with an unmodified ppd with media source="CD Tray" and Media
> size="CD 5 inch".
>

Applied.

Sascha

On Tuesday 27 September 2005 18:25, Sascha Sommer wrote:
> On Thursday 22 September 2005 22:41, Sascha Sommer wrote:
> > Hi,
> >
> > On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
> > > On Sat, 17 Sep 2005 09:24:33 +0200
> > >
> > > Sascha Sommer <saschasommer@...> wrote:
> > > > I agree here. Andreas, I think the relevant part is in the
> > > > escp2_print_data function in print_escp2.c. There a  cd_mask gets
> > > > created which is then passed to  stp_dither. Doesn't look to
> > > > difficult to port, it would be nice if you could add support for
> > > > this.
> > >
> > > http://auriga.wearlab.de/~andi/pixma-cd2.diff
> > >
> > > Questions: Should the magic numbers be configurable (CD_X_OFFSET and
> > > CD_Y_OFFSET)?
> >
> > No idea. Whit your settings the hole is at the wrong position here.
> > I'll try to find out why.
>
> Hm, how did you print the label? I now found out that when printing
> directly from gimp everything is fine, but when I print from some kde app
> the margins are wrong. Even though the numbers are correct in the ppd.
> Maybe it would be better to have the CD_X_OFFSET and Y_OFFSET absolute, not
> relative to the margins.
>

Replying the 3rd time to the same mail...
Ok the kde problem is actually a feature. When you manually adjust the margins 
it works just fine. I therefore applied the patch as is.

Regards

Sascha

On Tue, 27 Sep 2005 18:25:45 +0200
Sascha Sommer <saschasommer@...> wrote:

> On Thursday 22 September 2005 22:41, Sascha Sommer wrote:
> > Hi,
> >
> > On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
> > > On Sat, 17 Sep 2005 09:24:33 +0200
> > >
> > > Sascha Sommer <saschasommer@...> wrote:
> > > > I agree here. Andreas, I think the relevant part is in the
> > > > escp2_print_data function in print_escp2.c. There a  cd_mask gets
> > > > created which is then passed to  stp_dither. Doesn't look to difficult
> > > > to port, it would be nice if you could add support for this.
> > >
> > > http://auriga.wearlab.de/~andi/pixma-cd2.diff
> > >
> > > Questions: Should the magic numbers be configurable (CD_X_OFFSET and
> > > CD_Y_OFFSET)?
> >
> > No idea. Whit your settings the hole is at the wrong position here.
> > I'll try to find out why.
> >
> 
> Hm, how did you print the label? I now found out that when printing directly 
> from gimp everything is fine, but when I print from some kde app the margins 
> are wrong. Even though the numbers are correct in the ppd.
> Maybe it would be better to have the CD_X_OFFSET and Y_OFFSET absolute, not 
> relative to the margins.
> 
I'm using bash scripts to create an eps file from a background image,
a track list (in a text file), the audio files (to print track length and total
length on the cd).

Greetings
Andreas Kemnade

From: Sascha Sommer <saschasommer@...>
   Date: Wed, 28 Sep 2005 18:10:13 +0200

   On Tuesday 27 September 2005 18:25, Sascha Sommer wrote:
   > On Thursday 22 September 2005 22:41, Sascha Sommer wrote:
   > > Hi,
   > >
   > > On Monday 19 September 2005 00:24, Andreas Kemnade wrote:
   > > > On Sat, 17 Sep 2005 09:24:33 +0200
   > > >
   > > > Sascha Sommer <saschasommer@...> wrote:
   > > > > I agree here. Andreas, I think the relevant part is in the
   > > > > escp2_print_data function in print_escp2.c. There a  cd_mask gets
   > > > > created which is then passed to  stp_dither. Doesn't look to
   > > > > difficult to port, it would be nice if you could add support for
   > > > > this.
   > > >
   > > > http://auriga.wearlab.de/~andi/pixma-cd2.diff
   > > >
   > > > Questions: Should the magic numbers be configurable (CD_X_OFFSET and
   > > > CD_Y_OFFSET)?
   > >
   > > No idea. Whit your settings the hole is at the wrong position here.
   > > I'll try to find out why.
   >
   > Hm, how did you print the label? I now found out that when
   > printing directly from gimp everything is fine, but when I print
   > from some kde app the margins are wrong. Even though the numbers
   > are correct in the ppd.  Maybe it would be better to have the
   > CD_X_OFFSET and Y_OFFSET absolute, not relative to the margins.

   Replying the 3rd time to the same mail...  Ok the kde problem is
   actually a feature. When you manually adjust the margins it works
   just fine. I therefore applied the patch as is.

The Epson family driver takes care of the margins for printing to
CD's; it advertises zero margin on the top and left of the CD and does
the necessary conversion to the printer's reality internally.

-- 
Robert Krawitz                                     <rlk@...>

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

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