[gs-devel] Re: ghostscript vector devices

[Behdad Esfahbod]

On Wed, 2007-10-03 at 21:03 +0100, Till Kamppeter wrote:
> Behdad, would it not be possible to write an OpenPrinting Vector driver 
> to output into Cairo? This driver could plug into ant renderer and needs 
> not to be kept up to date with GhostScript's internal API changes as a 
> GhostScript built-in driver.

I'm not very familiar with the OpenPrinting stack, but my main goal
developing this backend is to use it in Poppler for PS display
rendering.  I'm not sure what you propose fits nicely there.

behdad

>     Till
> 
> Behdad Esfahbod wrote:
> > Thanks Ralph,
> > 
> > I'm subscribed to the gs-devel list now.  I started reading ghostscript
> > docs and learned most of the stuff you wrote, though I was starting from
> > gdevps.c.  Rebasing to gdevpx stuff now.
> > 
> > I'm impressed by the garbage collection implementation in ghostscript.
> > Very nice indeed.  But yeah, ugly, like all other OOP C implementations.
> > 
> > Thanks again, will keep you posted.
> > 
> > behdad
> > 
> > On Tue, 2007-10-02 at 18:17 -0700, Ralph Giles wrote:
> >> Behdad,
> >>
> >> You asked about where to start with a ghostscript output layer using 
> >> cairo, but we didn't get a chance to go over the details. Here's mostly 
> >> what I said, but in writing. :)
> >>
> >> Output back-ends in Ghostscript are called "devices". See 
> >> http://ghostscript.com/doc/current/Drivers.htm#Structure
> >> for general life cycle information.
> >>
> >> To do a vector output device you want to subclass gx_device_vector,
> >> which provides an callback vector for when any of the path stuff
> >> changes, which I think will be a good match for cairo's immediate
> >> mode api.
> >>
> >> The class is in gdevvec.h, reading the implementation in gdevvec.c will 
> >> be necessary on some points to get the calling convention right. The 
> >> simplest device to start cloning is the pxlcolor device (gdevpx*). The 
> >> most sophisticated is the pdfwrite device. You'll ultimately have to 
> >> look there for how to do fonts, etc.
> >>
> >> Probably a lot of the pdfwrite stuff could be moved into 
> >> gx_device_vector or an intermediate class if it ends up
> >> being shared. Ken's the one to talk about that (later).
> >>
> >> Some general notes on the gs source. Like all object oriented
> >> programming in C schemes, it's a bit messy. Objects are structs,
> >> "inheritance" is done by using macros to define the struct fields
> >> the class, which is the used to instantiate the same fields at
> >> the head of the struct defining any subclasses, so casting works.
> >> All pointer fields are enumerated in a special struct so the 
> >> garbage collector can update them after object relocation. Strings
> >> and few other things are special cased.
> >>
> >> Good luck, and let us know if you have any questions. I'd really
> >> like to see a gdevcairo!
> >>
> >> Cheers,
> >>  -r
> 
-- 
behdad
http://behdad.org/

"Those who would give up Essential Liberty to purchase a little
 Temporary Safety, deserve neither Liberty nor Safety."
        -- Benjamin Franklin, 1759