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

Re: [css-page] positioning of crop marks

From: Cramer, Dave <Dave.Cramer@hbgusa.com>
Date: Sat, 16 Nov 2013 07:58:04 -0500
To: MURAKAMI Shinyu <murakami@antenna.co.jp>
CC: "www-style@w3.org" <www-style@w3.org>, Michael Day <mikeday@yeslogic.com>
Message-ID: <CEAD66A9.41699%david.cramer@hbgusa.com>
On 11/16/13 3:27 AM, "MURAKAMI Shinyu" <murakami@antenna.co.jp> wrote:


>"Cramer, Dave" <Dave.Cramer@hbgusa.com> wrote on 2013/11/14 3:02:53
>>Name: mark-offset
>> Value: length
>> Initial: 12pt
>> Applies to: page context
>> Inherited: no
>> Media: visual, paged
>> Computed value: as specified
>> Percentages: refer to width of page box
>
>I think the initial value of the mark-offset should be auto.
>It depends on the style of crop marks.
>(the mark-style property will be defined in level 4)
>
>We use "double crop marks", the combination of crop marks and bleed marks.

Thanks for the information!

>
>With this crop mark style, the mark-offset equals to the bleed length.
>
>So I would like to suggest the following:
>
>Name: mark-offset
>Value: auto | <length>
>Initial: auto
>
>auto: 6pt if no bleeds, otherwise the bleed length

Having the mark offset match the bleed seems like a reasonable default.

>
>BTW, the standard bleed (and mark-offset) length is 3mm in Japan (and
>other many countries, probably).
>I'm not against with 6pt but would like to know whether this is
>acceptable default bleed length for other people.

The most common value I've seen in the U.S. is 9pt, which is much closer
to 3mm than the current 6pt value. I'd personally have no objections to a
3mm default, but I'd like to hear from more worldwide users.

Thanks,

Dave





This may contain confidential material. If you are not an intended recipient, please notify the sender, delete immediately, and understand that no disclosure or reliance on the information herein is permitted. Hachette Book Group may monitor email to and from our network.
Received on Saturday, 16 November 2013 12:58:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:37 UTC