<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class="">On Aug 30, 2015, at 7:43 AM, Pantxo Diribarne <<a href="mailto:pantxo.diribarne@gmail.com" class="">pantxo.diribarne@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
  
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type" class="">
  
  <div text="#000000" bgcolor="#FFFFFF" class="">
    <div class="moz-cite-prefix">Le 29/08/2015 19:55, Ben Abbott a
      écrit :<br class="">
    </div>
    <blockquote cite="mid:C32EC43A-8765-4033-A825-7A842ACF1660@mac.com" type="cite" class="">
      <meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
      <div class="">
        <blockquote type="cite" class="">
          <div class="">On Aug 28, 2015, at 6:21 AM, Pantxo Diribarne
            <<a moz-do-not-send="true" href="mailto:pantxo.diribarne@gmail.com" class="">pantxo.diribarne@gmail.com</a>>

            wrote:</div>
          <br class="Apple-interchange-newline">
          <div class="">
            <div dir="ltr" class="">
              <div class="">
                <div class="">
                  <div class="">Hi,<br class="">
                    <br class="">
                  </div>
                  In Octave we are using the default <span class=""><tt class="">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 class="">
                  <br class="">
                </div>
                <div class="">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 class="">
                </div>
                <div class=""><br class="">
                </div>
                <div class="">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 class="">
                  <br class="">
                </div>
                <div class="">Pantxo</div>
              </div>
            </div>
          </div>
        </blockquote>
        <br class="">
      </div>
      <div class="">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 class=""><br class="">
      </div>
      <div class="">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 class=""><br class="">
      </div>
      <div class="">My present display has 129 pixels/inch. As a test, I tried
        ...</div>
      <div class=""><br class="">
      </div>
      <div class="">
        <div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>clf

          ()</div>
        <div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>text

          (0.5, 0.5, {‘FOO’,’BAR'}, 'fontsize', 72,
          'horizontalalignment', 'center')</div>
      </div>
      <div class=""><br class="">
      </div>
      <div class="">… in both Octave (default branch) and Matlab.</div>
      <div class=""><br class="">
      </div>
      <div class="">The results are below. The lines are separated by 110 pixels
        high for Matlab and 84 for Octave.</div>
      <div class=""><br class="">
      </div>
      <div class="">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 class=""><br class="">
      </div>
      <div class="">Ben</div>
      <div class=""><br class="">
      </div>
      <div class=""><br class="">
      </div>
      <div class=""><span id="cid:part2.01040400.09090808@gmail.com"><Mail Attachment.png></span><span id="cid:part3.00080704.04080407@gmail.com"><Mail Attachment.png></span></div>
      <br class="">
    </blockquote>
    <br class="">
    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 class="">
    <br class="">
    AFAIU Octave uses a fontsize expressed in points (10 by default) to
    call fontconfig which expects pixels. <br class="">
    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 class="">
    <br class="">
    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 class="">
    <br class="">
    Pantxo<br class="">
    <br class="">
    [1] <a class="moz-txt-link-freetext" href="https://savannah.gnu.org/bugs/?45600">https://savannah.gnu.org/bugs/?45600</a> <br class="">
  </div>

</div></blockquote><br class=""></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 class=""></div><div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">     '-FFONTNAME'</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">     '-FFONTNAME:SIZE'</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">     '-F:SIZE'</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">          Use FONTNAME and/or FONTSIZE for all text.  FONTNAME is</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class="">          ignored for some devices: dxf, fig, hpgl, etc.</div><div style="margin: 0px; font-size: 11px; font-family: Menlo;" class=""><br class=""></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 class=""></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>opt.scalefontsize = 72 / get (0, ‘screenpixelsperinch’);</div><div><br class=""></div><div>Ben</div><div><br class=""></div><div><br class=""></div><br class=""></body></html>