Mon 25 Jan 2016 11:11:07 AM UTC, comment #25:
Thanks, Ben. You marked the bug as "fixed", but its status is still "open". Could you please close it? Thanks again.
|
Fri 18 Dec 2015 08:46:55 PM UTC, comment #24:
I've pushed a changeset to the default branch.
http://hg.savannah.gnu.org/hgweb/octave/rev/80dd7b3529ee
I'll close this bug report, but it can be reopened if I've missed something.
|
Thu 17 Dec 2015 08:50:21 PM UTC, comment #23:
@Ederag,
The size of the figure rendered is always equal to the size specified by paperposition(3:4). If paperunits = "centimeters", then the size of the rendered figure in centimeters will be paperposition(3:4).
Does that answer your question?
|
Thu 17 Dec 2015 08:39:01 PM UTC, comment #22:
Dear Ben, this looks like a very elegant solution.
After patching, and fixing a small typo ("ha" => "hax") twice,
the axes are not truncated any more.
So for my use case it is almost fine
(almost because the positions are only approximate. But I'll investigate that later)
But what would happen if paperposition was changed ?
Tomorrow I'll look into that. But meanwhile,
I would guess that the printout would scale accordingly.
So the sizes would not be in centimeters any more.
Is it the matlab behaviour ?
|
Thu 17 Dec 2015 02:15:59 AM UTC, comment #21:
Updated changeset to include all descendants of the figure.
(file #35776)
|
Wed 16 Dec 2015 09:11:31 PM UTC, comment #20:
Ok. You've finally got through. I was distracted by the other problems with your script and never got to the point you were making.
I'm reopening the bug report, and am proposing a patch.
Please try the attached patch.
(file #35774)
|
Wed 16 Dec 2015 07:54:02 PM UTC, comment #19:
Dear Ben, am I too tired, or are you still missing the point
(Your axes units still not "centimeters") ?
Thanks for your scripts, but it is not only achieving the final result that matter (this I figured as much now, after so much work on that). The point is to get it right even when axes units are in centimeters.
Regarding your observations about dpi, here are some links, maybe related:
http://fr.mathworks.com/help/matlab/creating_guis/dpi-aware-behavior-in-matlab.html?searchHighlight=screenpixelsperinch
Now (2015b) pixels are absolute values (like points, but conversions system-specific). On mac a pixel is like a point (1/72 "). On windows it is (1/96 "). Crazy ?
Only on linux do pixels stay screen pixels.
Aidtopia answer is old but interesting:
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/73412a1a-36c5-406c-8fcd-fc62e74c5bb5/display-resolution-and-font-size?forum=windowsuidevelopment
|
Wed 16 Dec 2015 07:22:19 PM UTC, comment #18:
Note that Gnuplot used 72 points/inch.
|
Wed 16 Dec 2015 07:21:31 PM UTC, comment #17:
I've modified my script to support Gnuplot output. I've attaching it and the PDF and figure images that result.
(file #35771, file #35772, file #35773)
|
Wed 16 Dec 2015 06:52:09 PM UTC, comment #16:
Now the Octave and Matlab images
(file #35767, file #35768, file #35769, file #35770)
|
Wed 16 Dec 2015 06:51:21 PM UTC, comment #15:
I've run tests on both Matlab and Octave. The principal difference between the two is that Matlab reports the screenpixelsperinch to be 90 and Octave reports 129. The Octave value is correct, while the Matlab value is reporting the screenpointsperinch. Both of these numbers are needed in order to produce a wysiwyg result.
I'm attaching a script that works for me on both Matlab and Octave (current stable branch with tip 40e1134ec984). I'll also attach images of the resulting PDFs generated as well as the original figures.
(file #35766)
|
Wed 16 Dec 2015 03:25:14 AM UTC, comment #14:
Sigh. Apparently operating systems don't use a consistent standard for the size of displayed font sizes.. My system appears to be using 90 points/inch.
To make matters more complicated, Mathworks doesn't interpret the root property screenpixelsperinch literally. Instead the value for this property implies it represents screenpointsperinch. My screen resolution is 129 dpi, but the font displays assuming 90 points/inch.
|
Wed 16 Dec 2015 03:05:24 AM UTC, comment #13:
Ederag / others,
I tried comparing a PDF of the same size as the plot on screen and discovered that the displayed fantasize on my Mac assumes 90 dpi (instead of 72 dpi).
The resulting images for the PDF and the figure are attached. I'm curious if the 90 dpi is some standard I'm not aware of ... i.e. do fontsizes on screen and on paper assume a different dpi?
(file #35760, file #35761)
|
Tue 15 Dec 2015 02:24:05 PM UTC, comment #12:
I tried a simple example
The resulting PDF has the width/height specified by the paperposition property.
This looks like an OpenGL version of the #46122 associated with Gnuplot (which will need to be backedout). In which case, there is no bug. The root cause is the confusing way Mathworks decided to implement the Paper* properties.
I'm closing this bug report. It can be reopened in the event there is something I've missed/overlooked.
|
Wed 25 Nov 2015 07:05:24 PM UTC, comment #11:
The repositioning must be avoided for objects with "data" units. Otherwise labels, titles (for instance) were not correctly positioned in the printout.
Patch attached
(file #35548)
|
Sat 31 Oct 2015 05:52:32 PM UTC, comment #10:
Actually it was already working for gnuplot, fltk and qt.
(with only small round-off errors for fltk and qt)
But with qt, sometimes the print command returned before the file was actually written. In these cases the checks were made on the wrong files.
cf. screenshots in tests_15a31aa.pdf
The tests script has been fixed (attached).
The cmp function could be handy elsewhere.
It displays observed and expected results
in green, yellow or red, depending on their mismatch.
It uses cprintf.m, which has been placed at
https://sourceforge.net/p/cprintf-m/code
(file #35349, file #35350)
|
Sun 25 Oct 2015 08:48:01 PM UTC, comment #9:
Meanwhile, the rescaling by 72/screenpixelsperinch (of positions and fonts) is done only in opengl_print.m, since it is quite specific to gl2ps.
with the (complete hg export) patch attached the pdf printout looks fine.
But this is not yet finished:
- error handling ?
- the png output is almost fine for "fltk" (just small round-off errors) but not quite for "qt".
- In this naive version, all positions are changed, but what if some are dependent on others ?
(file #35293)
|
Sun 25 Oct 2015 03:19:19 PM UTC, comment #8:
Thanks for the clarification. In my example the paperposition and the figure position are set to the same value (in centimeters), so that no rescaling should be needed (as for "auto" paperpositionmode).
But now I see that there is always the "draw and let gl2ps capture coordinates" step.
|
Sun 25 Oct 2015 02:37:32 PM UTC, comment #7:
gl2ps behavior is not responsible for the flickering, we do have to rescale the figure whatever the scale gl2ps uses. The process of printing is:
- resize the figure at printing dimensions so that the position of text and other fixed size objects can be recomputed,
- draw and let gl2ps capture coordinates
- come back to original on-screen dimensions.
The flickering is unavoidable (for non "auto" paperpositionmode) unless we make an invisible copy of the figure and print that one, but this only works on some machines with linux.
|
Sun 25 Oct 2015 01:57:35 PM UTC, comment #6:
Thanks Pantxo for your comment #2, comment #5 and the new title.
Your example is much simpler indeed, and solving this case might be enough.
You might find the additional tests in "script_wysiwyg_tests.m" useful, since with opengl ("qt") they do not pass.
Having gl2ps output in the right units would be much desired. That would avoid the rescaling (and hence the flickering).
But meanwhile the rescaling by 72/screenpixelsperinch (of positions and fonts) should be done only in _opengl_print_.m, since it is quite specific to gl2ps ?
|
Sun 25 Oct 2015 01:28:25 PM UTC, comment #5:
I don't have time to review your patch for gnuplot but I agree with the fact it would be much simpler in qt/fltk if gl2ps scaled coordinates itself.
Strangely enough (some old Matlab crap?), if you convert the default "paperposition" to points you'll get something that is not so far from the default "position" in pixels. This is why, by default, objects with absolute coordinates are not so wrong in gl2ps printout: the preprint resizing (to draw pixels as points) doesn't change the position so much.
Retitling the report to better describe the issue
|
Sun 25 Oct 2015 12:40:17 PM UTC, comment #4:
Sorry, I see your comment #2 only after sending my comment #3. Thanks for the feedback, I've got to read it.
|
Sun 25 Oct 2015 12:35:37 PM UTC, comment #3:
The attached hg export, relative to changeset 20599:1c5a86b7f838
fixes this bug for gnuplot.
The sizes and resolution can also be given from command line (the -r or -Ssx,sy options).
All the tests in the script attached pass with gnuplot.
Unfortunately with opengl (fltk or qt) things are still broken.
The discrepancy boils down to gnuplot using the real size, while the opengl uses gl2ps which does not use the real size. Instead, gl2ps uses the positions that are given in pixels, as if they were points (1 pt = 1 in / 72). This leads to problems when absolute units (centimeters for instance) are used. Actually the issue has already been raised:
http://www.geuz.org/pipermail/gl2ps/2015/000416.html
AFAIU, if the gl2ps behaviour can not be changed, we need to convert all the positions, either for gnuplot or for opengl.
I would vote to use real sizes (as in the given patch), since it is nicer for figure preparation (WYSIWYG), and scale the positions for opengl.
(file #35290, file #35291)
|
Sun 25 Oct 2015 11:40:06 AM UTC, comment #2:
Hi,
Thanks for your report. Your example is a bit complicated and I think it boils down to the script bellow:
For OpeznGL based toolkits (I don't know much about gnuplot), the problem is that when printing we basically have to assume "screenpixels=>points". The library we use for printing (gl2ps) captures our OpenGL operations and interprets pixels as points. See this discussion in which I was concerned about text (fixed size as in your example):
http://www.geuz.org/pipermail/gl2ps/2015/000418.html
So when using "paperpositionmode"="auto" we want to draw a figure that has the exact same size as on-screen: if it is X pixels wide on-screen, we have to redraw it (this is one of the reasons for the flickering) on a canvas that is (X/screenpixelsperinch*72) wide so that the final figure has the right size. As people tend to often have screenpixelsperinch>72 this usually means downsizing the figure. Unfortunately any fixed size object (text or absolute "units" property) will end-up being magnified in the printout figure.
Are there other issues I didn't notice that your example shows and that mine neglects?
|
Sun 25 Oct 2015 10:18:35 AM UTC, comment #1:
Here is the script used to generate the outputs of comment #1. The goal is a figure for an article, with several maps, and being more WYSIWYG would help a lot.
(file #35289)
|
Sun 25 Oct 2015 10:12:59 AM UTC, original submission:
This is closely related to bug #46122, which has been fixed,
but only for a single plot, where only the figure position was specified.
When the plot position also is specified in absolute units (centimeters for instance), then the figure is again truncated.
This happens both with gnuplot and qt toolkits, and both with png and pdf outputs, although the truncation is different. (outputs attached)
These outputs are from octave-4.0.0 patched according to bug #46122. But with stock 4.0.0 it was wrong also. And the same happens with the development version (changeset 20599:1c5a86b7f838).
|