[gs-devel] Asking for a application oriented API for libgs
Ralph Giles
giles at ghostscript.com
Fri Jul 6 10:47:30 PDT 2007
On Fri, Jul 06, 2007 at 06:25:26PM +0200, Albert Astals Cid wrote:
> Hi, i am one of the KDE[1] people working on okular[2], the KDE4 document
> viewer.
Cool.
> The problem is that libgs API [3] is much more oriented to writing a ps
> interpreter than oriented to what a viewer application needs. Or at least
> that's my opinion as a viewer developer ;-)
Yeah, we're aware of that, and would really like to have something.
Unfortunately none of the core developers are likely to get to it
patches and fresh contributers welcome. :)
> For number of pages, we are using a parser that gets the "%%Pages:" stuff.
> That is easy :-)
You're aware, I guess, that the DSC comments can be wrong or absent.
There should be some fallback for such cases, either pre-parsing the
document or just streaming it as it comes. Also, in some documents,
random access to pages is very expensive.
> The actual problem is knowing the page size. The problem exists because we
> need to know the page size before the actual rendering of the page to
> allocate the space in the page area, if not we could just use also the values
> that come with the display_size callback.
This may also be available from the DSC comment %%BoundingBox, but it
can be wrong, and of course it's possible to vary from page to page.
The display device is designed the way it is, with all the
callbacks, so support just streaming the document. For pre-parsing,
you can run the document through the bbox output device to get
the page count and the size of each page.
So if you want to develop something like this, I'd suggest going with
something like what you sketched, but make sure it can fall back
gracefully when the DSC information isn't available or is incorrect.
Also, while get_image() is a reasonable high level call, a viewer
api should also provide a tile-based call to get a subregion of
a page at a particular resolution. Otherwise you fall over when
zoomed in on a large document.
Anyway, we are happy to offer advice etc. if you want to help develop
soemthing like this.
-r
More information about the gs-devel
mailing list