Dave's latest draft table fragment has this to say about the way that
widths can be specified in tables:
| In general the units for widths are given by a suffix.
| The allowed suffices are:
|
| pixels /* the default units */
| ch /* characters */
| en /* half the point-size */
| % /* percentage */
| * /* relative widths e.g. for columns */
|
| Whitespace is permitted between the number and the suffix.
Let's take these one at a time.
| pixels /* the default units */
I personally am disinclined to make pixels the default unit. Of all
the possibilities, pixels have the least association with the intended
geometry of the table. (Think of what happens to a table intended to
occupy the width of the screen when the display resolution goes from
72 to 300 dpi). Based on my experience with putting tables online, I
would say the best choice for a default is the asterisk (relative
widths). A properly constructed CALS-like proportional-width
algorithm will generally give acceptable results no matter what the
original units were supposed to be, whereas an author who
absent-mindedly (or in an attempt to save keystrokes) leaves off the
units will surely be surprised at the way the table turns out if the
units are taken as pixels.
In any case, the unit name should be abbreviated. The proposed
"pixels" is strangely out of keeping with the laconic spirit of the
rest of the standard. How about "px" for this unit?
| ch /* characters */
What are "characters" in a proportional-space environment?
| en /* half the point-size */
I give up on the use of ems in tables. If people think that they know
what they mean by "em" in a mixed-font environment governed by
stylesheets, and browser makers think that they know what people mean
when they use ems in width specifications, more power to them. But if
we're going to include this in the spec, then let's use the right
terminology. The proper unit for this function is the em; the en is
never used this way in typography. Ens are used to refer to a
particular kind of space (the en space), a particular kind of dash
(the en dash), and on rare occasions, an indent less than an em. They
are not used as a unit for specifying widths in general.
Dave asks, "should we allow [presumably positive] floating point
numbers"; I would say yes. If so, then using ens for ems buys us
nothing in precision. The use of ens for ems is directly contrary to
industry practice and should be changed.
| % /* percentage */
The notes say, "If the percent sign is given, the value is taken as
the percentage of the document width." How is "document width"
defined here? Is this the current width of the document window? If
so, does it include margins, and does the specified width change
dynamically as the window is resized? In print, is this the width of
the page or the width of the text column in the current flow?
| * /* relative widths e.g. for columns */
I would make this the default; see comments above. I assume that
relative widths will use the CALS algorithm recently described here by
Paul Grosso.
In addition to the units listed above, we also need the traditional
printer's units -- the point and the pica. And I would grudgingly add
inches and centimeters to the list for people who like to think that
way about typography. The names should be
pt | pi | in | cm
where
pi = 12 pt
in = 6 pi = 2.54 cm (exactly).
Those who object to these "absolute" units have not, I would maintain,
thought through how rendition actually works in windowing
environments. These units do not refer to physical distances on the
physical screen; a moment's thought about what happens when you change
monitor sizes will demonstrate this clearly. Rather, they refer to an
unstated fixed mapping between points and pixels that is built into
the renderer in order to determine font display. In the MS-Windows
environment, for example, both Windows Write and FrameMaker (at the
100% scaling) use the relationship
1 "inch" = 96 pixels
which is the same as saying
1 "point" = 4/3 pixel
or, more cleanly,
1 "pica" = 16 pixels.
This relationship remains invariant among Windows screen drivers. It
is not cast in stone, however; WordPerfect 6.1 uses a slightly
different mapping that makes its screen "inches" a little shorter. In
all of these cases, the software has been configured so that a
"normal" line width on paper (where the absolute units really are
absolute) will display within the borders of a text processing
application on a VGA display. This width is about 576 pixels. Thus,
the points-to-pixels mapping built into the Windows Write and
FrameMaker for Windows applications assumes a typical line length of
about 6 inches, while the WordPerfect for Windows mapping has been
adjusted to fit the entire 6.5 inches of the usual U.S. business
letter into the same width on a VGA display.
I will observe parenthetically that we don't need to go by these rules
in designing applications specifically intended for computer displays;
we could, for example, specify a standard mapping of 1 "point" = 2
pixels, or (unlike the typical Windows app) make the relationship
scalable depending on the display driver. I have a couple of
proposals along this line in cold storage if we ever decide to get
into this level of user agent specification. For the moment, I just
want everyone to be clear that the "absolute" units are actually
relative. In fact, they are relative to the one thing that, as a
designer of tables, I really care about, which is the way that the
application is going to render font sizes.
If I have a header cell containing a word in 12 pt Helvetica bold, and
I know that the word fits the way that I want it to fit in a cell 4
picas wide when it's printed (which it will be somewhere along the
line), then *that* is the relationship that I want to be able to code
into a table when I use stylesheets that will allow me to specify the
font, because *that* is the relationship that will remain invariant no
matter how the app builder specifies the mapping between
points/picas/inches and pixels.
(In fact, this is just the kind of relative specification that people
who are fond of ems are trying to get, since "em" is just another name
for the body height in points of some unspecified font. But I
promised not to go on about that any more.)
We still need to thrash out the expected behavior of a table renderer
when a user with poor eyesight bumps up the size of the type. This
discussion will, I believe, reveal that the whole scalability problem
is orthogonal to the choice of units used to specify column widths.
But in any case, we need to have pt|pi|in|cm added to list of the
units that can be specified.
Another point that needs clarification is what happens when different
types of units are mixed in the column specifications for a given
table. The basic categories I see are "genuinely absolute" units
(px), "fixed" units (pt|pi|in|cm|em), "proportional" units (%|*), and
no units (i.e., back to the basic table algorithm). I would assume,
for starters, that this is the order of precedence (absolute, fixed,
proportional, none); thus, to take a very typical case, I might want
the leftmost column of a table specified as a fixed 4 picas wide and
leave the others unspecified, allowing the basic table algorithm to
allocate dynamic widths for the other columns using the space
remaining in the current window. But I suspect that it wouldn't be
hard to come up with cases that are a lot more difficult to resolve,
and we may have to impose some limitations on the extent to which
these categories can be combined in the same table.
Jon
========================================================================
Jon Bosak, Novell Corporate Publishing Services jb@novell.com
2180 Fortune Drive, San Jose, CA 95131 Fax: 408 577 5020
A sponsor of the Davenport Group (ftp://ftp.ora.com/pub/davenport/)
------------------------------------------------------------------------
The Library is a sphere whose consummate center is any hexagon, and
whose circumference is inaccessible. -- Jorge Luis Borges
========================================================================