Admittedly, Jim was emphasizing "wide divergences (like 9 point and 14
point in the same table)", whereas the examples you will find in
Novell manuals or GPO publications seldom if ever vary by more than a
a couple of points within a given table. Usually the difference isn't
even one of body size but rather a shift from medium to bold or
italic. But setting aside the whole issue of whether we're in charge
of building artistic norms into the table model, the important thing
to notice here is that it doesn't matter how small the difference is.
If you allow *any* change in font, you will be mixing different font
metrics and therefore making the absolute value of an "em" undefined.
This is as true of a shift from medium to bold or italic as it is of a
change in body height. It is even more true if you go to small caps
or change font families. You don't have to look very far in our
technical manuals to find tables in which some cells contain either 10
point Arial or 10 point Helvetica or 10 point Palatino (depending on
whether it happens to be rendered at the moment on a Unix machine, a
Macintosh, in Windows, or in print -- the same table code drives all
four output media!) while the cells immediately next to them contain
code examples in 10 point monospaced Courier. I've got hundreds of
these, including examples where the Courier is embedded right in the
body type in the same table cell.
As Jim concludes, it's not a good idea to allow ems as a unit for
table specifications. I will be more explicit: unless we are going to
prohibit font changes of any kind in tables, the idea of an em as a
determinate unit of measure across an entire table is conceptually
bogus.
Several people have defended table specifications in ems on the
grounds that they would allow scalability, implying that without ems,
scalability would not be possible. This is nonsense. The two issues
have nothing to do with each other. You can scale an online table in
which all of the column widths and type sizes are specified in "hard"
units like picas and points just as easily as you can scale an online
table specified any other way, because in the online environment, the
mapping between absolute units and pixels is entirely arbitrary and
implementation-dependent anyway. (I hope to say more about this in
another posting, so please hold indignant replies to the preceding
sentence for the time being and instead meditate on the relationship
between an "inch" displayed on a 14-inch screen and the same "inch"
displayed on a 17-inch screen. You might also try measuring the ruler
bar in WordPerfect and comparing it with the ruler bar in Windows
Write, for example.) The only unit that actually prevents you from
scaling freely is the pixel.
Not nearly enough attention has been payed in this discussion to the
answer to most table problems, which is the use of proportional units.
In CALS tables, you specify proportional units by following each
number with an asterisk. When we put our printed Novell manuals
online using the DocBook DTD, we simply grabbed the unit (in picas)
from the FrameMaker table code and substituted "*" for "pi" as the
unit. Now all the tables work properly across all output platforms,
including print, and online they scale just fine using "enlarge" or
"reduce" to suit the user while preserving the column relationships
that the authors originally specified. For those who may have missed
it, I will repeat Paul Grosso's excellent capsule summary of how this
works:
> 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.
This is how we should implement proportional widths. (Notice that
there is nothing to prevent you from using percentages, if you like;
this is just a special case of proportional widths where all the
widths happen to add up to 100.) I can tell you from experience that
proportional units will satisfy the overwhelming majority of online
and print table applications. We don't need ems in tables.
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
========================================================================