<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div class="h5"><div class="gmail_extra"><div class="gmail_quote"><blockquote style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex" class="gmail_quote"><div dir="ltr"><div><div><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div><div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra">I'd like to come back to this discussion in regard to the discrepancy between SVG and EPS output size: from a M-by-N *pixels* opengl viewport, gl2ps draws a M-by-N *points* figure for EPS format and a M-by-N *pixels* figure for SVG format.<br></div><div class="gmail_extra">I think one of those should be fixed.<br><br></div><div class="gmail_extra">As I said in the beginning of the discussion, I'd vote for introducing a new "resolution" (default 72 pixels per inch) argument for gl2psBeginPage. This would provide a way to translate screen coordinates into whatever units we like in gl2ps.<br><br></div><div class="gmail_extra">Pantxo<br></div></div>
</div></blockquote><br></div></div><div>I like your suggestion. That would simplify things. Are you working on a patch?</div><div><br></div><div>Since "points" has a different meaning for Linux, Windows (96 ppi), and Mac (72 ppi), should the default change with os? Or is the ppi always 72 for pdf?</div><span><font color="#888888"><div><br></div><div>Ben</div></font></span></div></blockquote></div><br></div></div></div><div class="gmail_extra">Why does the screen resolution (hardware+software) have to be OS specific (pure software)?<br><br></div><div class="gmail_extra">As for the patch, I'd like to hear opinions before going ahead. In particular the approach I propose will change the signature of gl2psBeginPage which will force every user to change their code. Another less invasive option would be adding a "gl2psScreenResolution" function. The drawback is that such parameter has no reason to be changed in the middle of a drawing so having it fixed from the start seems more consistent.<span><font color="#888888"><br><br></font></span></div><span><font color="#888888"><div class="gmail_extra">Pantxo<br></div></font></span></div>
</blockquote></div><br></div></div></div><div class="gmail_extra">Ben, now I think I understand what you meant. Actually it is "pixel" that have a different meaning for different systems: some use screen(physical) pixels (linux) and others use device independent pixels (Mac).<br>E.g in Mac carbon API if you request a 10-by-10 pixels window you will obtain a 20-by-20 physical pixels window on retina (HDPI) screens. This is untrue for the opengl API which always works with physical pixels. See e.g. <a rel="noreferrer" href="http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/" target="_blank">http://blog.qt.io/blog/2013/04<wbr>/25/retina-display-support-for<wbr>-mac-os-ios-and-x11/</a><br><br></div><div class="gmail_extra">This tells us that a "resolution" argument should be expressed in physical(screen)-pixels per inch.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">Pantxo<br></div></font></span></div>
</blockquote></div><br></div><div class="gmail_extra">I went ahead and produced a patch (see attached). I chose the invasive approach (adding an argument to gl2psBeginPage) since the resolution must be known at the very beginning of the process.<br><br></div><div class="gmail_extra">Pantxo <br></div><div class="gmail_extra"><br><br></div></div>