[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freedesktop-openicc
Subject:    Re: [Openicc] Print-Color-Pipeline: Learning from TurboPrint and
From:       Chris Murphy <lists () colorremedies ! com>
Date:       2011-02-12 1:20:51
Message-ID: 3003740B-77BC-492E-946C-97E98EA46DDF () colorremedies ! com
[Download RAW message or body]



On Feb 11, 2011, at 7:51 AM, Gerhard Fuernkranz wrote:

> Am 11.02.2011 14:04, schrieb Robert Krawitz:
> > Jan-Peter said -- correctly, in my view -- that concentrating on flat color \
> > documents *as a first step* is the way to go.  It's not the end goal, it's simply \
> > a first step that would achieve something useful as a proof of concept. 
> 
> Robert, what I mean is that enhancing the ghostscript-based PS/PDF
> rendering path with simple (as a first step) color management
> functionality is likely not more expensive either, but results in a more
> general solution (usable implicitly for all document formats, after
> converting them to PS/PDF by filters, which already exist anyway), while
> still fitting well with the PS and PDF color management semantics as
> defined by the PLRM and PDF specs (any attempt to do the color
> management for PS/PDF documents outside the RIP does IMO not fit with
> the color management semantics defined by the PLRM and PDF specs, so I'm
> not sure whether it should be considered an option at all). So I think
> you get more for the money when starting with a PS/PDF-based approach -
> but that's just my humble opinion, of course.

I tend to agree, but I am not familiar with the effort involved in the two proposed \
strategies.

If the flat implementation is "proof of concept" i.e. not encouraged for production \
use, OK, that sounds like a beta. But for subjecting users to this in an actual \
distribution, I would not recommend it. You can't expect applications to treat a \
myriad pile of PDF's of different flavors and specs to unwind those PDFs and turn \
them into normalized (single color space) flat (no live transparency) PDFs. You've \
got to be able to have pass throughs to the print system and let a PDF printing \
system do its job. That's kinda the point is that applications don't have to be \
overly smart about it.

And also, we need to consider the display in all of this as well, the application \
that submits PDF/A to GS and then back to display should be using all of this same \
effort. We are calling it (I'm guilty also) of calling this a printing pipeline, but \
it is a PDF rendering pipeline. It will be used for print and display and it should \
produce the same good results. A display is an output device.

Chris
_______________________________________________
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]