From: Atsushi Nakamura (nakamura.atsushi318@canon.co.jp)
Date: Tue Oct 10 2006 - 07:52:20 EDT
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-8530Tel : 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 - 07:52:32 EDT