PS vs. PDF

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

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:

 

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.