<br><br><div class="gmail_quote">On Fri, Jan 13, 2012 at 2:11 AM, Robert Krawitz <span dir="ltr">&lt;<a href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>&gt;</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>
&gt; I&#39;m not really as smart as y&#39;all about software engineering aspects, but<br>
&gt; rapidly scanning through some code, it looked like print settings can come<br>
&gt; from a bunch of places, and it would be nice to have a single pinch-point<br>
&gt; where Gutenprint final settings are known, in order to stream them out to<br>
&gt; file for keeping as a preset, or in order to be able to write some clean<br>
&gt; logic to merge a preset with the current user settings.<br>
&gt;<br>
&gt; Can such a pinch point be defined to create a single upstream gate for<br>
&gt; 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&#39;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                                     &lt;<a href="mailto:rlk@alum.mit.edu">rlk@alum.mit.edu</a>&gt;<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>