From: Grant, Melinda (melinda.grant@hp.com)
Date: Thu Sep 28 2006 - 15:48:12 EDT
Hi Ats,
This was my original thought as well. But others pointed out that
authors have many other more deterministic means to generate empty pages
if they wish. Having 'another way' by using page-break-always, which
doesn't work the same across different implementations, is not a good
thing.
If an author indeed intends to leave a blank page he can still do it in
multiple different ways, such as
1. Inserting a <br> or a <div> with just a space between paragraphs
(preventing them from collapsing page-breaks)
2. Inserting a unicode page-break character anywhere he wants (inserting
several of them will leave several pages blank if desired)
3. Inserting a <DIV style="page-break-after:always;
page-break-before:always>This page is intentionally left blank</DIV>
(most legal documents will choose this way, others may just put space
character instead of this text in the div, achieving a completely empty
page).
All these solutions will ensure the exact number of blank pages that the
author explicitly requested. Collapsing page breaks will on the other
hand prevent unintentional ones.
Best wishes,
Melinda
> -----Original Message-----
> From: Atsushi Nakamura [mailto:nakamura.atsushi318@canon.co.jp]
> Sent: Wednesday, September 27, 2006 11:24 PM
> To: Grant, Melinda
> Cc: xp@pwg.org
> Subject: Re: XP> [CSS3 Paged Media] Page collapsing
>
> Melinda,
>
> I apologize in my delay catching up on this subject, but
> Canon believes authors that accumulate multiple page-break-*
> properties will do this with intent.
> Collapsing valid properties is something we have not seen
> before, and seems something odd to do.
>
> Regards,
> Atsushi Nakamura
> Canon
>
> Grant, Melinda wrote:
> > The CSS Paged Media specification
> > (http://www.w3.org/TR/2004/CR-css3-page-20040225/) is currently
> > unclear as to what should happen when multiple page-break-*
> properties
> > accumulate. The spec is clear that a :left or :right
> pseudo-class can
> > require that a blank page or surface is generated.
> >
> > For example:
> >
> > <p>This is a paragraph on page 1.</p>
> > <div style="page-break-before">
> > <div style="page-break-before">
> > The first div causes a page break; does the second
> div cause
> > another page break, putting this content on page 3, or are the page
> > breaks collapsed into a single page break so that this is
> printed on
> > page 2?</div> </div>
> >
> > Or:
> >
> > <body>
> > <p> I am printed on the first page.</p>
> > <div style="page-break-after:always">
> > <div style="page-break-after:always">
> > <div style="page-break-after:always">
> > <div style="page-break-after:always">
> > <div style="page-break-after:always"> I am also
> printed on
> > the first page.
> > </div>
> > </div>
> > </div>
> > </div>
> > </div>
> > <p>Where am I printed?</p>
> > </body>
> >
> > Or:
> >
> > <body>
> > <p style="page-break-after">This is a paragraph on page 1.</p> <div
> > style="page-break-before">
> > The p generated a page break; does the div cause
> another page
> > break, putting this content on page 3, or are the page breaks
> > collapsed into a single page break so that this is printed
> on page 2?
> > </div>
> > </body>
> >
> > Different implementations behave differently, as might be
> expected. I
> > would like to tighten up the spec to require that page-break
> > properties collapse such that no empty pages or surfaces
> are generated
> > except for one when needed to get to the next right- or left-facing
> > page. Authors can use other means to create blank pages.
> This will
> > make results more interoperable.
> >
> > (I do not yet have consensus from the CSS WG to make this change.
> > Most implementations collapse pages, but Opera's does not, and they
> > may not be willing to accept the change.)
> >
> > If you wish to object to this proposed clarification or express
> > support, please do so by posting a response here or to
> > www-style@w3.org <mailto:www-style@w3.org> by September 23.
> >
> > Best wishes,
> >
> > Melinda
> > _____
> >
> > HP - Melinda Grant
> > Connectivity Standards
> > Consumer Printing and Imaging
> > +1 (541) 582-3681
> > melinda.grant@hp.com
> > _____
> >
> >
>
>
> --
> Atsushi Nakamura
> Senior Engineer
> Inkjet Device Firmware Design 31
> Canon, Inc.
> 3-451 Tsukagoshi Saiwai-Ku
> Kawasaki JAPAN
> 212-8530
>
> Tel : 81-44-542-2111 ext3713
> 81-44-548-7538 direct(shared)
>
> E-mail : nakamura.atsushi318@canon.co.jp
> --
>
This archive was generated by hypermail 2.1.4 : Thu Sep 28 2006 - 15:48:18 EDT