[Openicc] colord Printing Plans, CPD and Gutenprint role of PPD

[edmund ronald]

Chris, Graeme,

 My point is that
 A) Gutenprint needs come modernization to integrate with a color
managed workflow, but we know what that is (move settings into
bundles)
 and can simply GET IT DONE right now.
 B) If you guys continue to be sidetracked by red herrings and
theological discussions on the most complex and badly defined
super-pro workflows, then yes, *I* will actually sit down and do a
dirty hack so that users can print by whipping up a minimal workflow
for sRGB. That doesn't mean I like the idea, it doesn't mean I am not
a total idiot (I have no understanding of color compared to you guys),
it does mean that users need a way to print, that Gutenprint is
presently the main backend for putting physical ink on paper, that the
manual tunings will be obsolete because Robert will stop creating them
because of the workload, that it is time to crowdsource for new media,
and that yes, a hack which allows people to print will be at least as
useful as endless discussions.
C) I would suggest that you guys Graeme and Chris, who have great
color expertise, suggest a design for a minimal system that can be
brought up to provide consumer printing and extensibility to all the
pro needs, and yes, that CAN BE IMPLEMENTED WITHOUT THEOLOGICAL
DISCUSSIONS and that WORKS WITH SOME EXTANT TOOLS. In other words a
reference implementation.
D. Not that I will help you get any work done, apart from helping
making sure that the Gutenprint parts are designed right. But if you
guys don't do anything I guarantee I will sit down and make a hack,
and it will work, and its existence will embarrass you to death. I
wrote my first printer driver (a dvi tool for an experimental Canon
print engine with a hacked controller) back in 1984.

Edmund

Edmund


On Tue, Mar 1, 2011 at 5:54 AM, Chris Murphy <lists at colorremedies.com> wrote:
>
>
> On Feb 28, 2011, at 6:11 PM, Graeme Gill wrote:
>
>> edmund ronald wrote:
>>> I will *myself* write a module that assumes that everything sent to
>>> its is sRGB, apart from when it is clearly DeviceRGB or DeviceCMYK.
>>> This module will ensure that sRGB files are printed decently and solve
>>> the consumer printing issues.
>>
>> If you want a printing system right out of the 1980's, go right ahead.
>
> Well, actually 1996. However, we do have a rather substantial elephant in the room regarding sRGB's correlation to actual display device behavior.
>
>
> Chris Murphy
> _______________________________________________
> openicc mailing list
> openicc at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/openicc
>