[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: PostScript and IDL,




I got a very prompt reply from someone at RSI after my
previous posting. They are "acutely aware" of most of my
concerns, and are looking at different ways to address the
problems. They've asked for my comments on a few issues, and I
thought I'd give my views here so that other people may express
their (dis)agreement.

The bitmap rendering issue has, of course, been driven by
complaints about the non-WYSIWYG nature of the 'PS' device
compared to the window device, coupled with the big
difficulties of mapping object graphics primitives into PS
primitives (e.g. pixelized interpolation/textures/stenciling/
zbuffering).

Some questions that were asked by rfrank@rsinc.com:

> How acceptable is non-WYSIWYG printing as
> a trade-off for small, real EPS files?

In one way, the rasterized files ensure *very* consistent
rendering. However, wrt. the perceived *quality* of the output
when printed on paper, is *not* WYSIWYG with the current
implementation. It's more like "one type of WYSIWYG
(qualitative) vs another type of WYSIWYG (this *is* what you
did see on the screeen)". To me, it's more the perception of
the output that counts, rather than the bits &
bytes-true-to-life exact copy. So if things are slightly
different, but with things appearing in the same place, and
conveying the same "general impression" and *qualities* as the
window output, I'll be happy. Others may have very different
views on this, and my views are certainly colored by an *idea*
on what could be achieved, not having been tested on the final
trade-off...

The file sizes, however, can be a major obstacle for actually
getting to *use* the stuff. Very difficult question.... At
least I would like to have a choice in a given situation -
i.e., to be able to get *something* on a real-life printer
(within a real-life time span :-), but also to be able to get
something publishable if I want to, although it may be a post
mortem publication due to slow printing :-)

> Would you be willing to break up
> your OG scene into multiple views so that individual views could be
> drawn in raw PS while other views (depending on content) would be
> drawn as bitmaps?

Yes. Definitely. Most certainly. If that's what it takes.
This was my initial thought about those OG primitives that
*need* to be rasterized in order to get rendered at all. I
guess this is the way e.g., shade_surf works in direct
graphics...?

But is it necessary for the user to make the distinction between
the two, by using individual views? Couldn't it be done at the
"atomic" level, automatically?

> If sending out raw PostScript actually generated
> larger files (e.g. PS rasterizing replacement engines could be in the
> file or individual lines/polygons would have to be broken into smaller
> primitives to support correct clipping and composite buffering) would
> that be acceptable?

As far as I can see, this suggestion is really about
implementing some kind of OpenGL-type renderer in PostScript -
which *is* an extremely powerful, quite-useable-for-general-
purpose-programming language. Of course, I would like to say
yes thank you, both! Small files with perfectly rendered 3D
graphics objects! But I do understand that such a renderer
is a major piece of software - the files could easily end up
larger than half a Meg for the renderer alone. And furthermore,
they *may* take quite a while to process on a PostScript 
printer! I once saw a PS program that took less than one
page to print (the program itself), but produced a beautiful,
silver ball mirroring a chess board stretching out to infinity,
with some clouds around it. It took on the order of a day to
process :-)

Again, I'd suggest that the user be given a *choice* between
various output modes. Perhaps an adjustable-resolution bitmap
rendering mode (which could be used as a "draft" mode with low
resolution, producing manageable files, or as a "publication"
mode with high resolution for those with enough disk space and
printer capabilities), plus a PostScript software rendering
mode, that may produce *large* files for those graphics
hierarchies that need to have hi-tech rendering. (But remember
that it's possible to make subsets of the necessary preamble -
you don't need a huge rendering library to do a line plot
conversion from OG -> PS primitives!).

It seems like the implementation of an adjustable-resolution
bitmap rendering mode should be a piece of cake, given what's
already there... But I'd like to have at least some mode
that's not rasterizing my line plots/wire meshs etc..

RSI are continually trying to judge what compromizes to make
based on input from us - so please make your voice heard!

Regards,

Stein Vidar