cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
Showing results for 
Search instead for 
Did you mean: 

Community Tip - Have a PTC product question you need answered fast? Chances are someone has asked it before. Learn about the community search. X

alternate row shading

ssauvage
1-Newbie

alternate row shading

Dear Adepters,

We are using tables, based on Oasis models (in a DTD).
Is there a way to alternate row shading in tables display ? Maybe using 'tabstyle' attribute of <table>, Fosi (we have one) or Processing Instructions ?

Thanks for your answers,

Sébastien

25 REPLIES 25

You can set a counter on row and then do a #FOSI test on that counter and apply shading if rowct=1.

Not where I can input the code and test, so not saying anything definitive, but...

Wouldn't there need to be something that checks whether rowct is even or odd, and only shade for one or the other? In order to shade alternate rows...

Thanks for your answers.

When coursing a row, I can check in an ACL function, knowing its index (counter) i, the value of i % 2 (0 or 1) to apply shading.
But how in my Fosi can I apply shading to entire row (not cells one by one) ?

Regards,

Sébastien


Le 22/05/2012 00:26, Steve Thompson a écrit:Not where I can input the code and test, so not saying anything definitive, but... Wouldn't there need to be something that checks whether rowct is even or odd, and only shade for one or the other? In order to shade alternate rows...

I found a way to proceed in ACL (see code above), with Arbortext processing instructions.
Does someone knows if I can do the same with Fosi, i.e without inserting processing instructions in XML content ?

Thanks,
Sébastien

local $loidCaret = oid_caret();# should be a <table>
local $loidArrChildren[];
local $i = 0;
local $loid = oid_null();
local $loidChild = oid_null();
local $lintCellId = 0;
local $loidCellFont = oid_null();
local $lintRowId = 0;
local $lintRowIndex = 0;

oid_find_children($loidCaret, $loidArrChildren, 'entry', 0x04);
for ($i = 1; $i <= count($loidArrChildren); $i++)
{
$loid = $loidArrChildren[$i];

# gets Cell Id
$lintCellId = tbl_oid_cell($loid);
# gets oid of cellfont pi, if any
$loidCellFont = tbl_cell_fontpi($lintCellId, 'find');

# gets row id
$lintRowId = tbl_cell_row(lintCellId);
# gets row index
$lintRowIndex = tbl_row_index($lintRowId);

if (($lintRowIndex % 2) == 1)
{
# creates cellfont pi if it does not exist
if (!oid_valid($loidCellFont))
{
$loidCellFont = tbl_cell_fontpi($lintCellId, 'insert');
}
# modifies shading
oid_modify_attr($loidCellFont, 'Shading', 'gray2');
}
else
{
tbl_cell_fontpi($lintCellId, 'delete');
}
}
}

Le 22/05/2012 10:28, Sébastien Sauvage a écrit:Thanks for your answers.

When coursing a row, I can check in an ACL function, knowing its index (counter) i, the value of i % 2 (0 or 1) to apply shading.
But how in my Fosi can I apply shading to entire row (not cells one by one) ?

Regards,

Sébastien


Le 22/05/2012 00:26, Steve Thompson a écrit:Not where I can input the code and test, so not saying anything definitive, but... Wouldn't there need to be something that checks whether rowct is even or odd, and only shade for one or the other? In order to shade alternate rows...

HiSébastien!

The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.

Hope this helps! Please let me know any questions you may have.


Best regards,
Suzanne Napoleon
Suzanne Napoleon@FOSIexpert.com
"WYSIWYG is last-century technology!"

<counter initial="0" style="arabic" enumid="rowct">

<e-i-c gi="row">
<charlist inherit="1" charsubsetref="block">
<enumerat increm="1" enumid="rowct">
</charlist>
</e-i-c>

<e-i-c gi="entry" context="row">
<charlist inherit="1"></charlist>
<att>
<specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even">
<charsubset>
<usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>

</charsubset>
</att>
</e-i-c>


When I try this I am getting an error at the gray word, because the quote before it close the source string ... if I change to a single quote arround the gray word, it inserts the tag, but it is displayed as text ... Is my FOSI configured wrong?

Also, if I change the &lt; and &gt; to '<' and '>', the tag is not displayed, but it does not render either ...

 


@ptc-1908075 wrote:
HiSébastien!

The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.

Hope this helps! Please let me know any questions you may have.


Best regards,
Suzanne Napoleon
Suzanne Napoleon@FOSIexpert.com
"WYSIWYG is last-century technology!"

<counter initial="0" style="arabic" enumid="rowct">

<e-i-c gi="row">
<charlist inherit="1" charsubsetref="block">
<enumerat increm="1" enumid="rowct">
</charlist>
</e-i-c>

<e-i-c gi="entry" context="row">
<charlist inherit="1"></charlist>
<att>
<specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even">
<charsubset>
<usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>

</charsubset>
</att>
</e-i-c>



 

When I try this I am getting an error at the gray word, because the quote before it close the source string ... if I change to a single quote arround the gray word, it inserts the tag, but it is displayed as text ... Is my FOSI configured wrong?

Also, if I change the &lt; and &gt; to '<' and '>', the tag is not displayed, but it does not render either ...

There does not appear to be a way to handle row shading via the FOSI. I suggest using ACL.

 

Good luck!

Suzanne Napoleon

"WYSIWYG is last-century technology!"

But I am not doing row shading, I am doing cell shading, by adding the PI to the entry element ...

 

 <e-i-c gi="entry">
      <charlist inherit="1" charsubsetref="TypeTable">
			<indent inherit="0" rightind="0pt" firstln="*0pt">
			<presp minimum="0pt" nominal="0pt" maximum="0pt" priority="force">
			<textbrk startln="1" endln="1">
			<savetext textid="background.color" conrule='!<?Pub _cellfont Shading="gray"?>!'>
					<usetext source='background.color'></usetext>
	</charlist>

I expected this to make all the cells gray ... It does nothing. If this work, I will use an attribute on the cell (called background-color) to set the color of the shade.

 

If I do give up on the FOSI route, how do I trigger the ACL to create the PI? Do I use a callback or a Hook?

Unfortunately, a FOSI-generated PI for shading a table cell has no effect, so I suggest using ACL to find the desired <entry> elements and insert the PI.

 

If you format/print/create PDF from an open document, you can call your function from the command line before formatting/printing/creating PDF; for example:

 

add_Shading()

 

If you use a script to format/print/create PDF, add the function before the format/print/create PDF command.

 

Good luck!

Suzanne

Thanks, Suzanne!

 

I am looking at formating the table for display only ... I am looking for the correct event to trigger the code.

will formatbeforehook be called before the XML is rendered for display?

Should I trigger an ACL function from FOSI?

 

Thanks,

Yakir

This is now outside my area of expertise. I suggest you start a new subject asking for advice on calling an ACL function to insert cell shading PIs in tables when a document is opened. It sounds like you also want to remove those PIs before formatting the document and when the document is closed -- true?

 

Good luck!

Suzanne

Hello Suzanne.

Thank you for your response. It sounds very close to what I need.
In what you offer:
How to tell the FOSI to not insert text depending on the function return (typically 0 or 1). Is it with the value of "even" in your example ?How does the called ACL function know the context (oid ofentry element, rowct of row containing entry)?Sincerely,
Sébastien


Le 22/05/2012 19:15, Suzanne Napoleon a écrit:HiSébastien!
The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.
Hope this helps! Please let me know any questions you may have.

Best regards,Suzanne NapoleonSuzanne Napoleon@FOSIexpert.com "WYSIWYG is last-century technology!"
<counter initial="0" style="arabic" enumid="rowct">
<e-i-c gi="row"><charlist inherit="1" charsubsetref="block"><enumerat increm="1" enumid="rowct"></charlist></e-i-c>
<e-i-c gi="entry" context="row"><charlist inherit="1"></charlist><att><specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even"><charsubset><usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
</charsubset></att></e-i-c>

It's me again !

I found a few responses.
I've made an ACL function in a package called zzTables;
function testOK($win, $oid)
{
eval "call of testOK with win: $win and oid: $oid" output=>*;
return "1";
}
I updated my Fosi file with block:
<att>
<specval attname="zzTables::testOK" attloc="SYSTEM-FUNC" attval="1">
<charsubset>
<usetext source="!&lt;?Pub _cellfont Shading="gray5"?&gt;!"></usetext>
</charsubset>
</att>
But I have two sections for "entry":
one declared as this : <e-i-c gi="entry"> ...
an other as this : <e-i-c gi="entry" context="thead" *=" row&quot;="> ...
If I put the block in first section, function is called but shading is not applied ...
If I put it in second block, function is not called ...

I feel I'm near but I'm missing something.

Thanks for your help,
Sébastien



Le 23/05/2012 14:39, Sébastien Sauvage a écrit:Hello Suzanne.

Thank you for your response. It sounds very close to what I need.
In what you offer:
How to tell the FOSI to not insert text depending on the function return (typically 0 or 1). Is it with the value of "even" in your example ?How does the called ACL function know the context (oid ofentry element, rowct of row containing entry)?Sincerely,
Sébastien


Le 22/05/2012 19:15, Suzanne Napoleon a écrit:HiSébastien!
The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.
Hope this helps! Please let me know any questions you may have.

Best regards,Suzanne NapoleonSuzanne Napoleon@FOSIexpert.com "WYSIWYG is last-century technology!"
<counter initial="0" style="arabic" enumid="rowct">
<e-i-c gi="row"><charlist inherit="1" charsubsetref="block"><enumerat increm="1" enumid="rowct"></charlist></e-i-c>
<e-i-c gi="entry" context="row"><charlist inherit="1"></charlist><att><specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even"><charsubset><usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
</charsubset></att></e-i-c>

Try

return 1

without quotes.

OR try changing your test to

attval to "#EQ#\1\"

You may be getting a string vs. number mismatch.

(I like the former if this is the issue.)


You look very close, though. For what it's worth, here's an ACL we call
from the root element as a system-func to check whether or not to use a US
Letter or A4 collection of pagesets.


function us_letter_exists(win,oid) {
local exists = "no";
if (oid_xpath_boolean($oid,'/descendant::us_letter')) {
exists = "yes";
} # if
return exists
} # us_letter_exists


On Wed, May 23, 2012 at 6:17 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr<br/>> wrote:

> It's me again !
>
> I found a few responses.
> I've made an ACL function in a package called zzTables;
> function testOK($win, $oid)
> {
> eval "call of testOK with win: $win and oid: $oid" output=>*;
> return "1";
> }
> I updated my Fosi file with block:
> <att>
> <specval attname="zzTables::testOK" attloc="SYSTEM-FUNC" attval="1">
> <charsubset>
> <usetext source="!&lt;?Pub _cellfont Shading="gray5"?&gt;!"></usetext>
> </charsubset>
> </att>
> But I have two sections for "entry":
>
> - one declared as this : <e-i-c gi="entry"> ...
> - an other as this : <e-i-c gi="entry" context="thead" *=" row&quot;="> ...
>
> If I put the block in first section, function is called but *shading is
> not applied* ...
> If I put it in second block, function is not called ...
>
> I feel I'm near but I'm missing something.
>
> Thanks for your help,
> Sébastien
>
>
>
> Le 23/05/2012 14:39, Sébastien Sauvage a écrit :
>
> Hello Suzanne.
>
> Thank you for your response. It sounds very close to what I need.
> In what you offer:
>
> - How to tell the FOSI to not insert text depending on the function
> return (typically 0 or 1). Is it with the value of "even" in your
> example ?
> - How does the called ACL function know the context (oid of entry
> element, rowct of row containing entry)?
>
> Sincerely,
> Sébastien
>
>
> Le 22/05/2012 19:15, Suzanne Napoleon a écrit :
>
> Hi Sébastien!
>
> The PI for shading is inserted in <entry> tags, so it must be applied to
> <entry> rather than <row>. In the FOSI fragment below, the e-i-c for
> entry calls an ACL function named oddeven, which determines whether to
> insert the PI for shading.
>
> Hope this helps! Please let me know any questions you may have.
>
> Best regards,
> Suzanne Napoleon
> Suzanne Napoleon@FOSIexpert.com
> "WYSIWYG is last-century technology!"
>
> <counter initial="0" style="arabic" enumid="rowct">
>
> <e-i-c gi="row">
> <charlist inherit="1" charsubsetref="block">
> <enumerat increm="1" enumid="rowct">
> </charlist>
> </e-i-c>
>
> <e-i-c gi="entry" context="row">
> <charlist inherit="1"></charlist>
> <att>
> <specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even">
> <charsubset>
> <usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
> </charsubset>
> </att>
> </e-i-c>
>

Thanks Paul.
I've tried return 1 and return "1". It leads to the same result : function is called (tested with an eval call) but shading is not applied (i.e. processing instruction is not inserted by FOSI).

Regards,
Sébastien



Le 23/05/2012 18:04, Paul Nagai a écrit:Try

return 1

without quotes.

OR try changing your test to

attval to "#EQ#\1\"

You may be getting a string vs. number mismatch.

(I like the former if this is the issue.)


You look very close, though. For what it's worth, here's an ACL we call from the root element as a system-func to check whether or not to use a US Letter or A4 collection of pagesets.


function us_letter_exists(win,oid) {
local exists = "no";
if (oid_xpath_boolean($oid,'/descendant::us_letter')) {
exists = "yes";
} # if
return exists
} # us_letter_exists


On Wed, May 23, 2012 at 6:17 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr> wrote:
It's me again !

I found a few responses.
I've made an ACL function in a package called zzTables;
function testOK($win, $oid)
{
eval "call of testOK with win: $win and oid: $oid" output=>*;
return "1";
}
I updated my Fosi file with block:
<att>
<specval attname="zzTables::testOK" attloc="SYSTEM-FUNC" attval="1">
<charsubset>
<usetext source="!&lt;?Pub _cellfont Shading="gray5"?&gt;!"></usetext>
</charsubset>
</att>
But I have two sections for "entry":
one declared as this : <e-i-c gi="entry"> ...
an other as this : <e-i-c gi="entry" context="thead" *=" row&quot;="> ...
If I put the block in first section, function is called but shading is not applied ...
If I put it in second block, function is not called ...

I feel I'm near but I'm missing something.

Thanks for your help,
Sébastien



Le 23/05/2012 14:39, Sébastien Sauvage a écrit:Hello Suzanne.

Thank you for your response. It sounds very close to what I need.
In what you offer:
How to tell the FOSI to not insert text depending on the function return (typically 0 or 1). Is it with the value of "even" in your example ?How does the called ACL function know the context (oid ofentry element, rowct of row containing entry)?Sincerely,
Sébastien


Le 22/05/2012 19:15, Suzanne Napoleon a écrit:HiSébastien!
The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.
Hope this helps! Please let me know any questions you may have.

Best regards,Suzanne NapoleonSuzanne Napoleon@FOSIexpert.com "WYSIWYG is last-century technology!"
<counter initial="0" style="arabic" enumid="rowct">
<e-i-c gi="row"><charlist inherit="1" charsubsetref="block"><enumerat increm="1" enumid="rowct"></charlist></e-i-c>
<e-i-c gi="entry" context="row"><charlist inherit="1"></charlist><att><specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even"><charsubset><usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
</charsubset></att></e-i-c>

My next strategy would be to try calling it from something very simple
(maybe <para>) and applying a color to be sure you've got everything right
and that the only thing you're fighting is the table row logic. If you can
get para working, then apply color to a cell. Then see if you can get it to
alternate. Then try the shading PI.

Or some similar simplification of the problems at hand.

On Wed, May 23, 2012 at 9:18 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr<br/>> wrote:

> Thanks Paul.
> I've tried return 1 and return "1". It leads to the same result :
> function is called (tested with an eval call) but shading is not applied
> (i.e. processing instruction is not inserted by FOSI).
>
> Regards,
> Sébastien
>
>
>
> Le 23/05/2012 18:04, Paul Nagai a écrit :
>
> Try
>
> return 1
>
> without quotes.
>
> OR try changing your test to
>
> attval to "#EQ#\1\"
>
> You may be getting a string vs. number mismatch.
>
> (I like the former if this is the issue.)
>
>
> You look very close, though. For what it's worth, here's an ACL we call
> from the root element as a system-func to check whether or not to use a US
> Letter or A4 collection of pagesets.
>
>
> function us_letter_exists(win,oid) {
> local exists = "no";
> if (oid_xpath_boolean($oid,'/descendant::us_letter')) {
> exists = "yes";
> } # if
> return exists
> } # us_letter_exists
>
>
> On Wed, May 23, 2012 at 6:17 AM, Sébastien Sauvage <
> sebastien.sauvage@c-s.fr> wrote:
>
>> It's me again !
>>
>> I found a few responses.
>> I've made an ACL function in a package called zzTables;
>> function testOK($win, $oid)
>> {
>> eval "call of testOK with win: $win and oid: $oid" output=>*;
>> return "1";
>> }
>> I updated my Fosi file with block:
>> <att>
>> <specval attname="zzTables::testOK" attloc="SYSTEM-FUNC" attval="1">
>> <charsubset>
>> <usetext source="!&lt;?Pub _cellfont Shading="gray5"?&gt;!"></usetext>
>> </charsubset>
>> </att>
>> But I have two sections for "entry":
>>
>> - one declared as this : <e-i-c gi="entry"> ...
>> - an other as this : <e-i-c gi="entry" context="thead" *=" row&quot;="> ...
>>
>> If I put the block in first section, function is called but *shading is
>> not applied* ...
>> If I put it in second block, function is not called ...
>>
>> I feel I'm near but I'm missing something.
>>
>> Thanks for your help,
>> Sébastien
>>
>>
>>
>> Le 23/05/2012 14:39, Sébastien Sauvage a écrit :
>>
>> Hello Suzanne.
>>
>> Thank you for your response. It sounds very close to what I need.
>> In what you offer:
>>
>> - How to tell the FOSI to not insert text depending on the function
>> return (typically 0 or 1). Is it with the value of "even" in your
>> example ?
>> - How does the called ACL function know the context (oid of entry
>> element, rowct of row containing entry)?
>>
>> Sincerely,
>> Sébastien
>>
>>
>> Le 22/05/2012 19:15, Suzanne Napoleon a écrit :
>>
>> Hi Sébastien!
>>
>> The PI for shading is inserted in <entry> tags, so it must be applied
>> to <entry> rather than <row>. In the FOSI fragment below, the e-i-c for
>> entry calls an ACL function named oddeven, which determines whether to
>> insert the PI for shading.
>>
>> Hope this helps! Please let me know any questions you may have.
>>
>> Best regards,
>> Suzanne Napoleon
>> Suzanne Napoleon@FOSIexpert.com
>> "WYSIWYG is last-century technology!"
>>
>> <counter initial="0" style="arabic" enumid="rowct">
>>
>> <e-i-c gi="row">
>> <charlist inherit="1" charsubsetref="block">
>> <enumerat increm="1" enumid="rowct">
>> </charlist>
>> </e-i-c>
>>
>> <e-i-c gi="entry" context="row">
>> <charlist inherit="1"></charlist>
>> <att>
>> <specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even">
>> <charsubset>
>> <usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
>> </charsubset>
>> </att>
>> </e-i-c>
>>
>

I've made an other ACL code wich hardly insert the processing instruction, only using ACL functions, and it works.
The problem is it that it needs a user action or an initialization script to be called; that's not "clean".
So the processing instruction, as Suzanne wrote, is valid for element <entry>.
I don't understand why Fosi does not insert it. I will try to isolate the problem ...

Regards,
Sébastien


Le 23/05/2012 18:29, Paul Nagai a écrit:My next strategy would be to try calling it from something very simple (maybe <para>) and applying a color to be sure you've got everything right and that the only thing you're fighting is the table row logic. If you can get para working, then apply color to a cell. Then see if you can get it to alternate. Then try the shading PI.

Or some similar simplification of the problems at hand.

On Wed, May 23, 2012 at 9:18 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr> wrote:
Thanks Paul.
I've tried return 1 and return "1". It leads to the same result : function is called (tested with an eval call) but shading is not applied (i.e. processing instruction is not inserted by FOSI).

Regards,
Sébastien



Le 23/05/2012 18:04, Paul Nagai a écrit:Try

return 1

without quotes.

OR try changing your test to

attval to "#EQ#\1\"

You may be getting a string vs. number mismatch.

(I like the former if this is the issue.)


You look very close, though. For what it's worth, here's an ACL we call from the root element as a system-func to check whether or not to use a US Letter or A4 collection of pagesets.


function us_letter_exists(win,oid) {
local exists = "no";
if (oid_xpath_boolean($oid,'/descendant::us_letter')) {
exists = "yes";
} # if
return exists
} # us_letter_exists


On Wed, May 23, 2012 at 6:17 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr> wrote:
It's me again !

I found a few responses.
I've made an ACL function in a package called zzTables;
function testOK($win, $oid)
{
eval "call of testOK with win: $win and oid: $oid" output=>*;
return "1";
}
I updated my Fosi file with block:
<att>
<specval attname="zzTables::testOK" attloc="SYSTEM-FUNC" attval="1">
<charsubset>
<usetext source="!&lt;?Pub _cellfont Shading="gray5"?&gt;!"></usetext>
</charsubset>
</att>
But I have two sections for "entry":
one declared as this : <e-i-c gi="entry"> ...
an other as this : <e-i-c gi="entry" context="thead" *=" row&quot;="> ...
If I put the block in first section, function is called but shading is not applied ...
If I put it in second block, function is not called ...

