Folks,<br><br>I wanted to prepare my <a href="http://vbkto.dyndns.org/sdk/">daily built binaries</a> with cairo rendering support on Windows. In this regard the following dependencies have been compiled.<br><br>pixman-0.20.0 (with no MMX and SSE2 support at this stage)<br>
cairo-1.10.0 with the following features:<br><br>CAIRO_HAS_WIN32_SURFACE 1 <br>CAIRO_HAS_WIN32_FONT 1 <br>CAIRO_HAS_PNG_FUNCTIONS 1 --> with libpng 1.2.35<br>CAIRO_HAS_FT_FONT 1 --> with freetype 2.3.9<br>
CAIRO_HAS_FC_FONT 1 --> with fontconfig 2.6.0<br>CAIRO_HAS_PS_SURFACE 1 -->zlib 1.2.3<br>CAIRO_HAS_PDF_SURFACE 1 <br>CAIRO_HAS_SVG_SURFACE 1 <br>CAIRO_HAS_IMAGE_SURFACE 1 <br>CAIRO_HAS_RECORDING_SURFACE 1 <br>
CAIRO_HAS_USER_FONT 1 <br>CAIRO_HAS_INTERPRETER 1 <br><br>Having the configuration above with mapserver-trunk, I always get a blank image with no features drawn on it regardless of the layer type.<br>Do you have any idea what could be wrong with this or what else should be tested to identify the problem?<br>
<br>Further questions/problems:<br><br>1. Would it be reasonable to include support for the cairo Win32 surface in Mapserver?<br><br>2. I can see much of unimplemented functions with many of the vtable renderers (like GD2) do we have a plan to add a reasonable implementation here? There is quite some progress with this in sandbox/mapserver6, however this version doesn't seem to compile on Windows at the moment. I also see some additional dependency to giflib which should also be made conditional in the build process.<br>
<br>3. I've also added a new vtable method in <a href="http://trac.osgeo.org/mapserver/changeset/10698">r10698</a> in order to support the renderer specific way to serialize the images. Actually I'm not too satisfied with the signature of saveImage which if pretty much predefined to save on a FILE handle, it would be much more handy to save on a 'stream context structure' which could eventually be based on a file handle, a memory buffer, stdout, whatever, something like we do with msIOContext actually. For example with the GD driver, I would be in favour of transferring the the gdIOCtx way of serializing the image to a stream (msSaveImageGDCtx) which have been used for either the file based or the memory based output recently.<br>
<br><br><span class="illustration">The long and the short of it is, I think the new rendering approach is in a good shape to fininsh up this phase and finalize a set of the features being ready for </span>the 6.0 release.<span class="illustration"> </span>I'm confidently looking forward to have the users start testing with these new features as soon as possible.<br>
<br><br>Best regards,<br><br>Tamas<br><br><br><br><br>