Sat 10 Dec 2011 03:19:32 AM UTC, comment #15:
Since there has been no further discussion, I'm closing this bug report.
|
Wed 30 Nov 2011 08:51:06 PM UTC, comment #14:
Ok. I'll make the change.
Thanks
p.s. there appear to be some problems with the FLTK backend handling this correctly. I haven't checked to see if those bugs have already been reported, but it not feel free to add them.
|
Wed 30 Nov 2011 08:12:41 PM UTC, comment #13:
Fine with me.
|
Wed 30 Nov 2011 07:50:43 PM UTC, comment #12:
I think the wiggle is due to pixelization of the image.
In any event, the problem with the legend size is due to gnuplot's behavior.
The general fix is to finish the work on the OpenGL backend and switch to that.
Thus, if there is no objection, I'd like to mark the status as "Wont Fix", and close the report.
|
Wed 30 Nov 2011 05:27:56 PM UTC, comment #11:
Yes, now we are seeing the same thing.
Having that settled, do you also see the wiggle in the red legend bar in the Octave figure?
|
Wed 30 Nov 2011 01:37:10 PM UTC, comment #10:
Ok. I think I'm seeing what you are. I wrote a similar script that runs under both Octave and Matlab.
Both the Octave (tip 0fea4cf22f88) and Matlab (R2011b) results are attached.
The text sizes are spacing of the legend entries are the same. However, the position of the legend is different.
For the OpenGL backend Octave explicitly specifies the legend position. For the gnuplot backend the placement is determined by gnuplot. Unfortunately gnuplot's design allows each terminal to implement such things inconsistently.
Some of our developers had attempted to approximate the bbox of text objects and implement the legend in octave (without gnuplot's key feature). Ultimately, we gave up on this due to unreliable and ugly results.
In any event, please verify I am seeing the problem you're reporting.
(file #24505, file #24506)
|
Wed 30 Nov 2011 06:20:01 AM UTC, comment #9:
I'm really lost now, and I am still not convinced that we talk about the same thing. At least I have two clear answers:
To Jordi: ("Isn't this relative size also different if you resize the plot window?") - No it is not. If the right bar is, say, 10 times as tall as the the legends are thick, then they remain so if I resize the window.
To Ben: ("Using x11 the relative size does change as the figure is resized...") - Same thing. No. Not on any of my machines.
I just checked matlab, and everything (plot and print) looks absolute identical there, which is what I would expect.
Of course the size of the final figure depends on the screen or print resolution, but that should be unique across the entire figure, so that the bars and not scaled differently than the legends.
I may still be completely missing something, but could you at least confirm that matlab's behavior is what one would expect, that is, (mathematical) similarity of plotted and printed figure?
Thanks.
|
Wed 30 Nov 2011 03:27:04 AM UTC, comment #8:
Muhali,
You've misunderstood. The differences you see are not due to the fontsize.
It is due to (1) the difference is the size of the bitmaps, and (2) the difference in screen resolution and 150 dpi assumed by the print() command.
|
Wed 30 Nov 2011 03:21:30 AM UTC, comment #7:
Using x11 the relative size does change as the figure is resized. However, on MacOS X using "aqua" resizing the window just scales everything.
This is an annoying feature of gnuplot. Every terminal may behave differently.
|
Wed 30 Nov 2011 03:15:23 AM UTC, comment #6:
Isn't this relative size also different if you resize the plot window?
|
Wed 30 Nov 2011 03:09:37 AM UTC, comment #5:
so if it is fontsize (alone), why should that lead to a distortion of the figure? Meaning that the relative size of bars and legends is different when displayed and when printed.
That doesn't seem correct to me.
|
Wed 30 Nov 2011 02:40:21 AM UTC, comment #4:
There may be a problem with the fontsizes, but looking at your examples, they look correct to me.
You've set it to 6pts, which will display as 6*dpi_monitor/72 pixels. Looking at the png of your figure, I notice the font size is about 12 pixels. Thus, it looks to me as if your monitor's dpi is about 140-150 dpi.
You can check the dpi of your monitor by
The size of png output produced by print() is determined by ...
The size of the printed png is 1200x900, so that checks out.
The font size in pixels for the png should be 6 * 150 / 72 = 12.5 pixels.
Looking at the png output you provided, there are 13 pixels between baselines of the legend labels. So this looks about right to me.
Notice that the text height relative to the figure size should look very different because the figure window has a size of 560x420 pixels and the printed version is 1200x900 pixels.
|
Wed 30 Nov 2011 02:09:28 AM UTC, comment #3:
When you look at both plots side by side you will see that in foo.png the legend is much smaller relative to the bars. The relative scale of plot elements should be preserved in prints, no?
|
Wed 30 Nov 2011 01:38:52 AM UTC, comment #2:
Unless I'm missing something, I think you've misunderstood how the print command is designed to work.
The print command is not intended to produce bitmapped output that is identical in size to that displayed on the screen.
The size of the graphic is normally determined by the figure's "paperposition" property and the default resolution (150 dpi). This behavior can be over-ridden by using the appropriate options.
See "help print". To get the desired result, look at the `-SXSIZE,YSIZE' and `-rNUM' options.
Does this resolve the problem for you?
|
Tue 29 Nov 2011 09:27:32 PM UTC, comment #1:
You may have noticed that the 2nd legend (red) looks somewhat frizzy; it becomes obvious when you blow it up.
|
Tue 29 Nov 2011 07:18:23 PM UTC, original submission:
The following sequence produces two figures (attached) which should be identical but are not, as the legend size is completely different. gnuplot-foo.png is the figure displayed by octave/gnuplot, and foo.png is the actual print output.
|