FOSI and Table Properties?

ptc-953343 · ‎Sep 27, 2010

This relates to my previous post on table formatting. I've got a new
problem where I'm trying to format the header row of a table. I want to
set the text to center justify. Setting this in the FOSI doesn't change
the output even though the "resolve" display shows it as center.

When I select the row with Table Properties, it seems like Left justify
might be the default - Left is what I'm finding as my output.

For table width, PTC indicates that having a full width table is the as
designed intention when columns are set proportionally. Setting the Table
Property of Use Default (100%) seems to have no effect.

Setting the columns to fixed values makes the table set to less than full
page width. I thought that maybe center justification needed a fixed
width, but that didn't change anything.

Any idea why my headings will not center justify?

..dan

steve.thompson4 · ‎Sep 27, 2010

Definitely believe we could answer better if you included a chunk of tagged data and the FOSI <e-i-c>(s) involved.

Steve Thompson
+1(316)977-0515

AndyEsslinger · ‎Sep 27, 2010

Dan,

This "Use Default (100%)" on this screen shot is ONLY for display in the editor window and has nothing to do with output margins.

[cid:image001.png@01CB5E54.49DBB370]

If some columns must be fixed width, set the widest column to "Proportional" and Arbortext will make the column whatever width it needs to be to make the table fill between the margins.

The table usually is less of a pain if all columns are set to "proportional".

[cid:image002.png@01CB5E54.49DBB370]

Most of the crappy formatting I see in tables is where the author accidentally changes the row depth, so I select all rows and set the row height to "natural".

[cid:image003.png@01CB5E55.B3330ED0]

Instead of trying to set justification on ROW elements set it on the entry element (called CELL in this screen shot):

Set horizontal justification to CENTER on the cells you want centered (usually only the header row(s)).

[cid:image004.png@01CB5E55.B3330ED0]

I hope this helps and is not answering a question you didn't ask.

-Andy

\ / Andy Esslinger LM Aero Tech Order Data

_____-/\-_____ (817) 279-0442 1 Lockheed Blvd MZ 4285

\_\/_/ (817) 777-3047 Fort Worth, TX 76108

ptc-3050150 · ‎Sep 27, 2010

Thanks, Andy...I just copied that into the writer's training folder! As far as Dan goes, well...he's on his own.

John T. Jarrett CDT
Senior Tech Writer, Integrated Logistics Support, Land & Armaments/Global Tactical Systems

T 832.673.2147 | M 832.363.7234 | F 832.673.2376 | x1147 | -<">mailto:->
BAE Systems, 5000 I-10 West, Sealy, Texas USA 77474
www.baesystems.com

ptc-953343 · ‎Sep 27, 2010

> Definitely believe we could answer better if you included a chunk of
> tagged data and the FOSI <e-i-c>(s) involved.

Data

<table>
<tgroup cols="3">

<colspec colname="col1" colwidth="61.73pt"/">
<colspec colname="col2" colwidth="137.77pt"/">
<colspec colname="col3" colwidth="124.21pt"/">
<thead>
<row>
<entry valign="top">Light</entry>
<entry valign="top">Indicates</entry>
<entry valign="top">Corrective Action</entry></row>
</thead>
<tbody><row><entry><indicator>ANTSKID</indicator<br/>
EIC that is called up when I select "Indicates" entry

<e-i-c gi="entry" context="*" thead"<br="/>gitype="element">
<charlist inherit="0" charsubsetref="center" bold"=">
</charlist>
</e-i-c>

<charsubset charsubsetid="center<br"/><quadding quad="center" lastquad="lcenter">
</charsubset>

Seems pretty straight forward to me but for some resaon the "Resolved"
view shows that center justification is in effect (what I expect), but the
Print View version has left justified text.

>
>
> Steve Thompson
> +1(316)977-0515
>

tbihlmeyer · ‎Sep 27, 2010

quadding won't work on an inline element. Try making the eic a "block" and see
if that helps.

ptc-1908075 · ‎Sep 27, 2010

