Q: What is Desktop publishing

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.

Q: What is Quality Assurance

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: Fonts are correct Size of text is correct Formatting paragraphs Check if alignment is correct Paper size is same Headers and footers (if available) are same Quotation marks are correct Check if bold, italic or underline text is in same place as source Check for double spacing, periods, commas, etc. Check for spaces before commas Check for spaces before periods If there are tables - rows and lines have to be same as source If there are lines - check position and size If there are pictures - must look same as source Check the spaces around pictures (left, right, top, down) Make sure there are no missing period If there are bullets check with original Check for missing parts and sentences Check that links are updated Check for superscripts and Unicode Make sure that graphics are localized Check margins Check SAE J2450 translation quality metric where appropriate

Question 1

What is Desktop publishing

Accepted Answer

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.

Question 2

History of Desktop publishing

Accepted Answer

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.

Question 3

Bidirectional languages

Accepted Answer

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.

Question 4

Double byte languages

Accepted Answer

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.

Question 5

What is Quality Assurance

Accepted Answer

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:

Fonts are correct
Size of text is correct
Formatting paragraphs
Check if alignment is correct
Paper size is same
Headers and footers (if available) are same
Quotation marks are correct
Check if bold, italic or underline text is in same place as source
Check for double spacing, periods, commas, etc.
Check for spaces before commas
Check for spaces before periods
If there are tables - rows and lines have to be same as source
If there are lines - check position and size
If there are pictures - must look same as source
Check the spaces around pictures (left, right, top, down)
Make sure there are no missing period
If there are bullets check with original
Check for missing parts and sentences
Check that links are updated
Check for superscripts and Unicode
Make sure that graphics are localized
Check margins
Check SAE J2450 translation quality metric where appropriate

Question 6

What is Opticentre Desktop Publishing Workflow

Accepted Answer

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):

1. SAVE AS MIF - English FrameMaker files are saved in MIF format and then run through the HEARTSOME/TRADOS filter creating a marked-up RTF file. All character, paragraph and other formatting information is hidden inside of tags (like an HTML file).
2. TRANSLATE - We send back to client for translation (we do not offer translation services).
3. RE-FILTER BACK TO MIF - When we receive back the translations and edits, we process the tagged files back through the HEARTSOME/TRADOS filter and new MIF files are produced. HEARTSOME/TRADOS produces an error log warning us to check any out of place tags before we can move on. This ensures that translated files will have the exact same formatting characteristics as the original.
4. FINAL DTP - After the files are back to MIF, desktop publishing experts will go through FrameMaker (or Quark, PageMaker, etc.) files, page-by-page and line-by-line, to make sure everything looks right. They will regenerate the TOC and Indices, if applicable, and test any hyperlinks in place.
5. PENULTIMATE QA - Our in-house QA team then second-check every outgoing file according to bespoke requirements and/or a standard checklist of over 30 common issues.
6. CLIENT REVIEW - This is the most important step in the whole process. This is where we send you your translated, formatted file(s) for review. Usually, a PDF is created so your overseas customers or colleagues can review the translation and layout easily without the need for FrameMaker installed on their system.

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.

Question 7

From English to Cyrillic to Chinese

Accepted Answer

The 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?

Translating a source document into a multitude of languages holds the risk of exploding costs if certain issues are not addressed during project preparation.
These tasks demand considerable know-how regarding management and process workflow.
East European and Asian languages cannot be processed with West European character sets. Often these languages demand additional considerations so that the translations correspond with the respective country's customs. Thus applications that are not fully Unicode enabled (e.g. FrameMaker) require special process workarounds that need to be properly implemented, otherwise they can disrupt the entire translation project. To solve this specific issue itl AG has developed its One World Publishing concept, a useful process workaround description.

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:

Unresolved cross-references or other violations leading to error messages.
Manual text breaks leading to an awkward appearance of the translated version.
Text justification or line breaks via tabulators or blank spaces.
Text in graphics that cannot be edited or expanded if the translation is longer than the source.
Document layout that is CI-compatible in the source language, but has not been tested for all target languages, e.g. concerning fonts. Especially with non-Unicode applications such as FrameMaker, insufficient testing of the utilized fonts, regarding their suitability for all target languages may result in lengthy after-the-fact discussions. For example, only the brand-new FrameMaker patch from April 2006 solves a general font and presentation problem with the Polish, Slovakian and Serbian languages, and with certain diacritical characters in the Baltic languages, that previously called for rather adventuresome workarounds.
With Asian languages, aspects other than font selection may become significant, e.g. when the software application requires a Shift JIS coding instead of the supposedly future-proof Unicode. This is when all the fun stops, even with well-established translation memory systems (TMS), which like to advertise with Unicode. Occasionally these problems have to be solved without much help from the respective tool's technical support personnel, who cannot always be relied on to have grasped all the necessary product details.

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

Question 8

Troubleshoot exporting PDF using Acrobat Distiller

Accepted Answer

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.

FrameMaker 7.2 is compatible with Acrobat Distiller 7.0.
FrameMaker 7.1p116 is compatible with either Acrobat Distiller 6.0 or 7.0.
FrameMaker 7.1b023 and 7.1p114 are compatible with Acrobat Distiller 6.0.
FrameMaker 7.0p579 is compatible with Acrobat Distiller 5.0, 6.0 or 7.0.
FrameMaker 7.0p578 is compatible with either Acrobat Distiller 5.0 or 6.0.
FrameMaker 7.0p492 and 7.0p576 are compatible with Acrobat Distiller 5.0.

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:

In FrameMaker, open a document and choose File > Print.
In the Print dialog box, click Setup, select a PostScript printer (for example, the Adobe PDF printer) and then click OK.
In the Print dialog box, click Setup, select a PostScript printer (for example, the Adobe PDF printer) and then click OK.
Start Acrobat Distiller.
Choose File > Open, and choose All Files from the Files Of Type pop-up menu. Select the file you created in step 3, and then click Open.
-- If Acrobat Distiller creates a PDF file from the PostScript file, proceed to the next section, "Troubleshoot FrameMaker."
-- If Acrobat Distiller doesn't create a PDF file from the PostScript file, proceed to the next task.

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:

Windows 2000 and XP: Documents and Settings/ [user profile] /Application Data/Adobe/Acrobat/Distiller 7

For Acrobat Distiller 6.0:

Windows Me, 98, and 95: Windows/Application Data/Adobe/Acrobat/Distiller 6
Windows NT: Winnt/Profiles/ [user profile] /Application Data/Adobe/Acrobat/Distiller 6
Windows 2000 and XP: Documents and Settings/ [user profile] /Application Data/Adobe/Acrobat/Distiller 6

For Acrobat Distiller 5.0:

Windows Me, 98, and 95: Windows/Application Data/Adobe/Acrobat/Distiller 5
Windows NT: Winnt/Profiles/[user profile]/Application Data/Adobe/Acrobat/Distiller 5
Windows 2000 and XP: Documents and Settings/ [user profile] /Application Data/Adobe/Acrobat/Distiller 5.

Dépannage de l'export PDF avec Acrobat Distiller

Publication assistée par ordinateur (PAO) Foire aux questions

troubleshooting bei pdf export mit acrobat distiller?

Commentaires

Lundi:	9:00 à 23:59
Mardi:	00:00 à 1:00 9:00 à 23:59
Mercredi:	00:00 à 1:00 9:00 à 23:59
Jeudi:	00:00 à 1:00 9:00 à 23:59
Vendredi:	00:00 à 1:00 9:00 à 23:59
Samedi:	00:00 à 1:00
Dimanche:	Fermé