Skip to main content
N
naglists1-Visitor
1-Visitor
July 23, 2014
Question

table row break_penalty, system-func, and Screen FOSI help or bug confirmation needed

  • July 23, 2014
  • 10 replies
  • 2146 views
Hi all,

This feels like a Friday question. Is it Friday yet somewhere?

Authors have asked for feedback in the Edit Window whether or not a table
row has anything but a defaul break status. I have put together a few small
bits of code (embedded below) that do this. Sort of. For some reason the
detection/display is sort of "delayed" by one cell/column, wrapping when it
reaches the end of a row so there is feedback in the first cell of the
first row following the actual row where there is a break_penalty set.

If a row has break_penalty set to force, I expect this to display as
gentext in each cell of that row:
table break: force

Instead, that displays in cells in columns 2 through n, where n is the
number of columns in the table, AND the following displays in the first
cell of the first row following:
table break:

So, interesting, right?

Using the following series of commands (copy/pasted to the command line all
as one line of text), Editor will correctly report the break_penalty status
of each row. (You have to place your cursor in each cell and issue the
concatenated commands below). This seems reflected in that the gentext
described above is "correct" in that that first cell on the next row does
not report the presence of a break_penalty even though it is showing the
FOSI generated gentext introducing the break_penalty status. Is that
English?