You will have to confirm this with Arbortext Technical Support, but I think
quadding coded in the FOSI is overridden by the horizontal alignment setting in
Cell Table Properties. I think the problem is that the default selection is
Left. There is no Inherit or Default choice for quadding in Table Properties.
For example, if you code a font family in the FOSI for entry, it is used unless
the Modify Cell Font Table Property specifies something other than Inherit for
the font family. This choice overrides the FOSI. The same thing with table row
breaking. It has a choice of Default, which means whatever is coded in the FOSI.
Other row breaking settings override the FOSI setting.

Again, please confirm this with Arbortext, and also please share what you learn.
I'll put it in Essential FOSI.

Thanks!
Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

GregoryMackenzi · ‎Sep 28, 2010

Hi Suzanne,

I'm interested in this subject as well from the point of learning about
FOSI, however we do have a working FOSI that centers the text in the
title row. However, I'm not sure exactly how it works. This may well be
outside the scope of the answer Dan is looking for. From the point of
view of learning how the FOSI does what it does (I'm pretty much a noob
with regard to this), we have an attribute of the element "entry" which
is "center":

Our table "entry" element has an "align" attribute of "center", the
table markup looks like this:

<table id="123456">

<title>

<english>A Simple Table</english>

<french>A Simple Table</french>

</title>

<tgroup cols="3"><colspec colname="col1" colwidth="13.99pi"/"><colspec<br/>colname="col2" colwidth="13.99pi"/><colspec colname="col3"<br"/>colwidth="13.99pi"/>

<thead>

<row>

<entry align="center" valign="top">Etiam suscipit lorem </entry>

<entry align="center" valign="top">Etiam suscipit lorem </entry>

<entry align="center" valign="top">Etiam suscipit lorem </entry>

</row>

</thead>

<tbody>

<row>

<entry>1</entry>

<entry>Malesuada fames </entry>

<entry>Suspendisse eget </entry>

</row>

<row>

<entry>2</entry>

<entry>Malesuada fames </entry>

<entry>Suspendisse eget </entry>

</row>

</tbody>

</tgroup>

</table>

I could have the element "<text> Malesuada fames </text> within the
<entry> element. The code of the table made me consider whether I should
be looking for an attribute in the FOSI but I don't see one for
align="center". I suppose what I'm doing is trying to follow the
references backwards from the element entry. I took a look and in the
FOSI and the table eics which matched elements are as follows:

<e-i-c gi="table">

<charlist inherit="1" charsubsetref="block"></charlist>

</e-i-c>

<e-i-c gi="text" context="entry">

<charlist inherit="1"></charlist>

</e-i-c>

The <entry> element "charlist" is set to "1" so it inherits. So Looking
further up the fosi closer to the beginning for "block" and "charlist" I
note the following entries:

<charsubset charsubsetid="block">

<textbrk startln="1" endln="1"></charsubset>

<charsubset charsubsetid="inherit">

<quadding inherit="1">

<highlt inherit="1"></charsubset>

I note the "charsubsetid='inherit" quadding is set to "1" so it
inherits, but I'm not quite sure how that relates to the following
<docdesc> which also refers to "block" and "charlist":

<docdesc>

<charlist inherit="1" charsubsetref="block">

<leading inherit="0" lead="1.2em">

<indent inherit="0" leftind="@" rightind="@" firstln="*">

<quadding inherit="0" quad="left" lastquad="relative">

<presp minimum="0pt" nominal="0pt" maximum="0pt" condit="discard"<br"/>priority="none">

<postsp minimum="0pt" nominal="0pt" maximum="0pt" condit="discard"<br"/>priority="none">

<keeps scope="col" keep="0" widowct="0" orphanct="0" next="0" prev="0">

<textbrk startln="0" endln="0"></charlist>

</docdesc>

So in the <docdesc> the quadding in charlist is set to inherit="0". That
means no. I take it that the charsubsetid of inherit, where the quadding
is set to inherit for the <entry> element is over-riding the <docdesc>?
Did I get lost somewhere? What part did the attribute "align='center"
play if any? I did find some quadding charsubsetid entries in the FOSI:

<charsubset charsubsetid="cquad">

<quadding inherit="0" quad="center" lastquad="relative"></charsubset>

<charsubset charsubsetid="lquad">

<quadding inherit="0" quad="left" lastquad="relative"></charsubset>

