[gl2ps] Translate pixels to points

[Pantxo Diribarne]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.geuz.org/pipermail/gl2ps/attachments/20160913/cd3ab3fc/attachment.html>