Re: [Gnome-print] Re: PS Obsession????

[Lauris Kaplinski <lauris kaplinski com>]

Looked into PSI and still looking...

Long-long ago I wrote something similar for DOS, but it is lost. Not a big
loss, I think ;)

I would split picasso into 2 clearly distinct picoscopic parts:
- interpreter
- parser
So interpreter part of PSI can facultatively use parsing plugin (to read
stdin/file/etc...)
I also used 2 additional stacks
- input stack (where current input streams were pushed)
- error stack (where errors were pushed)
And separate errordict for matching numeric/string error formats

Some more suggestions (of usability of whose I am not absolutely sure):
You do not need array close operators. Parser shouldn't do any
dictionary lookups itself. Instead, if it encounters simple set of
characters (neither (xxx) nor /xxx nor %%xxx), it creates executable name
object from it, and feeds that to interpreter. Now interpreter keeps track
of current state, and decides, whether to push it (in exec array array) or
lookup it (in normal context)
'}' / ']' is special kind of token, as is '[' / '{'.
So I would strongly suggest clear split:
Parser splits stream into tokens
Interpreter interprets tokens

Still I love such kind of animal and hope it would be nice addition to
gnome-print :)

Best wishes,
Lauris

On Thu, 8 Jun 2000, Damien Diederen wrote:

> Hello !
> 
> On Wed, Jun 07, 2000 at 10:33:39PM +0200, Lauris Kaplinski wrote:
> [clip]
> > What probably is needed, is new and improved, forth extesible imaging
> > API, so traditional PS can be implemented as plugin library.
> 
> As you may remember from my controversial 'RFC' document, I am very
> inclined towards having a forth-like language as a possible metadata
> format.
> 
> As Miguel pointed out that GhostScript code is spaghetti-land, and was
> not something he wanted to deal with, I was toying with the idea of
> writing a forth-like interpreter.
> 
> As I read your comment, I think you should have a look at the following
> code, which implements a simplistic (and extremely experimental)
> interpreter :
> 
> http://users.swing.be/diederen/tarballs/picasso-0.0.3.tar.gz
> 
> While it may not be a suitable base to build a complete GhostScript-like
> solution, I have tried to keep the following goals during the (short)
> design phase :
> 
> * Embeddable. The interpreter should be usable as a library, and the state
> 	should be kept in data structures (it should be possible to
> 	have multiple interpreters running simultaneously).
> 
> * Extensible. The interpreter should not assume anything about the 
> 	operators/functions implemented, except that their use is
> 	stack-based ;). Even the base functionality could reside in
> 	a plugin.
> 
> * Clean. Written with the help of GLib, the core should only feature clean,
> 	Gtk+-style, OO-like code. The messy code can go in the plugins.
> 
> If anything were to come out of this experiment, it would be cool to 
> implement the following functionnality :
> 
> * A superset of PostScript as a plugin for the interpreter. This could
> 	include Alpha, Antialiasing, and whatever you want. This plugin
> 	should use the Libart API for the rasterizing process, and could
> 	reside on the print server. If the Picasso language were
> 	PostScript-compatible enough, it would even be possible to use
> 	it to print PostScript output from legacy programs with
> 	the gnome-print raster drivers (!). 
> 
> * A Gnome-print driver for Picasso, which could be based on the existing
> 	PostScript driver, with the hackish Alpha/etc. replaced by
> 	native Picasso operators.
> 
> * A Canvas print driver for Picasso, which would enable a GGV-like 
> 	program with Antialiasing, Alpha and real-time zooming.
> 
> * PS-Compatible PPD files for inkjet printers.
> 
> I was also thinking about a pure binary string format for Picasso, with 
> the same semantics (filtering, etc.) than base-85 PS strings. This
> would solve the main problem with huge images in PS streams. Something
> like this could do the job : 
> 
> <[KEYWORD[binary, possibly compressed (filtered) data]KEYWORD]>
> 
> It would also help to implement a UTF-8 based 'show' operator.
> 
> Please let me know what you think about this.
> 
> > Lauris
> 
> Cu,
> Damien.