Standard Finishing
4Over

Announcement

Collapse
No announcement yet.

PostScript verses PDF

Collapse
Canon
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • PostScript verses PDF

    Nice to see you here, Dov. This continual merry-go-round with transparency always brings me back to: so when're you Adobe boys going to bite the bullet and roll-out PostScript Level 4? I know the answer, "never", but I also know you've probably got it pretty much worked out in your spare time and it's just wasting away on your hard drive.

    The entire "abstract until RIP" philosophy is a cornerstone of PostScript, so it's a crying shame Adobe abandoned parallel PDF / PostScript development.

  • #2
    Re: PostScript verses PDF

    Absolutely isn't going to happen. PostScript is a +programming language+, not really a page description language. By its very nature, it does not provide for really reliable end-to-end workflows since by definition, content can change on the fly. Fun for hackers, disaster for people who need to earn a living.

    No, there is not a +PostScript Language Level 4+ sitting on disk somewhere waiting for marketing to give a signal. Beginning with PDF 1.4, all additions to the Adobe imaging model went into PDF and not PostScript.

    To be very clear, Adobe will continue to license PostScript technology through our EOM partners as long as there is a demand for it from their customers. We will also continue support a gateway from PostScript to PDF via our Distiller technology in Acrobat. Adobe will continue to support EPS as a +legacy+ graphics format for import of non-color managed, opaque graphical data into Adobe applications (such as InDesign and Illustrator). Although we certain do +not+ recommend that new graphical content be stored in EPS format (except to satisfy the need to import data into page layout programs that aren't quite PDF-centric -- no need to mention names here!), our user base should feel comfortable that there is no need to worry about a need to convert their very sizable libraries of EPS-based graphic assets.

    - Dov

    Comment


    • #3
      Re: PostScript verses PDF

      Dov,

      I can't argue with any of that (well, except for the dig at "hackers", who need to earn a living, too). I love the PDF format, and recognize the need for a "hard target" final format. I think Adobe went a little haywire with the Acrobat product line, and shoved too many things into PDF, but the PDF/X formats fixed that, more or less. What I can't understand though is the abandonment of the only print-centric programming language. PostScript and PDF are not mutually exclusive, and it never needed to be an either/or proposition, at least not from a technical point of view. I would have loved to have been a fly on the wall during the "let's abandon PostScript" discussions at Adobe.

      [PostScript is Dead, Long Live... PDF?|http://www.tgreer.com/printforum/showthread.php?t=186]

      Why don't you drag Leonard over here, too? Then the both of you can REALLY put me in my place!

      Thanks for the reply.

      Comment


      • #4
        Re: PostScript verses PDF

        Leonard and I are busy working on the upcoming ISO PDF standards for VDP. We just finished up PDF/X-4 and PDF/X-5, to be published soon.

        BTW, there was never a "let's abandon PostScript" discussion at Adobe. And for that matter, we never abandoned PostScript, we just never pursued trying to reconcile its aging imaging model with that of PDF. PostScript may be "fun" for programmers, but it certainly is not something that is particularly "reliable" for rendering -- how can it be reliable if you can use random number generators in it to determine layout and pagination on the fly? PDF may not be easily to edit (i.e., you can't edit it with an ASCII text file editor like you can ASCII PostScript -- forget about binary PostScript), but trying to edit PostScript, even in ASCII is an exercise in puzzle solving at best!

        - Dov

        Comment


        • #5
          Re: PostScript verses PDF

          PostScript programming certainly isn't for everyone. I have no problems with the move to PDF. But what a PDF file can't do is share in the computational workload of a print generation system. With the PDF imaging model growing increasingly unreconciled to the PostScript imaging model, at some point I'll have to switch gears in how I approach these projects. Either I license the Adobe library, or fall behind the curve. Neither choice is great.

          PDF standards for VDP? I'm scratching my head trying to figure that one out... why that would need a separate standard. However, I see how far I've taken this thread away from a discussion about Quark. Sorry about that; I'll just watch Leonard's blog for more info on those specs.

          Comment


          • #6
            Re: PostScript verses PDF

            Dov,

            It's true. PostScript is dynamic, and can alter it's behavior on the fly, which makes it perfect for VDP. Your criticism is that it's hard to troubleshoot. Granted. But PDF has JavaScripts, which alter content on the fly. External Streams. All very useful. But with the same inherent problems, which you solve by adhering strictly to the appropriate PDF/X standard, which introduces more complexity to the workflow. I don't think the "PostScript is too wild and dynamic" vs. "PDF is stable and static" argument is that cut and dried.

            But you're dead right about it: PostScript is a lot of fun. Call me crazy.

            Comment


            • #7
              Re: PostScript verses PDF

              Thomas D. Greer wrote:
              "But what a PDF file can't do is share in the computational workload of a print generation system."

              I don't understand this phrase. PDF is far more efficient than postscript in a print generation system. Postscript tends to repeat data a lot when it is not necessary - a problem you don't have with PDF. If its reusable, it gets reused.

              Methinks you may be jesting when you say you have no problems with the move to PDF. The only problem with PDF is, you need all your systems to be PDF savvy to get the benefits.

              Comment


              • #8
                Re: PostScript verses PDF

                Alan,

                PostScript doesn't need to repeat any data at all. It's all in the way it's written. What I mean by "share in the computational workload"... consider a web-to-print application that generates business cards. There is a lot of work to do in DHTML, AJAX, SQL queries, and of course, how to translate all of what the user does when building their cards into something that prints. Copyfitting, graphic resizing, and so on.

                In such a system, I can have web designers do their part, scripters do their part, a database guy design the stored procedures, and someone else write the PostScript to translate it all into a final print job. We don't have to figure out how to measure the width of a string in the given font in ASP.NET. PostScript does it. Often with such systems I'll as a last step convert the PostScript to PDF. Yes, I do like PDF. It's highly transportable and reliable. But it isn't a programming language, and that is what is missing today.

                Comment


                • #9
                  Re: PostScript verses PDF

                  I see what you mean. In general usage though, PS forms type re-use of data is rarely seen in postscript yet is more standard as PDF output, in effect giving generally smaller file sizes than its postscript equivalent (even with compression taken into account).

                  Comment


                  • #10
                    Re: PostScript verses PDF

                    Alan,

                    You're right. Driver-produced PostScript is generally bloated and full of unused procsets. VDP applications though all do generic or vendor-specific forms caching. Generally, when I talk PostScript I mean custom-written PostScript. It's so convenient just to have a windows app or web app output basic data or data formatted as a PostScript dictionary:

                    {color:#ff0000}
                    /myData << /fname Thomas /lname Greer /font Helvetica /ptSize 12 >> def{color}

                    {color:#000000}and then have a PostScript program to do all the work of setting the fonts, positioning the strings, copyfitting the strings, and so on. Without PostScript, the choices get pretty narrow and pretty expensive. It's viable for big developers to license the Adobe Library / SDK which abstracts all the power of PDF and PostScript into an API, but for typical in-house programmers, which many financial printers and mailing houses have, that's often not a choice. They either pay Adobe big bucks to get the SDK, or they use 3rd party PDF tools which are often very crude compared to the raw capabilities of PostScript.

                    From a business perspective, I understand Adobe's decision. Push forward with PDF, without the burden of constantly upgrading PostScript to match. It makes sense, but the side effect is that a certain segment of the market is now left out in the cold.
                    {color}

                    Edited by: Thomas D. Greer on Sep 7, 2007 11:20 AM - forum messed up the colors.

                    Comment


                    • #11
                      Re: PostScript verses PDF


                      Actually, JavaScript is not part of the PDF stream itself. When associated with a PDF file and activated within a PDF editor, it certainly can change the PDF, but the PDF cannot change itself. When you "print" a PDF file, the JavaScripts are not active. I know of no PDF print renderer that does anything with the JavaScript at all. Thus, for print publishing purposes, PDF is truely deterministic.

                      Maybe you can explain what you mean with regards to PDF/X introducing +more complexity to the workflow.+ I am not sure how that follows, especially if you are dealing with PDF/X-4 and PDF/X-5 variants, recently approved by ISO and about to become published and public.

                      With regards to earlier postings wrt/ PostScript for VDP, yes, as a programming language, PostScript is very convenient for doing data merge and layout on the fly. But quite frankly, is that what you want to do at the RIP when trying to keep an engine going possibly hundreds of pages a minute going at full speed? I don't think so. There are any number of good reasons to segregate data merge and layout from the graphical interpretation and RIP stage -- more than I feel I can readily go into via this type of forum. Needless to say, you will be hearing much more about pure PDF/JDF VDP workflows in the coming few years.

                      - Dov

                      Comment


                      • #12
                        Re: PostScript verses PDF

                        >No, there is not a PostScript Language Level 4 sitting on disk somewhere waiting for
                        >marketing to give a signal. Beginning with PDF 1.4, all additions to the
                        >Adobe imaging model went into PDF and not PostScript.

                        What about the Mars format ?
                        How does that fit in ?
                        Will PDF morph into Mars at some point ?

                        Chasd

                        Comment


                        • #13
                          Re: PostScript verses PDF

                          MARS is PDF... it's an XML storage system for PDF. It doesn't add or subtract any functionality to the PDF per se, it's merely another way of storing a PDF on disk. What it WILL do is greatly expand, I believe, the software tools available for creating and editing PDF files.

                          Comment


                          • #14
                            Re: PostScript verses PDF

                            >It doesn't add or subtract any functionality to the PDF

                            The Mars file spec does say that data should be able to be round-tripped from PDF to Mars and back to PDF. However, that spec also says that :

                            1)
                            deprecated PDF features will not be available in Mars.
                            2)
                            Some ways of doing things won't be supported, such as Type 1 fonts would be converted to OpenType.
                            3)
                            The presentation of the round-tripped PDF may be the same, but the internal construction of the document may be very different from the original.

                            So in practice there may not be a difference in functionality, but _all_ PDF features will not be available. The most used and best ones will be available, Adobe doesn't want to deal with cruft, which is a understandable and smart decision.

                            Comment


                            • #15
                              Re: PostScript verses PDF

                              That's good info, Charles. Thanks for the clarification.

                              Comment

                              Unconfigured Static HTML Module

                              Collapse

                              Static HTML Module Content
                              4OverStandard FinishingDuploSmartsoft (Presswise)CanonKBAUltimateTharstern
                              4OverStandard FinishingDuploCanonKBAKBA4 PeesSmartsoft (Presswise)TharsternUltimate

                              What's Going On

                              Collapse

                              There are currently 5564 users online. 125 members and 5439 guests.

                              Most users ever online was 6,597 at 10:25 AM on 04-20-2018.

                              Working...
                              X