Re: [Groff] PIC misunderstanding?

[Werner LEMBERG]

> On 10-Nov-00 address@hidden wrote:

> > I am probably being incredibly stupid but could someone please
> > explain to me why the two pictures produced by the following
> > fragment of PIC code are different?
> >
> > The second picture is the one I would expect.
> >
> >    .PS 5in
> >    [
> >       move to (0,0)
> >       line to (1,1) -> "A"
> >    ]
> >    [
> >       move to (0,0)
> >       line to (-1, 1) -> "B"
> >    ]
> >    .PE
> >
> >    .PS 5in
> >
> >       move to (0,0)
> >       line to (1,1) -> "A"
> >
> >
> >       move to (0,0)
> >       line to (-1, 1) -> "B"
> >
> >    .PE
>
> So it would seem, on the surface. I can't be definitive about this,
> but I believe it is consistent with intended behaviour, on the
> following grounds.
>
> In Kernighan's original PIC manual (section 9, Blocks) it says:
>
>   "Any sequence of pic statements may be enclosed in brackets [ and ]
>    to form a block, which can then be treated as a single object, and
>    manipulated rather like an ordinary box" ... "By default, blocks
>    join with other things as boxes do, at the center of the appropriate
>    side."

pic.ms gives a better explanation IMHO:

  A block composite object is created a series of commands enclosed by
  square brackets.  The composite can be treated for most purposes
  like a single closed object,
  with the size and shape of its bounding box.
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

And to really complete the documentation, I've just added the
following sentence (together with an example):

  Note that both width and height of the block composite object are
  always positive.

> An interpretation of this which is consistent with the behaviour you
> observed is that when you wrote [ ... ] ; [ ... ] the first [] was
> drawn from left to right leaving the "current point" at the centre
> of its righthand side. Then the second [] was drawn from this point,
> giving rise to the result you obtained,
>
> If this is correct, then there is an implicit over-ride of absolute
> coordinates given inside the block, by the coordinates of the
> current point, in the sense that the contents of the block are drawn
> "silently" using the absolute coordinates within, and then the whole
> drawn block gets shifted so that its left-hand centre point is at
> the current point prior to being physically drawn.
>
> However, my interpretation above is not based on having seen any such
> thing documented, merely on trying to see whether your results might
> be kosher.
>
> So, either this behaviour is a bug, or it is yet another instance
> of the documentation being laconic to the point of being misleading.

In case you believe that pic.ms is misleading also, maybe you can
formulate something which I can then add...


    Werner