[R] grob questions
Paul Murrell
p.murrell at auckland.ac.nz
Wed Oct 5 03:50:13 CEST 2005
Hi
Gabor Grothendieck wrote:
> On 10/4/05, Paul Murrell <p.murrell at auckland.ac.nz> wrote:
>
>>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?
>>
>
>
>
> That certainly helps although some examples would be nice.
>
> 1. I understand that in the original example:
>
> 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"))
>
> we can do this:
>
> grid.get("myplot::xaxis::labels")$label
>
> and without specifying complete paths it can be done like this:
>
> get.grid("labels")$label
>
> so I am ok on this one.
>
>
> 2. But going back to:
>
> 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
>
> I see you mention that vp= is always strict so is there a way to
> do this somehow:
>
> library(grid)
> vp <- vpTree(
> viewport(layout=grid.layout(2,2), name="layout"),
> children=vpList(
> viewport(layout.pos.col = 1, layout.pos.row=1, name="tl"),
> viewport(layout.pos.col = 2, layout.pos.row=2, name="br")
> )
> )
>
> grobs <- gList(
> rectGrob(vp=vpPath("layout","tl")),
> textGrob("Top left", vp=vpPath("layout","tl")),
> textGrob("Bottom right", vp=vpPath("layout","br"))
> )
>
> grid.draw(gTree(childrenvp=vp, children = grobs))
>
> without repeating "layout" three times in the definition of the
> grobs object?
How about ... ?
vptop <- viewport(layout=grid.layout(2,2), name="layout")
vpbelow <- vpList(viewport(layout.pos.col = 1,
layout.pos.row=1, name="tl"),
viewport(layout.pos.col = 2,
layout.pos.row=2, name="br"))
grobs <- gTree(childrenvp=vptop,
children=gList(gTree(vp="layout",
childrenvp=vpbelow,
children=gList(
rectGrob(vp="tl"),
textGrob("Top left", vp="tl"),
textGrob("Bottom right", vp="br")))))
grid.draw(grobs)
... or ... ?
vp <- vpTree(viewport(layout=grid.layout(2,2), name="layout"),
children=
vpList(viewport(layout.pos.col = 1,
layout.pos.row=1, name="tl"),
viewport(layout.pos.col = 2,
layout.pos.row=2, name="br")))
grobs <- gTree(childrenvp=vp,
children=gList(gTree(vp="layout",
children=gList(
rectGrob(vp="tl"),
textGrob("Top left", vp="tl"),
textGrob("Bottom right", vp="br")))))
grid.draw(grobs)
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/
More information about the R-help
mailing list