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.
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 table.
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 plagiarize.
Doug, Since the line is required by MIL-STD-38784 (paragraph 22.214.171.124) 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 \ / 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 Sindy