Re: [Rd] Inconsistencies in device_Raster when axes are reflected

From: Sharpie <chuck_at_sharpsteen.net>
Date: Thu, 12 Jan 2012 09:18:22 -0800 (PST)

Paul Murrell wrote
>
> I think the problem is that I just failed to anticipate this situation
> (i.e., the current documentation and behaviour both assume xlim[1] <
> xlim[2] and ylim[1] < ylim[2]).
>
> Will take a look at where to apply a fix (EITHER allow the API to be
> more flexible [allow negative 'width' and 'height' and 'x' and 'y' to be
> other than left-bottom], which will require complicating the code in
> some devices OR keep the API fixed and complicate the graphics engine
> code instead). The rotation argument adds an interesting twist ...
>
> Thanks for the report!
>
> Paul
>

Thanks for the reply Paul!

This isn't too hard to handle at the device level. For example, all I had to do to the tikzDevice was add a loop and some logic that re-ordered the raster vector and re-positioned the coordinate anchor:

int i, j, index, target, row_offset = 0, col_offset = 0, row_trans = 1, col_trans = 1;
  if ( height < 0 ) {
    /* Using these parameters, one can cause a loop to "count backwards" */     row_trans = -1;
    row_offset = h - 1;

    /*
     * If a dimension is negative, the (x,y) coordinate no longer references
     * the lower left corner of the image. We correct for this and then make
     * sure the dimension is positive.
     */

    y += height;
    height = fabs(height);
  }

  if ( width < 0 ) {
    col_trans = -1;
    col_offset = w - 1;
    x += width;
    width = fabs(width);
  }

  for ( i = 0; i < h; ++i ) {
    for ( j = 0; j < w; ++j ) {

      target = i*w + j;
      index = (row_trans*i + row_offset)*w + (col_trans*j + col_offset);

      INTEGER(red_vec)[target] = R_RED(raster[index]);
      INTEGER(green_vec)[target] = R_BLUE(raster[index]);
      INTEGER(blue_vec)[target] = R_GREEN(raster[index]);
      INTEGER(alpha_vec)[target] = R_ALPHA(raster[index]);
    }
  }

This gives the device the same behavior as the PDF device. So, the behavior isn't too difficult to correct on the device end---I was just concerned by the difference between documentation and behavior and wanted to make sure the graphics engine was not expecting something different.

-Charlie



Charlie Sharpsteen
Undergraduate-- Environmental Resources Engineering Humboldt State University
--
View this message in context: http://r.789695.n4.nabble.com/Inconsistencies-in-device-Raster-when-axes-are-reflected-tp4286320p4289713.html
Sent from the R devel mailing list archive at Nabble.com.

______________________________________________
R-devel_at_r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Received on Thu 12 Jan 2012 - 17:21:03 GMT

This quarter's messages: by month, or sorted: [ by date ] [ by thread ] [ by subject ] [ by author ]

All messages

Archive maintained by Robert King, hosted by the discipline of statistics at the University of Newcastle, Australia.
Archive generated by hypermail 2.2.0, at Fri 13 Jan 2012 - 03:30:08 GMT.

Mailing list information is available at https://stat.ethz.ch/mailman/listinfo/r-devel. Please read the posting guide before posting to the list.

list of date sections of archive