<charsubset charsubsetid="rquad">

<quadding inherit="0" quad="right" lastquad="relative"></charsubset>

Anyway, it would seem I have much to learn as I eventually want to add
new elements to my DTD and create entries in the FOSI to output them.

Greg

J

GregoryMackenzi · ‎Sep 28, 2010

Hi Suzanne,

That attribute had to do something. Digging a little further, when in
Epic Editor if I choose format/modify element-in-context I find the
element text in the context of entry is set to inherit missing
categories. It has an Attribute Rule or:

if element: attribute entry: align is center

if element: attribute entry: halign is c

I'll look in the FOSI with a text editor for these values.

Greg

J

GregoryMackenzi · ‎Sep 28, 2010

Wow, I got myself turned around J. Ok, the first set of e-i-c's I quoted
were from the screen FOSI. There is a lot of code in the print FOSI. You
may find this snippet useful, the e-i-c for the "text" element below in
the context of entry is from the print FOSI:

<e-i-c gi="text" context="entry" row=" tbody"=">

<charlist inherit="1" charsubsetref="block" hyphen-en"="></charlist>

<att logic="or">

<specval attname="align" attloc="entry" attval="center">

<specval attname="halign" attloc="entry" attval="c">

<charsubset>

<quadding inherit="0" quad="center" lastquad="relative"></charsubset>

</att>

The elements english, french, and text are often used interchangeably
within the element entry. I note that "quadding inherit" is set to "0"
(not to inherit) and the quad is set to center. At this stage, I'm out
of my depth, as the specval attname="align" is still used with a value
of center. I'm not sure how that is interpreted to turn out centered
text in printed copy. More reading to do I guess. I've got the Arbortext
FOSI Reference,AE 5.4 F000 of June 2009, so I guess it's a good place to
start. J

Greg

steve.thompson4 · ‎Sep 28, 2010

And there's your problem. At least, as far as any 'header' row is concerned. The context is "entry row tbody", which in SGML/XML path parlance is tbody/row/entry/text. You need an e-i-c for thead/row/entry/text, which would be context="entry row thead" (or more simply context="* thead"), if you want to format the content in a header row.

HTH,
Steve Thompson
+1(316)977-0515

----------

ptc-953343 · ‎Sep 28, 2010

It looks like Suzzane was right. there is an align proerty on the entry
element that appears to take precedence. If I set that to center, then I
get the headings I want. I'm writing up a bug report for PTC as I think it
is at the very least wrong that the "Resolve" results shows center rather
than the true value that is being used.

FYI, I also set the element to block to see if that made a difference,
nothing changed with that.

Your context statements might be right, I didn't look at this in detail.
But the FOSI editor pulls the one EIC up for the context and I set Center
on it, nothing centered in the table. This could have been a secondary
problem that was being hidden.

I'll let you know what comes of the support call.

thanks everyone for the insights.

..dan

> And there's your problem. At least, as far as any 'header' row is
> concerned. The context is "entry row tbody", which in SGML/XML path
> parlance is tbody/row/entry/text. You need an e-i-c for
> thead/row/entry/text, which would be context="entry row thead" (or more
> simply context="* thead"), if you want to format the content in a header
> row.
>
> HTH,
> Steve Thompson
> +1(316)977-0515
>

GregoryMackenzi · ‎Sep 29, 2010

Hi Steve,

Thanks for noticing that. J I hope it didn't detract from the
discussion. I was poking around in the FOSI using a text editor with
tunnel vision focusing on "entry". I was also looking for the align
attribute. I knew our FOSI did center text in the output so I thought
I'd take a look and see what was in it thinking there might be something
useful in it that might help Dan. I've dabbled a bit in our DTD and FOSI
and I can see that context is somewhat like an xpath; which I'm a bit
more familiar with. Interestingly, looking through the FOSI, a search
does not appear to locate an e-i-c for the context thead/row/entry/text.
I'm not having any particular problem myself, except that I'm trying to
learn something from this. There must be something in the chain of
inheritance that works with thead in our particular FOSI.

Greg

J

ebenton · ‎Sep 29, 2010

