macros vs definitions vs. parameters (and the tricks of @LengthUnits)

[Greg A. Woods]

So I'm still fiddling around with labels and business cards and other
silly things that require very accurate placement of marks and lines and
such on the page, and I'm doing relatively well -- much better than I
could if I tried to do it in raw PostScript I think.

However I'm beginning to wonder if maybe my exposure to many procedural
languages and more traditional object-oriented languages like Smalltalk
hasn't built a mind block for me against functional programming.

I'm trying to use @Place to put cut-marks out in the page margins and
I've got a relatively simple scheme that works that isn't quite as
flexible as it maybe could be with a bit more work, but currently it
allows me to concatenate an "invocation" of this object to a table
cell's content (and its mirror twin to another cell) and it works quite
well:

# Place a cut mark on the bottom right of card in row 'n'
#
# Note this object must be concatenated with the table cell contents
# else will cause white space separation to be included in the table
# cell which will then throw off the cell width calculations.
#
extend @DocumentSetup
def @RightCutMark
        right cardrow
{
        @Place
                x { right - 0.4i - xsize }
                y { foot + 8i - { { cardrow - 1 } * 2i } + 0.5625i - ymark }
        {
                @Sym arrowleft | @Sym arrowhorizex
        }
}

With a bit more arithmetic and some named parameters and some fancier
arithmetic I could get rid of the "8i" and "2i" magic numbers.

However the 0.5625i magic number is really the @FootMargin value.
I.e. I want to write:

extend @DocumentSetup
def @RightCutMark
        right cardrow
{
        @Place
                x { right - 0.4i - xsize }
                y { foot + 8i - { { cardrow - 1 } * 2i } + @FootMargin - ymark }
        {
                @Sym arrowleft | @Sym arrowhorizex
        }
}


Now I've tried every way I can think of to get that value into the form
that works with @Place.  Basically the rather "lame" way that
expressions such as those used for the 'x' and 'y' parameters of @Place
are translated into PostScript notation is thwarting my attempts as it
prevents me from using the @FootMargin named parameter directly in the
@RightCutMark definition.

Without that magic translation done by @LengthUnits this would of course
have to be written as:

extend @DocumentSetup
def @RightCutMark
        right cardrow
{
        @Place
                x { right - 0.4 in - xsize }
                y { foot + 8 in - { { cardrow - 1 } * 2 in } + 0.5625 in - 
ymark }
        {
                @Sym arrowleft | @Sym arrowhorizex
        }
}

and indeed it can be written that way and works just as well with (IIRC)
no change in the resulting PostScript.

The problem is of course that the @FootMargin value _must_ be in the
lout form with the units designator as part of the "value" since it's
used in various places as a gap value, while in the @Place parameters it
really should be in the PostScript notation even though as in the above
some lout magic can translate the parameters "on the fly", except it's
too "on the fly" as it seems to happen when the definition is parsed and
not when the object is "invoked".

Now I thought I could define a macro as the value for the foot margin
and then offer that macro as the @FootMargin parameter and in the @Place
parameter(s), but that didn't help.

I also tried defining yet another intermediate function which I hoped
would be able to use the same internal magic translation trick via
"import @BasicSetup @LengthUnits" to parse apart the lout-style units.
That didn't work either -- it only seems to work with constant values,
not with other definitions, macros, or named parameters.

One thing I haven't tried yet is to make @RightCutMark a macro itself.
The problem there though is that I suddenly can't use any parameters,
let alone named parameters (why can't macros have parameters?) so for
this use the excercise would at best be a proof of concept but would not
be practical for the purpose.

I think the real problem is with @Graphic, @Place, et al where lout
units clash with the way PostScript translations are done.  I think this
clash could be eliminated by post-processing the PostScript output

Another (bad?) hack would be to simply add yet another set of PostScript
variables (as companions to left, right, foot, top, xmark, ymark, et al)
to use in @Place, @Graphic, etc., -- i.e. the page margins from
@DocumentSetup.  I could even hack this into an "extend @DocumentSetup"
macro, I think, but I don't think it would be very elegant....

Does anyone have any other thoughts?

I can post a complete example if all I've done is confuse (its from my
business card template, now translated to @Tbl and with some new
features such as these cut marks so they can be printed on plain stock
instead of the perforated stuff I use)....

-- 
                                                                Greg A. Woods

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