[Desktop_printing] Re: [Printing-architecture] Printing Summit memo (for tomorrow sc meeting)

[PLinnell]

On Wednesday 08 February 2006 21:03, Till Kamppeter wrote:
> Osamu MIHARA wrote:
> > Hi,
> >
> > I just joined Desktop_printing ML and am on the way to understand
> > what is discussed for printing summit reading archived mails.
> >
> > One thing I'm concerning is that transition of printing spool
> > format from PostScript to PDF.  Moving spooling format from PS to
> > other is a good idea and PDF can be a candidate for it.  However,
> > the original PDF from Adobe places meta information (dictionary)
> > at the end of the PDF file.  This requires spooling all of the
> > PDF file to spooler or renderer before start printing.  PDF/is is
> > proposed by IEEE for facsimile application in order to handle
> > stream PDF, but it handles only raster data and graphics
> > information seems to be lost. Also streamed PDF is provided from
> > Adobe, but I heard that streaming technology about PDF format is
> > patented by Adobe.
> >
> > Under these situation, adopting PDF to spool format can be
> > problems in many aspects.
> >
The  PDF spec (since 4.x at a guess ) has a feature called 
'optimizing'. 

This gives you ability to view PDFs in a browser, one page at a time. 
You dont *necessarily* need to read the whole PDF or to download the 
first few pages while reading and the rest of the file downloads in 
the back ground.

It does so by PDF page by page from a web server to the viewer 
embedded in a web browser. To enable this in apache you need 
byte-serving enabled, but it does work quite well.

The challenge with this is you will need to receive the full PDF from 
all the apps that cant write an optimized PDF and then process it 
into the optimized format.

Ghostscript already has this capability. The trade off at least when 
GS optimizes a PDF, the cost is a much larger PDF file size - 
sometimes 2 or 3 times the original in my limited testing. I have a 
hunch this function could be optimized (no pun intended) to squeeze 
smaller files out of GS with some attention.

Other than that, a spec needs to be given to PDF producing apps and 
libraries and get them to add optimized PDF support.

With all of that, moving to PDF might overcome some issues we face 
more and more with highly graphical apps like Scribus and Inkscape 
which can output content which cannot be printed directly with PS3. 

On win32, the gdi plus library helps to overcome this with 
non-postscript printers by offering painting operations which are 
similar to PDF operators. 

> > I'd rather like to take SVG for the spooling format, as it is
> > *OPEN*, not under control of particular company and well designed
> > graphic format, although it has less actual results.
> >
> > What do you think?
>
> Good point, then we have full control on the job transfer format.
> For PostScript and PDF printers we then will simply have a
> PostScript driver and a PDF driver.
>
> If important criteria for a print job transfer format are not
> fulfilled by SVG, we could more easily add them than add features
> to Adobe's job formats.
>


> We need in SVG:
>
> - Embedding of job ticket/or a standard to accompany the SVG with a
> job ticket

Possibly with metadata extensions to the spec.

> - Embedding of fonts

SVG fonts are painful, but do exist. This is the weakest part of the 
spec from my observation and experience with Scribus. It is the 
html/css vs postscript naming style of fonts which is painful. 
Matching one to the other is not nice.

> - Color management (ICC, ...)

Yes, but only as far as RGB to screen rendering. No other mention from 
what I remember reading the specs.

> - More?
>
> Das SVG do this already?
>
>    Till

There is/was an SVG draft print spec, but I have not looked at it in a 
while. 

Peter