Concatenated commands to report break_penalty status:
$oid = oid_caret();$cell = tbl_oid_cell($oid);$row =
tbl_cell_row($cell);tbl_obj_attr_get($row,"BREAK_PENALTY",$break_penalty);response('$break_penalty
= ' . $break_penalty);


I discovered this in a custom environment using FOSI in Arbortext 6.0 m090.
I replicated it using FOSI edits in AXDocbook's .style stylesheet.


my_fosi.acl (must be in editinit):

    10 replies

    P
    ptc-19080751-Visitor
    1-Visitor
    July 23, 2014
    Hi Paul,

    Try putting the atts in a pseudo-element called by gi=entry. That is generally the solution when things are off by one.


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

    D
    DavidS.Taylor1-Visitor
    1-Visitor
    July 23, 2014
    Under what circumstances would the row break status be of concern to the authors?

    Just curious.

    David

    David S. Taylor

    Project Manager, Production and Marketing
    Building Regulations | NRC Construction
    National Research Council Canada
    Building M-23A, Room 114 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
    Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
    David.S.Taylor@nrc-cnrc.gc.ca<">mailto:David.S.Taylor@nrc-cnrc.gc.ca>


    J
    jsillari1-Visitor
    1-Visitor
    July 23, 2014
    Wow!

    Thanks for sharing the code, Paul. Your writers are very lucky to have someone like you on board.

    John Sillari
    Chief Technologist
    Dayton T. Brown, Inc.
    M +1 631.742.3477
    V +1 650.735.5864
    N
    naglists1-VisitorAuthor
    1-Visitor
    July 23, 2014
    So I added the following to gi="entry":
    <usetext source="!&lt;entry.psu">,</entry.psu>!" placemnt="before"></usetext>

    And created an e-i-c for entry.psu from where I called out the <att>s I
    sent along earlier. The screen display is still off by one "cell" in that
    weird way that if they provide feedback, the feedback is correct, but no
    feedback is provided on the first <entry> and unexpected feedback is
    provided on the first <entry> of the subsequent row.

    Did I do what you meant, Suzanne?


    On Wed, Jul 23, 2014 at 10:46 AM, Suzanne Napoleon <
    -> wrote:

    > Hi Paul,
    >
    > Try putting the atts in a pseudo-element called by gi=entry. That is
    > generally the solution when things are off by one.
    >
    > Good luck!
    > Suzanne Napoleon
    > www.FOSIexpert.com
    >
    N
    naglists1-VisitorAuthor
    1-Visitor
    July 23, 2014
    Hi David,

    The authors in some cases (far too many if you ask me) carefully craft
    where their tables break. In many situations content preceding and rows in
    the table themselves are profiled requiring different forced breaks for
    different audiences. The feedback in the Edit Window for the forced breaks
    is helpful in managing this. (I do other things to provide feedback on
    whether and how a row is profiled since both things are used in conjunction
    with each other.)


    On Wed, Jul 23, 2014 at 10:51 AM, Taylor, David S. <
    -> wrote:

    > Under what circumstances would the row break status be of concern to the
    > authors?
    >
    >
    >
    > Just curious.
    >
    >
    >
    > David
    >
    >
    >
    > *David S. Taylor*
    >
    >
    > *Project Manager, *Production and Marketing
    > Building Regulations | *NRC Construction*
    > National Research Council Canada
    > Building M-23A, Room 114 | 1200 Montreal Road | Ottawa, ON | K1A 0R6
    >
    > Telephone: +1.613.990.2731 | Fax: +1.613.952.4040
    > David.S.Taylor@nrc-cnrc.gc.ca
    >
    >
    >
    >
    >
    >
    >
    > *From:* Paul Nagai [
    > reaches the end of a row so there is feedback in the first cell of the
    > first row following the actual row where there is a break_penalty set.
    >
    > If a row has break_penalty set to force, I expect this to display as
    > gentext in each cell of that row:
    > table break: force
    >
    > Instead, that displays in cells in columns 2 through n, where n is the
    > number of columns in the table, AND the following displays in the first
    > cell of the first row following:
    > table break:
    >
    > So, interesting, right?
    >
    > Using the following series of commands (copy/pasted to the command line
    > all as one line of text), Editor will correctly report the break_penalty
    > status of each row. (You have to place your cursor in each cell and issue
    > the concatenated commands below). This seems reflected in that the gentext
    > described above is "correct" in that that first cell on the next row does
    > not report the presence of a break_penalty even though it is showing the
    > FOSI generated gentext introducing the break_penalty status. Is that
    > English?
    >
    > Concatenated commands to report break_penalty status:
    > $oid = oid_caret();$cell = tbl_oid_cell($oid);$row =
    > tbl_cell_row($cell);tbl_obj_attr_get($row,"BREAK_PENALTY",$break_penalty);response('$break_penalty
    > = ' . $break_penalty);
    >
    >
    > I discovered this in a custom environment using FOSI in Arbortext 6.0
    > m090. I replicated it using FOSI edits in AXDocbook's .style stylesheet.
    >
    >
    > my_fosi.acl (must be in editinit):
    N
    naglists1-VisitorAuthor
    1-Visitor
    July 23, 2014
    Hi Lynn,

    1) I am a creature of habit (some say OCD) so all my ACLs are packaged,
    required or not.

    2) I am also lazy (some say slothful), so I often copy an existing ACL and
    work from the skeleton of a previous customization. Rather than think about
    whether package is required, I just find/replace everything.

    3) I am also forgetful. So I extend this naming thing to the file names.
    Most of my editinit code is one filename, one package, one function. This
    allows me to know what is going on (in most cases) by reading the file
    list. It also facilitates sharing functionality between different
    environments. In many cases I can just drag/drop one file and I've carried
    a feature from here to there.

    4) Yes, in this case, there are many other goodies. I'll take a look at
    them and share any that might possibly be useful.



    P
    ptc-19080751-Visitor
    1-Visitor
    July 23, 2014
    Paul,

    That's what I had in mind. But now that I look more closely, I think I understand the situation. The first 2 atts save to a textid. Any tests of that textid must be in a different e-i-c. If a DTD element isn't available, then a pseudo-element is used.

    Move the first 2 atts from the pseudo-element and put them in the e-i-c. After these 2 atts, add an unconditional att with a usetext for the pseudo-element, which has the remaining atts.

    Clear as mud? Please let me know any questions.

    Good luck!
    Suzanne

    N
    naglists1-VisitorAuthor
    1-Visitor
    July 23, 2014
    Dang list reply-to header got me! Already thanked Suzanne, and confirmed
    her fix, but directly.

    So, dear list, Suzanne's last pointer helped get me where I was going.
    However, the problem with saving the "easy" stuff for the end of a
    development run is that sometimes your brain is broken by that time. One
    test (included below) solves all the problems I was having in a much more
    (watch out!) elegant fashion. (I swear this is near where I started but I
    must have had some sort of typo or something that drove me down that other
    path.) No pseudo element required. No tests of each possible break penalty
    value required.

    Duh!

    <att>

    <specval attname="beam_fosi::break_penalty" attloc="system-func"&lt;br"/>attval="#NE#\default\">

    <fillval attname="beam_fosi::break_penalty" attloc="system-func"&lt;br"/>fillcat="savetext" fillchar="conrule">

    <charsubset>

    <savetext textid="break_penalty.txt" placemnt="before">

    <usetext source="\break" penalty:=" \,=" break_penalty.txt&quot;="></usetext>

    </charsubset>
    </att>




    On Wed, Jul 23, 2014 at 12:54 PM, Suzanne Napoleon <
    -> wrote:

    > Paul,
    >
    > That's what I had in mind. But now that I look more closely, I think I
    > understand the situation. The first 2 atts save to a textid. Any tests of
    > that textid must be in a different e-i-c. If a DTD element isn't available,
    > then a pseudo-element is used.
    >
    > Move the first 2 atts from the pseudo-element and put them in the e-i-c.
    > After these 2 atts, add an unconditional att with a usetext for the
    > pseudo-element, which has the remaining atts.
    >
    > Clear as mud? Please let me know any questions.
    >
    > Good luck!
    > Suzanne
    >
    B
    BobSpangenburg1-Visitor
    1-Visitor
    July 28, 2014

    Paul,


    A small detail I'd like to point out is the use of variables in a command line window. Generally, you have to put the command "execute" before each of the addtional commands in the command line. Otherwise, the value in the variable is the value set the last time the varialble was hit, not this time. That can cause the apparent "lag" in the response, or the one behind response.


    In your example of the Concatenated commands to report break_penalty status:


    $oid = oid_caret();$cell = tbl_oid_cell($oid);$row = tbl_cell_row($cell);tbl_obj_attr_get($row,"BREAK_PENALTY",$break_penalty);response('$break_penalty = ' . $break_penalty);


    In order to get this to work right "now," you have to do this:


    $oid = oid_caret(); execute $cell = tbl_oid_cell( $oid ); execute $row = tbl_cell_row( $cell ); execute tbl_obj_attr_get( $row,"BREAK_PENALTY",$break_penalty ); execute response( '$break_penalty = ' . $break_penalty );


    The result of thecommand line is to evaluate each varialbe with the current values of the variables involved, not what they were the last time.


    Hth,


    Bob

    N
    naglists1-VisitorAuthor
    1-Visitor
    July 28, 2014
    Good to know. Thanks for the tip!


    On Mon, Jul 28, 2014 at 9:27 AM, Bob Spangenburg <->
    wrote:

    > Paul,
    >
    > A small detail I'd like to point out is the use of variables in a command
    > line window. Generally, you have to put the command "execute" before each
    > of the addtional commands in the command line. Otherwise, the value in the
    > variable is the value set the last time the varialble was hit, not this
    > time. That can cause the apparent "lag" in the response, or the one behind
    > response.
    >
    > In your example of the Concatenated commands to report break_penalty
    > status:
    >
    > $oid = oid_caret();$cell = tbl_oid_cell($oid);$row =
    > tbl_cell_row($cell);tbl_obj_attr_get($row,"BREAK_PENALTY",$break_penalty);response('$break_penalty
    > = ' . $break_penalty);
    >
    > In order to get this to work right "now," you have to do this:
    >
    > $oid = oid_caret(); execute $cell = tbl_oid_cell( $oid ); execute $row =
    > tbl_cell_row( $cell ); execute tbl_obj_attr_get(
    > $row,"BREAK_PENALTY",$break_penalty ); execute response( '$break_penalty =
    > ' . $break_penalty );
    >
    > The result of the command line is to evaluate each varialbe with the
    > current values of the variables involved, not what they were the last time.
    >
    > Hth,
    >
    > Bob
    >
    Terms & ConditionsAccessibility statement