PS vs. PDF

There are a number of incorrect assumptions in your post.

First PDF is a very portable format, even if you don't believe the name

"Portable Document Format".  The Acrobat reader is available for free on

just about every platform out there, certainly on all platforms Eagle runs

on, and all the ones you mention as examples you can us PS on.

Second, using PDF to convey schematics is not rare at all.  In fact, is the

the #1 format of communicating schematics between people that use different

software.  All my customers expect me to send them schematics in PDF, and

this is how customers send me schematics without asking about the format.

That's how it's done.

I've never actually exported anything from Eagle to a PS file.  PS is

basically a printer language.  It's the printer driver's job to produce

that if that's what the printer wants.  Perhaps some of the time I have

printed schematics to paper there was a PS step in the middle, perhaps not.

But in no case is that, nor should it be, relevant to me.  I either print

from Eagle directly if I'm doing it myself, or someone else prints from the

PDF file.  I have never seen that process produce erroneous results.

Printing from a PDF file is a solved problem and a reliable process.

--

Web access to CadSoft support forums at www.eaglecentral.ca.  Where the CadSoft EAGLE community meets.

Am 28.02.2013 15:03, schrieb Chuck Huber:

I understand that the

languages were defined by the same company, but PS is a far more

portable format (supported on linux, mac, windows, BSD, and just about

any unix derivative you can name).

For documentation, I MUCH prefer PDF, because everyone can EASILY view

it (GhostView etc. are known only to specialists).

For PRINTING, though, PDF is a bad choice for us: We etch our own

circuit boards here with a typical size of 200x200mm, and ALL standard

printers (InkJet, Laser, etc.) have small manufacturing tolerances,

resulting in a systematically slightly skewed printout (about 0.15mm

skew error on 200mm length). For double-sided boards, the difference

between the printed top and bottom layers might therefore easily be

0.3mm, which is intolerable.

With Postscript, you can just add a 'transpose matrix' into the file

which unskews the printer tolerance again. We do this automatically

since about 15 years, and it works VERY well. This is NOT possible with

PDFs at all...

Therefore:

  - Documentation printing to PDF

  - Board transparency printing to PS

Andreas Weidner

Olin,

I agree with all three of your points.  PDF the best way to go for

documentation purposes.  I'm not suggesting doing away with printing to

a PDF file.  The name even implies that it's tailored for "documents".

Instead, I was referring to the internals of Eagle regarding how print

jobs are produced.  Currently, that process is to produce a PDF then

send it to the host.  On unix systems (I include linux and OSX in this

reference), the PDF is first converted to Post Script by the host

printing system, and then to the printer language (but only if the

printer does not support PS natively).  This conversion is sometimes

problematic.  The idea is that if Eagle produces a PS print job and the

printer understands PS, then no format conversion is needed.

Case in point: Eagle has trouble printing hashed lines due to its

backend PDF software.  I'm having this problem on linux, and others are

having this problem on Macs.  The problem I was having first surfaced in

6.3 and carried into 6.4.  It was /not/ present in 6.2.  It shows up

when printing to a PDF file, then manually sending the PDF to the host's

printing system.  It is /avoided/ when printing to a PS file, then

manually sending the file to the host's printing system.  So it is

specific to the way Eagle produces a print job.

I was asking Jorge of the motivation to produce PDF for print jobs

rather than PS.  What was it the engineers saw in PDF that caused the

team to select that format for print jobs?  Assuming they were aware of

the prolific support of PS on unix systems, what was it about PS that

drove the decision to produce PDF's for print jobs?  I want to

understand /why/ PDF was chosen over PS in light of the conversion

overhead and conversion risks incurred in doing so.

Enjoy,

    - Chuck

On 02/28/2013 09:03 AM, Chuck Huber wrote:

Jorge,

 

One thing I don't understand is the strategic decision to print via PDF

format as opposed to print via PostScript.  I understand that the

languages were defined by the same company, but PS is a far more

portable format (supported on linux, mac, windows, BSD, and just about

any unix derivative you can name).  Additionally, many printers support

PS natively.  In the rare cases where you needed a PDF (as in print to a

PDF file), ghostscript, or ps2pdf are good candidates.  In contrast, I

don't know of any printers that support PDF format natively, so you'll

always have a backed process that converts PDF to the printer language.

 

By emitting a PDF format, you leave it to the print subsystem to convert

it to PS, and then to the printer's native language.  This happens every

time one prints as opposed to the rare times when one prints to a PDF.

 

I guess my point is that every time the data goes through a format

conversion, there is a risk of conversion errors causing problems.  So

the fewer conversions, the less likely of a conversion problem, and the

more efficient the overall process.  After all, isn't that what

engineering is all about - avoiding potential problems and efficiency?

 

I welcome your thoughts on why PDF was chosen rather than PS.

 

Thanks,

    - Chuck

Chuck Huber wrote:

Jorge,

 

One thing I don't understand is the strategic decision to print via PDF

format as opposed to print via PostScript.  I understand that the

languages were defined by the same company, but PS is a far more

portable format (supported on linux, mac, windows, BSD, and just about

any unix derivative you can name).  Additionally, many printers support

PS natively.  In the rare cases where you needed a PDF (as in print to a

PDF file), ghostscript, or ps2pdf are good candidates.  In contrast, I

don't know of any printers that support PDF format natively, so you'll

always have a backed process that converts PDF to the printer language.

 

By emitting a PDF format, you leave it to the print subsystem to convert

it to PS, and then to the printer's native language.  This happens every

time one prints as opposed to the rare times when one prints to a PDF.

 

I guess my point is that every time the data goes through a format

conversion, there is a risk of conversion errors causing problems.  So

the fewer conversions, the less likely of a conversion problem, and the

more efficient the overall process.  After all, isn't that what

engineering is all about - avoiding potential problems and efficiency?

 

I welcome your thoughts on why PDF was chosen rather than PS.

 

Thanks,

    - Chuck

I suspect it has little to do with Eagle and a lot to do with Qt and the

general move to PDF as a print job format. This page discusses some of the

reasons:

http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat

And here:

http://lwn.net/Articles/485617/

For general printing, the page-oriented font-embedding nature of PDF makes a

lot of sense. For 1:1 printing, I don't know, but then again, 1:1 printing

has always been a can of worms.

Chuck Huber wrote:

 

In contrast, I

don't know of any printers that support PDF format natively, so you'll

always have a backed process that converts PDF to the printer language.

 

Unfortunately anything using recent CUPS as the printing system (i.e. any recent Mac / Linux) is doing PDF as the backend printing format. So app produces, PS, cups converts to PDF to mess with it, cups then converts back to PS to send to the printer. Yes I agree this is nuts. (having recently been round this loop where the cups PDF to PS thing produces PS files that don't print when the original PS does)

However, most recent (non bargain bucket) printers can handle PDF natively. My new laser does PCL5, PCL6, PS 3, PDF 1.5 natively

On 03/01/2013 01:45 AM, Bob Johnson wrote:

Chuck Huber wrote:

 

I welcome your thoughts on why PDF was chosen rather than PS.

 

Thanks,

    - Chuck

I suspect it has little to do with Eagle and a lot to do with Qt and the

general move to PDF as a print job format. This page discusses some of the

reasons:

 

http://www.linuxfoundation.org/collaborate/workgroups/openprinting/pdfasstandardprintjobformat

Interesting reads.  I was not aware that PDF provided significantly more

functionality than PS.

Thanks for the research.

    - Chuck

Guest wrote:

 

I have never seen that process produce erroneous results.

Printing from a PDF file is a solved problem and a reliable process.

 

Try exact scale 1:1 from a PDF. It's not too good. Mainly due to printer tolerances and lack of control in PDF to fix it. I'd agree that PDF for general text documents (or schematics) is perfectly fine.

Chuck Huber wrote:

 

Case in point: Eagle has trouble printing hashed lines due to its

backend PDF software.  I'm having this problem on linux, and others are

having this problem on Macs.  The problem I was having first surfaced in

6.3 and carried into 6.4.  It was /not/ present in 6.2.  It shows up

when printing to a PDF file, then manually sending the PDF to the host's

printing system.  It is /avoided/ when printing to a PS file, then

manually sending the file to the host's printing system.  So it is

specific to the way Eagle produces a print job.

 

Or it's something to do with how cups is mangling the file? Have a read at the link Bob posted and then start to wonder why it has filters like 'pdftopdf' - yes, that's converting a pdf to a pdf...

I'd be interested in how your PDF prints when it's sent directly to a natively PDF capable printer without going through the hosts printing system as I suspect cups may be the culprit here rather than generically the PDF format.

selsinork schrieb:

Guest wrote: I have never seen that process produce erroneous

results. Printing from a PDF file is a solved problem and a

reliable process.

 

Try exact scale 1:1 from a PDF. It's not too good. Mainly due to

printer tolerances and lack of control in PDF to fix it. I'd agree

that PDF for general text documents (or schematics) is perfectly

fine.

Just for the record: PDF, just like PS, basically is a vector oriented

data format containing numerical information (unless we are talking

about embedded pixel graphics).

So it has exactly the same precision as PS. If there are any tolerances

in printing, they are caused be the printer or the driver, but

definitely not by the file format.

Tilmann

Tilmann Reh wrote:

 

 

Just for the record: PDF, just like PS, basically is a vector oriented

data format containing numerical information (unless we are talking

about embedded pixel graphics).

 

So it has exactly the same precision as PS. If there are any tolerances

in printing, they are caused be the printer or the driver, but

definitely not by the file format.

You're absolutely correct, it has very little to do with the format itself.

Much more to do with native PDF printers being comparitively new, multiple conversions between formats behind the scenes in the driver and not all the pieces having caught up. For example, when I print artwork direct to PS (not with eagle I hasten to add) I can individually control x & y scaling to compensate for printer discrepancies, but that either isn't an option or simply doesn't work properly for PDF.   Yes, I'm quite sure cups and it's strange multiple conversions isn't helping at all here.

I'm equally sure that at some point, when native PDF printers are as common as PS ones are today, these problems will get sorted. But until then...