[Desktop_printing] Re: [Printing-architecture] Printing Summit
memo (for tomorrow sc meeting)
mrdocs at scribus.info
Wed Feb 8 13:58:46 PST 2006
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
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?
There is/was an SVG draft print spec, but I have not looked at it in a
More information about the Printing-summit