[gl2ps] Translate pixels to points

[Pantxo Diribarne]

2016-09-13 15:53 GMT+02:00 Pantxo Diribarne <pantxo.diribarne at gmail.com>:

>
>
> 2016-09-13 15:24 GMT+02:00 Ben Abbott <bpabbott at mac.com>:
>
>>
>> On Sep 13, 2016, at 07:27, Pantxo Diribarne <pantxo.diribarne at gmail.com>
>> wrote:
>>
>>
>> 2015-08-30 19:51 GMT+02:00 Ben Abbott <bpabbott at mac.com>:
>>
>>> On Aug 30, 2015, at 7:43 AM, Pantxo Diribarne <
>>> pantxo.diribarne at gmail.com> wrote:
>>>
>>> Le 29/08/2015 19:55, Ben Abbott a écrit :
>>>
>>> On Aug 28, 2015, at 6:21 AM, Pantxo Diribarne <
>>> pantxo.diribarne at gmail.com> wrote:
>>>
>>> Hi,
>>>
>>> In Octave we are using the default GL2PS_USE_CURRENT_VIEWPORT 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.
>>>
>>> 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...)
>>>
>>> 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?
>>>
>>> Pantxo
>>>
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> My present display has 129 pixels/inch. As a test, I tried ...
>>>
>>> clf ()
>>> text (0.5, 0.5, {‘FOO’,’BAR'}, 'fontsize', 72, 'horizontalalignment',
>>> 'center')
>>>
>>> … in both Octave (default branch) and Matlab.
>>>
>>> The results are below. The lines are separated by 110 pixels high for
>>> Matlab and 84 for Octave.
>>>
>>> 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.
>>>
>>> Ben
>>>
>>>
>>> <Mail Attachment.png><Mail Attachment.png>
>>>
>>>
>>> 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.
>>>
>>> AFAIU Octave uses a fontsize expressed in points (10 by default) to call
>>> fontconfig which expects pixels.
>>> 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.
>>>
>>> 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?
>>>
>>> Pantxo
>>>
>>> [1] https://savannah.gnu.org/bugs/?45600
>>>
>>>
>>> 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.
>>>
>>>      '-FFONTNAME'
>>>      '-FFONTNAME:SIZE'
>>>      '-F:SIZE'
>>>           Use FONTNAME and/or FONTSIZE for all text.  FONTNAME is
>>>           ignored for some devices: dxf, fig, hpgl, etc.
>>>
>>> Since print.m already scales the fontsizes, I think the easiest solution
>>> is to set the proper default for opt.scalefontsize in print.m.
>>>
>>> opt.scalefontsize = 72 / get (0, ‘screenpixelsperinch’);
>>>
>>> Ben
>>>
>>>
>>>
>>>
>> 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.
>> I think one of those should be fixed.
>>
>> 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.
>>
>> Pantxo
>>
>>
>> I like your suggestion. That would simplify things. Are you working on a
>> patch?
>>
>> 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?
>>
>> Ben
>>
>
> Why does the screen resolution (hardware+software) have to be OS specific
> (pure software)?
>
> 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.
>
> Pantxo
>

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).
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.
http://blog.qt.io/blog/2013/04/25/retina-display-support-
for-mac-os-ios-and-x11/

This tells us that a "resolution" argument should be expressed in
physical(screen)-pixels per inch.

Pantxo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gl2ps/attachments/20160914/fce4111f/attachment.html>