[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Printers using free software only



On Fri 27 Jul 2012 at 14:15:56 +0000, Camaleón wrote:

> On Thu, 26 Jul 2012 23:26:37 +0100, Brian wrote:
> 
> > Roger Leigh gave a good explanation of the role played by PDF in the
> > CUPS printing process on Debian. You snipped most of it, including this:
> > 
> >    > A native PDF workflow is far, far better and vastly more flexible
> >    > than a native PostScript workflow.
> 
> Time will prove the role of PDF in the printing chain process. By now, I 
> only can say that my printers were manufactured to "speak" PS and not 
> PDF, 

They *are* given PostScript. No problem there.

>      so any additional convertion will only waste time to get the job 
> done and printer resources.

If you only ever send PostScript to CUPS and have a particular type of
PPD file there will be no extra conversions. The chain would be:

   PostScript --> pstops ----> Printer

Isn't CUPS wonderful? Surely there are no grounds for complaint here?
However, you do lose any advantages pdftopdf might have provided.

Send anything other than PostScript (apart from PDF) and there has to be
a couple of conversions, but the same is true for the defunct PostScript
workflow. So its swings and roundabouts, except the PDF swings are better
and much more flexible.
 
> > To understand its importance you need a better reference than the one
> > given to a page on the cups website a few posts back. For example, there
> > is:
> > 
> >    http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat
> 
> Let's recap to have a better understanding:
> 
> ***
> (...) This format has many important advantages, especially
> 
> PDF is the common platform-independent web format for printable documents
> Portable
> Easy post-processing (N-up, booklets, scaling, ...)
> Easy Color management support
> Easy High color depth support (> 8bit/channel)
> Easy Transparency support
> Smaller files
> Linux workflow gets closer to Mac OS X
> ***
> 
> Look, I was not very deviated in my thought... There are four "easies" 
> listed as advantadges. Perfect, but I prefer accurateness over "easiness"
> for the output jobs, thanks :-)

Being easily understood does not diminish their advantages. As for the
PostScript workflow being more accurate than the PDF workflow I do not
know. You would have to substantiate that.

> In addition.. do we really want to get closer to MacOS X? If so, why? 
> Just becasue CUPS is MacOS tool? The far we are from anything that smells 
> to Apple the better for the linux users >;-)

I don't do OS wars but will point out that printing is a cross-platform
activity.

> > To illustrate the difference between printing in the olden days and now
> > we'll take someone who has set up a print queue to send a job to a
> > printer as PostScript. A text file is sent to CUPS, which filters it.
> > 
> >    On Lenny:   text --> texttops  --> pstops ----> printer
> > 
> >    On Squeeze: text --> texttopdf --> pdftopdf --> pdftops ----> printer
> > 
> > Note that the printer still gets PostScript (which should make you
> > happy) and the advantages of the PDF workflow which have been described
> > occur at the pdftopdf filtering stage.
> 
> How can be that adding an extra step (which increases time and resources) 
> is something "good"? And good for "who" (developers, printers or users)?

Its a balance. Pros and cons. With a PDF printer:

   On Lenny:   PDF --> pdftops  --> pstops --> pstopdf ----> Printer

   On Squeeze: PDF --> pdftopdf ----> Printer

I don't think I would want to criticise the PostScript centred workflow
solely on this.

The heart of the matter could be seen as pdftopdf versus pstops. The
advantages pdftopdf have been adequately covered - an earlier mail and
points 2 to 5 above. Perhaps you could give us the advantages of pstops
and what we are missing out on when it is not used.


Reply to: