Desktop publishing (abbreviated DTP) is the creation of documents using page layout skills on a personal computer, primarily for print. Desktop publishing software can generate layouts and produce typographic quality text and images comparable to traditional typography and printing.
Desktop publishing (also known as DTP) combines a personal computer, page layout software and a printer to create publications on a small economic scale. Users create page layouts with text, graphics, photos and other visual elements using desktop publishing software such as QuarkXPress, Adobe InDesign, etc.
Desktop publishing began in 1985 with the introduction of PageMaker software from Aldus and the LaserWriter printer from Apple Computer for the Apple Macintosh computer. The ability to create WYSIWYG page layouts on screen and then print pages at crisp 300 ppi resolution was revolutionary for both the typesetting industry as well as the personal computer industry. The term "desktop publishing" is attributed to Aldus Corporation founder Paul Brainerd, who sought a marketing catch-phrase to describe the small size and relative affordability of this suite of products in contrast to the expensive commercial phototypesetting equipment of the day.
Desktop publishing began in 1985 with the introduction of PageMaker software from Aldus and the LaserWriter printer from Apple Computer for the Apple Macintosh computer. The ability to create WYSIWYG page layouts on screen and then print pages at crisp 300 ppi resolution was revolutionary for both the typesetting industry as well as the personal computer industry. The term "desktop publishing" is attributed to Aldus Corporation founder Paul Brainerd, who sought a marketing catch phrase to describe the small size and relative affordability of this suite of products in contrast to the expensive commercial phototypesetting equipment of the day.
Often considered a primary skill, increased accessibility to more user friendly DTP software has made DTP a secondary skill to art direction, graphic design, multimedia development, marketing communications, administrative careers and advanced high school literacy in thriving economies. DTP skill levels range from what may be learned in a few hours (e.g. learning how to put clip art in a word processor) to what requires a college education and years of experience (e.g. advertising agency positions.)
Early systems
By today's standards, early desktop publishing was a primitive affair. Users of the PageMaker-LaserWriter-Macintosh 512K system endured frequent software crashes, the Mac's tiny 512 x 342 1-bit black and white screen, the inability to control letter spacing, kerning and other typographic features, and discrepancies between the screen display and printed output. However, for that moment in time, it was received like a magic trick: difficult to believe, but everyone wants to know how to do the trick. Behind-the-scenes technologies developed by Adobe Systems set the foundation for professional desktop publishing applications. The LaserWriter and LaserWriter Plus printers included high quality, scalable Adobe fonts built into their ROM memory. The LaserWriter's additional PostScript capability allowed publication designers to proof files on a local printer then print the same file at DTP service bureaus using optical resolution 600+ ppi PostScript-printers such as those from Linotronic. Later, the Macintosh II was released which was much more suitable for desktop publishing because of its larger, color screen. In 1986, the GEM-based Ventura Publisher was introduced for MS-DOS computers. While PageMaker's pasteboard metaphor closely simulated the process of creating layouts manually, Ventura Publisher automated the layout process through its use of tags/style sheets and automatically generated indices and other body matter. This made it suitable for manuals and other long-format documents. Desktop publishing moved into the home market with Publishing Partner for the Atari ST in 1986 and later for the Amiga, GST's Timeworks Publisher on the PC and Atari ST, Calamus for the Atari TT030, Home Publisher and Newsroom for 8 bit computers like the Apple II. During these early years, desktop publishing acquired a bad reputation from untrained users who created chaotically organized ransom note effect layouts - criticisms that would be levied again against early web publishers a decade later.
Mature systems
The improved typographic controls and image handling of PC and Mac-based publishing systems increasingly attracted the attention of professional publishers. The turning point was the introduction of Quark XPress in the 1990s and an ever increasing number of digital typefaces. Xpress became dominant in the publishing world until the early 2000s when Adobe InDesign grew in popularity for its powerful typographic controls and integration with other Adobe publishing products, especially those which were predominate within the design, photography, publishing, printing, and digital media industries. By the late 1990s, virtually all publishing had become "desktop publishing." The superior flexibility and speed of desktop publishing systems has greatly reduced the lead time for all forms of publication and accommodates elaborate designs and layouts that were unfathomable in the decades before DTP. Database publishing has further reduced the time required to develop thick manuals and catalog publications. Desktop publishing helped condition a generation of personal computer users to be on the lookout for "the next big thing." In the late 1980s, developers hopefully applied the "desktop" prefix to potential new markets like "desktop presentations," "desktop forms" and "desktop video." All of these markets proved to be important (see PowerPoint, Adobe Acrobat, and miniDV for example), especially desktop video editing. Many cinema length movies are now edited on Apple Final Cut Pro on a desktop computer, replacing equipment and software that would have cost a hundred thousand dollars in the 1980s.
Comparisons with word processing
While desktop publishing software still provides extensive features necessary for print publishing, modern word processors now have publishing capabilities beyond those of many older DTP applications, blurring the line between word processing and desktop publishing.
In the early days of graphical user interfaces, DTP software was in a class of its own when compared to the fairly spartan word processing applications of the time. Programs such as WordPerfect and WordStar were still mainly text-based and offered little in the way of page layout, other than perhaps margins and line spacing. On the other hand, word processing software was necessary for features like indexing and spell checking, features that are today taken for granted. As computers and operating systems have become more powerful, vendors have sought to provide users with a single application platform that can meet all needs. Software such as Microsoft Word offers advanced layouts and linking between documents, and DTP applications have added in common word processor features.
Comparisons with other electronic layout
In modern usage, DTP is not generally said to include tools such as TeX or troff, though both can easily be used on a modern desktop system and are standard with many Unix-like operating systems and readily available for other systems. The key difference between electronic typesetting software and DTP software is that DTP software is generally interactive and WYSIWIG in design, while older electronic typesetting software tends to operate in batch mode, requiring the user to enter the processing program's markup language manually without a direct visualization of the finished product. The older style of typesetting software occupies a substantial but shrinking niche in technical writing and textbook publication; however, since much software in this genre is now open source, it can be more cost-effective than the professionally-oriented DTP systems.
There is some overlap between desktop publishing and what is known as Hypermedia publishing (i.e. Web design, Kiosk, CD-ROM.) Many graphical HTML editors such as Microsoft FrontPage and Dreamweaver use a layout engine similar to a DTP program. However, some Web designers still prefer to write HTML without the assistance of a WYSIWIG editor and resort to such software, if at all, solely for complex layout that cannot easily be rendered in hand-written HTML code.
Some writing systems of the world, such as Arabic, Farsi, Urdu and Hebrew, are written in a form known as right-to-left (RTL), in which writing begins at the right-hand side of a page and concludes at the left-hand side. This is different from the left-to-right (LTR) direction in which languages using the Latin alphabet (such as English) are written. When LTR text is mixed with RTL in the same paragraph, each type of text should be written in its own direction, which is known as bi-directional text. This can get rather complex when multiple levels of quotation are used. Almost all writing systems originating in the Middle East are of this nature.
Bidirectional script support is the capability of a computer system to correctly display bi-directional text. The term is often shortened to the jargon term BiDi or bidi.
The CJK languages are syllabic languages. And each syllable occupies two bytes in computer memory. There is no such thing as a single letter in the CJK languages.
The Chinese, Japanese and Korean (CJK) languages are character-based with each character referring to an idea - as opposed to a specific shape of the character or an object. Because their characters are more complex and graphical than Roman alphabet letters, they typically use twice as much memory and are considered double-byte languages.
The complexities of the double-byte languages raises issues of file size, operating system and software compatibility, and even the clarity and readability of text due to fewer font choices. And, because character text is semantic-based, a phrase cannot simply be broken at any random point.
Quality Assurance (QA) is the process of monitoring specific project results to determine if they comply with relevant quality standards, and identifying ways to eliminate causes of unsatisfactory performance.
When checking the layout of the files the QA team apply strict criteria, checking punctuation, headers and footers, titles, numbering and graphics, as well as updating cross-references, tables of contents and indexes, etc.
The standard list for QA check involves these activities:
Clients are always asking us for our methodology on multilingual desktop publishing (DTP) projects. The correct response is that projects vary in process.
Opticentre is geared towards very large projects with many 100s of pages in many languages so clients handing off volumes like this normally have a bespoke workflow in place. Opticentre then simply plugs into that and goes with the flow.
However, if we were managing a project from scratch, here is a sample process (using FrameMaker):
Any changes from your reviewers can be sent to us outlined in a Word file, annotated in the PDF file or marked-up on a hard copy (if the changes are not extensive). Changes are then incorporated and the review cycle continues until the end client is perfectly content.
Read moreThe increasing number of languages that companies need to translate into requires careful planning when preparing translation projects. Thus, choosing appropriate tools, finding qualified project teams, and applying suitable concepts to avoid additional work become crucial tasks for the project manager. If all these issues are considered beforehand, a perfect balance can be achieved within the magic triangle of time, cost and quality.
Due to globalization and the opening of markets today translation and localization projects often involve twenty or more languages. The notion that these projects can be handled just like the translation of a Word-written handbook into English is widespread - but mistaken. So what are the differences between these two tasks?
Due to the above-mentioned facts the early planning stage of multi-language translation projects is of great importance. To increase the odds for a successful completion of such a project, the following should be observed during the preparatory phase.
1. Project preparation
Ideally, process optimization with particular regard to the planned translation volume should already begin during editorial compilation. Corresponding elements include tools that support terminology, appropriate marking of information not to be translated, design of a process-compatible layout while taking into account that certain languages require more text space than others, and tools supporting structural document quality control ("preflight tools for translations"). In large-scale translation projects, such efforts will easily prove to be cost-effective even if the initial editing process is more costly and time-consuming.
The first step of the translation service provider is a "data input check" or inspection of the structural quality of the source documents.
Experience shows that the structural quality of source documents often is not optimal for the translation process. This can be attributed to one or more of the following factors:
Unfortunately, human intuition frequently fails when such situations are evaluated. One example: many contemporary projects are of the single-source type, where one source of data forms the basis for several other products in different media, e.g. PDF files for printing, context-sensitive HTML help and other WWW applications. Let's assume the source project consists of five FrameMaker books. It only takes a simple calculation to realize that if such a project involves twenty languages, the amount of effort expended on the source language may have to be multiplied by a factor of 300 (five books x twenty languages x three media). This means, that five minutes of work on the source language may translate to more than three days of work to accomplish the same task for all target languages and media.
These large-scale projects can be made easier if scripts (for FrameMaker) or macros (for Word) are employed, that may be customized for the respective customer and may be adapted continuously. A prerequisite for this is a full mastery of the corresponding tool. Moreover, only translation service providers with the necessary in-house technical support will manage to perform the small miracles an ongoing project may still require on a daily basis.
2. Employing the adequate tools
The use of translation memory tools for multilingual projects has become a matter of fact. For this reason, the issue is neither discussed any further here nor is any evaluation attempted as to which tool may be the most appropriate. Still, TMS are not exempt from continuous development. Therefore, the planning of large translation projects should include detailed considerations of the different functionalities and which TMS covers them best. This may involve items like terminology extraction, filter quality for the DTP tool used, quality assurance features, handling of twenty and more languages at the same time or procedures for TM update, to just mention a few.
3. The project team
The number of team members required for such a project varies greatly. However, the following positions should always be filled: project manager(s), process manager(s) with expert TMS know-how, translators, layouter(s), proofreader(s), and possibly terminologist(s).
The project manager must be able to coordinate all project members and maintain firm control over the magic triangle between project deadlines, cost, and product quality. Ideally the manager will be involved in all project phases, from preparation of the bid to project completion. He/she ought to have at least basic knowledge of the tools employed, and must be able to provide the customer with an interim report at any time. In particular with large projects, clients expect feedback on status and progress. Tools offering integrated project management functions can be helpful, but the opposite is possible as well: because such tools generally indicate project progress in percentage values, the merit of such a statistic depends on the sophistication of the underlying algorithm. It has happened that these percentage values had little to do with reality.
An important criteria when selecting translators is a genuine competence regarding the language and subject matter as well as the translation memory tool. One secret of high-quality translations is the ability to "anticipate terminology", even if no standard terminology has been established.
Apart from tool proficiency, layouters should have developed a sense for layout effects caused by various languages. Localization tools facilitate the solving of difficult layout problems with the help of translation simulations in which text expansion effects can be modeled. The classic DTP tools do not offer these functions.
TM specialists are indispensable if standard filters have to be adapted for the project or if a TMS first has to be configured to customer needs, e.g. by protecting text that must not be translated or by guiding special objects such as conditional text or variables through the entire process.
Proofreaders do not have to be native speakers of the respective language but need to be briefed precisely on quality definitions.
4. Quality assurance
Given the large budgets required for major multi-language translation projects, timely agreement on quality and its management is essential. The customer surely expects maximum quality translation. But what does this mean? For example, how can terminology be kept consistent if the project does not include corresponding standards or if the project volume or duration lead to several translators being employed for a single language? And what about the notorious 100 percent matches: do they have to be proofread or not? This much can be said here: do not blindly trust the marketing claims for any tool. Because in TMS-based translation workflows the essential question is, how much "garbage" does the existing translation memory contain already. This is one topic where the translating community is suffering from serious misconceptions.
Should quality assurance be done according to the four-eyes principle, because translations are always subject to interpretation? Does a formal workflow involving client reviewers have to be arranged? If so, who will ensure timely feedback? And will reviewers know the areas to which their responsibilities extend versus those aspects they better not evaluate?
A minor but unpleasant side issue is the habit of performing corrections via notes in PDFs. Keep in mind that it is rather challenging to incorporate PDF notes, for example in the Polish language, into a FrameMaker document. Again, this requires special know-how.
Summary
The issues addressed above illustrate that language proficiency is an essential but not the only precondition for the success of multilingual projects. In our view experience with the relevant processes and detailed knowledge of the tools are far more important. Even before the start of the project close coordination and agreement between customer and service provider have to be achieved if the project should to be completed successfully.
Go to Services
Perform the tasks in this section to determine if Acrobat Distiller causes the problem.
1. Make sure that you use a version of Acrobat Distiller that is compatible with FrameMaker.
FrameMaker installs the required version of Acrobat Distiller. If you use a version of Acrobat Distiller that's not compatible with FrameMaker, you may need to update or upgrade FrameMaker, or remove Acrobat Distiller and reinstall FrameMaker.
To determine which version of Acrobat Distiller is installed, start Acrobat Distiller and choose Help > About Acrobat Distiller.
2. Make sure that Acrobat Distiller works.
Create a PDF file from another application, (for example, Microsoft Word) by printing a document to the Adobe PDF printer. If you can create a PDF file, FrameMaker may be the cause of the problem; proceed to the "Troubleshoot FrameMaker" section in this document. If you can't create a PDF file, create a PostScript file and then open it in Acrobat Distiller:
3. Check the messages.log file.
The messages.log file may include information (for example, PostScript errors) that you can use to troubleshoot the problem. If the file lists a PostScript error, troubleshoot the error according to document 328515 , "Troubleshoot PostScript errors." You can find the messages.log file in the Acrobat Distiller [version] folder.
For Acrobat Distiller 7.0:
For Acrobat Distiller 6.0:
For Acrobat Distiller 5.0:
