From chuck at sharpsteen.net  Thu Jan 12 18:18:22 2012
From: chuck at sharpsteen.net (Sharpie)
Date: Thu, 12 Jan 2012 09:18:22 -0800 (PST)
Subject: [Rd] Inconsistencies in device_Raster when axes are reflected
In-Reply-To: <4F0E4C40.5060407@auckland.ac.nz>
References: <1326305479642-4286320.post@n4.nabble.com>
	<4F0E4C40.5060407@auckland.ac.nz>
Message-ID: <1326388702792-4289713.post@n4.nabble.com>


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.



[Rd] Inconsistencies in device_Raster when axes are reflected
Sharpie