Re: [Gimp-print-devel] 5.1.0 - CUPS Print Margins

[Todd D. <Tod...@ss...>]

Robert L Krawitz wrote:
>    Date: Tue, 27 Feb 2007 08:52:16 +0100 (CET)
>    From: "Lorenzo M. Catucci" <lo...@sa...>
> 
>    On Mon, 26 Feb 2007, Robert L Krawitz wrote:
> 
>    RLK>    Date: Mon, 26 Feb 2007 17:05:28 +0100 (CET)
>    RLK>    From: "Lorenzo M. Catucci" <lo...@sa...>
>    RLK> 
>    RLK>    I jump in this thread just to make a small suggestion: if at all
>    RLK>    possible, I think the "right" default would be to tell CUPS clients
>    RLK>    the truth about the imageable area, and then crop if someone tries
>    RLK>    to print outside it.
>    RLK> 
>    RLK> There's no problem on printers that only support one imageable area
>    RLK> (margins).  The issue is with printers that support two (or more) sets
>    RLK> of margins (typically a borderless or full bleed mode in addition to a
>    RLK> mode with borders).  Any one paper size can only advertise one
>    RLK> imageable area, so we either have to offer twice as many page sizes,
>    RLK> only offer borderless printing (which is usually slower, since the
>    RLK> printer has to measure the paper, and puts more wear on the printer,
>    RLK> since any ink bleed goes into the printer mechanism), don't offer
>    RLK> borderless printing at all, or do some kind of subterfuge.
>    RLK> 
> 
>    Now I'll make myself un-popular, and just try asking what harm
>    would do putting explicit page sizes for full bleed and standard
>    printing, other than making for a page size list twice as long. I
>    for myself wouldn' even object to a need for two print queues, one
>    with full-bleed margins and one with standard margins, or anything
>    the like. As you just said, I'd try to save both the wear to the
>    printer and the extra setup time for when I'm really printing
>    photos, while still being able to print a CAD output with real
>    1:100 scales and not a physical 1:104 with a reading guide of
>    1:100.
> 
> The problem is that the number of paper sizes is already very large --
> the Epson R1800, for example, lists 80 separate paper sizes.  Doubling
> this number would make for a very unpleasant experience.  Furthermore,
> I don't see a way to do this for custom media sizes, since there seems
> to be only one entry for *HWMargins.
> 

For who and how often would there be an unpleasant experience?
On the machine where I have the R800 I knew that having the users go in and 
set ALL the differences that we wanted between letter and CD printing each 
time they wanted to change would
A: be very error prone.
B: require them having root (IIRC the CUPS interface).
C: confuse the users I have.

My solution was to have two queues,
one for low resolution Letter size (named Letter) for text printing,
and one medium resolution CD size (named CD) for label making.

So in my situation it would (_maybe_) be an unpleasant experience once, each 
time I upgrade either the OS or gutenprint, and it would always be me the 
admin who had the experience.

> You can always modify your own PPD file appropriately if you like.  I
> don't think there really is a way to do this that will work optimally
> for all cases; this seems like the best compromise I've come up with
> to date.
> 


Been there, done that, I really did not understand what I was doing or why _I_ 
had to do it that way (see my first posts to this list).  I would much rather 
have massive options list to deal with (in something that is supposed to just 
work) than to have to learn a whole new language.

-- 
Todd Denniston
Crane Division, Naval Surface Warfare Center (NSWC Crane)
Harnessing the Power of Technology for the Warfighter