bugGNU Octave - Bugs: bug #46292, Axes with absolute...

 
 

bug #46292: Axes with absolute "units" have wrong dimensions in printout

Submitter:  ederag <ederag>
Submitted:  Sun 25 Oct 2015 10:12:59 AM UTC
   
 
Category:  Plotting Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  Fixed Assigned to:  bpabbott
Originator Name:  Ederag Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

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.

Lachlan Andrew <lachlan>
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.

Ben Abbott <bpabbott>
Group Member
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?

Ben Abbott <bpabbott>
Group Member
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 ?

ederag <ederag>
Thu 17 Dec 2015 02:15:59 AM UTC, comment #21: 

Updated changeset to include all descendants of the figure.

(file #35776)

Ben Abbott <bpabbott>
Group Member
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)

Ben Abbott <bpabbott>
Group Member
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


ederag <ederag>
Wed 16 Dec 2015 07:22:19 PM UTC, comment #18: 

Note that Gnuplot used 72 points/inch.

Ben Abbott <bpabbott>
Group Member
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,

Ben Abbott <bpabbott>
Group Member
Wed 16 Dec 2015 06:52:09 PM UTC, comment #16: 

Now the Octave and Matlab images


Ben Abbott <bpabbott>
Group Member
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)

Ben Abbott <bpabbott>
Group Member
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.


Ben Abbott <bpabbott>
Group Member
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).


close all
graphics_toolkit qt
width = 4;
height = 3;
figure (1)
set (gcf (), 'units', 'inches')
set (gcf (), 'paperunits', 'inches')
position = get (gcf (), 'position');
paperposition = get (gcf (), 'paperposition');
position(3:4) = [width, height];
paperposition(3:4) = [width, height];
set (gcf (), 'position', position)
set (gcf (), 'paperposition', paperposition)
plot (rand (3))
xlabel xlabel
ylabel ylabel
title 123456789012345678900123456789012345678901234567890
pdffile = 'wysisyg.pdf';
h = findall (gcf (), '-property', 'fontsize');
fontsize = cell2mat (get (h, 'fontsize'));
scale = 90 / get (0, 'screenpixelsperinch');
for n = 1:numel(h)
  set (h(n), 'fontsize', fontsize(n) * scale)
end
print ('-dpdfwrite', pdffile)
for n = 1:numel(h)
  set (h(n), 'fontsize', fontsize(n))
end


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?




Ben Abbott <bpabbott>
Group Member
Tue 15 Dec 2015 02:24:05 PM UTC, comment #12: 

I tried a simple example

close all
graphics_toolkit qt
plot (rand (3))
print -dpdfwrite foo.pdf

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.

Ben Abbott <bpabbott>
Group Member
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)

ederag <ederag>
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)

ederag <ederag>
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)

ederag <ederag>
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.

ederag <ederag>
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.

Pantxo Diribarne <pantxo>
Group Member
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 ?

ederag <ederag>
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

Pantxo Diribarne <pantxo>
Group Member
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.

ederag <ederag>
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)

ederag <ederag>
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:


## Use absolute units for the axes object
hax = axes ("units", "centimeters");
set (gcf, "paperpositionmode", "auto")
print foo.pdf


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?

Pantxo Diribarne <pantxo>
Group Member
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)

ederag <ederag>
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).

