Re: Lout 3.13 Bug with margin notes and PDF

[Valeriy E. Ushakov]

On Thu, Mar 18, 1999 at 11:48:34AM -0600, Glauber Ribeiro wrote:

> I think I found a bug in 3.13. When outputting to PDF (-Z), margin notes
> (@LeftNote, @RightNote, etc...) are overwriting the text they point to.
> If I output the exact same document to Postscript, it works fine.

Margin notes are not supposed to work with PDF, since they rely on
some PostScript programmatic magic.  Since PDF is not a fully blown
programming language, things like margin notes, diagrams, graphs just
will not work.

I've been comtemplating how this situation may be addressed.

Lout layout engine deals with concatenataion of rectangular objects.
In Lout world there're not such things as arcs orline.  However
there's @Graphics.  And I think that @Graphics is a very clever way of
gluing the Lout world of rectangular objects with arbitrary graphics.
The layout engine only sees the right argument of @Graphics and let
the left argument to do the whatever painting is necessary.

So far so good, but since the original target was PostScript (plain
text backend was introduced in 3.01 and PDF in 3.12) packages like
@Diag take this advantage to use loops, to define dictionaries and
perform other things that will survive the extent of their left
paramters to @Graphics.  And all this just does not work with PDF.

How this can be addressed is an interesting question.  Arbitrary
graphics cannot be easily pulled into the Lout word of rectangles, so
something like @Graphics is the way to go.  As I've already noted
above, @Graphics is a very smart way of gluing the two worlds.  The
next question is what will go into the left paramters to @Graphics.
Currently, this is implementation dependent (though we have exactly
one implementation of Lout), but essentialy it's some form of PDL.  We
could impose the restriction that the only external information the
left parameter have access to is the [xy]size and [xy]mark that the
layout engine is responsible for.  Of course any Lout _language_ level
substitutions that are effectively text substitutions are also
allowable, but the raw PDL code after Lout language layer has done its
job has only the four unknowns mentioned above.

Whith this restriction it's not unreasonable to use PS as the PDL
language and use a sort of flattener to eliminate any programmatic
costructs and then translate the flat PS into the backend's target
(e.g. PDF).

However this still leaves open the question of side effects - a
feature that some of exiting packages rely upon, like defining
dictionaries that will be visible in other invocation of @Graphics
(something @Diag labeling relies upon).  Those side effects seems hard
to fit into the functional style of Lout.

It's the first time that I've tried to write down my random thoughts
on this subject, so suggestions and criticism are solicited.

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