From: karlton@fudge.asd.sgi.com (Phil Karlton)
Newsgroups: comp.graphics.opengl,comp.sys.sgi
Subject: Re: OpenGL Printers?
Date: 5 Oct 92 03:35:29 GMT
Reply-To: karlton@sgi.com
Followup-To: comp.graphics.opengl
Organization: Silicon Graphics, ASD
NNTP-Posting-Host: fudge.asd.sgi.com

In article <1992Oct5.030037.26873@sol.ctr.columbia.edu>, shenkin@avogadro.barnard.columbia.edu (Peter S. Shenkin) writes:

    I posted the following to comp.sys.sgi, and someone suggested that
    I crosspost to comp.graphics.opengl, so I'm doing this now.

I am posting the answer to both groups with the followup only to
comp.graphics.opengl.

    I'm wondering if it would be possible to devise an interpretive
    languge which would do for the printing of 3D images what
    PostScript did for the printing of 2D images.

Software can do anything, so it's possible. In fact I think there are
no technical reasons to keep it from being a straightforward task.
Whether it is as successful as PostScript is more of a marketing as
oppposed to technical question.

    Right now, all techniques that I am aware of for printing a 3D
    image involve passing a bitmap -- embedded in PostScript or in some
    other protocol -- to a printer.  This results in huge files
    (especially for PostScript), and restricts the output to the
    resolution of the device from which the image was captured (eg, the
    screen), rather than to the intrinsic resolution of the ouput
    device (ie, the printer), unless I misunderstand.

True.

    There is no reason that OpenGL could not be ported to a printer.

The printer should have fairly good floating point capabilities as well
as enough memory to hold all the buffers (Z, stencil, etc.) that may
be needed to render the image.

    If one then had an ascii language that describes a 3D scene and
    that maps onto OpenGL, one could pass the scene description to the
    printer in concise ascii form, and it would render to the full
    resolution of the printer.

The hardest part of this task is doing all the wrapper code for
controlling the printer. All OpenGL implementations need to have some
binding to the "native" window system; in this case the window system
is the printer's environment. If one were to try and use OpenGL as an
extension to PostScript, then that definition would have to be made
formal.

    Right now there providers of packages that use GL face large
    problems in getting good hard-copy of images in a general way.  It
    seems to me that this would solve that problem.

It certainly seems like an attractive path to pursue. Anybody with a
license for OpenGL is free to implement such a solution.

    Is such a thing possible?  Note that the implementation would not
    have to be as blazingly fast as one needs it for interactive work.
    Anyone who's ever sent a PostScript bitmap to a printer knows how
    much room there is for improvement.  Even a dumb implementation on
    a reasonably fast general- purpose processor would probably
    suffice.

See above re: floating point.

    Even without an intermediate ascii language, it would be an
    advantage for OpenGL to be ported to printers, it seems to me.  By
    rendering directly to the printer, one could take advantage of
    whatever resolution and other features the printer had.

Resolution is mostly one of those environment issues. It would also
impact the definition of glViewport. See the man page.

PK
--
Phil Karlton				Silicon Graphics Computer Systems
Curmudgeon				2011 N. Shoreline Blvd.
					Mountain View, CA  94039-7311
karlton@.sgi.com			415-390-1557

It's hard to get off course in one dimension.