Scott,
In section 8.2.1 of CSS Print Profile we talk about rendering page boxes
that do not fit a target sheet. This is an extension of a statement in
CSS2.
Perhaps the process of reducing specified column widths falls under the
category of "reformat the page". All of the bullets listed in this
section could be thought of as violating the author's instructions...what
we currently say is that the PP-UA is allowed to do these things if it has
to.
Although I'm not sure we say so explicitly, I would expect the rules for
Enhanced Layout to handle this differently. In that case "layout is king"
and the printer is supposed to refuse if it can't do it right.
Do we need a way for an author to say "clipping is better than
reformatting"?
Anyhow: by default, what can an author count on? Can he assume the printer
will never override his layout, or should he expect that layout changes
might happen if needed to preserve content? I vote for the latter.
Also, I think devices like handhelds must have similar format-override
issues.
BTW, we (at Oak) have been giving some thought to providing user control
for some of these policies. This might be a printer-specific mechanism, at
least for now. Longer term, maybe PWG or W3C can invent yet more
properties to let authors specify, e.g., whether to rotate or shrink first.
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"SILBERNAGEL,SCO
TT To: "'don@lexmark.com'" <don@lexmark.com>,
(HP-Vancouver,ex ElliottBradshaw@oaktech.com
1)" cc: "SILBERNAGEL,SCOTT (HP-Vancouver,ex1)"
<scott_silbernag <scott_silbernagel@hp.com>, xp@pwg.org
el@hp.com> Subject: RE: XP> Table column width algorithms
11/15/2002 03:04
PM
I understand the reasoning as to why we might want to allow this behavior
but if we did allow it I believe we may want to specify when it can be
used.
If the author gives a table a fixed width or specifies "table-layout:
fixed", we don't want to allow the table to expand or contract since this
would be ignoring the author's valid request. For example if the author
specifies a 8 inch wide table and tries to print it on a 3x5 index card, I
think we should respect the specifications of the author and allow the
table
to clip at the edge of the card. CSS2 specifies how to handle conflicting
specifications (with the overflow and clip properties) but it never states
that a UA can ignore width/height specifications.
So I think it only makes sense to allow this behavior when the we are using
the automatic column width algorithm (table-layout: auto) with no specified
table width. In this case, we would not be ignoring author specifications
when modifying the columns (and table width) but we may surprise some XHTML
authors since this type of behavior never occurs in a web browser and by
changing the column widths we will alter the normal flow of the table cell
contents.
Also, this could only be allowed for printers that support the CSS-Print
Enhanced extensions since the table-layout property is not supported by a
minimally conforming printer.
Scott Silbernagel
Hewlett-Packard
-----Original Message-----
From: don@lexmark.com [mailto:don@lexmark.com]
Sent: Friday, November 15, 2002 11:12 AM
To: ElliottBradshaw@oaktech.com
Cc: SILBERNAGEL,SCOTT (HP-Vancouver,ex1); xp@pwg.org
Subject: Re: XP> Table column width algorithms
I would agree with Elliott. Remember, the XHTML-Print philosophy is
"Content is King" (rule #1) which means it is better to have the words on
the paper (and not clipped) in some form that not on the paper at all. If
it is absolutely mandatory that the columns be presented consistently from
page to page then the content provider can specify exactly the size of the
cells needed. As Elliott points out, since the page size and even the
orientation can change from page to page (my display seldom spins 90
degrees) there really isn't a way to guarantee constant cell sizes for
tables that span multiple pages in a resource constrained printer unless
you are willing to throw away content (see rule #1).
**********************************************
Don Wright don@lexmark.com
Member, IEEE SA Standards Board
PatCom Chair, SCC Liaison
Member, IEEE-ISTO Board of Directors
f.wright@ieee.org / f.wright@computer.org
Director, Alliances & Standards
Lexmark International
740 New Circle Rd
Lexington, Ky 40550
859-825-4808 (phone) 603-963-8352 (fax)
**********************************************
ElliottBradshaw@oaktech.com@pwg.org on 11/15/2002 02:01:54 PM
Sent by: owner-xp@pwg.org
To: "SILBERNAGEL,SCOTT (HP-Vancouver,ex1)" <scott_silbernagel@hp.com>
cc: owner-xp@pwg.org, "'xp@pwg.org'" <xp@pwg.org>
Subject: Re: XP> Table column width algorithms
A printer has two challenges that don't affect a browser (much...):
1. The @page rule allows an author to create a document with multiple page
styles, and different pages can have different widths available for
content.
2. There is no scrollbar on a printer, so we are highly motivated to
compress a table to make it fit on the width of a page.
Thus, it is conceivable that a printer might find itself with a table with
wide content on one page, but which flows onto a narrower page. An
advanced algorithm might take advantage of this and change the column
widhts to better fit on the new page. If the new page is narrower than the
first, reducing column width is probably bettter than falling off the edge
of the page.
Does this create problems for the user? I don't think it necessarily does.
I think it is OK for XHTML-Print to allow this; although certainly we
don't want to require it.
E.
------------------------------------------
Elliott Bradshaw
Director, Software Engineering
Oak Technology Imaging Group
781 638-7534
"SILBERNAGEL,SCO
TT To: "'xp@pwg.org'"
<xp@pwg.org>
(HP-Vancouver,ex cc:
1)" Subject: XP> Table column
width algorithms
<scott_silbernag
el@hp.com>
Sent by:
owner-xp@pwg.org
11/15/2002 01:53
PM
Hello,
The following are comments to the latest update slides from the New Orleans
PWG meeting.
Taken from Slide #22:
XHTML-Print: 3.8 Basic Tables Module
กค Column width may vary from page to page when width is
determined by td content.
Allowing column width to vary page to page would be inconsistent with the
way table column widths are normally computed and rendered (in browsers and
according to CSS2). Table columns are normally computed (and fixed for the
entire table) solely on either: the first tr element and its child td/th
elements (table-layout: fixed) -or- all tr and td/th elements in the table
along with the contents of those td/th elements (table-layout: auto).
When using the auto column width algorithm, column widths will be large
enough to handle the widest td/th in the table and varying the column
widths
page by page would never be necessary. Unfortunately, a minimally
conforming printer cannot be forced to use this algorithm since it is not
always possible to store the entire table in memory.
This leaves us with the fixed algorithm for computing column widths. With
the fixed method, column widths are only computed by looking at the first
tr
element and the widths of the first rows cells. The CSS2 specification
clearly states that the cells beyond the first table row do not affect
column widths (section 17.5.2):
<quote>
In this manner, the user agent can begin to lay out the table once the
entire first row has been received. Cells in subsequent rows do not affect
column widths. Any cell that has content that overflows uses the 'overflow'
property to determine whether to clip the overflow content.
</quote>
So, in my opinion, allowing varying column widths in a single table would
conflict with statements made in the CSS2 spec as well the "standard"
rendering of web pages by popular web browsers (IE, Opera,
Mozilla/Netscape).
Other questions/concerns:
If we did allow table columns to vary page-by-page, how would this behavior
affect table cells that span multiple pages? Would they suddenly get wider
or narrower when crossing a page boundary or would we only vary column
widths between rows? If we only varied between rows, the table would look
pretty strange (cell borders between columns would not line up...).
Scott Silbernagel
Hewlett-Packard
This archive was generated by hypermail 2b29 : Fri Nov 15 2002 - 17:08:42 EST