Re: macros vs definitions vs. parameters

[Greg A. Woods]

[ On Wednesday, October 16, 2002 at 09:53:12 (+1100), Jeff Kingston wrote: ]
> Subject: Re: macros vs definitions vs. parameters
>
> I've only read your stuff briefly, but if what you are looking
> for is a way toinclude a Lout length inside some PostScript
> and get it handled correctly, you could pass it to PostScript
> as a string with a conversion command attached:
> 
>     "("@FootLength") cvt_lout_to_ps"
> 
> and write a PostScript routine to do the conversion.

I suppose that's not a whole lot different than my idea of stuffing some
more PostScript variables into the LoutPageDict dictionary.  I think I
like my idea more though -- it at least stays consistent with the
"hacks" already used with @Place (and to a lesser extent @Graphic).  I
just haven't yet figured out how to get the values for those
variables.... :-)

> However I'm not sure that @Place is the way to do this stuff.

I tried using margin notes, but they can't seem to be controlled tightly
enough to line them up with the table cell boundaries.  If I could more
accurately position them then they might do almost as well.

Ideally I'd like to find some way to make some arbitrary object line up
exactly with the baseline (or mark for vertical alignment) of a table
cell, and then be able to shift that object out into the margin along
the line/mark it is aligned with.

This might also be useful in making change marks in ordinary text too.
For example in IEEE Standard drafts the lines changed from a previous
draft are marked with a grey bar and the number of the draft in which
the change occurred (so that the history of changes can be followed to
some degree just by reading the most recent draft).  On the other hand
this kind of markup would maybe better be hidden a bit deeper so that
the changed text would be marked in the input and the line numbers would
be calculated automatically and the and actual change markers could be
tags or something similar.

> As I said, I have not read your mail closely, but have you
> looked at @PageBackground (or whatever it's called)?

Yes, I tried putting them in @PageBackground too, though that means the
page background now has a lot of duplicate assumptions copied from the
overall layout table in the main document body and that's the kind of
thing I'm trying to avoid in the first place.

>  I
> expect you rejected that because the background does not
> extend into the margins.

At first I tried the "trivial" trick using @Place in @PageBackground,
but of course that didn't work at all.  Then I ran into the 

>  But what about having margins
> of size 0 and using @PageEnclose?

Hmmm.... maybe.  I didn't try that yet, though I had thought about it.
I'll look a little closer again....

One potential problem that I've been avoiding by use of the
@DocumentSetup margins is the issue of dealing with poorly aligned
printers.  It is easiest to adjust the margins to account for the
alignment problems, unless of course there are also paper slippage
problems.....  :-)

However if I can find a simple way to move all that stuff into the
document proper then maybe I can just expand the table by two rows and
two columns to account for the page margins and then just use rules to
draw the cut marks.  The only trick I don't know yet is how I might keep
the rules from going right to the edge of a cell.

-- 
                                                                Greg A. Woods

+1 416 218-0098;            <address@hidden>;           <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>