RE: XP> [CSS3 Paged Media] Page collapsing

From: Elliott Bradshaw (Elliott.Bradshaw@Zoran.com)
Date: Tue Oct 10 2006 - 11:31:27 EDT

  • Next message: Michael Sweet: "Re: XP> [CSS3 Paged Media] Page collapsing"

    If you have nested elements, say <divs>, it may be convenient to mark
    both styles with page-break-after. For example:

    <div class="chapter">
    Some text here...
    <div class="section">
    Some more text here in section 1
    </div>
    <div class="section">
    Some more test here in section 2
    </div>
    A little more
    </div>

    You'd like each type to break the page at its end. But then you might
    have a section and chapter ending together, and normally you would not
    want a blank page. Without page-break collapsing, this would require
    special coding for a section at the end of a chapter.

    Also, I think this is analogous to the way lines are broken. If you
    have a div inside a div, you don't get a blank line at the end.

    Unfortunately the price we pay is that forcing that blank line requires
    a little doing and might vary from browser to browser.

    Nevertheless, I think collapsing page breaks is what is normally wanted,
    and is consistent with line breaks.

      Best regards,
      Elliott Bradshaw, Zoran

    -----Original Message-----
    From: owner-xp@pwg.org [mailto:owner-xp@pwg.org] On Behalf Of Atsushi
    Nakamura
    Sent: Tuesday, October 10, 2006 7:52 AM
    To: Grant, Melinda
    Cc: xp@pwg.org
    Subject: Re: XP> [CSS3 Paged Media] Page collapsing

    Melinda,

    I do agree that the generation of unintentional empty pages would lead
    to
    dissatisfaction. However, if an author intends to include empty pages,
    that
    author has a reason to do so, and this must be respected.

    I don't think that the choice between providing (other) good tools to
    achieve
    empty pages, or we let consecutive page breaks to generate empty pages
    is an
    issue, an author is going to generate empty pages in whatever method is
    allowed,
    if she/he wants to.
    The issue is that we have to make it clear that empty pages lead to bad
    user
    experience.

    In that sense, I do not see a benefit in prohibiting consecutive page
    breaks to
    generate empty pages. (i.e. I don't see a meaning in choosing between
    methods to
    generate empty pages)
    However, I do see a benefit in adding a note that generating empty pages
    in any
    way will cause dissatisfaction.

    Regards,
    Ats Nakamura
    Canon

    Grant, Melinda wrote:
    > 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
    >> --
    >>
    >
    >

    -- 
    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 : Tue Oct 10 2006 - 11:31:33 EDT