/usr/share/scribus/doc/de/print1.html is in scribus-doc 1.4.6-2.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | <html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>Printing with Scribus</title>
</head>
<body>
<h2>Printing with Scribus</h2>
<p>One of the issues in connection with an advanced DTP application like Scribus, is one of semantics, as “printing” or “printer” can mean different things. A “printer” can be either a device or a printing company, which will, of course, also use devices, but these are quite different from the one on your desktop. Moreover, a “printer” can also be a human being, i.e., someone whose profession is printing. Unfortunately, things are even more complicated, since not all printing devices are equal, and neither are professional printing companies. Nevertheless, to make things at least a bit clearer we will from now on refer to printing via your desktop device as “local printing”, whereas for print jobs at a printing company or a high-end printing machine the term “commercial printing” will be applied.</p>
<h3>Local Printing – Some Background Information</h3>
<h4>General</h4>
<p>As odd as it may seem at first glance, the DTP program Scribus, whose main purpose it is to create documents which will be printed, may not work at all directly with the noisy device sitting on your desktop, even though the program seems to detect the printer just fine via the system settings. This is a known issue, but while the developers are aware of it, resolving the problem is very complicated, and, more importantly, there are easy workarounds.</p>
<p>Why, you will probably ask, is direct printing from within Scribus such a problem? Other applications print just fine on any of the many platforms supported by Scribus. The short answer is that Scribus’s print output (i.e., the data being transferred to a printing device) expects a high-end PostScript printer. Such a machine can be (and most likely is) quite expensive. Most consumer devices (or their device drivers) simply can’t handle the PostScript instructions created by Scribus.</p>
<p>For those with a technical background, as well as some knowledge of the more recent computer history, there’s another reason for potential issues: A few decades ago, when affordable printing devices were hardly more than externally driven typewriters, a startup company called Adobe, which would later become one of the giants in the software industry, introduced the page description language <a href="importhints1.html">PostScript</a>, which became an integral part of the “Desktop Publishing Revolution”. With PostScript and PostScript-enabled printing devices available, it became possible to print attractive layouts on a “desktop” device – although early PostScript printers were so expensive that only a tiny percentage of desktops ever had the honor of hosting such a device. Among the reasons that drove up the costs for PostScript printers were the licensing costs of the PostScript language itself, as well as a basic set of PostScript fonts, since both were required to build a “real” PostScript printer. Another reason was related to printing hardware. This is where Microsoft stepped in and provided hardware vendors an offer they were unable to refuse: Microsoft introduced the so-called Graphical Device Interface (GDI), which made PostScript largely obsolete (at least for desktop printers), as it provided significantly less (but in most cases sufficient) features, and also moved some of the necessary data processing from the printing device (hardware) to the operating system (software), which was, of course, Windows. The opportunity to save a few cents per device led manufacturers to create cheap desktop printers that would only work with the Windows operating system. It took the developers of other operating systems years to provide a bridge between “GDI” devices and their own printing system, which is based on PostScript (e.g., Mac OS X, Linux, *BSD, UNIX), but not all GDI printers are fully supported by PostScript-based printing systems (which means pretty much every system that’s not called Windows). Today, many vendors offer drivers for their printers for Mac OS X and Linux, or they provide enough information for developers to let them write working printer drivers.</p>
<p>While the previous excursion may help to understand why direct printing from within Scribus may not work, it is not a sufficient explanation. Since the output of Scribus is supposed to be printed on a “real” (read: high-end) PostScript printer, it may fail with many other devices. Readers with some background knowledge of the UNIX printing standard (CUPS – Common UNIX Printing System, used by Mac OS X, Linux, *BSD, and others), will probably ask how that can be, but the answer is that Scribus creates high-level PostScript output, whose instructions sometimes cannot be processed by the respective PostScript interpreters or printer drivers.</p>
<p>This all sounds rather scary, but it’s fairly likely you will be able to directly print to your local printer. A properly configured printer with Windows will likely print without any problems. In Linux, it may work fine, or simply require an alternative print command. It’s probably at least worth a try.</p>
<h4>How to Print Reliably on Your Local Printer</h4>
<p>The most reliable way to print your Scribus document with your local printer is to export the Scribus file to PDF and then print from <a href="toolbox1.html">Adobe Reader</a>. While AR has received some well-deserved criticism in terms of security issues, it is still the most reliable PDF viewer and works flawlessly with the printing subsystems of every modern operating system.</p>
</body>
</html>
|