Re: The need for an integrated PDF reader/Implementation ofNSPDFImageRep

[stefan]

>> i think implementing our own renderer is the better choice. I've already
>> made some investigations for my Preview-Application ViewIt
>> (http://mac.wms-network.de/gnustep/viewit/viewit.html). It currently
>> uses
>> an xpdf/ghostscript based combination for PDF rendering. My plans are to
>> implement a mechanism that produces custom (PDF)ImageReps by using the
>> code from xpdf. xpdf does rendering very well and it is modular so that
>> it
>> is easy to write new output devices. xpdf uses this output devices to
>> 'visualize' PDF content. An output device must implement some methods
>> that
>> can be translated (nearly) directly to postscript, so it may be possible
>> to use display-postscript here.
>
> It sounds a lot like a proposal to implement Quartz, or at least large
> pieces of it...
no, not really. What i mean is that an xpdf output-device (this is an
interface that is specified by xpdf and has to be implemented by
'backends' that are used to render pdf output) can be easily implemented
by using
mechanisms that are already present in GNUstep (Text may be drawn by using
NSStringDrawing, drawings can be implemented by using NSBezierPath or by
using the operators from DPSOperators.h directly).

> I'm all for a PDF renderer here -- Either calling Ghostscript (and doing
> so as a library -- display ghostscript + PDF, anyone) or the xpdf system
> sounds like a good place to start.  The GNU licensing and FSF copyright
> on GS is a plus to me...
yes thats true. and the author seems not to worry about copyrights too much.
ghostscript has the disadvantage (too me) that rendering of complex pages
takes too long. I don't wan't to spend a minute waiting for a page to be
displayed.

> Is xpdf based on ghostscript code?
no, it's seems to be a 'standaolne' implementation. And it renders PDF's
fast (have a look at the xpdf program).

Stefan