W3C home > Mailing lists > Public > www-style@w3.org > June 2013

Re: CSS overprinting

From: Rik Cabanier <cabanier@gmail.com>
Date: Tue, 18 Jun 2013 20:17:02 -0700
Message-ID: <CAGN7qDCH1ND2=Bj76f9y2xfhBkeaQit9gEMtY3GiV+XHVnPkPA@mail.gmail.com>
To: liam@w3.org
Cc: Lea Verou <lea@w3.org>, www-style list <www-style@w3.org>
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.

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

> On Tue, 2013-06-18 at 17:39 -0400, Lea Verou wrote:
>
> > Iím not sure how overprint could be controlled, since it could be for
> > the entire element, or just the text etc. It looks more like a
> > blending mode.
>
> +1 to thinking about this.
>
> Related, there's also undercolour removal --
>
> Typically an offset lithography press (the sort used for most commercial
> bulk printing) has a limit on the amount of ink at any one place. Often
> a given CMYK value with cyan, magenta and yellow all non-zero but black
> zero can be represented (or approximated) by adding black and reducing
> the other inks in a process known as undercolour removal.
>
> There's also trapping, or making narrow corners wider to avoid getting
> blobs of ink caught in them. The "N" of Franklin Gothic has a clear
> example of allowing for this, giving it a very different look on
> displays than on printed paper.
>
> These things are usually done by specialist "preflight" software, or by
> e.g. photoshop plugins. Other things not handled currently by CSS
> include
> . specifying bleed and crop
> . placing colour registration marks outside the crop area
> . imposition (folding printed sheets into pages before the cropper uses
> the crop marks to cut the edges off so you can open the book)
> . binding (long edge or short edge? hardback or paperback?...)
> . spot colours - it's common to print with e.g. CMYK + one or two others
> for highlights, e.g. a particular orange.
> . duotones and other non-CMYK non-RGB models, often with different
> colour gamuts
> . fold-outs, changing paper size / orientation part-way through a job
> (even multi-tray office printers can do this)
> . folding, envelope stuffing (e.g. for mass mailers, bank statement etc)
>
> Job Definition Format (JDF) does some of this, and you can do manual
> overprint in SVG of course, with more or less effort.
>
> >  However, if we add a blending mode for it, what will it do for RGB?
> > I'm not sure if overprinting is even a thing in RGB.
> I don't think so. Light-based displays don't have the same blending
> characteristics :)
>
> This sort of issue - the role of CSS in printing - is definitely a topic
> for the Workshop we're holding in Paris this September.
>
> I'm eager to see solutions for overprinting, as well as for all the
> other issues and I don't want to suggest "don't do one unless they are
> all done."  I still think the CSS WG needs to have some separate task
> forces, or maybe just interest groups and/or community groups, to split
> off some of this necessary work.
>
> In the meantime, note that because of out-of-line rendering,
> overprinting is asynchronous to the element tree. I agree it's like
> compositing, but of the whole rendered page.
>
> Liam
>
> --
> Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
> Pictures from old books: http://fromoldbooks.org/
> Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
>
>
>
Received on Wednesday, 19 June 2013 03:17:30 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC