Another Index question: savetext during index processing?

[naglists]

You might recall I'm working on an index based on the parts index described
in help 70. I currently have it formatted using the recommended algroup
strategy. My customer would like it to format as a table. I have FOSI code
that creates a table based on the recursive nesting of ixentry. However,
it's not working in the "real" index.

What am I missing that the following e-i-c will generate the correct output
in my algroup formatting but it will not populate field-index_row.app? At
least I believe that is the error ... that somehow the variable storing all
the rows of my semantic table isn't processed like other such variables
during the index processing.

<e-i-c gi="ixhead" context="ixentry">
<charlist inherit="1" charsubsetref="red">
<indent inherit="0" leftind="0in" rightind="*+1in" firstln="*">
<quadding quad="center" lastquad="lcenter">
<algroup refpoint="first">
<savetext textid="field-index_row.app"&lt;br"/>conrule='!<row><entry><para>!,#CONTENT,!</para></entry>!' append="1">
</charlist>
</e-i-c>

Not sure these last bits are relevant, but just in case ... here they are:

Ignoring the unused portions of the indexing content model, I believe it
nets out to this:
ixentry (ixhead, ixentry)*

Here is a sample of the markup I have working if the tags are actually
entered into a document (bypassing the index processing):
<para><ixentry>
<ixhead>Apple</ixhead>
<ixentry><ixhead>Orange</ixhead>
<ixentry><ixhead>Banana</ixhead>
<ixentry><ixhead>Grape</ixhead>
<ixentry><ixhead>Cherry</ixhead>
<ixentry></ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</para>

--
Paul Nagai

[ptc-1787870]

Ugh.

If you can get the formatting to appear like a table using algroup, as
shown in the example in Help 70, then isn't that good enough? You must
have some *tough* customers.

I expect you are calling field-index_row.app from your index element and
not seeing anything? Where is the end tag for your row?

I would try experimenting with a simple test variable until I was sure
that the timing of the savetext/usetext combo was right. Try replacing
field-index_row.app with something else (e.g. test.app that has a conrule
of !test!, then #CONTENT, then table mark-up, etc.). Depending on what
works and what doesn't, you may need to pass variables from one to
another.

There's also the set gentexttagdisplay=full setting to see how things are
laying out in Editor...this may give you more information about what's
happening in the index.

I'd also look more into the "format as a table" requirement. If all the
customer wants is rules, then perhaps you can simulate that with a
different effect using your algroup approach. Would something like boxing
be able to help there?

Hope that helps,
Jason






"Paul Nagai" <->
08/02/2007 10:45 AM
Please respond to
-


To
-
cc

Subject
[adepters] - Another Index question: savetext during index processing?






You might recall I'm working on an index based on the parts index
described in help 70. I currently have it formatted using the recommended
algroup strategy. My customer would like it to format as a table. I have
FOSI code that creates a table based on the recursive nesting of ixentry.
However, it's not working in the "real" index.

What am I missing that the following e-i-c will generate the correct
output in my algroup formatting but it will not populate
field-index_row.app? At least I believe that is the error ... that somehow
the variable storing all the rows of my semantic table isn't processed
like other such variables during the index processing.

<e-i-c gi="ixhead" context="ixentry">
<charlist inherit="1" charsubsetref="red">
<indent inherit="0" leftind="0in" rightind="*+1in" firstln="*">
<quadding quad="center" lastquad="lcenter">
<algroup refpoint="first">
<savetext textid="field-index_row.app" <br="/>conrule='!<row><entry><para>!,#CONTENT,!</para></entry>!' append="1">
</charlist>
</e-i-c>

Not sure these last bits are relevant, but just in case ... here they are:


Ignoring the unused portions of the indexing content model, I believe it
nets out to this:
ixentry (ixhead, ixentry)*

Here is a sample of the markup I have working if the tags are actually
entered into a document (bypassing the index processing):
<para><ixentry>
<ixhead>Apple</ixhead>
<ixentry><ixhead>Orange</ixhead>
<ixentry><ixhead>Banana</ixhead>
<ixentry><ixhead>Grape</ixhead>
<ixentry><ixhead>Cherry</ixhead>
<ixentry></ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</para>

--
Paul Nagai
-----End Original Message-----

[ptc-1908075]

Here's a tip for debugging gentables: Add userule=1 to the usetext that outputs the appended variable with the gentable. Then you can check the FOSI-generated external file to see exactly what is in the variable.

Good luck!
Suzanne Napoleon
www.FOSIexpert.com



You might recall I'm working on an index based on the parts index described in help 70. I currently have it formatted using the recommended algroup strategy. My customer would like it to format as a table. I have FOSI code that creates a table based on the recursive nesting of ixentry. However, it's not working in the "real" index.

What am I missing that the following e-i-c will generate the correct output in my algroup formatting but it will not populate field-index_row.app? At least I believe that is the error ... that somehow the variable storing all the rows of my semantic table isn't processed like other such variables during the index processing.

<e-i-c gi="ixhead" context="ixentry">
<charlist inherit="1" charsubsetref="red">
<indent inherit="0" leftind="0in" rightind="*+1in" firstln="*">
<quadding quad="center" lastquad="lcenter">
<algroup refpoint="first">
<savetext textid="field-index_row.app" conrule="!&lt;row&gt;&lt;entry&gt;&lt;para&gt;!,#CONTENT,!&lt;/para&gt;&lt;/entry&gt;!" append="1">
</charlist>
</e-i-c>

Not sure these last bits are relevant, but just in case ... here they are:

Ignoring the unused portions of the indexing content model, I believe it nets out to this:
ixentry (ixhead, ixentry)*

Here is a sample of the markup I have working if the tags are actually entered into a document (bypassing the index processing):
<para><ixentry>
<ixhead>Apple</ixhead>
<ixentry><ixhead>Orange</ixhead>
<ixentry><ixhead>Banana</ixhead>
<ixentry><ixhead>Grape</ixhead>
<ixentry><ixhead>Cherry</ixhead>
<ixentry></ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</ixentry>
</para>

--
Paul Nagai

[naglists]

On 8/2/07, Jason Aiken <jason.aiken@jeppesen.com> wrote:
>
> Ugh.


You took the words right out of my mouth!


If you can get the formatting to appear like a table using algroup, as
> shown in the example in Help 70, then isn't that good enough? You must
> have some *tough* customers. 😉


It's actually customers behind my customers. They are *very*
format-conscious. I don't pretend to understand their business ... but
sometimes I don't understand the requirements. (Not technically don't
understand, but the justification thereof ... is .1mm *really* going to make
a difference!??)


