XP Mail Archive: RE: XP> Table column width algorithms

RE: XP> Table column width algorithms

From: BIGELOW,JIM (HP-Boise,ex1) (jim_bigelow@hp.com)
Date: Fri Nov 15 2002 - 14:23:13 EST

  • Next message: SILBERNAGEL,SCOTT (HP-Vancouver,ex1): "RE: XP> Table column width algorithms"

    Don,

    One point about the logic in the message below, the content will flow within
    the table cell. Setting a column width from the first row of the table
    (table-layout: fixed) doesn't imply clipping content, just a potentially
    higher row height, than it has with a wider column. So all the content is
    printed, but arranged out in different width line boxes within the table
    cells.

    I think it is best to adhere to CSS rules whenever possible as long as a
    printers can, in some way, without content loss, render the page.

    Jim
    http://oz.boi.hp.com/~jhb/

    -----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 - 14:23:30 EST