<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-08-30 19:51 GMT+02:00 Ben Abbott <span dir="ltr"><<a href="mailto:bpabbott@mac.com" target="_blank">bpabbott@mac.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><blockquote type="cite"><span class=""><div>On Aug 30, 2015, at 7:43 AM, Pantxo Diribarne <<a href="mailto:pantxo.diribarne@gmail.com" target="_blank">pantxo.diribarne@gmail.com</a>> wrote:</div><br></span><div>
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>Le 29/08/2015 19:55, Ben Abbott a
écrit :<br>
</div>
</span><blockquote type="cite"><span class="">
<div>
<blockquote type="cite">
<div>On Aug 28, 2015, at 6:21 AM, Pantxo Diribarne
<<a href="mailto:pantxo.diribarne@gmail.com" target="_blank">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 class="">
<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 href="https://savannah.gnu.org/bugs/?45600" target="_blank">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>