Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

The PTC Community email address has changed to Learn more.

thead screen fosi


thead screen fosi

I need a little help with the table's thead in the screen fosi. I am not
sure now to place a line on the bottom of the e-i-c for either or "thead" or
the "row" inside the thead on tables. Here is a sample of the table, it is
38784 Mil standard.


the default behavior is to have a frame around the entire table, and no line
between the thead and tbody.


Douglas Wade
Contact Me: [image:

--- @ WiseStamp Signature. <">> Get it

Do you mean add a border, or is this in addition to the normal Table
properties functions? You should be able to select any row, and modify
attributes for the row. If you make the rowsep attribute ="1", that
should put a normal table "row line" below that row, if you don't
already have one. If you want something more than this, I don't think
there is any easy way to modify Arbortext's core table "grid" display.

If all you want is for your authors to be able to quickly determine a
header row, you can make your <thead> <entry> tags contain bold text, or
a colored background. There is also the little green table icon to the
side of the row, but that only shows up when your cursor is inside the

You could also maybe modify the CALS table content model by declaring
one of the parameter entries in the CALS table DTD within your own DTD,
before the CALS DTD declaration occurs. Using this method, you could
add a tag after thead to the tgroup model, and the screen FOSI could
render a line for this new tag. I have never tried this, so I am not
sure how well it would work.

Just a line separating the thead from the tbody. I do not want the writer to
change the content (rowsep="1"), but rather have it match the print FOSI,
which default behavior has the line. As I walk around I notice writers,
adding rowsep attributes to display the line, but since the print FOSI does
it already, it adds no value to have the writers add it, except to make it
pretty on the screen. Our print engine is DL Composer, so the print FOSI's
are not interchangable with our screen FOSI's, even at the table, thead,
tbody areas.

I could change the background color, I do that now if the writer has
multiple thead rows the background is changed to red, (sort of an error
check), but that is not what I would like.

Also, I am not interested in changing anything in the DTD's, because this is
really just eye-candy for the screen.


My guess is that unless you use one of the methods I described below,
that the table/thead line is something you can do in the DL composer
FOSI/rendering engine, but not in Arbortext FOSI. You could try taking
a look at the print FOSI. Maybe there *is* something there that you can


The print FOSI is different in this area and does not have anything to
steal, that was my first choice; I steal anything I can, I mean "reuse"
anything I can <grin>.



Since the line is required by MIL-STD-38784 (paragraph perhaps
it is a bug that Arbortext would consider fixing if you open a case. On
the other hand, maybe there is some other formatting specification that
doesn't want a line to separate the heading from the body of a table and
Arbortext favors allowing a choice.

I think this boils down to a difference in interpretation of the CALS
table spec by Datalogics and Arbortext. Datalogics puts it in whether
the rowsep attribute calls for it or not. Arbortext leaves it out
unless the rowsep attribute calls for it.

If anyone is taking a poll I would prefer that Arbortext render the line
automatically since the only place a horizontal line is required is to
end a table heading or end a table (which makes it impractical to change
the default in the DTD).

\ / Andy Esslinger LM Aero Tech Order Data
_____-/\-_____ (817) 279-0442 Box 748, Mail Zone 4285
\_\/_/ (817) 777 3047 Ft. Worth, TX 76101-0748

Being the one in our group that deals with the screen fosi, I
temporarily bristled at the remark "it adds no value to have the writers
add it, except to make it pretty on the screen." It does add value in
that it looks more like the author is used to seeing their data and
without it, it seems "wrong" to them and it is almost impossbile for
them not to fix it, or at least it is for me. However, if your that set
on the authors not changing the attributes, you could develope a generic
Table entity that sets the construction of the table the way you want
it. I caution though that you be very careful because it can limit the
authors ability to add or delete rows if constructed incorrectly. You
could also use the tag template to build the table the way you want it
and insist the author use that template only, however it does not lock
down the atts the way the entity would. Either one could be labor
intensive if your well into sgml already.

No hard feelings about the "no value" remark. lol