Engineering broad-spectrum document software: lessons from ghostscript


	BibTex \| RIS \| RefWorks Download

Almost 14 years after its first public release, Ghostscript is still a commercially thriving, actively evolving, nearly-Open Source PDL interpreter. It has successfully evolved from its original function as a PostScript Level 1 previewer running on MS-DOS on IBM-compatible PCs to cover new input PDLs (PDF, PCL5, and PCL XL), output formats (bitmaps, many printers, and low- and high-level PDLs, including PostScript-to-PDF "distilling"), development platforms (Unix, Linux, MS Windows, Macintosh, VMS, ...), deployment platforms (desktop, server, and embedded), and graphics capabilities (including CIE-based and CMYK color, RasterOp, anti-aliasing, and partial transparency), while maintaining or improving performance and output quality. This talk will examine, within the available time, the design choices (some more successful than others) relating specifically to this broad-spectrum coverage.Ghostscript repeatedly uses several design patterns to achieve functional and performance coverage. One example is "least common denominator plus specialized but functionally equivalent modules selected at build time". This handles differences in build environments, C language dialects, and operating system interfaces, as well as some user-selectable options. A second example is virtual functions, which handle output formats, color representations, and many other points of variability within Ghostscript. A third is "pipelineable interface", used in the memory manager and also for back ends. A fourth is "mixed-level interface", which places both high-level and low-level operations in a single interface with default implementation of the former in terms of the latter. The talk will give some specific examples of each of these, with an assessment of how well they have worked.Until mid-2000, nearly all the development of Ghostscript was done by a single developer with little input. This produced code with extremely high internal consistency, but spotty documentation and some idiosyncratic coding and design choices (such as extremely heavy use of C preprocessor macros). With the transition of development and maintenance to a mixed team of both commercial and public developers working in a much more open process, many processes formerly happening within a single person's head must be documented (e.g., necessary coding rules), automated (e.g., checking for conformity with those rules), modified (e.g., accepting a lower level of quality in intermediate releases), and/or augmented (e.g., public code review, allowing the existence of multiple code branches). The talk will assess some of these changes and their likely impact on future evolution of the code.

Conference: ACM Symposium on Document Engineering - DocEng , pp. 1-1, 2002

DOI: 10.1145/585058.585059

Cumulative Annual

View Publication

( portal.acm.org )

( doi.acm.org )


	The following links allow you to view full publications. These links are maintained by other sources not affiliated with Microsoft Academic Search.

Keywords (7)