Hi, I have a problem and a couple of questions related thereto. The problem: I am trying to convert a programmatically generated RGB Buffer to a Cairo surface.  Up till now, I have used GDK to create all my graphics (since I started before Cairo came to be, and required display within a GUI), but now need to convert to Cairo since I need to generate these PDF plots in the background on a server machine without a display.  All fine and good. Until I try to understand how to convert my gdk_* routines to their cairo equivalents. In GDK, once I have created and filled my RGB buffer (3-byte color, RGB), I call: rgbbuf = malloc(wL * hL * 3);            // RGB Buffer - 3-byte color - RGB memset(rgbbuf, 240, wL * hL * 3);        // make the grey background pdf(rgbbuf, wL, hL, pdfReq, &gr, perB);  // make the PDF plot gdk_draw_rgb_image (pmap, gc, sideM, topM, wL, hL, GDK_RGB_DITHER_NONE, rgbbuf, wL*3); After investigating how to do this in Cairo, I came up with this replacement: rgbbuf = malloc(wL * hL * 4);            // RGB Buffer - 4-byte color - ARGB memset(rgbbuf, 240, wL * hL * 4);        // make the grey background pdf(rgbbuf, wL, hL, pdfReq, &gr, perB);  // make the PDF plot pdfOut = cairo_image_surface_create_for_data(rgbbuf, CAIRO_FORMAT_RGB24, wL, hL, wL*4); cairo_set_source_surface (cr, pdfOut, sideM, topM);  // cr is previously created cairo_rectangle (cr, sideM, topM, wL, hL);  cairo_fill (cr); cairo_surface_destroy (pdfOut); I have modified the RGB buffer size to 4-byte colors (ARGB) and filled it according to the cairo_format_t definition for <code class="literal">CAIRO_FORMAT_RGB24.  However, this does not result in a picture that is correct. My suspicion is that since the row stride is being optimized by Cairo, it does not nicely align on a boundary of width*4.  The documentation currently states that in order to obtain the proper stride, the routine </code>cairo_format_stride_for_width() should be used.  And also says that this is available since 1.6. My questions: <ol><li>I do not find a v1.6 of Cairo available from the download site.  Is it really true?  The documentation preceeds the release of the software itself?  (wow...)  Or am I missing something?  </li><li>If v1.6 isn't yet available, how do I get the optimized stride defined internally by Cairo? </li><li>Anyway, assuming for the moment this routine existed, how would I use it properly?  Meaning, how do I programmatically generate a RGB buffer for display?</li> </ol>My guess at Q3 would be: <ol><li>obtain the row stride using the cairo routine.</li><li>fill my RGB buffer, row by row, keeping track when i've hit the stride (computed in 1) to advance to the next proper 4-byte RGB location.</li> </ol>This is based, however, on too many assumptions: <ol><li>I'm assuming that to optimize, Cairo makes the stride bigger (smaller makes no sense to me) than simply width*4 bytes.</li><li>Every row is guaranteed to be the same?  Including the last? </li><li>Where are the empty bytes placed?  at the end of the row or at the beginning?  </li><li>Is the stride always a multiple of 4? </li></ol>More generally, it seems that programmatically generating a RGB buffer for conversion to a Cairo surface is not obvious (to me, yet).  Am I wrong about this?  Is there a more straightforward way of doing this I haven't yet teased from the documentation?  Is there a different way of accessing the individual pixels of an RGB buffer I am unaware of that would allow me to fill them up individually without having to make wrong assumptions and guesses? Any information to help me out of my pickle would be greatly appreciated. regards, richard