I feel I'm near but I'm missing something.

Thanks for your help,
Sébastien



Le 23/05/2012 14:39, Sébastien Sauvage a écrit:Hello Suzanne.

Thank you for your response. It sounds very close to what I need.
In what you offer:
How to tell the FOSI to not insert text depending on the function return (typically 0 or 1). Is it with the value of "even" in your example ?How does the called ACL function know the context (oid ofentry element, rowct of row containing entry)?Sincerely,
Sébastien


Le 22/05/2012 19:15, Suzanne Napoleon a écrit:HiSébastien!
The PI for shading is inserted in <entry> tags, so it must be applied to <entry> rather than <row>.In the FOSI fragment below, the e-i-c for entry calls an ACL function named oddeven, which determines whether to insert the PI for shading.
Hope this helps! Please let me know any questions you may have.

Best regards,Suzanne NapoleonSuzanne Napoleon@FOSIexpert.com "WYSIWYG is last-century technology!"
<counter initial="0" style="arabic" enumid="rowct">
<e-i-c gi="row"><charlist inherit="1" charsubsetref="block"><enumerat increm="1" enumid="rowct"></charlist></e-i-c>
<e-i-c gi="entry" context="row"><charlist inherit="1"></charlist><att><specval attname="oddeven" attloc="SYSTEM-FUNC" attval="even"><charsubset><usetext source="!&lt;?Pub _cellfont Shading="gray"?&gt;!"></usetext>
</charsubset></att></e-i-c>

When the ACL below returns even, a usetext outputs the processing instruction. When gentexttagdisplay is set to full, the PI shows in the Edit window. However, when the doc is previewed, the shading does not appear. I'm thinking the table needs to be output as a gentable for this to work.

function oddeven(window,oid)
{
$n=fosivar_value(window,"rowct.txt",oid);
if (($n % 2) == 1) {return "odd"};
if (($n % 2) == 0) {return "even"};
}



Thanks Suzanne.

I'm not sure to well understand.
Now my problem is not in the treatment of the function.
It is that, like in the sample I post, the shading is not applied by the FOSI (processing instruction is not inserted).

Regards,
Sébastien

Le 23/05/2012 18:51, Suzanne Napoleon a écrit:When the ACL below returns even, a usetext outputs the processing instruction. When gentexttagdisplay is set to full, the PI shows in the Edit window. However, when the doc is previewed, the shading does not appear. I'm thinking the table needs to be output as a gentable for this to work.
function oddeven(window,oid){$n=fosivar_value(window,"rowct.txt",oid);if (($n % 2) == 1) {return "odd"};if (($n % 2) == 0) {return "even"};}

In my case, the processing instruction is inserted, but it is ignored.

The only other approach I can think of is to output the table as a gentable. Go to my website at

Brute force idea: Purge and write the processing instructions to each table
on each save. Or, using a slightly smaller hammer, provide a menu selection
to do so manually before submitting a composition request. Or attach it to
a compose hook (is that the right name for that hook?) ...

On Wed, May 23, 2012 at 7:10 PM, Suzanne Napoleon <
SuzanneNapoleon@fosiexpert.com> wrote:

> In my case, the processing instruction is inserted, but it is ignored.
>
> The only other approach I can think of is to output the table as a
> gentable. Go to my website at

Suzanne & Paul, thanks for your Help.

Gentable way cannot be used in the context of my project, as there is a large volume of existing data, consisting in XML documents following specific DTD with Cals/Oasis model.
Brute force way is, I think, the function I proposed in a previous mail, which is intended to be called from a custom menu:

function ToBeCalledFromSpecificMenu()

local $loidCaret = oid_caret();# should be a <table>
local $loidArrChildren[];
local $i = 0;
local $loid = oid_null();
local $lintCellId = 0;
local $loidCellFont = oid_null();
local $lintRowId = 0;
local $lintRowIndex = 0;

# todo : check that $loidCaret is a <table>

