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

[naglists]

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):

[ptc-1908075]

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!"

[DavidS.Taylor]

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>

[jsillari]

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

[naglists]

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
>

[naglists]

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 c...

[naglists]

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.

[ptc-1908075]

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

[naglists]

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
>

[BobSpangenburg]

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

[naglists]

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
>