algroup-fu needed

[naglists]

Hiya,
I've got a complex procedural data model and associated FOSI coding that
output the following information in "three columns":
actor
step number
task

Sometimes the task needs to be wider than the space allocated to it by the
algroup. (For example, when it contains a results screen.) I can cause that
element's content to take more space than allocated, but I can't do it
without having the task content format below the last line of the deepest of
the first two algroups.

Correct output:
Bob 1 Do this thing

But if it is wide it looks like this
Bob 1
do this thing and do it right and don't forget to tell someone you
did it

It is never actually the first line of the task that needs the extra space
so I don't have any risk of overwriting the step number. Theoretically if
the actor name (or list) is long enough, and my wide element wide enough,
those two could overwrite, but I should be able to "recover" at least the
width of the step "column."

If there is a trick.

Does this make sense? (Sorry for "drawing" with ASCII.)

--
Paul Nagai

[ptc-1908075]

With algroup, text flows within fixed-width columns that are created with indents in the FOSI. For example:

[naglists]

Thanks, Suzanne. I don't recall seeing overset warnings, but I may have them
suppressed (and my memory isn't sharp like it used to be). What I'm looking
for is, I think, a hack or a trick. This is the output I'd like to be able
to get, if i need more width in "col3":
Bob, 3 do this thing and
Jo, do it right and
Tom don't forget to
tell someone you
did it

do more in step 3

do more in step 3

oh, now here's the long line


What I actually get is:

[ebenton]

I don't think you get any warnings for overlapping of indents when using
algroup formatting. It just does the "stair-stepping" that you show.
If the left-indent for "TASK" is physically located to the right of
right-indent for "STEP", this will happen. It is a little bit difficult
to figure out, in that you have to count the left-indent from the left
margin and the right-indent from the right margin and make sure they
don't overlap.

[jkaplansky]

More so, I believe that the last line of the last group ("oh, now
there's a long line") is the source of the stair stepping since the
indent on the last element in that last column determines whether or not
the line will fit. If memory serves, there's no such thing as a margin
release in algroup.



How important is it to "get more width" in col. 3? You might be able to
do a markup+touchup workaround to achieve the effect you're looking for
depending on how semantic the markup for the last line (yes. I mean
fudge it.)



-Jean K

[naglists]

There are lots of occurrences where the task is falling off the line. I
don't think it makes the information unusable, but it doesn't look very
professional ... If I can't cheat my way around the algroup limitations,
I'll have to recode that whole construct. Ugh.

[steve.thompson4]

I obviously missed something. How did you get the last line to not wrap,
if you're using the same column parameters?


Steve Thompson
(316)977-0515

[naglists]

You didn't miss anything. I still can't prevent it from wrapping. That said,
I just got an off-list suggestion that might work.

Have the authors set an attribute which when found causes a different
algroup set to be called. One where col1 = col1 width in the "normal," 3col
algroup, and where col2 = col2+col3 width. Aha! Maybe. Also, my users are
breaking col3 now by setting a child of element representing col3 to pgwide,
so maybe I can actually trigger the second, two-col algroup, by looking for
that child/@pgwide=yes.

The tricky bit will be that there are a handful of children that might set
pgwide.


On Thu, Sep 11, 2008 at 10:31 AM, EXT-Thompson, Steve <
steve.thompson2@boeing.com> wrote:

> I obviously missed something. How did you get the last line to not wrap,
> if you're using the same column parameters?
>
>
> *Steve Thompson*
> (316)977-0515
>

[steve.thompson4]

Obviously didn't make myself clear.
Below, where you say "What I actually get is:", how do you get that last
line to not wrap? I realize the 'not wrap' is triggering the behavior
you don't want, but I'm not clear as to how you're getting it, so have
no way of analyzing how that might trigger something else.

Yeah, my question/explanation is really clear, too... 😕
Steve Thompson
(316)977-0515

[ptc-1908075]

Assuming para is the child element in task, if each para in task can have its own wider column, then step 4 below shows the extra vertical space (in gray) that will occur when the Actor column happens to be deeper than the first para in task.

ACTOR STEP TASK

[naglists]

While not ideal, the following would probably be acceptable ... at least the
most distracting "error" of the first line formatting below the gray line
(what I'm getting now) would be fixed.


Bob, 4 do it again
> Jo,
> Tom
> oh, here's a long line
> that spans 2 columns
>
> do more in step 4

[naglists]

Oh, sorry!

Sometimes authors need to show content that should not break. Long commands.
System responses. Mainframe screen captures. Etc. All of these elements are
formatted as non-flowing/breaking text. It's late in the day and my brain
has apparently checked out and I can't remember the "technical" FOSI name
for that. Anyhow, when those don't fit in the text column, authors often
have a couple of options, smallify the font, go page wide (rather than in
our offset text column).

In my problem, technically, it's not the not-wrapping that is causing the
problem. (The too-wide text "happily" launches through the right margin and
beyond.) It's when the author chooses pgwide="yes" to fix that problem, that
FOSI forces it to align too far to the left colliding with the algroup area
for "col2."

Is that what you were after? If it's the FOSI language for "don't break me
no matter what" ... <xmp> from HTML ... as I said earlier, that word has
left my brain for today. Hopefully someone else will remind us (or I'll
update this thread tomorrow).

On Thu, Sep 11, 2008 at 1:31 PM, EXT-Thompson, Steve <
steve.thompson2@boeing.com> wrote:

> Obviously didn't make myself clear.
> Below, where you say "What I actually get is:", how do you get that last
> line to not wrap? I realize the 'not wrap' is triggering the behavior you
> don't want, but I'm not clear as to how you're getting it, so have no way of
> analyzing how that might trigger something else.
>
> Yeah, my question/explanation is really clear, too... 😕
> *Steve Thompson*
> (316)977-0515

[steve.thompson4]

Paul,
Thanks for the explanatory reply on the other thread.

Looks like Suzanne is on the same track I am, so I'll bow out for now
with this one suggestion:
If tables are the 'spawn of satan', then semantic tables (FOSI
generated) are their ugly aunts and uncles. At least, judging from the
difficulties they've generated around here. Don't use 'em if you can
avoid 'em.

Looking forward to seeing the solution,
Steve Thompson
(316)977-0515

[ptc-1908075]

As-is
quadding allows authors to enter multiple spaces and line breaks. Note
that an as-is element must be a block element. It starts a new line and continues on the same line, even
oversetting off the page, unless an authored line break starts a new
line. Coding as-is quadding for an inline element has no effect in my testing.

Keep-together with scope=line (keep-line), on the other hand, can be coded for an inline
element. If an element with keep-line oversets the current line, the
formatting engine tries to fix the oveset by moving the element content
to the beginning of the next line. If the text still oversets the line,
a line overset fault is reported (unless fmtfaultlineoverset is set otherwise). The previous line be underfull as well.


BTW:
I neglected to mention that any eic with yalgroup will not
break at a page or column break, so if you want column and page breaks
to be allowed within a Task, don't include algroup in the eic. When
algroup alignment is set to first, usually algroup needs to be coded
only in the eic for the first column, and does not need to be coded for
the eic for the last column (in this case, the task column). But my
experience is that sometimes algroup is needed in more than the first
eic. On the other hand, all rows in a gentable are unbreakable unless
deepcontentsplitting is enabled.

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