I expect you are calling field-index_row.app from your index element and
> not seeing anything? Where is the end tag for your row?


I only included one ixhead e-i-c. There are five. This is the first. The
middles only have entrys. The last has the closing row tag. I'm calling
field-index_row.app from a pseudo element like the one described in Help 70.
The pseudo element is called from something called field_index_anchor. I
guess I could try calling the .app directly from the legit element. Anyone
think that should matter?

Another question I had was about all of the index markup. Is any of that
required in the DTD? It works fine for the algroup formatting not being in
the DTD. I had to add it to my test application since I was creating "live"
markup, not processing an index, to test my semantic table semantics.


I would try experimenting with a simple test variable until I was sure
> that the timing of the savetext/usetext combo was right. Try replacing
> field-index_row.app with something else (e.g. test.app that has a conrule
> of !test!, then #CONTENT, then table mark-up, etc.). Depending on what
> works and what doesn't, you may need to pass variables from one to
> another.


I think this is the trick to what I'm trying to do ... or limitation
preventing me. I went through several gyrating variations on my savetexts
and related usetext sources and I don't think I hit the right one (and maybe
it's not possible) to savetext within the index processing "loop" or
"pipeline" or "pass" or whatever subroutine is handling things.

I'm pretty sure, based on "replicating" the
ixentry/ixhead/ixentry/ixhead.... tagging structure *in* a document, that my
semantic table markup is right.

I'm pretty sure, based on simple savetext/usetext tests, that the ixhead
e-i-cs will emit content but not save it. OR that some subsequent processing
pass/step purges my allegedly time independent variable (status="1")
field-index_row.app. OR maybe that a special environment is set up for index
processing in which the variable is time independent, but then that
environment is dropped once the output is created.

(This is starting to sound like a conspiracy theory!)

ANYHOW ... can you say more about tricks for saving and passing variables?
Maybe I have to save my row content to time dependent variables and then
save them all at once to the time independent variable?


There's also the set gentexttagdisplay=full setting to see how things are
> laying out in Editor...this may give you more information about what's
> happening in the index.


I hadn't thought of that. Hmm. Would that reveal final index markup, though?
I think there is preliminary index markup that would be available to Editor.
But I can see what you're saying ... maybe that would show something.
Thanks.


I'd also look more into the "format as a table" requirement. If all the
> customer wants is rules, then perhaps you can simulate that with a
> different effect using your algroup approach. Would something like boxing
> be able to help there?


The version they have now and are passing back to their customer has
horizontal rules inside of the algroup markup. It's wrapped in markup that
functions like a table title. So, compared to the style of other tables in
their "library," it's missing vertical rules, the last rule on the page *IF*
the index breaks across a page, and a repeating table header. Hopefully
it'll fly.

I tried boxing but waved off when I saw what happened when the content of
one of the "cells" wraps: Sibling cells don't increase their depth. Yikes.

Thanks for the thoughts!

--
Paul Nagai

[naglists]

On 8/2/07, Suzanne Napoleon <suzannenapoleon@fosiexpert.com> wrote:
>
> Here's a tip for debugging gentables: Add userule=1 to the usetext that
> outputs the appended variable with the gentable. Then you can check the
> FOSI-generated external file to see exactly what is in the variable.


Excellent! Thanks. I'll give that a shot.

--
Paul Nagai

[ptc-1787870]

> the justification thereof ... is .1mm *really*
> going to make a difference!??

I think this is the FOSI developer's mantra. There's attention to detail
and then there's insanity. The boundary between the two tends to vary
widely among humankind. As long as someone somewhere along the
requirements chain makes an attempt to justify cost/benefit, I'll do what
I can to appease.

> I only included one ixhead e-i-c. There are five.
> This is the first. The middles only have entrys.
> The last has the closing row tag. I'm calling
> field-index_row.app from a pseudo element like
> the one described in Help 70. The pseudo element is
> called from something called field_index_anchor. I
> guess I could try calling the .app directly from the
> legit element. Anyone think that should matter?

Somehow I knew we were glimpsing the tip of the iceberg. Calling the .app
from the legit element may be worth a try; I thought you would have gone
through the steps of creating the right table mark-up. It does sound more
like a matter of finding the right variable & timing combination. Be
creative, make multiple back-ups, hold on tight, and accept my apologies
for not being able to dive deeper into all the details with you! (I'm
LEP-ifying our FOSI right now.)

> I went through several gyrating variations on my
> savetexts and related usetext sources and I don't
> think I hit the right one (and maybe it's not
> possible) to savetext within the index processing
> "loop" or "pipeline" or "pass" or whatever subroutine
> is handling things.

I hate saying anything in FOSI is impossible. That only inspires someone
to prove me wrong (again). However, I support the hypothesis that the
Arbortext index processing may be doing something to get in the way here.

> ANYHOW ... can you say more about tricks for
> saving and passing variables? Maybe I have to
> save my row content to time dependent variables
> and then save them all at once to the time independent
> variable?

It sounds like you are already doing this to some extent with
pseudo-elements and your other gyrations. Maybe you can get different
results and support easier maintenance if you can save your #CONTENT in
one place and then stitch it together with your row mark-up later.

The forward-referencing variables can be tricky. In my recent LEP
experience, for example, I was trying to create chapter-level dividers to
organize the page hits. Saving to the .app variable didn't work so well
when I was trying to do it from within the context of styledesc and
pagedesc. The styledesc call to the variable was simply ignored.

You don't have styledesc/pagedesc barriers here, but you do have your
legit elements, your preliminary index mark-up, and your final index
mark-up. I'd systematically try each of these with a simple test scenario
until I could get the index content to come out with some custom element
mark-up. So far, doing it in the final index mark-up appears too late to
achieve the effect you desire. Perhaps there's some variable magic between
the legit elements and the preliminary mark-up that will circumvent the
index processing issue (if that is an issue).

As many of the high FOSI techno-priests have said, "the sooner you code,
the longer it takes."

> The version they have now and are passing back to
> their customer has horizontal rules inside of the algroup markup.

It sounds like a well-placed FOSI rule may help here. I agree that the
boxing can do weird things, but if you can create some sort of wrapper
that can act like a <row> and generate a rule, who knows.

> Thanks for the thoughts!

No problem. I hope my light drizzle of a brainstorm provides some relief.
Back to my relatively simple life of LEPs, table templates, and
"Intentionally Left Blank" pages...




"Paul Nagai" <->
08/02/2007 11:43 AM
Please respond to
-


To
-
cc

Subject
[adepters] - RE: Another Index question: savetext during index processing?