With difficulty. Especially in an on-screen viewing mode [paper is a
bit more fixed target] I would almost always advocate the specification
of measures that are relative to the full table's width (which may in
turn be relative to the column/page/screen/window width).
This point may have been glossed over in Steve's posting, but by
specifying column width using a "unit" of "*", you give the columns
width that are proportional to their coefficient such that the sum of
the column widths equals the table width. For example, if you give 4
columns width specifications of 1.5*, 1.5*, 3*, 4* [or, equivalently,
3*, 3*, 6*, 8* or 15*, 15*, 30*, 40*], you've defined a table whose
first two columns will each be 15% of the full table width, whose third
column is 30% of the table width, and whose last column is 40% of the
table width. The model has been working for CALS tables for several
years--there are a variety of implementations available.
>
> I agree fully with this and would like to take it a bit further. Even
> fully-sighted people may want to make the text on their screen larger than
> imagined by the document creator. I often hear "how can you *read* that?"
> when people are looking at my screen and I'm reading in 12-point type.
>
> Further, not using ems forces the document creator to guess the width of
> all the fonts as displayed on the viewer's screen.
I don't believe it's the document creator who should know what size type
you can/want to read, it's you. This is a job for user-supplied style
(be it in style sheets or otherwise).
I'm hoping Yuri will have a comment from the ICADD point of view, but
I fail to see how the author's use of a unit of "em" is the solution to
reader's need to have things displayed differently.
Let's not confuse the general issue of hierarchical inheritance of the
style properties of a display environment (with which I'm not arguing)
with the use of a unit in the source document (as opposed to in a style
specification) that, in the experience of lots of people who have been
doing this for a while, often leads to interoperability problems or at
least general user confusion.
paul
Paul Grosso
VP Research, ArborText, Inc.
and
Chief Technical Officer, SGML Open
Email: paul@arbortext.com