Table formatting by Editor/Print Composer is pretty much "automatically" standard, unless you explicitly format table thingies differently. One of the useful things that you get by declaring a row to be a header is to allow the header to float to the beginning of every table page on multi-page tables.
Yes, context is *very* important in FOSI. The FOSI element "e-i-c" stands for "element-in-context", after all.

steve.thompson4 · ‎Sep 29, 2010

And it has been my experience that the FOSI parser/engine/whatever-you-want-to/ought-to-call-it tries so hard to find an e-i-c that it sometimes does moderately surprising things. For instance, a context of "chapter" should be different than one of "* chapter", but failing to find any other e-i-c for a particular descendant, it will treat those two as synonymous.

That is, if <chgdesc> is a descendant of <chapter>, and it can't find any other e-i-c that matches better, then it'll apply the former as though it were written to be the latter. The former should only apply to a <chgdesc> that's a child, while the latter should be any <chgdesc> descendant that doesn't better match some other e-i-c.

Throwing a screen FOSI into the mix, so that things on the screen use an e-i-c from a different FOSI than does the printing just makes it that much harder. For debugging purposes in such cases, the print FOSI should be at least temporarily used for Editor display, so that the Element in Context tools have the opportunity to find the actual e-i-c being used to print.

My really long two-cents...
Steve Thompson
+1(316)977-0515

ptc-953343 · ‎Sep 30, 2010

In Reply to Suzanne Napoleon:

You will have to confirm this with Arbortext Technical Support, but I think
quadding coded in the FOSI is overridden by the horizontal alignment setting in
Cell Table Properties. I think the problem is that the default selection is
Left. There is no Inherit or Default choice for quadding in Table Properties.
For example, if you code a font family in the FOSI for entry, it is used unless
the Modify Cell Font Table Property specifies something other than Inherit for
the font family. This choice overrides the FOSI. The same thing with table row
breaking. It has a choice of Default, which means whatever is coded in the FOSI.
Other row breaking settings override the FOSI setting.

Again, please confirm this with Arbortext, and also please share what you learn.
I'll put it in Essential FOSI.

>>> Here is the response I got from support. Basically the table implementation is older than FOSIs and does things different (hard wired) and some things just can't be controlled via the FOSI. To change would be a lot of work ....

----------

Regarding “Centering cell content with FOSI - bug?”

Thanks for further clarification of this issue. This is not considered a bug by Arbortext. The situation is that we implemented table creation technology long before we implemented FOSI technology. Our software is coded for the Table Editor to control the look and feel of tables. We did this so we could convert table tags to a graphical image so people could edit in something that looks like a table and not just a bunch of tags. It also draws all the row rules and segments. As a result, the Table Editor controls the structural look and feel of the table. With this in place, the FOSI is not coded to override attribute settings in the table structural elements. You can code the eic to be always centered but it will never center as long as entry has align=none. Align=none is the controlling factor, not the stylesheet. This is the Table Editor taking control of the table and FOSI does not trump the Table Editor.

What the FOSI can control is the justification applied to markup used inside entry. That’s where the discussion of the element being a block comes into discussion. If you authored inside a paragraph, you could set a paragraph inside * thead to be always centered and it will work so long as paragraph is a block. Attribute settings on entry are ignored. The FOSI controls this because it is not a table structural element.

The eic panel shows a resolved value of centered because that is how the FOSI is correctly coded. The FOSI is coded perfectly and it will show the correct resolved value according to FOSI code. What the resolving technology does not take into account is something outside the FOSI. The Table Editor is not part of the FOSI code so the FOSI doesn’t take this into account.

I’m sorry, but everything is just designed this way. It’s always been that way and it will not be easily changed. It’s part of our core code. Had we chosen to implement tabdesc as defined in the outspec, then, perhaps the FOSI would have been able to control the look and feel of tables. Since we already had a robust table creation and formatting technology, we decided not to implement tabdesc.

---------------

ebenton · ‎Sep 30, 2010

And yet, the current inline table editor came about after FOSI technology. The table editor used to be a separate pop-up window in older versions of Adept Editor. They changed the table editor to inline when it became Epic Editor or maybe sometime before that. I guess that doesn't count as table implementation...?