PDF workflow (top)

Current Postscript-based prepress workflows have been promoted in printing and export centers. However, Postscript-based prepress workflows still have problems that need to be urgently improved, both at home and abroad. Most printers and output centers are involved in the production of job jobs. There are many sources of live jobs: one is a complete task delivered by the customer, and the printing factory or output center can be from input to output, in full accordance with its own work. The process completes the task; one is to accept the room, has been processed by the groupware software, and requires that the printer and output center be converted to Postscript for output; or directly receive the Post script from the client for output. Regardless of the method used, if there is a file format or condition that does not match at a certain point, problems such as loss of fonts, graphics, mismatches, and file transfer errors will occur during output.
Actually, the Postscript encountered in the production process cannot be guaranteed to be completely consistent, and it is difficult to exactly match the RIP used by the printing factory or the output center. Moreover, the Postscript file itself also has the disadvantage of being unable to edit the character, cannot be foreseen, and unable to check whether there is an error before output, and the main thing is that the Postscript language file becomes unpredictable and unreliable. In addition, the large number of document accommodations is not conducive to transmission. Therefore, Postscript-based prepress workflows require a reliable, stable, and predictable Postscript output that requires a more integrated process that meets high quality standards. In short, the prepress workflow is still evolving.
Basic Postscript Workflow At present, we are familiar with the workflow is: first use the group version and image software (such as PageMaker, QuarkXPress, Photoshop, etc.) for text image processing, typesetting, convert the processing results into Postscript or EPS before entering the RIP Files, and then enter the RIP conforming to Postscript standard for rasterization and screen output. Some prepress software such as imposition, trapping, etc., can also accept Postscript, EPS and other files for prepress processing, and then again interpreted by RIP as Postscript data and reproduced into bit data, ready for a specific Postscript output device Output. The most basic Postscript prepress workflow is widely used today.
Postscript is still underserved Postscript's strength lies in the fact that it is a very flexible and device-independent page description language and has become a standard printing technology for producing high-quality output. Since Adobe developed PostScript in 1985, after continuous improvement and improvement, Postscript II and Postscript III page description reviews have been launched, which solved many issues such as double-byte, color prepress processing, and became indispensable for today's printing and publishing industry. A general-purpose programming review missing is that it can output Postscript files in high quality on any print output device with Postscript capabilities, including low-priced desktop printers and high-end image-setters, platesetters.
In recent years, Adobe has made many improvements on Postscript III: smooth smooth nuances; improved quality of two color blends; 16-bit color grayscale to prevent visible defects; and Ldiom recognition using Postscript III RIP Recognizes the gradual, variable and automatic use of Postscript III generated in Postscript II applications for better quality; improved font technology to handle double-byte fonts such as Chinese characters; extends color separation beyond the usual CMYK planes, Such as high-fidelity HiFi color, to provide a new level of color printing quality; within the RIP separation technology, with the greatest output flexibility and last minute personality; trapping in the RIP, improve productivity and process automation and so on. In particular, the standard Postscript III RIP can accept and process PDF files directly, which is an important step towards the standardization of PDF workflow in the future.
In spite of this, the internal format of Postscript as a workflow is still insufficient, mainly in:
Invisible, non-editable Postscript is converted from the groupware processing results, invisible, non-editable; some prepress software may accept Postscript file input, but if errors are found on the output device, it still needs to return to the application The software will be edited and modified again.
Without Page Independence As a general-purpose programming language, diet has processes, variables, and control structures that must first be interpreted and rasterized to render pages. This process must be performed in a certain order. The last page to open the file must start from the first page to open. The following page has a dependency on the previous page.
Unpredictable Postscript technology was originally developed as a language for describing pages and controlling simple machines. Now it is used for high-precision image-setters and CTP and other output devices, but this flexibility results in unpredictable output. The reason is because so many software versions create Postscript in so many ways that the Postscript page description becomes arbitrary and complex. For different applications, the generated Postscript page description is different. Some application software developers complain that they have to spend so much energy on Postscript output versions. And for users, This leads to unpredictability in the production workflow, that is, due to the fact that the Postscript is not exactly the same, many errors may occur at the output.
Transmission difficulties In the prepress workflow or in the network to transmit Bitmap, Postscript large files is difficult, large file information, low transmission speed and small transmission bandwidth must significantly reduce the operation, and the system also needs to set a large And expensive storage. From the perspective of file transfer, we also need to have a more suitable page description language format. (To be continued)