W3C home > Mailing lists > Public > www-svg@w3.org > August 2011

RE: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color

From: Alex Danilo <alex@abbra.com>
Date: Tue, 02 Aug 2011 17:28:51 +1000
Message-Id: <34IAPL.WRKSPE6U4XH4@abbra.com>
To: Nick Hofstede <Nick.Hofstede@inventivegroup.com>
Cc: Rik Cabanier <cabanier@gmail.com>, "www-svg@w3.org" <www-svg@w3.org>
Hi All,

	I have a couple of comments about the auto black
switching stuff.

	Anyway, as far as black preservation goes - this does
need to be specified and preserved through the render engine.

	It is quite common in printing to preserve black for an
object even if it's overlayed with transparent things on top.
So the example in the minutes with a gradient on top of a black
object could still retain the full black channel underneath.

	This is done primarily for bleed/registration at the edges
of objects such as glyphs, etc. The end result is that you have a mix
of CMY as well as black in a channel (no under colour removal).
So it's not uncommon to see something like (30%, 30%, 30%, 100%)
for the CMYK channels. None of this matters for screen/pixel
scenarios but is essential on any RIP used for printing.

	The spot/named colour case is another where this kind of
thing is mandated.

	The upshot of this is that the objects do need to be
tagged at the input, you can't do it automatically. All RIPs
used in typesetting do this one way or another. So if we're
going to let SVG be used for print workflows the colour
management model needs beefing up.

	Don't know that these comments add much, but the printing
people that care may want to add some RIP compatible suggestions
so someone one day will stick native SVG in a printer...

Alex
	
--Original Message--:
>No, the profile on the image is correct. I want the image to use rich black. That way any gradient in the image (the example image doesn¢t really have one, but imagine a picture that fades to black on the edges) is nice and continuous.
>
>Therefore, if I put the image on a black background or want to put a black border on it, I want that black to be rich black as well.
>
>If we¢re going to decide automatically that all solid filled black (and presumably gray) shapes and strokes will use preserve-black, this isn¢t going to happen.
>
>That¢s why I think we need an extra switch for the preserve black option.
>
>Lcms2 added this extra option (no-preservation, black only, black-plane) by duplicating its intents, but an optional switch seems cleaner to me. (http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/thirdparty/lcms2/src/cmscnvrt.c?rev=3024 see DefaultIntents[])
>
> 
>Nick Hofstede
>
>R&D Manager
>
>From: Rik Cabanier [mailto:cabanier@gmail.com] 
>Sent: maandag 1 augustus 2011 19:26
>To: Nick Hofstede
>Cc: www-svg@w3.org
>Subject: Re: minutes, SVG WG Seattle F2F 2011 day 3 - SVG Color
>
> 
>Hi Nick,
>
> 
>I think this is a case where you want to ignore the profile that is attached to the image and swap it out with the destination profile instead.
>
> 
>There was a discussion at the f2f why we would need to swap out the attached profile. This seems to be a valid use-case for such a feature.
>
> 
>Rik Cabanier
>
> 
>On Mon, Aug 1, 2011 at 12:07 AM, Nick Hofstede <Nick.Hofstede@inventivegroup.com> wrote:
>
>Quick note on the black preservation:
>
>  ChrisL: last issue is preserving black.
>  ... For example, in ICC if you specify cmyk(0,0,0,1),
>  color-management systems tend to have a switch that specially treats
>  that value.
>  ... So even if the system does color-manipulation normally, that one
>  color will instead stay solid, total black.
>  ... This is so black text stays pure black and doesn't mix in other
>  colors.
>  ... So, similarly, we need to see if we need it, and see if it's an
>  input or output feature.
>
>  cabanier: We have it in InDesign, and it's an output feature there.
>  ... So we have some special cases there again; you don't want to
>  preserve black on an image.
>
>  ChrisL: So that's basically actually being an input feature.
>
>  heycam: Does it make sense to have this controllable on images, or
>  if we can magically just apply it to solid-color fills and strokes?
>  ... Also, if you have some colored shapes which are composited
>  together, and you happen to get black out of that, should that be
>  preservable?
>
>  TabAtkins_: So it sounds like we can just specify that solid-color
>  strokes and fills automatically preserve black, and nothing else
>  does. It can be applied on output, and doesn't need to be specified
>  on input.
>
>  cabanier: So we look at the operator on printing - if a shape is
>  filled with an image or gradient, we don't preserve black. If it's
>  filled with a color, we preserve.
>
>  TabAtkins_: So if you composite a partially-transparent gradient
>  over a black rectangle, you wouldn't preserve the black in it.
>
>  heycam: So basically, for any image, track if the result color comes
>  partially from a gradient or image. If so, don't preserve black;
>  otherwise, preserve it.
>
>  TabAtkins_: So it sounds like we can do this automatically at the
>  end, and thus don't need a property for it.
>
>  heycam: And in PDF, it's not controllable; it just happens
>  automatically.
>
>I'm not sure automatically deciding when to use black preservation is a good idea. I don't think you can always deduce it automatically and I think you should therefore be able to specify it.
>Consider the use case talked about here for example:
>http://www.blog.spoongraphics.co.uk/articles/the-ultimate-guide-to-designing-with-black
>If you would create this in SVG your underlying rectangle would become black-preserved black, and the black from the image would be rich black.
>You're going to want to be able to trigger rich black on the solid-color fill.
>
>With kind regards,
>
>Nick Hofstede
>
>________________________________
>
>Inventive Designers' Email Disclaimer:
>http://www.inventivedesigners.com/email-disclaimer
>
> 
>
>-- 
>This message has been scanned for viruses and 
>dangerous content by MailScanner, and is 
>believed to be clean. 
>
>
>
>
>Inventive Designers' Email Disclaimer:
>http://www.inventivedesigners.com/email-disclaimer
>
>
>
Received on Tuesday, 2 August 2011 07:29:39 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:49 GMT