In idl, we distinguish between generating a postscript file from an encapsulated postscript file by using or not using the /encapsulated keyword in the device command after the set_plot,'ps' command. If no /encapsulated keyword is used (or if encapsulated=0 is used) in the device command, we generate a postscript file, with full page layout controlled by device keywords xoffset, yoffset, xsize, and ysize, and the generated postscript file is then ready to output to a printer. If the /encapsulated keyword is used (or encapsulated=1), we generate an encapsulated postscript file suitable for importing into other documents, with the xsize and ysize device command keywords controlling the size of the viewing area.
E.g. the following procedure generates a postscript file:
And the following procedure generates an encapsulated postscript file:
pro simple_eps
set_plot, 'ps'
device, filename='simple_eps.eps', $
/encapsulated, $
/inches, $
xsize=6.0, ysize=6.0
plot, [0.,1.,2.,3.], [0.,1.,4.,9.], title='TITLE'
device, /close
end
Using gdl 0.9.1 under OS-X 10.6.8, neither of these simple procedures runs. The xoffset and yoffset keywords generate an error in the simple_ps procedure. The /encapsulated keyword generates an error in the simple_eps procedure.
If the /encapsulated keyword is removed in the simple_eps procedure, the procedure will then run with gdl-0.9.1. But it generates an encapsulated postscript file instead of the expected postscript file. And this encapsulated postscript file contains an unexpected bounding box ( 93 152 516 606 ), which indicates that the xsize=6.0 and ysize=6.0 keywords did not make the plotting area the same size in the x and y directions with gdl. Under idl, the bounding box for the encapsulated postscript file is 0 0 432 432 as expected, with 432 being 6 * 72 (6 inches, 72 default postscript points per inch).
It appears that gdl cannot generate a regular postscript file using the standard idl technique. And the encapsulated postscript file generated by gdl does not have the expected x vs y aspect ratio.
Are these apparent gdl postscript (regular and encapsulated) problems known? I'm just beginning to explore gdl as an alternative to idl for my scientific work group, but precise control of postscript output is usually an important issue with my users. Being unable to generate a ready to print regular postscript file with explicit page margins and plotting area size would be a serious limitation for our users, as would being unable to precisely control the size of the generated encapsulated postscript.
Does gdl-0.9.1 possibly use different keywords in the device command to handle these critical postscript controls?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hello,
Thanks a lot for a detailed report! Some of the problems you've mentioned were already reported/known but it's very helpful to have a detailed description with examples. I'll try to find some time this week to fix it.
Best,
Sylwester
P.S. In some cases, converting the resultant PostScript file to PDF helps with the bounding-box problem.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks to Andrew Ross PLplot has the offset issue fixed now (in their SVN version).
I shall try to put into the GDL CVS a fix for the OFFSET and SIZE keywords in the upcoming days.
Anyhow, working on it I realised that as of now PLplot can produce only encapsulated PostScript (e.g. it has the EPS header hardcoded- see line 245 in http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/drivers/ps.c?annotate=11916)
Perhaps the non-encapsulated file can be produced with help of another PostScript library (e.g. pslib) - I'll look into it.
Sylwester
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That is really a great news. So much requests for that.
We have a to-be-enriched testsuite/test_postscript.pro file ;-)
The main difference between PS and EPS (excepted some tricks on starting points for Bounding Box) is the last commands in PS file, "restore" and "showpage"
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
A preliminary support for XSIZE, YSIZE, XOFFSET, YOFFSET, ENCAPSULATED, SCALE_FACTOR, PORTRAIT and LANDSCAPE is now included in the CVS version of GDL. It requires the -with-pslib option (enabled by default) and installation of pslib (http://pslib.sourceforge.net/)
Please test,
Sylwester
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In idl, we distinguish between generating a postscript file from an encapsulated postscript file by using or not using the /encapsulated keyword in the device command after the set_plot,'ps' command. If no /encapsulated keyword is used (or if encapsulated=0 is used) in the device command, we generate a postscript file, with full page layout controlled by device keywords xoffset, yoffset, xsize, and ysize, and the generated postscript file is then ready to output to a printer. If the /encapsulated keyword is used (or encapsulated=1), we generate an encapsulated postscript file suitable for importing into other documents, with the xsize and ysize device command keywords controlling the size of the viewing area.
E.g. the following procedure generates a postscript file:
And the following procedure generates an encapsulated postscript file:
Using gdl 0.9.1 under OS-X 10.6.8, neither of these simple procedures runs. The xoffset and yoffset keywords generate an error in the simple_ps procedure. The /encapsulated keyword generates an error in the simple_eps procedure.
If the /encapsulated keyword is removed in the simple_eps procedure, the procedure will then run with gdl-0.9.1. But it generates an encapsulated postscript file instead of the expected postscript file. And this encapsulated postscript file contains an unexpected bounding box ( 93 152 516 606 ), which indicates that the xsize=6.0 and ysize=6.0 keywords did not make the plotting area the same size in the x and y directions with gdl. Under idl, the bounding box for the encapsulated postscript file is 0 0 432 432 as expected, with 432 being 6 * 72 (6 inches, 72 default postscript points per inch).
It appears that gdl cannot generate a regular postscript file using the standard idl technique. And the encapsulated postscript file generated by gdl does not have the expected x vs y aspect ratio.
Are these apparent gdl postscript (regular and encapsulated) problems known? I'm just beginning to explore gdl as an alternative to idl for my scientific work group, but precise control of postscript output is usually an important issue with my users. Being unable to generate a ready to print regular postscript file with explicit page margins and plotting area size would be a serious limitation for our users, as would being unable to precisely control the size of the generated encapsulated postscript.
Does gdl-0.9.1 possibly use different keywords in the device command to handle these critical postscript controls?
Hello,
Thanks a lot for a detailed report! Some of the problems you've mentioned were already reported/known but it's very helpful to have a detailed description with examples. I'll try to find some time this week to fix it.
Best,
Sylwester
P.S. In some cases, converting the resultant PostScript file to PDF helps with the bounding-box problem.
Well, the problem is that the values corresponding to XOFFSET and YOFFSET are hardcoded in the underlying Plplot library
(http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/include/ps.h). I've just submitted a bug report describing the issue to the Plplot bug tracker: https://sourceforge.net/tracker/?func=detail&aid=3404359&group_id=2915&atid=102915
Once plplot has it fixed, it will be possible to implement XOFFSET and YOFFSET, and all other PostScript paper size settings in gdl.
Sylwester
Thanks to Andrew Ross PLplot has the offset issue fixed now (in their SVN version).
I shall try to put into the GDL CVS a fix for the OFFSET and SIZE keywords in the upcoming days.
Anyhow, working on it I realised that as of now PLplot can produce only encapsulated PostScript (e.g. it has the EPS header hardcoded- see line 245 in http://plplot.svn.sourceforge.net/viewvc/plplot/trunk/drivers/ps.c?annotate=11916)
Perhaps the non-encapsulated file can be produced with help of another PostScript library (e.g. pslib) - I'll look into it.
Sylwester
Just for the record, the plplot only-EPS issue is described here:
https://sourceforge.net/tracker/?func=detail&aid=3407861&group_id=2915&atid=102915
S.
That is really a great news. So much requests for that.
We have a to-be-enriched testsuite/test_postscript.pro file ;-)
The main difference between PS and EPS (excepted some tricks on starting points for Bounding Box) is the last commands in PS file, "restore" and "showpage"
A preliminary support for XSIZE, YSIZE, XOFFSET, YOFFSET, ENCAPSULATED, SCALE_FACTOR, PORTRAIT and LANDSCAPE is now included in the CVS version of GDL. It requires the -with-pslib option (enabled by default) and installation of pslib (http://pslib.sourceforge.net/)
Please test,
Sylwester
when I did "make check", the test failed for test_ps_decomposed.pro
basically the ps file became blank after the "device, /close" command.
P.S. I am using ubuntu 11.04 (plplot from repository, CVS version of gdl),