I ran again the macro using the X11 backend on Mac both in natch and interactive mode and the 3 png files are correct. It was hard to debug a problem I cannot reproduce …
I’ve further narrowed this issue down. It doesn’t have anything to do with the construction of the Canvas. It just so happened that when specifying the size alone the canvas was created on the largest monitor in my setup (3360 x 1890), while in the other two case the canvases were created on other windows. If I move any canvas to the large monitor and select print I only get a corner of the image. Further more this screen has the resolution scaled, if I remove the scaling and use the native resolution (3840 x 1920) then the issue disappears.
I see. I am sorry but i do not have such setup to test/debug that.
You do not have access to a Mac? Wile, indicated that the problem is also visible on Ubuntu. I believe all that needs to be done is to scale the resolution through the Display Settings. Is there something I can do on my end to provide more debugging information? I probably just need a couple of ideas of where to look to get started.
Yes that’s my machine. But the macro you provided are giving me the right png output whatever I try. May be I missed something.
I think the problem originates somewhere in TCanvas::SetWindowSize which sometimes fails in interactive mode, but here’s your own, more than 2 years old, post concerning the second problem:
Thanks for the reminder. I am looking at it again now. There is an even simpler reproducer.
void png_double_x_axis_title(){
TCanvas *c1 = new TCanvas("c1","c1",0,0,1000,2000);
c1->DrawFrame(0.,0.,10.,10.);
c1->Print("test1.gif");
c1->Print("test1.png");
c1->Print("test1.pdf");
}
So it shows only with the X11 version in interactive mode. It works in batch mode. gif and pdf work in both mode. The Cocoa version is fine in all cases.
This problem is now fixed in the ROOT master. It was in TASimage::FromPad.
Excellent, thanks for not giving up on this. I’ll be able to check it on my system next week.
Please let me know if the fix I did for the old post Wile reminded me, also fixes the issue you mentioned at the beginning of this thread. And thanks to Wile to have reminded me this old issue.
Unfortunately, this did not resolve my issue. I tested it with the master branch pulled today (commit 9e3f9c85136b26708c6813aa0fc96600b0130d21).
In you environment, does it fix the example if posted before ? i.e.:
void png_double_x_axis_title(){
TCanvas *c1 = new TCanvas("c1","c1",0,0,1000,2000);
c1->DrawFrame(0.,0.,10.,10.);
c1->Print("test1.gif");
c1->Print("test1.png");
c1->Print("test1.pdf");
}
I’m afraid that, in all cases, I get the whole non-truncated pictures but I also see some problems with the current “v5-34-00-patches” (see the reported widths and heights of GIF and PNG images and note the PDF “page rotation”):
[...] $ root -n -l -q png_double_x_axis_title.cxx
(...)
[...] $ identify test1.gif
test1.gif GIF 998x1973 998x1973+0+0 8-bit PseudoClass 8c 10.8KB 0.000u 0:00.000
[...] $ identify test1.png
test1.png PNG 998x961 998x961+0+0 8-bit DirectClass 11KB 0.000u 0:00.000
[...] $ identify test1.pdf
test1.pdf PDF 842x595 842x595+0+0 16-bit Bilevel DirectClass 63.1KB 0.000u 0:00.019
[...] $ root -b -n -l -q png_double_x_axis_title.cxx
(...)
[...] $ identify test1.gif
test1.gif GIF 996x1972 996x1972+0+0 8-bit PseudoClass 8c 10.9KB 0.000u 0:00.000
[...] $ identify test1.png
test1.png PNG 996x1972 996x1972+0+0 8-bit DirectClass 16.8KB 0.000u 0:00.010
[...] $ identify test1.pdf
test1.pdf PDF 595x842 595x842+0+0 16-bit Bilevel DirectClass 63.2KB 0.000u 0:00.000
I get non truncated pictures (gif, png, pdf) with both 5.34 and 6.11
See the two attached screen shots I just did:
Try to run “identify” on all three files (I think I can clearly see that your GIF has another “proportions” than your PNG and PDF).
Note also that in my case, my screen is 1680x1050 so, requesting a canvas 1000x2000 will trigger its “shrinking” in interactive mode (and that happens for the second PNG but not for the first GIF and then the third PDF “aspect ratio” is wrong -> in batch mode there is no need for “shrinking” so GIF and PNG sizes seem to be o.k. but the PDF “aspect ratio” is again wrong, but different from the one in the interactive mode).
Hi @Wile_E_Coyote, I am trying to first solve the @ksmith issue: which is the truncated output for the png and gif files. None of the ROOT versions I am suing produce such truncated output after the fix I did. I do not understand why he gets this truncation with the small macro example I posted. Then I will look at your suggestion in this post . If you think there is an other issue wihen running “identify” it might better to make an other post or a Jira report. Right now I am debugging an other issue not related to this topic.
Note that I am also talking about your small macro example. Like you, I also get non-truncated output, but I can clearly see that their sizes, reported by “identify”, are wrong.
Why are the figures so much taller than mine? Mine look rather square by eye. In addition, have you scaled the resolution down, if you are using a mac? I don’t see the issue at the nominal resolution.
No idea.
I am using an iMac 27 inches with the X11 backend. I did nothing special. Just ran the normal ROOT. I had the truncated output before I did the fix. Now with the fix it is fine,
So what do you suggest I tried on my Mac ?