Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print(fwd)

[Lauris Kaplinski <lauris kaplinski com>]

On Wed, 7 Jun 2000, Michael Sweet wrote:

> Lauris Kaplinski wrote:
> > ...
> > 3. Fonts suck badly :(
> 
> Aside from the fact that font formats are complicated, I think the
> font *handling* in PS is pretty darn good.  You can do just about
> anything you like as long as you have the fonts.

1. Reencoding sucs. You cannot use exact (integer) metrics without using
   strings. PS string handling was (at least with PS level II) ugly - all
   kinds of absurd variable width font/char pairs, but neither 32-bit
   glyphlist nor way to show array of glyph names.
2. You cannot do anything similar to TTF, as there is no acess to buffer
   (again)

> > AFAIK there is still no way to acess underlying rendered buffer in
> 
> Nope, nor will there be for an important reason - the PostScript
> rendering model is designed to work with raster *and* vector
> devices.

And that exactly IS the reason you cannot do anything advanced in PS, but
have to render HUGE clent side bitmaps from almost everything.
P.S. Plotters usually cannot print bitmaps too - why there are image
operators at all - pixels could also been drawn as tiny vector boxes ;)

> > PS, nor ability to render temporary buffers (a la OpenGL). No way to
> > compile procedures - only bind, which is poor solution. Even worse -
> 
> Binding procedures "compiles" them into the intermediate binary
> coded format (kinda like Java), so it's as fast as can be expected
> short of generating actual machine language code.

O.K. I was wrong.
But:
/mypath {long_path_description fill} bind def
Can I count, that later, using mypath, it is rendered without intermediate
path construction?

> > no graphic operator does not have to do anything trackable, before
> > showpage. Probably DPS has addressed some of these issues.
> 
> The current graphics position is tracked.  The current color is
> tracked.  Clipping paths, rendering paths, etc.
> 
> What are you referring to?

stroke, fill, eofill - after invocation I need to know, that buffer really
was changed. Then take this buffer, and do some magic.

> 
> > Adding bezier planes to OpenGL would result in a bit better API,
> > IMHO.
> 
> Off topic, but having done 3D graphics for 12 years I can tell you
> that bezier clipping planes would make rendering unbelievably
> slow (it's bad enough rendering NURBS)