Skip to main content
P
ptc-9533431-Visitor
1-Visitor
September 27, 2010
Question

FOSI and Table Properties?

  • September 27, 2010
  • 16 replies
  • 8648 views
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

    16 replies

    Show previous replies
    P
    ptc-9533431-VisitorAuthor
    1-Visitor
    September 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
    >
    G
    GregoryMackenzi1-Visitor
    1-Visitor
    September 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


    E
    ebenton1-Visitor
    1-Visitor
    September 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.
    S
    steve.thompson41-Visitor
    1-Visitor
    September 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
    P
    ptc-9533431-VisitorAuthor
    1-Visitor
    September 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.

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

    E
    ebenton1-Visitor
    1-Visitor
    September 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...?
    Terms & ConditionsAccessibility statement