[prev in list] [next in list] [prev in thread] [next in thread]
List: freedesktop-openicc
Subject: Re: [Openicc] Synchronizing printer driver settings and printer profiles
From: edmund ronald <edmundronald () gmail ! com>
Date: 2012-01-13 8:54:10
Message-ID: CAJe_Mai0ocE1jGVB1yvN-MyEZiJhcSrXHz+f0EP=ZNXk6QbgGg () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
On Fri, Jan 13, 2012 at 2:11 AM, Robert Krawitz <rlk@alum.mit.edu> wrote:
> On Fri, 13 Jan 2012 01:11:13 +0100, edmund ronald wrote:
> > I'm not really as smart as y'all about software engineering aspects, but
> > rapidly scanning through some code, it looked like print settings can
> come
> > from a bunch of places, and it would be nice to have a single pinch-point
> > where Gutenprint final settings are known, in order to stream them out to
> > file for keeping as a preset, or in order to be able to write some clean
> > logic to merge a preset with the current user settings.
> >
> > Can such a pinch point be defined to create a single upstream gate for
> > Gutenprint?
>
> There are three places that options come from: the CUPS command line,
> the PPD file, and the CUPS page header.
>
> One possible mechanism would be a CUPS option passed on the command line
> (it might have to be in the PPD file also for CUPS to allow it through,
> I'm not certain) telling Gutenprint to ignore any color-relevant options
> in the PPD file and the CUPS page header, and only use the command line
> options.
> --
> Robert Krawitz <rlk@alum.mit.edu>
>
I think we can say that the XML stuff is in place to make presets work, and
there is a prototype that sometimes works, but for software engineering
reasons making it work reliably requires some form of upstream constraint
of how it is invoked. Without such a constraint, debugging may be too hard.
Edmund
[Attachment #5 (text/html)]
<br><br><div class="gmail_quote">On Fri, Jan 13, 2012 at 2:11 AM, Robert Krawitz \
<span dir="ltr"><<a href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>></span> \
wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px \
#ccc solid;padding-left:1ex"> <div class="HOEnZb"><div class="h5">On Fri, 13 Jan 2012 \
01:11:13 +0100, edmund ronald wrote:<br> > I'm not really as smart as \
y'all about software engineering aspects, but<br> > rapidly scanning through \
some code, it looked like print settings can come<br> > from a bunch of places, \
and it would be nice to have a single pinch-point<br> > where Gutenprint final \
settings are known, in order to stream them out to<br> > file for keeping as a \
preset, or in order to be able to write some clean<br> > logic to merge a preset \
with the current user settings.<br> ><br>
> Can such a pinch point be defined to create a single upstream gate for<br>
> Gutenprint?<br>
<br>
</div></div>There are three places that options come from: the CUPS command line,<br>
the PPD file, and the CUPS page header.<br>
<br>
One possible mechanism would be a CUPS option passed on the command line<br>
(it might have to be in the PPD file also for CUPS to allow it through,<br>
I'm not certain) telling Gutenprint to ignore any color-relevant options<br>
in the PPD file and the CUPS page header, and only use the command line<br>
options.<br>
<div class="HOEnZb"><div class="h5">--<br>
Robert Krawitz <<a \
href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>><br></div></div></blockquote><div><br></div><div>I \
think we can say that the XML stuff is in place to make presets work, and there is a \
prototype that sometimes works, but for software engineering reasons making it work \
reliably requires some form of upstream constraint of how it is invoked. Without such \
a constraint, debugging may be too hard.</div> <div><br></div><div>Edmund</div></div>
_______________________________________________
openicc mailing list
openicc@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/openicc
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic