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

Re: [css-page-3] 'marks' and 'bleed'

From: Håkon Wium Lie <howcome@opera.com>
Date: Mon, 21 Oct 2013 20:41:11 +0200
Message-ID: <21093.30023.929241.638730@gargle.gargle.HOWL>
To: "Cramer\, Dave" <Dave.Cramer@hbgusa.com>
Cc: Simon Sapin <simon.sapin@exyr.org>, "www-style\@w3.org" <www-style@w3.org>
Dave Cramer wrote:

 > > > http://dev.w3.org/csswg/css-page/#page-marks-bleed
 > >
 > >Good. Perhaps the text should say explicitly that negative values are
 > >allowed? Like:
 > >
 > >  A positive value makes the background of the page box extend outside
 > >  the edge of the page on all four sides. Correspondingly, a negative
 > >  value will result in the background of the page box being pushed in
 > >  from the edge of the page on all four sides. Setting the bleed does
 > >  not change the starting position of background images.
 > I've never heard of a negative bleed. Would this just be an easy way to
 > have backgrounds that don't extend to the edge of the page?

Yes. And a way of avoiding to describe error situations. 

Currently, AH supports negative values, PR does not. 

 > At least in the U.S., the most common value for bleeds is 9pt; would that
 > be a better initial value, or do other parts of the world use smaller
 > values?

I don't know. 9pt sounds like an excellent value :)

 > Another issue for us is how far the page marks are from the page box.
 > Commercial printers sometimes want this value to be larger than the bleed
 > amount. Our major printer wants all marks to be at least 18pt from the
 > page box, even though the bleed amount is 9pt. PrinceXML has a
 > "prince-trim" property which used to affect this (its behavior has changed
 > in current versions).

In the interest of avoiding stacks of properties, could we find one
descign that works for all/most printers?

              Håkon Wium Lie                          CTO °þe®ª
howcome@opera.com                  http://people.opera.com/howcome
Received on Monday, 21 October 2013 18:42:07 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:51:03 UTC