[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PostScript and IDL,
- Subject: Re: PostScript and IDL,
- From: steinhh(at)ulrik.uio.no (Stein Vidar Hagfors Haugan)
- Date: 27 May 1998 09:32:55 GMT
- In-reply-to: email@example.com's message of Tue, 26 May 1998 07:58:01 -0600
- Newsgroups: comp.lang.idl-pvwave
- Organization: University of Oslo, Norway
- References: <Pine.LNX.3.95.980526091307.6500Bfirstname.lastname@example.org><MPG.email@example.com>
- Xref: news.doit.wisc.edu comp.lang.idl-pvwave:11062
In my opinion, the PostScript output from object graphics
is so lame (both in quality and file size) that it is
endangering the whole idea of using object graphics for
anything that you may at some point in time want to
publish on paper.
This is a bit of ranting over some details that irritate
me enormously. For some reason, it seems that the OG
printer output interface was written by someone with
experience exclusively from PC's, with a very cheap
(low-resolution) printer hanging on the side, hardwired
into the motherboard for instantaneous input of whatever
is on the screen in a WYSIWYG manner :-). Never any *real*
reason to create *real* encapsulated postscript files with
any controllable size or anything!
With the normal 'PS' device you can control the sizes
etc. of the EPS output, but no, this object graphics stuff
is so great it always deserves a full page by itself..?
With a showpage command thrown into the file for good
measure, so the whole thing will print if you send it
straight to the printer in stead of encapsulating it in a
real document (just points out the mindset of whoever
wrote the stuff). This may cause problems for some
programs that try to manipulate/overplot stuff on the EPS
Even the simplest line plot (Generic, EPSF format) comes
out to about half a MB. Imagine writing a thesis with a
hundred of those - since you need to have the original
file as well as one copy included in your PS file, you
spend 100MB on plots!
If you throw the thing at the printer, the lines are
clearly more jagged than direct graphics output. The lines
are thinner, apparently just one "pixel" wide, and if you
try to shrink the full page to fit into a document, the
subsampling of the pixelized image seems to throw out
pixel rows/lines, making everything in your plot look like
it's produced with a dash-dash linestyle.
And if I ever write a *program* that produces postscript
output from object graphics, I would like to have the
ability to have some control over where the files end up,
without having to interrogate the user (myself or whoever)
every bloody time I want to send stuff to a new file!
Please, a printer->setproperty,filename=<string>!
I do like IDL's object graphics, conceptually it's very
neat and *extremely* powerful - though you *really* need
to have good graphics acceleration harware! (I don't have
But unless someone provides a method to produce sensible
postscript output, I for one will be very reluctant about
using object graphics at all.
Although the internal bitmap rendering process of OG PS
files ensures "consistent" looks between screen/postscript
output, it is simply *no* good for producing quality
output for publication! We need better resolution for
lines *and* smaller files!
Given an OG hierarchy, most of the objects contents can be
rendered quite faithfully in direct graphics without using
pixelization (shaded surfaces/texture mapped
surfaces/lighted surfaces etc excluded). Maybe someone
could write a direct graphics "renderer" of OG hierarchies?
Or maybe what we should hope for is an OpenGL printer