Re: Simple printing

[Fred Kiefer]

Adam Fedor wrote:
> 
> Fred Kiefer wrote:
> > operation and a lot of additions to the XGStreamContext. My impression
> > is that we will have to make this context a full context similar the
> > XGContext, with its one gstate class, that would not produce any output,
> > but could hold state. So I am thinking about writting a base class for
> > XGGState that would just keep the current state and also one common
> > superclass for XGStreamContext and XGContext. These two could than also
> > serve as the starting poing for any none Postscript backend.
> 
> I'm not sure why a printing context needs to keep track of gstate info?
> A PostScript file doesn't need to keep track of state info, it just
> 'stores' the postscript commands in the order it receives them. I
> suspect any changes you need to make to support what you're thinking of
> should be implemented in the front-end, as even a true Postscript
> backend would need the same changes.
> 

I was thinking of operations that report back the state of the drawing
context. E.g. methods as [DPScurrentgray:] where the frontend asks the
backend its internal state, we have about twenty of them, but even for
one we need to keep track of a stack of gstates to report back the
current value correctly. We may either drop all those interfaces as a
whole or decide that they are not important for printing (Which would
force code to be implemented different when drawing on screen than when
printing). Or we have to implement them for the printing context too. 

My suggestion is to ad two new classes to the frontend (that is, gui):
GSGraphicsContext and GSGState. The former would consist of most of the
code now in xgps/Source/XGContext.m, everything beside the X specific
code. Which is all the stack handling and the forwarding of calls to the
gstate. In the later class we would just do the house keeping, we would
have a NSBezierPath, a NSColor and a NSAffineTransform and store in them
the current state. There wont be any drawing operations implemented
here.
In the xgps subclass of GSGState we would than only implement the
drawing operations. For printing the XGStreamContext (or a specific
subclass of GSGState) would add the output of the PostScript operations
to the file.

This architecture would not only be usable for xgps and printing, but
would come handy for any non-PostScript backend. The overhead would be
rather small, as we would need about one extra method call per drawing
operation (where the operation itself is much heavier) and nothing for
most state operations.