Re: Strange behavior of "root" in "over"'s context

[Valeriy E. Ushakov]

On Sat, Jan 01, 2000 at 02:51:35AM +0100, Giovanni Zezza wrote:

> > Tell that to people that want PDF output from Lout ...
> 
> This has nothing to do with *output*. PostScript would be simply (well, not
> so simply) the internal graphic language of Lout. From that you could get
> whatever you want (in a single passage too, if you want).
> You have to have some sort of a graphic language or tool; if I correctly
> understand this is something even Jeff Kingston agree about, in a way. I
> say, let's be it PostScript.

Oh, so I have misunderstood you.  That's something I've been long
thinking about myself, but have absolutely no time to work on.

Take TPS (Tiny PostScript from Arcadia Project), which is PS, the
language, sans graphics.  Link it with Lout.  Change @Graphics to pass
it's left paramter through it.  For PS it will flatten the PS code,
for PDF it will distill it.  Of course you take care to provide
different implementations for different backends.  E.g. "setrgbcolor"
in PS backend takes numbers from stack prints them to the output
stream and then it prints "setrgbcolor"; in PDF backend it prints
numbers prints "rg" prints numbers again then prints "RG".  And so on.

TPS have freeze/thaw capibilities, so you freeze after all the
@PrependGraphic and just before starting the first page.  You restore
the state before the page starts and discard it after the page is
over.

Anyone interested?


> though, at every situation when would be useful having Lout knowing what
> was presently done in PostScript; objects dimensions and positions, at
> least.

IMO, that's a no-no.  This kind of symbiosis is simply not possible,
at least that would be an entirely different system.

In the current design @Graphics simply attaches parameterized drawing
instructions (xsize &co being the parameters) to a Lout object.  Lout
formatting engine sizes and positions the object as usual and then
arranges for the drawing instructions (the left paramter of @Graphic)
to be executed supplying actual parameters.  IMO this is the cleanest
possible design.  Once you require that Lout be aware of what's going
on in those drawing instructions there's immediately a problem of
*when* things happen (i.e. when side-effects happen).  And having to
know *when* things happen breaks Lout functional nature.

But standardizing on the subset of PS that can go into the left
paramter of @Graphic and using TPS as flattener/distiller would be a
very useful thing.

SY, Uwe
-- 
address@hidden                         |       Zu Grunde kommen
http://www.ptc.spbu.ru/~uwe/            |       Ist zu Grunde gehen