[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