On Thu, Aug 14, 2003 at 01:34:01PM -0400, Leonard Rosenthol wrote: | | >Implementing a full PDF parser is definitely much harder than a full | >PostScript parser. PDF more or less encompasses PostScript. | | You are quite misinformed... | | PDF is a static file format of structured objects referenced | by a single catalog (cross reference table). It's pretty easy to | write a PDF parser - a couple of days at most, which is why there are | so many of them. (the hard part is getting all the object management | correct for later modification). It has NO variables, loops, | conditionals, etc. | | Postscript is a full fledged programming language with all | that at entails (stack managements, variables, loops, functions, | conditionals, turing completeness, etc.).
Person! I said it more or less encompasses PostScript. I do agree that the interpreter is much simpler in case of the PDF due to the absence of procedures, variables, conditionals, etc. But PDF has a lot of other features which add complexity to it over PostScript. You yourself have listed features such as JPEG2000, 16-bit images and JBIG. PDF also supports more types of fonts, supports hyperlinks, annotations, bookmarks, thumbnails, scripting -- there you go, encryption and signatures, plug-ins and more. | >PostScript is much more widely supported than PDF. | | Only as far as direct/native printing goes - that's true. | | On the application side, PDF has wider support due to the | ease of implementation. See above. PDF has become popular on screen displays (and even for printing as a result), but I think it has more to do with Adobe pushing the PDF format with a free viewer, and due to it's document capabilities. | > It is just as extensible as PDF as far as imaging goes. | | To an extent - there are things that PDF does by default that | PS can't do (eg. 16bit images, JPEG2000, JBIG2), and there are areas | of PDF that provide extensibility that PS does not. We were talking about extensibility, not about features that come bundled. There are areas of PDF that provide extensibility, but none of them directly apply to the GIMP or processing of imaging information. | Sure, at some point the printer is just putting bits on a | page - but only the home-level inkjets are ONLY raster-based. | Professional office and prepress printers use a page description | language (usually either PCL or PS) to keep traffic down and then | rasterize on the device. | | Most implement RIPping on the device itself... | | | >More or less, most people are able to print PostScript on their printers | >on most major operating systems. | | Not out of the box! They would need to install Ghostscript | (and associated drivers, which might also require something like | GIMP-print). To print PostScript, one doesn't need GIMP-print. My OS (Red Hat Linux) came with Ghostscript installed out of the box. I assume Mac OS X can also handle PostScript out of the box as it has a unix toolchain. IIRC it uses CUPS as its print system. I am not sure about Windows as I haven't worked with it in a long time. The point of my statements was to say that despite them being PCL or raster-based printers, they can still print PostScript. They can sure print PDF as well in the same way. The point Joao was trying to make was that one can print PostScript on a printer way easier than one might print a custom GIMP file format as they don't need to find a copy of GIMP to print it, and that gives weightage to going with a PostScript file format. Mukund _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