ederag <ederag>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #35776:  changeset.patch added by bpabbott (3KiB - application/octet-stream)
file #35774:  print.patch added by bpabbott (2KiB - application/octet-stream - allows printing when axes units are not "normalized")
file #35773:  Gnuplot PDF Image.png added by bpabbott (80KiB - image/png - Gnuplot pseudo wysiwyg results)
file #35772:  Gnuplot Figure Image.png added by bpabbott (50KiB - image/png - Gnuplot pseudo wysiwyg results)
file #35771:  wysiwyg_matlab.m added by bpabbott (2KiB - application/octet-stream - Gnuplot pseudo wysiwyg results)
file #35769:  Octave PDF Image.png added by bpabbott (84KiB - image/png)
file #35770:  Matlab PDF Image.png added by bpabbott (85KiB - image/png)
file #35766:  wysiwyg_matlab.m added by bpabbott (2KiB - application/octet-stream - script to achieve pseudo wysiwyg output)
file #35760:  figure-image.png added by bpabbott (48KiB - image/png - Ben's images from Mac OS X)
file #35761:  PDF-image.png added by bpabbott (82KiB - image/png - Ben's images from Mac OS X)
file #35548:  octave-4.1.0p_15b25aa_noreposition-for-data.hg.diff added by ederag (1KiB - text/x-patch - do not reposition objects with "data" units)
file #35349:  tests_15a31aa.pdf added by ederag (34KiB - application/pdf - test script and screenshots, with colors)
file #35350:  script_wysiwyg_tests.m added by ederag (4KiB - text/x-matlab - test script and screenshots, with colors)
file #35293:  wysiwyg_15a25ba.hg.diff added by ederag (14KiB - text/x-patch - [full hg export] rescaling by 72/screenpixelsperinch in opengl_print.m)
file #35290:  wysiwyg_15a25.hg.diff added by ederag (13KiB - text/x-patch - patch (hg export) for "gnuplot" + tests)
file #35291:  script_wysiwyg_tests.m added by ederag (2KiB - text/x-matlab - patch (hg export) for "gnuplot" + tests)
file #35289:  script_wysiwyg_multi.m added by ederag (2KiB - text/x-matlab - The script used to generate the outputs of comment #1)
file #35285:  multi_v4.0.0_gnuplot.pdf added by ederag (7KiB - application/pdf - outputs from octave-4.0.0 patched according to bug #46122)
file #35286:  multi_v4.0.0_qt.pdf added by ederag (5KiB - application/pdf - outputs from octave-4.0.0 patched according to bug #46122)
file #35287:  multi_v4.0.0_gnuplot.png added by ederag (29KiB - image/png - outputs from octave-4.0.0 patched according to bug #46122)
file #35288:  multi_v4.0.0_qt.png added by ederag (29KiB - image/png - outputs from octave-4.0.0 patched according to bug #46122)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lachlan (Posted a comment)
  • -email is unavailable- added by bpabbott (Posted a comment)
  • -email is unavailable- added by pantxo (Posted a comment)
  • -email is unavailable- added by ederag (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 25 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2016-01-25 bpabbott Open/ClosedOpen Closed
    2015-12-18 bpabbott StatusPatch Submitted Fixed
        Release4.0.0 dev
    2015-12-17 bpabbott Attached File- Added changeset.patch, #35776
    2015-12-16 bpabbott Attached File- Added print.patch, #35774
        StatusInvalid / Not an Octave Bug Patch Submitted
        Open/ClosedClosed Open
    2015-12-16 bpabbott Attached File- Added wysiwyg_matlab.m, #35771
        Attached File- Added Gnuplot Figure Image.png, #35772
        Attached File- Added Gnuplot PDF Image.png, #35773
    2015-12-16 bpabbott Attached File- Added Octave Figure Image.png, #35767
        Attached File- Added Matlab Figure Image.png, #35768
        Attached File- Added Octave PDF Image.png, #35769
        Attached File- Added Matlab PDF Image.png, #35770
    2015-12-16 bpabbott Attached File- Added wysiwyg_matlab.m, #35766
    2015-12-16 bpabbott Attached File- Added figure-image.png, #35760
        Attached File- Added PDF-image.png, #35761
    2015-12-15 bpabbott Item GroupIncorrect Result Other
        StatusConfirmed Invalid / Not an Octave Bug
        Assigned toNone bpabbott
        Originator Name Ederag
        Open/ClosedOpen Closed
    2015-11-25 ederag Attached File- Added octave-4.1.0p_15b25aa_noreposition-for-data.hg.diff, #35548
    2015-10-31 ederag Attached File- Added tests_15a31aa.pdf, #35349
        Attached File- Added script_wysiwyg_tests.m, #35350

    Back to the top

    Powered by Savane 3.13-758e.
    Corresponding source code