[R] grob questions

[Paul Murrell]

Hi


Gabor Grothendieck wrote:
> On 10/4/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
> 
>>Hi
>>
>>
>>Gabor Grothendieck wrote:
>>
>>>If I run the following example from:
>>>http://www.stat.auckland.ac.nz/~paul/grid/doc/grobs.pdf
>>>
>>>
>>>
>>>>grid.newpage()
>>>>pushViewport(viewport(w = 0.5, h = 0.5))
>>>>myplot <- gTree(name = "myplot", children = gList(rectGrob(name = "box",
>>>
>>>+ gp = gpar(col = "grey")), xaxisGrob(name = "xaxis")))
>>>
>>>
>>>>grid.draw(myplot)
>>>>grid.edit("myplot::xaxis", at = 1:10/11)
>>>>grid.edit("myplot::xaxis::labels", label = round(1:10/11, 2))
>>>>grid.edit("myplot::xaxis::labels", y = unit(-1, "lines"))
>>>
>>>
>>>then
>>>
>>>
>>>
>>>>str(myplot$children$xaxis)
>>>
>>>
>>>lists 'at' but not the 'labels'.
>>>
>>>yet if I do this then the labels are listed:
>>>
>>>
>>>
>>>>xx <- xaxisGrob(name = "myX", at = 1:10)
>>>>childNames(xx)
>>>
>>>[1] "major"  "ticks"  "labels"
>>>
>>>
>>>1. How do I get to labels in the first case?
>>
>>
>>First, if the xaxisGrob has at=NULL then it calculates its tick-marks at
>>drawing time (based on the viewport it gets drawn in).  So it does not
>>store any labels (it doesn't know what they are until it gets drawn). If
>>you specify a non-NULL 'at' then the axis creates labels.
>>
>>Second, grid grobs are standard R objects (copy-on-modify) so the object
>>'myplot' is not the same object that is being modified by the calls to
>>grid.edit().  grid.edit() destructively modifies a copy of the grob that
>>grid has stored on its display list;  you refer to the appropriate grob
>>via its name (not via an R object).  By comparison, editGrob() takes a
>>grob and returns a modified copy of the grob, for example ...
> 
> 
> Just one clarification.  What is the scope of names?
> In a recent post
> 
>   https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078653.html
>   https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078656.html
> 
> it seems that one had to use absolute paths and that seems to be the
> case here too where as mkondrin pointed out earlier in this thread
> 
>   https://www.stat.math.ethz.ch/pipermail/r-help/2005-October/078635.html
> 
> that get.grid("myplot::xaxis::labels")$label works.
> 
> Its not clear to me whether names:
> 
> - must be in absolute paths
> - can be relative to some position under some conditions
> - are global across all grob names in use and can be referred to directly
> as long as they are unique among all grobs defined so far.
> 
> It seems absolute path names work but I am not sure whether the
> other possibilities can work under some conditions too.
> 
> Also what the scope of viewports?   Absolute path? Relative path?
> Global names?  Does it work the same way?  I think at least
> absolute and relative paths are avalable here but could you confirm
> my understanding and whether the situation is the same for
> viewports and grobs?
> 
> (In the Windows, and analogously in UNIX, file system one can write
> \usr\myname or position oneself to \usr using cd and then refer to
> myname in a relative way:
> 
> cd \usr
> dir myname
> )


The distinction is not between "relative" or "absolute" paths, but 
between "strict" and "not strict" paths.

Matching a path always *starts* from your current "position" (so in that 
sense it is always "relative" and never "absolute").  When working with 
viewports, there is a current viewport tree and it is possible to be in 
different positions within that tree --- via [push|down|up]Viewport() 
--- so a path may have different meanings depending on where you are. 
(The seekViewport() function is sort of absolute because it always 
starts from the root of the viewport tree, but a non-strict 
seekViewport() [see below] behaves quite differently from an absolute 
filesystem directory path.)  When working with grobs, you tend to always 
be at the "top" or "root".  You are either: working off-screen with a 
single specific grob (gTree) so you are always at the top of that gTree; 
  or working with the grid display list, in which case you have a list 
of grobs and gTrees, which are searched one after the other.

The functions that take paths for grobs, such as grid.edit(), and for 
viewports, such as downViewport(), have an argument 'strict' which 
controls whether the path should be matched from the current position or 
whether the search can start from the current position and we'll match 
the path if it occurs anywhere below the current position.  (There are 
also 'grep' and 'global' arguments so you can get multiple matches where 
it makes sense.)

In some cases, grid has to make use of a path on its own, without 
knowing explicitly whether the path is strict (e.g., when you specify a 
path in a 'vp' slot).  In those cases, grid interprets the path as 
strict (so that, for example, grid has some chance of undoing the 
navigation down to a viewport).

Regarding uniqueness of names, all viewports *which share the same 
parent viewport* must have unique names (same for grobs).  You can, 
however, have several grobs with the same name on the display list. 
i.e., the following produces two separate grobs on the display list

grid.rect(name="rect")
grid.rect(name="rect")

Does that make things any clearer?

Paul
-- 
Dr Paul Murrell
Department of Statistics
The University of Auckland
Private Bag 92019
Auckland
New Zealand
64 9 3737599 x85392
paul at stat.auckland.ac.nz
http://www.stat.auckland.ac.nz/~paul/