From: Grant, Melinda (melinda.grant@hp.com)
Date: Thu Oct 05 2006 - 22:35:11 EDT
Hi Ats,
Hopefully we agree that, as things are, one implementer might interpret
the specification as requiring a single page feed when multiple
page-break properties apply at a margin between blocks (say HP), while
another implementer might interpret the spec as calling for as many page
feeds as there are applicable page break properties (say Canon).
Another implementer might decide to limit empty pages to one or ten.
These differences would not serve clients and end-users.
So it's best to pick one way or the other, and be clear as to what's
required. The next version will specify that empty pages are minimized.
(Maybe it's better to avoid the word 'collapse'.)
Part of the rationale for choosing this answer (in addition to my
previous point that authors have other good tools to produce empty
pages) is that one of the major sources of dissatisfaction with Web
printing is the generation of empty pages (that is, with only headers
and footers on them, so the media can't be reused). Remember that the
Paged Media document specifies how all web pages should print, not only
XHTML-Print pages, but desktop PC printing as well.
I will post more information about the upcoming release and how to raise
issues for things you see as problematic in a separate message.
Best wishes,
Melinda
> -----Original Message-----
> From: Atsushi Nakamura [mailto:nakamura.atsushi318@canon.co.jp]
> Sent: Monday, October 02, 2006 4:59 PM
> To: Grant, Melinda
> Cc: xp@pwg.org
> Subject: Re: XP> [CSS3 Paged Media] Page collapsing
>
> Melinda,
>
> This may be just a way of thinking, but
> I don't think authors would unintentionally place consecutive
> page breaks, but they will be intentional. Collapsing them
> would neglect author's intent
>
> Authors would likely place "just" page breaks where they want
> page breaks to occur, since "page-break-after:always;"
> has a function on it's own, and normally would not think it
> would require some "magic".
>
> If other tags (or styles) behave he same way, this would be a
> different story.
> However, consecutive <br>s do not collapse, consecutive <p>s
> do not collapse, and styles do not collapse. Under this
> condition, the behavior proposed seems strange.
>
> Regards,
> Ats Nakamura
> Canon
>
>
> Grant, Melinda wrote:
> > 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
> >> --
> >>
> >
> >
>
>
> --
> 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 Oct 05 2006 - 22:35:25 EDT