<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-13 15:53 GMT+02:00 Pantxo Diribarne <span dir="ltr"><<a target="_blank" href="mailto:pantxo.diribarne@gmail.com">pantxo.diribarne@gmail.com</a>></span>:<br><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><br><div class="gmail_extra"><br><div class="gmail_quote">2016-09-13 15:24 GMT+02:00 Ben Abbott <span dir="ltr"><<a target="_blank" href="mailto:bpabbott@mac.com">bpabbott@mac.com</a>></span>:<br><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><div></div><div><br></div><div>On Sep 13, 2016, at 07:27, Pantxo Diribarne <<a target="_blank" href="mailto:pantxo.diribarne@gmail.com">pantxo.diribarne@gmail.com</a>> wrote:<br></div><blockquote type="cite"><div><div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2015-08-30 19:51 GMT+02:00 Ben Abbott <span dir="ltr"><<a target="_blank" href="mailto:bpabbott@mac.com">bpabbott@mac.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><span><div>On Aug 30, 2015, at 7:43 AM, Pantxo Diribarne <<a target="_blank" href="mailto:pantxo.diribarne@gmail.com">pantxo.diribarne@gmail.com</a>> wrote:</div><br></span><div>
<div bgcolor="#FFFFFF"><span>
<div>Le 29/08/2015 19:55, Ben Abbott a
écrit :<br>
</div>
</span><blockquote type="cite"><span>
<div>
<blockquote type="cite">
<div>On Aug 28, 2015, at 6:21 AM, Pantxo Diribarne
<<a target="_blank" href="mailto:pantxo.diribarne@gmail.com">pantxo.diribarne@gmail.com</a>>
wrote:</div>
<br>
<div>
<div dir="ltr">
<div>
<div>
<div>Hi,<br>
<br>
</div>
In Octave we are using the default <span><tt>GL2PS_USE_CURRENT_VIEWPORT</tt></span>
argument in the page initialization. This leads to a
mismatch between the original figure size (for which
the viewport is returned in pixels) and the ouput
eps/pdf that has the same size in points. To sum up: a
400x400 *pixels* opengl window will be printed as a
400x400 *points* eps file.<br>
<br>
</div>
<div>This would not really matter if we had
only vectorial objects in our figures ... but we have
text that are supposed to have a fixed size. For this
we use (intentionally???) a nasty trick which leads to
have a font size on-screen that is lower than it
should (a 10 pts font is displayed as 10 pixels
one...)<br>
</div>
<div><br>
</div>
<div>How should we go if we want to draw an eps
that has the same *physical* size has our on-screen
figure, e.g. is there a way to specify the screen
resolution so that gl2ps is able to translate pixels
to points?<br>
<br>
</div>
<div>Pantxo</div>
</div>
</div>
</div>
</blockquote>
<br>
</div>
<div>The root object (handle = 0) includes the property
“ScreenPixelsPerInch”. This can be used to determine the
physical figure size. Then it *should* be as simple as setting
PaperPosition property to the physical size.</div>
<div><br>
</div>
<div>I had worked on the displayed fontsize, and recall some
confusion (on my part) when reading the Matlab docs and
examining the rendered results. My confusion was compounded by
my display’s resolution being 72 pixels/inch.</div>
<div><br>
</div>
<div>My present display has 129 pixels/inch. As a test, I tried
...</div>
<div><br>
</div>
<div>
<div><span style="white-space:pre-wrap"> </span>clf
()</div>
<div><span style="white-space:pre-wrap"> </span>text
(0.5, 0.5, {‘FOO’,’BAR'}, 'fontsize', 72,
'horizontalalignment', 'center')</div>
</div>
<div><br>
</div>
<div>… in both Octave (default branch) and Matlab.</div>
<div><br>
</div>
<div>The results are below. The lines are separated by 110 pixels
high for Matlab and 84 for Octave.</div>
<div><br>
</div>
<div>I think the intention was that the on screen size should be
correct and that the print() function would handle the scaling
between pixels and points.</div>
<div><br>
</div>
<div>Ben</div>
<div><br>
</div>
<div><br>
</div>
</span><div><span><Mail Attachment.png></span><span><Mail Attachment.png></span></div>
<br>
</blockquote><span>
<br>
My first concern was initially the size of on-screen characters that
I found to be much smaller than e.g. in LibreOffice (see [1]). The
size of font in printed images is right though.<br>
<br>
AFAIU Octave uses a fontsize expressed in points (10 by default) to
call fontconfig which expects pixels. <br>
Now in gl2psSimple.c, glut is used to render text bitmaps of size
24: this is a comparable approach as in Octave. If you compare the
on-screen string from this example with the same string in
libreoffice you'll also notice that the font is smaller. The same
remark can be done about the screen shots you provide.<br>
<br>
Does it make sense to have, in gl2ps, a scaling factor between
pixels and points that external programs such as Octave can provide
or am I completely misunderstanding the printing process?<br>
<br>
Pantxo<br>
<br>
[1] <a target="_blank" href="https://savannah.gnu.org/bugs/?45600">https://savannah.gnu.org/bugs/<wbr>?45600</a> <br>
</span></div>
</div></blockquote><br></div><div>I think that could work, but some care needs to be taken to ensure the fontsizes are correct when specified as an option to the print comment.</div><div><br></div><div><div style="margin:0px;font-size:11px;font-family:menlo"> '-FFONTNAME'</div><div style="margin:0px;font-size:11px;font-family:menlo"> '-FFONTNAME:SIZE'</div><div style="margin:0px;font-size:11px;font-family:menlo"> '-F:SIZE'</div><div style="margin:0px;font-size:11px;font-family:menlo"> Use FONTNAME and/or FONTSIZE for all text. FONTNAME is</div><div style="margin:0px;font-size:11px;font-family:menlo"> ignored for some devices: dxf, fig, hpgl, etc.</div><div style="margin:0px;font-size:11px;font-family:menlo"><br></div></div><div>Since print.m already scales the fontsizes, I think the easiest solution is to set the proper default for opt.scalefontsize in print.m.</div><div><br></div><div><span style="white-space:pre-wrap"> </span>opt.scalefontsize = 72 / get (0, ‘screenpixelsperinch’);</div><div><br></div><div>Ben</div><div><br></div><div><br></div><br></div></blockquote></div><br></div><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 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 target="_blank" rel="noreferrer" href="http://blog.qt.io/blog/2013/04/25/retina-display-support-for-mac-os-ios-and-x11/">http://blog.qt.io/blog/2013/<wbr>04/25/retina-display-support-<wbr>for-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.<br><br></div><div class="gmail_extra">Pantxo<br></div></div>