<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 26, 2016 at 7:38 AM, Robert Kuszinger <span dir="ltr"><<a href="mailto:kuszinger@giscom.hu" target="_blank">kuszinger@giscom.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div><div><div>As a workaround I've created a script and discovered that I could simulate the work done by ps.map with some handmade calculations.<br></div>The result is not worse (visually in terms of generated code) than my beloved ps.map definition files. I have full control on display, raster, vector and other map gadgets (north, scalebar, etc). I use GRASS_RENDER_* variables, and all d.* commands. Cairo driver with BMP output is very fast. I put each map "layer" into a different BMP files with identicatal resolutions.<br></div></div></div></div></blockquote><div><br></div><div>This sounds good. Perhaps you can share your work at some point. It would be a good contribution to the discussion about the future of ps.map and d. commands.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div><div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>The resolution is currently a given dpi (300-600) bitmap but I'd like to test the toolchain with svg output as well to keep vectors for best print process.<br></div></div></blockquote><div><br></div><div>Please see:<br></div><div><br></div></div><a href="https://trac.osgeo.org/grass/ticket/3033">https://trac.osgeo.org/grass/ticket/3033</a><br><br></div><div class="gmail_extra">Vaclav<br></div></div>