oid_find_children($loidCaret, $loidArrChildren, 'entry', 0x04);
for ($i = 1; $i <= count($loidArrChildren); $i++)
{
$loid = $loidArrChildren[$i];

# gets Cell Id
$lintCellId = tbl_oid_cell($loid);
# gets oid of cellfont pi, if any
$loidCellFont = tbl_cell_fontpi($lintCellId, 'find');

# gets row id
$lintRowId = tbl_cell_row(lintCellId);
# gets row index
$lintRowIndex = tbl_row_index($lintRowId);

if (($lintRowIndex % 2) == 1)
{
# creates cellfont pi if it does not exist
if (!oid_valid($loidCellFont))
{
$loidCellFont = tbl_cell_fontpi($lintCellId, 'insert');
}
# modifies shading
oid_modify_attr($loidCellFont, 'Shading', 'gray2');
}
else
{
tbl_cell_fontpi($lintCellId, 'delete');
}
}
}
This function inserts desired processing instructions and cleans existing ones.
It works, but a method using the FOSI would be more flexible, because without user interaction.
I'll have to content myself with this brute force solution.

Sincerely,
Sébastien

Le 24/05/2012 06:06, Paul Nagai a écrit:
Brute force idea: Purge and write the processing instructions to each table on each save. Or, using a slightly smaller hammer, provide a menu selection to do so manually before submitting a composition request. Or attach it to a compose hook (is that the right name for that hook?) ...

Consider the following "features" you might want to include in this
solution. Some features might be mutually exclusive.

Using a unique color name that is sure not to be used by an author. It can
be defined to duplicate your gray of choice.
Removing previous shading, if it exists, before writing current shading.
(The previous feature helps this one.)
Removing the shading on file close.
Removing/Adding the shading on file save.
Special handling for table header and/or footer rows.

On Thu, May 24, 2012 at 5:50 AM, Sébastien Sauvage <sebastien.sauvage@c-s.fr<br/>> wrote:

> Suzanne & Paul, thanks for your Help.
>
> *Gentable *way cannot be used in the context of my project, as there is a
> large volume of existing data, consisting in XML documents following
> specific DTD with Cals/Oasis model.
> *Brute force* way is, I think, the function I proposed in a previous
> mail, which is intended to be called from a custom menu:
>
> function ToBeCalledFromSpecificMenu()
>
>
> local $loidCaret = oid_caret();# should be a <table>
> local $loidArrChildren[];
> local $i = 0;
> local $loid = oid_null();
> local $lintCellId = 0;
> local $loidCellFont = oid_null();
> local $lintRowId = 0;
> local $lintRowIndex = 0;
>
> # todo : check that $loidCaret is a <table>
>
>
> oid_find_children($loidCaret, $loidArrChildren, 'entry', 0x04);
> for ($i = 1; $i <= count($loidArrChildren); $i++)
> {
> $loid = $loidArrChildren[$i];
>
> # gets Cell Id
> $lintCellId = tbl_oid_cell($loid);
> # gets oid of cellfont pi, if any
> $loidCellFont = tbl_cell_fontpi($lintCellId, 'find');
>
> # gets row id
> $lintRowId = tbl_cell_row(lintCellId);
> # gets row index
> $lintRowIndex = tbl_row_index($lintRowId);
>
> if (($lintRowIndex % 2) == 1)
> {
> # creates cellfont pi if it does not exist
> if (!oid_valid($loidCellFont))
> {
> $loidCellFont = tbl_cell_fontpi($lintCellId, 'insert');
> }
> # modifies shading
> oid_modify_attr($loidCellFont, 'Shading', 'gray2');
> }
> else
> {
> tbl_cell_fontpi($lintCellId, 'delete');
> }
> }
> }
>
> This function inserts desired processing instructions and cleans existing
> ones.
> It works, but a method using the FOSI would be more flexible, because
> without user interaction.
> I'll have to content myself with this *brute force* solution.
>
> Sincerely,
> Sébastien
>
> Le 24/05/2012 06:06, Paul Nagai a écrit :
>
>
> Brute force idea: Purge and write the processing instructions to each
> table on each save. Or, using a slightly smaller hammer, provide a menu
> selection to do so manually before submitting a composition request. Or
> attach it to a compose hook (is that the right name for that hook?) ...
>
> On Wed, May 23, 2012 at 7:10 PM, Suzanne Napoleon <
> SuzanneNapoleon@fosiexpert.com> wrote:
>
>> In my case, the processing instruction is inserted, but it is
>> ignored.
>>
>> The only other approach I can think of is to output the table as a
>> gentable. Go to my website at

Special handling for spanned/merged cells.

Top Tags