Hamish wrote: > > So, it's still not able to obsolete the PS driver. Initially, this > > isn't likely to be a problem; cairo's drawing model is close enough to > > PostScript that it would be feasible to maintain both drivers in the > > short term. > > I had expected from the current Tcl/wxPy work that the PNG driver would be the > mainstay of the GRASS 7 desktop GUI rendering. Do I detect a hint that the PS > driver may be challenging it for that role?
Yes. The original intention was that libraster would generate PostScript, which would be rendered with Ghostscript for raster output. > (with some ps2ppm magic) Or what > about the choice of Cairo vs. the PNG driver for ppm-backed GUI display > windows? > It is kind of cool to think that they may be somewhat interchangable for GUI > rendering. The idea was to avoid having to maintain multiple drivers along with a mechanism to dispatch R_* calls to the appropriate driver. All calls would produce PostScript, and the only thing that would need to be "dispatched" is the output stream. There isn't any point maintaining both the cairo and PNG drivers. cairo does everything the PNG driver does, and does a better job of it. If cairo could generate decent PostScript, then mapping R_* functions to cairo functions would achieve the same result but would be quicker for generating raster output. Unfortunately, cairo seems too ready to fall-back to rasterising everything, and doesn't do a particularly good job of handling raster output (it requires that the entire raster can fit into the interpreter's VM; not a problem when running Ghostscript on a PC, but a significant problem for printers). The main issue is ensuring that the fall-backs can be prevented. The raster issue can be solved by splitting rasters into strips. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
