[Openicc] Printing profiling targets - state of implementation?

[edmund ronald]

Is the idea bad because it would place additional burden on the CUPS
maintainers, or is it bad for some architectural reason?
My reasoning is that if data cannot be passed via the options (too big)
then it needs to be put in a file somewhere, if PPDs are going away then
the PPD file is a bad place, and another file means a security headache
etc, so why not squirrel the stuff away via CUPS.

Edmund


On Wed, May 22, 2013 at 5:45 PM, Michael Sweet <msweet at apple.com> wrote:

> Or not. :)
>
>
> On 2013-05-22, at 11:38 AM, edmund ronald <edmundronald at gmail.com> wrote:
>
> If all else fails, maybe the local CUPS web server can store and serve XML
> inking data and even profiles associated with a media-type keyword :)
>
> Edmund
>
>
> On Wed, May 22, 2013 at 3:15 PM, Michael Sweet <msweet at apple.com> wrote:
>
>> Edmund,
>>
>> On 2013-05-22, at 5:18 AM, edmund ronald <edmundronald at gmail.com> wrote:
>>
>> ...
>> I think this issue of making inking parameters first order citizens was
>> discussed at length on this list - what mechanism is going to be used to
>> allow people to load and save queue inking parameters?
>>
>>
>> Yes, this issue has been discussed here, at OpenPrinting meetings, and in
>> PWG meetings. The consensus so far is that this isn't something we can
>> easily standardize - different drivers do things wildly differently, and
>> what would work for Gutenprint wouldn't work for, say, the old CUPS DDK
>> drivers.
>>
>> My recommended solution is to associate linearization curves and other
>> driver-specific data with media type and ink type names - this provides
>> access to data that has been stored in a PPD file or other driver-specific
>> location through a simple keyword/string (think: a preset or saved setting
>> name), and that can subsequently be used when printing targets for
>> profiling and (finally) printing documents using the generated profile.
>> This is also consistent across drivers and printers.
>>
>> The initial ink characterization will likely need to be done using a
>> driver-specific utility unless the stakeholders can agree on a generic set
>> of options that satisfy their requirements.  However, I know that in the
>> past Robert has claimed the current option/attribute support in CUPS was
>> insufficient to supply linearization curves with a print job, so that level
>> of integration/support may not be possible.
>>
>>  _________________________________________________________
>> Michael Sweet, Senior Printing System Engineer, PWG Chair
>>
>>
>> _______________________________________________
>> openicc mailing list
>> openicc at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/openicc
>>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
>
> _________________________________________________________
> Michael Sweet, Senior Printing System Engineer, PWG Chair
>
>
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/openicc/attachments/20130522/f15b99a1/attachment-0001.html>