Re: Vertical margin bars

[Jeff Kingston]

Definitely a job for PostScript magic, I would say.  Margin notes
are certainly the model to follow; they don't just get dumped in
the margin, they store PostScript state which allows them to not
bump into each other.  In the same way you would need to store
the starting point of each margin bar in PostScript state.  The
hard bit would be obtaining a hook which fired up at the end of
the column or page to actually draw a line when the line goes
over the column or page.  You'd probably have to insert something
into dsf's page definitions for that.

Another nasty problem would be telling the following page that
a line was continuing from the previous one.  This is looking
like a roadblock, because Lout's PostScript pages are independent
of each other - page n cannot inherit PostScript state from
page n-1.

One approach I can think of is to use the expert's guide symbols
which are used for running table headers.  They allow you to
get arbitrary Lout into a galley at the start and end of each
column.  (Hmm, not sure about at the end, but that could be
looked into.)  If the arbitrary Lout was a call on a @Graphic
symbol that did the right PostScript stuff, you'd have it.

So my off-the-cuff suggestion would be to delimit the margin
bar region by calls like @MarginBarBegin and @MarginBarEnd.
@MarginBarBegin would set a PostScript variable to the start
point of the bar, and @MarginBarEnd would find the end point
and draw the line from the previously stored start point.

To handle column and page boundaries, @MarginBarBegin would
use the running headers symbols to ensure that it got
re-instantiated at the start of each subsequent column or
page, with @MarginBarEnd withdrawing this.  Then there would
need to be an invocation of @MarginBarEnd at the end of each
column - a call to it would need to be inserted into dsf's
page code.  It would do nothing if it could not find a
PostScript start point.

It would be better if a solution could be found that did
not involve dsf's page code, because then it would work
more simply and reliably for footnotes and floating figures
as well as for body text.  I believe that would require
adding new primitives which handled running footers in
the same way that running headers are handled now; there
may already be such stuff but I suspect not.

It would be cool to add such new primitives because then
they could be used to draw a rule across the bottom of
each fragment of a multi-page table.  So I could find
the motivation to do that, I believe.

Jeff