Re: [Gnome-print] clip and newpath

[Lauris Kaplinski <lauris helixcode com>]

On 04 Dec 2000 13:44:48 -0600, Chema Celorio wrote:
> Lauris Kaplinski wrote:
> > I am planning to modify the behaviour of clip and eoclip calls in
> > gnome-print to execute implicit newpath. This is NOT COMPATIBLE with
> > PostScript - but PS behaviour does not make any sense. I cannot
> > think about any situation, where clip without newpath would be
> > useful.
> > So what do ou think?
> I'd say that it is ok as long as it is documented.

I though a bit about the whole issue (I am privately experimenting with
cleanup of ps2 context at moment), and got to the following conclusions:
1. Current gnome-print API is modelled after PostScript stream - that is OK
2. In addition to stream-like API, we want to add object-based API at
  some moment (Open2D, CanvasPrint or something similar)
Ideally drivers should be agnostic about the whole issue - i.e. they can
be equally easily used from both API types.

Current driver internal structure is too closely modelled after the
PostScript stream. That will make writing drivers more complex, than
it should be.

So I propose, we move to the following direction (I am speaking about
driver internals - external API will remain the same - we simply
move a little more code to main GnomePrintContext, and reduce the
code in most driver contexts):
1. We get fully rid of separate path operations in drivers. Instead
   toplevel driver keep track of currentpath
2. We get rid of separate graphic state property settings, instead there
   will be 3 available states:
 - fill (color (with colorspace), opacity)
 - stroke (color, opacity, width, dash, miter, flatness, join, cap)
 - text (color, font)
3. Basic graphic operators are
 - fill
 - stroke
 - various text oprators
 - clip
Those are treated one-shot - i.e. they are responsible about making sure
that device state is set correctly
4. Gsave and grestore are preserved, but we probably want to treat those
as hints for object grouping, instead of blindly updating device state
5. Strokepath will be managed by base GnomePrintContext. It is tricky
   if we want to preserve the possibility to do PostScript strokepaths
   - but I am not sure we want.
6. concat is managed by base GnomePrintContext

As a result PostScript is not privileged context any more and applications
should not take the false approach trying to optimize their output to
PostScript stream. We probably want to add separate object-based API
ASAP, to allow programs easy way to choose the best suitable approach.

Comments?

Lauris