Re: CSS overprinting

On Tue, Jun 18, 2013 at 11:25 PM, Liam R E Quin <liam@w3.org> wrote:

> On Tue, 2013-06-18 at 20:17 -0700, Rik Cabanier wrote:
> > This is indeed all true to create a prepress workflow.
> > You forgot to include filter, blending and simple opacity.
> :-)
>
> > These make
> > printing at high quality fiendishly hard. (It took us at Adobe close to a
> > decade to get it right)
> >
> > I think what is needed, is a way to reliably export to a PDF file with
> CMYK
> > and spot colors from a web page. Prepress systems and applications (such
> as
> > InDesign, QuarkXpress or Acrobat) have all the logic to produce the right
> > output.
> > Putting all this logic in the browser is unlikely to happen.
>
> Long term I see InDesign & Quark moving into the browser, which becomes
> an operating system with a million lines of code. I'm not sure that I
> like this vision particularly but it's what's happening.
>
> In that vision yes, the browser does the prepress stuff too.
>

Maybe eventually.
However, if you want to get something in a couple of years, it would be
better to produce PDF/X since it's the standard input format for prepress
systems.
So, the browser would generate a prepress-ready pdf along with a JDF that
describes what you want to do with separations and color.


>
> Right now, though, I'm aiming for
> . CSS powerful enough to describe the processes (so that e.g. Quark or
> InDesign could handle it, or Antenna House or RenderX or...)
> . web browsers can do basic typography enough for most simple
> publications, including print-on-demand book kiosks that are springing
> up
> . another application can take over for higher end work, e.g. where
> people want "advanced" things like page numbers :D yes, as long as the
> hooks are there in the markup and the CSS
> . we must not do anything now that would make it difficult or impossible
> to do the right thing later.
>
> At any rate I think we both agree that overprinting is a prepress
> function today.


I agree.