[gs-devel] beginpage and the vector device
Ralph Giles
ralph.giles at artifex.com
Thu Nov 1 23:22:43 PDT 2007
Ken,
Sorry this is a bit long, but I wanted to check with you before I
started patching things. I've done a little hacking on an SVG output
device for Ghostscript, and ran into something silly. My understanding
so far:
We have gx_device_vector which is supposed to track changes in graphics
state and call a set of notification methods on itself (or rather a
subclass) when drawing happens. By its own admission it's incomplete,
but another thing it provides is an output stream for the device, to
simplify additional manipulation later. I've been using that for
convenience and conformance.
I ran into trouble with my beginpage method not being called. I was
relying on this to write the file header if it hadn't been written
already, because there's no 'begindocument' and it can't be done from
device_open because the client needs to call put_params to set the
filename, etc. before the stream can be opened.
As it turns out, the way gx_device_vector decides when to call
beginpage is by testing vdev->in_page INSIDE AN ACCESSOR for
the output stream. So, the subclass is expected to call
gdev_vector_stream() whenever it wants to write EXCEPT from
inside the beginpage method, where it must access the stream
directly. The subclass is also expected to set in_page back to
false after finishing a page if it wants its beginpage method
called again. Essentially the same hack I was doing, but half
a level up. And gdevpx.c does all this in implementing the
pxl output device. Whacky.
I think someone was just trying to save some code by blurring a
boundary, which is unfortunately common in Ghostscript, and I'd
like to fix it. Do you have any thoughts before I try and rework
this? Is there a general page_begin event that I've missed? If
not I guess we just have to make all the gdevvec.c routines check
in_page themselves. More code, but less surprise.
-r
More information about the gs-devel
mailing list