Re: (Another) Frame bug not fixed in 6.0 -- Tables: the PhantomFont Menace [LONGISH]

[Michael Cudmore <mcudmore@xxxxxxxxxxx>]

Donald F. Pratt wrote:

... 

> After you've finished defining/redefining para formats,
> create one table of each table format,
> specifying 1 each of header, body, and footer rows,
> and the minimum number of columns for which
> you need to specify column widths or para tags

...

> For each table,
> when you've got all the asterisks gone from your paras,
> click Update All in the table designer.
> When you're done,
> all paras stored for all table formats will have default font properties,
> and those properties WON'T be stored in the table formats
> (check the MIF and you'll see).
> They will come back if you later change your para definitions --
> whether this is bug or feature,
> tables keep the exact para properites they were defined with.

And later:

OK. I see it now.
The fonts used when any given table instance was created
stay, uselessly, in its own little copy of the original table-format
definition
EVEN IF YOU CHANGE ALL THE FONTS IN THAT INSTANCE AND USE
THAT INSTANCE TO UPDATE THE FORMAT DEFINITION.

...

Caveat: The techniques below are based on experience in 5.5, not 6.0.

The definition of each table format in the catalog contains the full
specifications of the table that was used to create the format. If that
table format is later updated, some of the properties of the selected
table instance will replace the original properties in the definition,
but others will not. To make sure that all properties are updated, you
need to replace the table definition, not update it.  

For each table format:

1. Create a new table of the desired table format that will act as the
new table definition, i.e. carefully set up all its properties (number
of columns and number of head, body and foot rows, para formats for all
those cells, ruling and shading, title, margins, alignment, the lot). If
necessary, APPLY settings changed in the Table Designer to the selected
table. 

2. From the Commands menu of the Table Designer, DELETE that table
format from the catalog.

3. From the Commands menu of the Table Designer, create a NEW FORMAT
with the same name as the now deleted format (you should be prompted to
use the old name).


If you follow this procedure after changing para formats and use the
correct para formats in the table being used to create the new
definition, there should be no font or other overrides in the table
definitions, and you should get no subsequent unavailable font messages
due to paras in table format definitions. 

You might be able to keep control of this a little bit better by having
a reference page or pages for tables, where you keep a correct instance
for each format, and then delete and recreate that table format any time
the relevant para formats change. 

A variant technique suited to a large number of chapters needing the
same formats would be 
1. Create the correct table, para and character formats in a template.
2. (for safety) Delete the table formats from each chapter. 
3. Import table, para and char formats from the template into each
chapter.

(Of course, tables already existing in the document will not have their
para formats, custom ruling, column widths or other properties updated
when you follow these steps.)

Good luck,

Michael

--
Michael Cudmore
Project Development Manager
National Educational Advancement Programs (NEAP) Pty Ltd
58 Pelham St  Carlton  Vic  3053   AUSTRALIA
Tel:    +61 3 9663 2523    Fax:  +61 3 9663 7182
e-mail: (work)    mcudmore@neap.com.au
        (pers)    mcudmore@email.com

No bytes were harmed in the making of this message

** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **