103

I submitted a journal paper this morning, and they asked me to include a PDF file, which I expected, and a Postscript (PS) file.

Generating the PS file proved more difficult, because some of my LaTeX commands, which I always compiled with pdflatex, wouldn't compile with latex (in particular including graphics).

I ended up converting the PDF into a PS file, but obtained a file 4 times the size (approx 20 MB instead of 5 MB).

It also seems that opening a Postscript file with any modern reader takes longer, as it has to 'convert' (compile maybe? or interpret?) the file.

I was wondering -- what's the use of Postscript today? Are there advantages over the more modern and widely used PDF?

gozzilli
  • 1,594
  • 3
  • 12
  • 15
  • 16
    use pdftops to create a ps version of your pdf file –  Dec 11 '14 at 12:59
  • 1
    Most readers will call pstopdf to convert the ps file to a temp pdf file and then open the resultant pdf file. A nice thing about postscript is that I can send it directly to most decent printers. – Batman Dec 11 '14 at 18:37
  • @Batman I realise it gets converted in many cases, but can't you send a PDF directly, too? (I can send this from the command line and let CUPS worry about any conversions required.) – cfr Dec 12 '14 at 03:14
  • 6
    If you use pdftops, *check for discrepancies*. Especially if your document includes any diagrams - make sure these are rendered correctly. If not, use pdf2ps from ghostscript instead. (The file will be larger in this case, though.) – cfr Dec 12 '14 at 03:18
  • 1
    @cfr - depends on the printer. My home printer (a Samsung) does postscript but not pdf, so I can netcat postscript files to it on machines without CUPS. – Batman Dec 12 '14 at 11:41
  • 1
    It is easier to generate a PostScript file "by hand" or using a simple script than a PDF file. – Jake Oct 06 '20 at 09:57

13 Answers13

80

From a publishers perspective, I think, the only fundamental reason is legacy software. Postscript has been a long-lasting and broadly accepted standard. Updating the existing tool chains to PDF would require a massive investment.

So I think, it is all about history. There is a great Q&A that discusses the fundamental differences between Postscript (PS) and PDF from a technical perspective: Fundamental differences : PSTricks, TikZ/PGF and others, but misses a bit on the (historical) significance of these technical differences:

Basically, the technical differences are:

  • PS is a (Turing-)complete language that permits to defer arbitrary computations to rendering time, that is, when the PS file is used (i.e., printed).
  • In PDF, all calculations have be completed when the PDF file is produced.

At its time, the PS model had some clear advantages:

  • In the 80s a decent workstation (VAX-11) was able to compute 1.5 million instructions per second (MIPS) and was equipped with maybe 1 MiB of RAM.
  • Rendering a complete A4 page at 150x150 dpi resolution on such a system was already challenging. Going higher (300x300 or 600x600 dpi) was basically impossible.

  • However, even at that time, a laser printer was able to print a page with 200x200 dpi or more.

  • Industrial printing machines used by publishers were already able to cope with much higher resolutions.

By delegating the computational intensive part to use-time, that is, the printing device, PS provided portability between all these devices and made it possible to prepare high-quality documents even on affordable computers. Instead of equipping every workstation with enough RAM and CPU power to render pages at 200x200 dpi (not to speak about the disk sizes and network throughput one needs to store and transfer the resulting documents), it was enough to have one $10,000 laser printer to do the job for the complete department. If the book got professionally published, the $10,000,000 industrial printer could process the same PS document to render it at 1200x1200 dpi.

20 year later, the CPU power and available amount of RAM is 4,000 times higher. Printers featuring a PS raster image processor (RIP), however, are still relatively expensive:

  • Already in the 90s, "software-RIPs" (e.g., ghostscript) became popular. Ghostscript does all rendering on your computer and thereby makes it possible to print PS documents even on an affordable printer that does not feature a hardware RIP.

  • By the year 2000, the ordinary PC and network throughput has become so powerful that "software-RIPing" before printing is typically a lot faster than using the printer's built-in RIP – especially when printing complex PS documents.

  • In the same decade, PDF became popular, so also the importance of PS as the broadly supported standard for printer documents declines.

Daniel
  • 37,517
  • Nice. See the video link at the end of my question for more pragmatic chocie that drove people to go with the flattened version of PS which became PDF. – percusse Dec 11 '14 at 17:57
  • It is not just history and inertia which makes PS an important file format in the printing business. It is its potential to be modified by humans in order to adapt it to special requirements. – AlexG Dec 15 '14 at 15:22
73

Postscript is still used as an intermediate document format, since it is a fully fledged programming language allowing you to compute graphics, which PDF doesn't. PDF shows just the result (after some conversions, sometimes called "Distillation") of the computation Postscript is able to do.

The Postscript based PSTricks package is an example that heavily makes use of graphical computation. It can even solve differential equations. And if you have a Postscript printer, it can do these computations for you.

EDIT, to answer Daniels comment:

One feature that makes Postscript the preferred format, in particular for a publisher, is its editability. If, for instance, line art in a document is too faint, the publisher may want to enhance it a bit globally before giving the document to press. This very issue was raised, e. g., in this question.

With Postscript, doubling the line width in the whole document is easily accomplished by putting

userdict /setlinewidth {2 mul systemdict /setlinewidth get exec} put

into the document header.

With PDF such a tweak is much more complicated.

jiggunjer
  • 103
  • 5
AlexG
  • 54,894
  • 21
    All this is right, but IMHO misses the point. What exactly is the benefit of having the printer to solve the differential equations? What cannot be done with PDF? – Daniel Dec 11 '14 at 13:56
  • 2
    @Daniel See the answers here – percusse Dec 11 '14 at 14:16
  • @Daniel It is just an example. Usually the Postscript programme is executed during Distillation (using ps2pdf or Distiller) when the PDF is produced, and the PDF viewer sends a static Postcript file (converted back from the PDF) to the printer. For example, you cannot programme a sinus curve into a PDF file. You need to provide the line segments at their final positions. – AlexG Dec 11 '14 at 14:19
  • @percusse Thanks for providing the link. The answers there are quite exhaustive. – AlexG Dec 11 '14 at 14:35
  • 6
    @percusse: I know the linked question and answers and also quite a bit about PS features. I just think all this misses the point. IMHO, the question is not "what could be done with PS", but "what could only be done with PS" in the context of document typesetting. Is their any "killer feature" wrt. document processing that causes publishers to still insist on PS, because with PDF they could not produce adequate results? I strongly doubt this and think the only reason is: History. The old PS tool chain just works and updating it to PDF would cost money. – Daniel Dec 11 '14 at 15:12
  • 8
    @Daniel The reason for publishers to insist on PS is simply stupid. So I don't mean to praise the usage of PS. I think today it's just a matter of a nice compact way of preserving document content. However it is not to reject that PS is an amazing way of doing very very complicated stuff. You can also say you should be able to simulate a pendulum with say as a ridiculous example XML. We don't need to generalize every tool to everything. I think PDF and PS are a perfect couple in terms of how performance, portability and sophistication is compartmentalized. – percusse Dec 11 '14 at 15:35
  • 1
    Postscript is a fully fledged programming Turing-complete language. People have made their printers raytrace with it. – geometrian Dec 11 '14 at 16:39
  • 6
    Sounds like PS is a bit like LaTeX itself. – user253751 Dec 11 '14 at 23:38
  • @Daniel, PS is still valuable for publishers. See my edit. – AlexG Dec 15 '14 at 13:39
  • @AlexG As Heiko demonstrated a few times you can change the pen properties on the PDF code too after changing compression level. I couldn't find the relevant question though – percusse Dec 15 '14 at 13:43
  • 1
    @percusse Indeed, a default graphics state can be set in a per-page / per-XObject manner. But the next time the line width is hard-coded at a particular location in a graphics, then this value takes precedence and the default setting is forgotten. You just cannot globally scale any line width occurring in a PDF document. One would have to filter the uncompressed PDF and replace all (zillion) occurrences of <number> w using sed or perl. – AlexG Dec 15 '14 at 14:10
  • Is this really a problem? I guess your machine happily changes a zillion occurrences in basically no time :-). No, seriously: This is a valid concern, but I would like to understand it's long term impact. So is the worse editability a fundamental problem of PDF ("can never be solved") or is it just a matter of yet missing tools? – Daniel Dec 15 '14 at 16:36
  • 1
    @Daniel I think, the relationship between PS and PDF is similar to the one between a C-source and a binary. It is safe to keep the former. Although it is possible to change anything in the latter, chances are high to end up with a broken file. PDFs and binaries aren't meant to be edited. This might be one reason for publishers to ask for a PS. But I am only guessing... – AlexG Dec 16 '14 at 08:16
  • I prefer PDF of course. However I must admit that a couple of times I edited postscript figure for last minute changes (color and line thickness) in submitted figures (BTW made with gnuplot). (Otherwise I would have to have edited the figures with some program like inkscape at the risk of this doing something funny to the graphic) – alfC Dec 17 '14 at 10:27
  • @AlexG: Good comparison! However, as a matter of fact fewer and fewer tools are able to generate PS out of the box, so what publishers actually get is PS that has been converted from PDF. To stay into you picture this would be C code generated by a disassembler/decompiler out of the binary. I doubt that this is more editable than the PDF directly. – Daniel Dec 20 '14 at 09:20
  • 1
    Your part that PostScript can be edited and PDF can not is wrong: Editing PostScript ist just easier (a capable person needs only a text editor). Those transformations can be applied to PDF as well with the right tools (e.g. Adobe Acrobat). – Martin Schröder Dec 24 '14 at 11:59
16

As you've already experienced, there's a tendency for modest-sized ps files to blow up to enormous pdf files. This is because postscript, being a general programming language, has enormous potential for algorithmic compression.

For a simple example, consider a sheet of 5mm graph paper. A pdf would contain the end-points for every line. In postscript, however, this could be accomplished with 2 loops.


Converting backwards, from pdf back to ps, is not capable in general of making use of algorithmic compression. The pdf would have to be analyzed by some really smart AI/expert. The normal conversion is just to represent the same pdf structures with postscript, which tends to be more verbose. Eg. a 32-bit binary integer will take 4 bytes in a pdf, but it will take 1..14 bytes in a (ascii) text representation.

  • 3
    gozzilli is doing the opposite conversion – Max Dec 12 '14 at 15:18
  • @Max Indeed, that order makes it a bit pointless. – JamesRyan Dec 12 '14 at 17:56
  • @Max & James, I've added more to address the pdf->ps conversion. – luser droog Dec 13 '14 at 04:58
  • @Max & James : The conversion direction is irrelevant here. The original question is about the value of Postscript these days. +1, btw. – AlexG Dec 17 '14 at 11:36
  • @AlexG the conversion direction is vitally relevant here because it is not a lossless conversion. By starting in PS and adding an intermediate PDF step you lose quality. By starting in PDF and converting to PS you gain nothing. – JamesRyan Dec 29 '14 at 17:47
12

There is also a Latex-specific historical reason why some publishers still request PS versions of documents. This is relevant primarily in cases in which the publisher just takes an author-prepared document and prints it (or puts it online); for example, many conference proceedings in computer science are produced this way.

Previously, the typical toolchain for Latex users involved EPS figures for vector graphics, latex, dvips, and ps2pdf. With this kind of toolchain it was easy to produce broken PDF files that did not properly embed all fonts that they used. Fixing this was a bit painful if you just have the broken PDF file, but it is usually fairly easy with standard tools if you have the original PS file. Hence publishers asked for the PS version so that they can re-do the PS-to-PDF conversion for the authors.

Nowadays everyone uses PDF figures for vector graphs and pdflatex to compile their Latex files. This way anyone can easily produce valid PDF files with all fonts correctly embedded.

Publishers are a bit slow to learn that the world has changed, and they are a bit slow to update their tools. For example, I am aware of a publisher that has a web system that requires that you submit a PS file along with the PDF file, but they do not really need those PS files anymore, so they nowadays recommend that the authors just submit some dummy PS file and name it so that the publisher knows that it should be ignored...

Jukka Suomela
  • 20,795
  • 13
  • 74
  • 91
7

One reason I recently learned about is that you can generate a printer-specific PS file (e.g. by using your PDF reader's print to file feature), which already contains all the printer settings you chose, which is very helpful for complex print jobs (e.g. containing different but same-size paper media) that need to be printed again every now and then.

4

In my world they are two sides of the same coin. PDF is a display format. Postscript is a printer control language. Both were created by Adobe but for slightly different jobs. PDF is difficult to program against for sorting or adding objects (yes I know you can do it in Acrobat, etc. - try sorting or adding dynamic text to 250,000 pages and let me know how long it takes!) PDF does not have tray logic - all pages must be printed on the same paper stock, not so with Postscript. If there is any chance that the original data might end up in a book/collection where the printer might have to pull glossy paper stock for images, or card stock for covers - can't use PDF. Also depending on the printer - for almost any printer - all it can really print is either Postscript or PCL. Anything else requires your computer it "translate/convert" which adds another layer of what can possibly go wrong? So I think the question really is what the end user envisions they will have to do with the data - and that they don't want to be responsible for the conversion.

3

I simply use ps for creating my graphics and embed these in plain TeX, which is processed by pdfTeX. Advantage: portability and full generality of the graphics. PStricks uses ps under the hood, and is in LaTeX, and because of that is restricted by the inheritance of LaTeXs picture environment. The big advantage is that you don't have to be aware of ps. No experience with PStricks on the issue. Disadvantage: In PStricks for example not all orientations of straight lines are possible. Advantage: a wealth of PStricks examples are available. I have created a library of ps pictures, which is called PSlib and made avaible on NTGs WWW. An article on the matter has appeared in GUST bulletin and has been submitted to MAPS. My work is similar to the work of Don Lancaster. The files I submit are the ps pictures and the plain TeX source code. I process it by pdfTeX. MAPs editors convert my plain TeX material into CONTeXt and that has proven to work fine. I suppose that GUST works along similar lines. I have no experience in how to submit to a general publisher. Kees van der Laan

1

So, PDF and PostScript are targeted to different needs. If you want to VIEW a document you use PDF. IF you want to print a document, especially in a large batch print facility, you use PostScript.

1

I avoid using pdf, if pdf is all I can find then I first convert it with ghostscript. PDF has plenty of security and privacy issues. Most PDF viewers have zero focus on privacy, postscript files don't have nearly as many "features"(i.e. underhanded attack vectors), and postscript viewers, the ones I have used at least, restrict access to the filesystem. However, I wouldn't trust printers to not be vulnerable to filesystem access from postscript files. In circumstances requiring privacy the use of PDF as opposed to PostScript should be considered a hostile act.

1

Postscript is still important for people who need to create documents programmatically. Imagine you need to create a nice printable document based on an input from a user. Since you do not know what the input would be like, your document cannot be created beforehand. It has to be created on the fly.

LaTeX is well designed for this kind of task but, unless your application is web based, you need to have LaTeX installed on the user's machine, which is not always feasible. On the other hand, PostScript viewers are ubiquitous and free, e.g. Adobe Acrobat, so having your application create PostScript files,rather than LaTeX is an advantage.

0

The practical reason why they ask for postscript is because they want the highest possible quality source file. When you convert to PDF it does things like scale/compress images, substantiate formula based drawing to fixed coords and so on. It is possible to use better quality settings than the defaults when generating a PDF, but people tend not to.

No matter what interprets the code the values become baked in at the point it is run. ie. as it is converted to PDF.

So outputting a PDF and then converting back to a PS is really missing the point. The quality is already lost. Just as if a photographer wanted a RAW to keep extra photo info, you can't take a JPEG and convert it back to one.

(Printer toolchains have been able to easily convert between PS and PDF for over a decade, it isn't a legacy issue)

  • The advantage of using PS is that the printed result will be closer to what was originally intended.
  • The advantage of using PDF is that the printed result is repeatably what is baked into the PDF.

Since I worked on the code that does the conversion I thought I would be helpful. But it is clear that new people are not welcome here and that plausible but incorrect guesswork is favoured over fact. Daniel's answer has a lot of correct technical details but then jumps to the wrong conclusion. Postscript is not some out of date thing that is being left behind, it is THE format that printers use and that whatever you send will be converted to at some point.

JamesRyan
  • 141
  • 1
    PS is not the highest possible quality at all. – percusse Dec 12 '14 at 18:40
  • 5
    The print output quality of PostScript and PDF file formats is the same. If you use a good converter with the right settings, conversion from PDF to PostScript and back doesn't lose visual quality. The default settings of PDF and PostScript generators may be indeed different, PDF generators being set up to do lossy compression to decrease quality. So if a random PDF generator and a random PostScript generator are used with their default settings, it may be possible that the PostScript generator generators better visual quality. But this depends on the tools. – pts Dec 12 '14 at 19:00
  • 3
    @pts technically speaking you are incorrect. Postscript can algorithmically generate shapes much more accurately. Imagine a curve on a graph, a postscript file can contain the formula whereas the pdf has the plotted points. So if you know what your target is you can make a pdf of similar quality, but if you decided later to blow it up to double the size the postcript file would give a much smoother curve. It is similar but not identical to the difference between raster and vector. – JamesRyan Dec 12 '14 at 20:42
  • 3
    Depends on your object. If your object consists of curves and lines there is no difference at all. Note that, PDF still understands the basic arithmetic primitives of PS and can represent objects symbolically. Besides that a vector graphic is meant to be a vector graphic so doubling its size does not change the quality. You have to have a computationally very very complicated mathematical object (even mandelbrot set is not enough) to see any difference. – percusse Dec 12 '14 at 21:06
  • @JamesRyan: Here is how I interpret your comment about the accuracy of PostScript. Table B.1. in https://www.adobe.com/products/postscript/pdfs/PLRM.pdf suggests that typically PostScript interpreters use the 4-byte float type to represent numbers. For example, Ghostscript also does it (see http://ghostscript.com/doc/current/Language.htm). Let's suppose that a PostScript interpreter is modified so that it will use 8 bytes (or even more) for a number, giving it better accuracy. Then some existing PostScript programs would produce slightly better visual quality, and most PDFs wouldn't benefit. – pts Dec 12 '14 at 22:07
  • @pts It has nothing to do with number length but that no matter what interprets the code the values become baked in at the point it is run. ie. as it is converted to PDF – JamesRyan Dec 12 '14 at 22:44
  • @percusse that is simply not the case. It is very simple to demonstrate for yourself. Take an A4 page PS, convert it to PDF, output them both at A3 to bmp and compare pixels. There will be differences. – JamesRyan Dec 12 '14 at 22:52
  • 2
    Flatten properly and there will be no difference. I don't understand your point. It is how people use Adobe Illustrator all the time PDF output with extremely detailed vector graphics. Nobody creates them in actual sizes. A billboard poster can be created in landscape A4. Exceptions don't rule the common point of PDF. Did you ever flattened a PDF and read what the commands are? It is PostScript language. I recommend you to do so. – percusse Dec 12 '14 at 23:05
  • @percusse PDF uses EPS which is a subset of postscript. Converting back from a PDF will result in postscript, but it will not result in the original postcript. I may be a new user on here but I worked on the code that does this so I am aware how it works, thank you. :P – JamesRyan Dec 12 '14 at 23:11
  • 2
    So you know what subset means I presume. To get out of that subset is really requires some unnecessary complication. Thank you indeed. – percusse Dec 12 '14 at 23:12
  • @percusse yup subset means it does not contain everything, ie bits are missing, ie PDF can not represent the content as fully – JamesRyan Dec 12 '14 at 23:17
  • 3
    OK let's keep it at that point. – percusse Dec 12 '14 at 23:18
  • @JamesRyan: I don't understand your point. Could you please clarify what the difference is if it has nothing to do with number length? Could you please give me a simple PostScript file which loses quality when converting to PDF, even with high quality conversion settings? I'd really like to understand, and based on your description I can't imagine what such a file would contain. A counterexample (whose visual quality does not decrease): 0 9 99 { newpath dup 0 moveto 0 -99 add neg exch lineto stroke } for showpage quit – pts Dec 12 '14 at 23:58
  • @pts I think what you dont understand is that postscript is a program not a definition. You can craft a postscript file that will print something entirely different on different page sizes if you did it purposefully. So if I make a PS file that prints a circle on A4 for example but a square on A3, when I convert to PDF I choose A3 or A4 at that point and it only ever prints one shape or the other no matter what size it is printed at. That is a bit of a contrived example but it happens to a less obvious extent naturally. Get it? – JamesRyan Dec 13 '14 at 22:07
  • @JamesRyan: Sure, I get it. But this doesn't answer my question about quality. Let's suppose the PostScript program always runs with the same input (e.g. same page size). I can't imagine a situation in which conversion to PDF loses visual quality, and it's not related to numeric precision. From our conversation it seems to me that you can imagine it. Could you please give an example? – pts Dec 14 '14 at 14:15
  • @JamesRyan: I'm 100% sure that I get what you said, but I'm interested in getting to know more. Do you know the answer to my question? Do you care sharing the answer with us? – pts Dec 14 '14 at 22:54
  • @JamesRyan: For the record, I completely disagree with your opinion on what I understand and what I don't. But luckily nobody else cares. – pts Dec 15 '14 at 11:41
  • This summarizes my understanding. 1. The same PostScript program can be run in different environments (e.g. with different page sizes), and it can do and draw different things based on the environment. PDF can't do this. 2. The same PostScript program can be run with an interpreter with more accurate number representation, thus the visual output can be of higher quality. PDF can do this only to a limited extent (by pushing multiple transformation matrices to the stack), so it can benefit less from better numeric accuracy. 3. PDF has some other features (e.g. videos, forms and JavaScript). – pts Dec 15 '14 at 11:44
  • PostScript programs can generate the page algorithmically , thus they can be smaller than PDF for complex graphics. -- These differences are not always relevant (i.e. they don't affect the final output noticably), in those cases the correctness, speed and configurability of the available tools decides if PostScript or PDF is used.
  • – pts Dec 15 '14 at 11:54