Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print(fwd)
- From: Michael Sweet <mike easysw com>
- To: Lauris Kaplinski <lauris kaplinski com>
- CC: Ben Woodard <ben valinux com>, Robert L Krawitz <rlk alum mit edu>, miguel helixcode com, neumanns uni-duesseldorf de, gnome-print helixcode com, rlk tiac net
- Subject: Re: [Gnome-print] Re: [Gimp-print-devel] An introduction to gnome-print(fwd)
- Date: Wed, 07 Jun 2000 08:48:26 -0400
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.
> 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.
> 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.
> 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?
> 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)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike@easysw.com
Printing Software for UNIX http://www.easysw.com
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]