lout-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Two-part @Graphic vs. xsize etc


From: Valery Ushakov
Subject: Re: Two-part @Graphic vs. xsize etc
Date: Fri, 7 Mar 2014 01:32:21 +0400
User-agent: Mutt/1.4.2.3i

On Fri, Mar 07, 2014 at 07:22:28 +1100, Jeff Kingston wrote:

> > I have stumbled into a problem with two-part left parameter of
> > @Graphic.  When the second part is emitted the values of xsize etc
> > might have been overwritten by nested calls to @Graphic inside the
> > right parameter.
> 
> Or you could push a dict in the first part and pop it in the
> second part.  I think it's fair to ask anyone who is using
> two-part left parameters of @Graphic to handle this kind of
> thing themselves.

It can be argued that it's not fair to ask that as that leaks
implementation details, since one has to examine the emited postscript
code to save and restore the right parts, dict or not.  xsize/ysize
and xmark/ymark are at least documented, but the code you ask callers
to write also has to know about internal loutf, loutv, louts.  If in
some future version you add a new internal variable to LoutGraphic,
existing code like that (e.g. my example) that saves/restores this
state manually will break.


> Here's what I did in @Diag to get the graphics state of the
> left parameter to affect the object to the right, a kind of
> opposite of what is wanted here:
> 
>     # Like @Graphic, but affects the graphics state of right parameter
>     def @InnerGraphic
>       left ps
>       right x
>     {
>       { ps gsave // grestore } @Graphic x
>     }

Note that my example does both.  It imposes clipping onto the graphic
state of the right parameter though it does this instead with

    grestore ... gsave

in the first part.  Since LoutGr2 provides an extra gsave at the very
beginning before it does "translate" it's easier to modify "top-level"
graphic state of @Graphic to avoid extra pressure on graphic state
stack.  The last grestore emitted for @Graphic that restores the state
to before the "translate" of LoutGr2 will throw away all the changes.

Also note that gsave/grestore provide an opaque way to manipulate
graphic state.  On the other hand, as I wrote above, there's no opaque
way to save/restore values of LoutGraphic context.

-uwe



reply via email to

[Prev in Thread] Current Thread [Next in Thread]