Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.postscript > #2337

Re: How does the pdf-writer interface with the postscript interpreter?

Show all headers | View raw

In article <90b29975-1051-43cb-8b9e-6cf5824cd426@googlegroups.com>, 
mijoryx@yahoo.com says...

> Is this how Ghostscript does it? With a "virtual device" that replaces
> parts of the graphics algorithms (eg. saving arcs as 'arcs' rather
> than beziers, saving shown text as 'text' rather than bitmaps).

Sort of. Like most PostScript RIPs Ghostscript has an intermediate 
representation, higher level than the bitmap or rectangles used to 
render, but not the same as the incoming data stream (remember, GhostPCL 
and GhostXPS are also capable of producing PDF output).

This is the Ghostscript device interface which is astonishingly (over) 
complex for what it is. The interpreter interprets the input language 
and creates 'primitives' from the input. In Ghostscript terms these are 
things like 'stroke', 'fill' and 'text'.

I believe ths can be considered as similar to the P code or other 
intermediate representaton used by a compiler as an intermediate step to 
producing executable code. This also has the same advantage that the 
intermediate representation can be repurposed by simply fitting a 
different back end.

The primitives are passed through the device which optionally 
manipulates the primitive and then uses the graphics library to render 
them to the canvas.

In the case of the pdfwrite device, of course, the primitive isn't 
rendered, its emitted as a PDF construct.

This is also the level at whch the display list is created, stored and 
re-excuted. A low level (stored rectangle) display list is of course  
also possible, but generally produces a much larger list, which requires 
more storage and can atually take longer to process.

There is, as always, a trade-off. Idenitfying an appropriate level of 
complexity for the interface is key to the process.


> More to the point, would an appropriate strategy be to start with
> something like the Distillery and then customize the output to produce
> pdf? How should I go about designing and implementing a pdf-writer
> for xpost which heretofore has implemented the traditional Warnock/Wyatt
> device model?

I've been exposed to three commercial implementatoins. Two of those used 
a scheme as described above the other, well, didn't.....

The two using an intermediate scheme both have PDF (and PostScript and 
other high level labguage) output capability, as well as considerable 
flexibility in implementing 'unusual' requests. One more so than the 
other. The flexibility of the approach enabled the teams I was working 
in to produce novel implementations of customer reqauirements in 
surprisingly short order, many of those solutions have worked for years 
very robustly.

Ths was only possible because there was a well defined, comparatively 
simple (compared to the input language) layer to interface at which 
allowed considerable customisation.

The one interpreter I know of which didn't use such a scheme was unable 
to produce PDF output of any quality, despite considerable efforts to do 
so. In my opinion that implementation was also extremely hard to work 
with, difficult to extend and required a much larger team of engineers 
to support and develop.

If I were implementing any language interpreter I would look to define 
an an intermediate 'graphic primitive' level between the interpreter and 
rasteriser. Ths is an area that will reward careful design and 
consideration, you want something that will be flexible (so a rich 
interface), but not overly complicated, as that makes new devices 
challenging to implement, and also leads to duplication.

As an example, the Ghostscript device API does not pass the current 
graphcs state to all device methods. This is, in my opinion, a mistake. 
It leads to a great deal of complexity in the methods as individual 
parts of the graphics state are passed instead. Only to discover later 
in the chain that aditional informaiotn is required, particularly when 
implementing new features. I believe ths is a mistake made early in the 
evolution of the itnerface, and one which I would dearly like to get rid 
of.

In addition, I recently had cause to count up the number of device 
methods in the Ghostscript device API, and including every possible 
method it came to over 90. I beleive that's too many by a factor of at 
least 5.

I suspect ths is likely due to the API having evolved rather than being 
designed, and a rather inflexible attitude to redesign whch has required 
that the interface must always be backwards compatible.


I would also put in a suggestion that you permit early scan-conversion. 
One of the implementations I dealt with permitted this and it saved a 
lot of complexity. What ths means in practice is that a high level 
construct such as a path could be passed to the scan converter to create 
a rectangel list, and that list could then be reattached to the 
construct and carried around with it. Ths allowed operations to access 
the rectangle list as needed (and potentially even modify it) without 
requireing the scan conversion to be repeated.

			Regards,

					Ken

Back to comp.lang.postscript | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

How does the pdf-writer interface with the postscript interpreter? luser- -droog <mijoryx@yahoo.com> - 2015-09-01 14:39 -0700
  Re: How does the pdf-writer interface with the postscript interpreter? ken <ken@spamcop.net> - 2015-09-02 08:32 +0100

csiph-web