Subversion Repositories Scribus

Compare Revisions

Ignore whitespace Rev 3772 → Rev 3813

/trunk/Scribus/scribus/doc/en/importhints.html
1,8 → 1,7
<qt>
<title>Notes on Importing Issues with Scribus</title>
<h2>Notes on Importing Issues with Scribus</h2>
<p>Although Scribus imports most common DTP image formats like TIFF and EPS, over time one of the more difficult tasks in DTP is getting stuff into your layout. Unlike some other DTP programs where printing can be finicky, Scribus print and PDF export has always been very reliable. I can think of
a handful of times when I had crashes or could not get the desired print or PDF from Scribus. With correctly prepared images and files, the output from Scribus matches proprietary layout programs.</p>
<p>Although Scribus imports most common DTP image formats like TIFF and EPS, over time one of the more difficult tasks in DTP is getting stuff <strong>into</strong> your layout. Unlike some other DTP programs where printing can be finicky, Scribus print and PDF export has always been very reliable. I can think of a handful of times when I had crashes or could not get the desired print or PDF from Scribus. With correctly prepared images and files, the output from Scribus matches proprietary layout programs.</p>
<p>In my experience, the key to this are using the right format for the right type of image. Whenever possible, import your images as vector via SVG, EPS or PDF. The other is I am <strong>really</strong> picky about fonts. You will see this noted through the docs; when you are working with high-end DTP tools like Scribus, font quality matters. In professional DTP, it matters <strong>a lot</strong>. Probably the number one reason postscript output fails, whether to a printer or PDF export, is a dodgy or corrupted font.</p>
 
<h3>TIFF, JPEG, PNG what is the difference?</h3>
27,8 → 26,8
<p>There are more than fifty different flavors of TIFF. Not every image editor saves them with the same fidelity to the standards. GIMP through its use of libtiff, shared with Scribus, does a fine job of supporting Tiffs. The way I work with files from GIMP is to save the original file in the native GIMP xcf format and then, once edited to your satisfaction, re-save as a tiff or with screen shots meant for the web, PNG.</p>
<p>Now the exception to that rule is PNG, especially for application screen shots. PNG has a lot of advanced features, like ICC color support and real alpha transparency, which are often not supported well by some applications (a certain leading browser comes to mind). PNG also compresses very well. The only time I prefer Jpeg to PNG is for photos with high dynamic range, mostly for reasons of size on a web page. For creating PDFs with screen shots, PNG is superb and will print well, as long as you do not make any scaling adjustments which reduce the image size. So if you have a screen shot which is typically at 72-96dpi, but you need to shrink it, do so by scaling the image in the GIMP or within Scribus. Whenever you are scaling screen shots disable re-sampling in any image editor. With screen-shots you should never reduce the number of pixels or you will lose sharpness quickly.</p>
 
<h3>If it looks bad on screen, it will print terribly</h3>
<p>EPS files or Encapsulated PostScript files. EPS files natively have no screen preview at all. EPS files are really a special subset of postscript instructions. They typically look just plain awful on screen if they have a TIFF or PICT preview embedded or are just a simple gray box. EPS have two important virtues: They print well to both high resolution printers or when creating PDFs. EPS files can be resolution independent and are the only file you can (sometimes) safely scale larger than 100% than its native size without degrading image sharpness.</p>
<h3>If it looks bad on screen, it will print terribly..</h3>
<p>EPS files or Encapsulated PostScript files. EPS files natively have no screen preview at all. EPS files are really a special subset of postscript instructions. They typically look just plain awful on screen if they have a TIFF or PICT preview embedded or are just a simple gray box. EPS have two important virtues: They print well to both high resolution printers or when creating PDFs. EPS files can be resolution independent and along with SVG are the only types of files you can (sometimes) safely scale larger than 100% than its native size without degrading image sharpness.</p>
<p>The one issue you might find with EPS files is while a lot of applications can generate EPS files, not all do so with the same fidelity to high-quality printing, nor do all apps follow the EPS specs properly. One way to test an EPS for use with Scribus, is to open the EPS in GSview and look in the message box, by pressing Shift M. This will show the output messages from Ghostscript. Ghostscript is correctly quite fussy about EPS files. So, if you are trying to import EPS files and they do not work properly in Scribus and GSview/Ghostscript is spitting lots of error messages, try using a different application to generate them.</p>
<p>One reason for the ubiquity of EPS files in DTP is there is another DTP application which historically had poor support for TIFF and other bitmap image files, but does have good support for EPS import. So, many DTP users habitually create EPS files from bitmap images from Photoshop or others. Unfortunately, this can have the side effect of receiving image files which may need adjustment, but without the original image file - impossible. EPS is ideal for receiving vector artwork like maps, mixed with text. The caveat is the fonts should be embedded in the EPS properly
to print properly from Scribus.</p>
/trunk/Scribus/scribus/doc/en/importhints3.html
4,7 → 4,7
<h4>Overview</h4>
<p>The open and XML based file format used by OpenOffice.org in all versions, share some common traits with Scribus. The clear documentation and specs have helped the Scribus Team to create very useful import features. Expect more enhancements in the future. One of the pleasant surprises to see in the OpenOffice.org version 2 beta releases is the improved EPS exporter. The 1.1.x version sometimes had difficulties exporting correctly. The exporter in V 2.x in testing here seems to create better, more conformant files, which Scribus imports with little difficulties. Except for OpenOffice.org Writer files, the magic trick to get high quality imports into Scribus depends on using OO.org Draw. Almost any type of OpenOffice.org file can be imported into Scribus with high fidelity, provided you export from Draw as EPS. Native Draw files can usually be imported directly into Scribus. </p>
<h4>Importing from OpenOffice.org Writer</h4>
<p>The importer for Writer imports <strong>only</strong> the text contained in your document. Images and drawing need to be saved separately outside of the Writer document and imported separately.</p>
<p>The importer for Writer imports <strong>only</strong> the text contained in your document. Images and drawing need to be saved separately outside of the Writer document and imported separately. Thus, a compound Writer document with tables of charts will not import the tables or charts. Tables, charts or other embedded objects, need to be separately placed in a Draw file and exported by the methods below.</p>
<p>The singular most important issue to take into consideration for hassle free OO.org Writer import is well chosen usage and correctly applying styles in OO.org. Doing so will greatly reduce the amount of time needed within Scribus to format and style text. Any special paragraph styles in your Writer document will automatically be imported into your existing Scribus layout.</p>
<h4>Step by Step:</h4>
<ul>
13,7 → 13,7
<li>Select your OO.org document. The importer is smart enough to know recognize the type of OO.org file.</li>
</ul>
 
<p>This will import <strong>all</strong> the text in your document, so ensure there is enough space in your frames or link extra text frames on subsequent pages. You can comfortably import 10,20 or 50 pages of text in one go. In testing the importer we have imported 600 pages. However, the practical limit is probably not more than a chapter's (15-30 pages) worth of text for performance reasons.</p>
<p>This will import <strong>all</strong> the text in your document, so ensure there is enough space in your frames or link extra text frames on subsequent pages. You can comfortably import 10,20 or 50 pages of text in one go. In testing the importer, we have imported 600 pages. However, the practical limit is probably not more than a chapter's (15-30 pages) worth of text for performance reasons.</p>
 
<p> When importing text from OO.org there are three important options which need to be carefully considered:</p>
 
28,7 → 28,7
 
 
<h4>Importing Charts and Tables from Calc </h4>
<p>This is a special case, which needs to be done carefully. After you have created your Chart or Table in Calc, then <strong>Copy > Paste Special </strong> and embed the chart <strong>not</strong> as a GDI image, but as a linked object into a Draw Document, like below:</p>
<p>This is a special case which needs to be done carefully. After you have created your Chart or Table in Calc, then <strong>Copy > Paste Special </strong> and embed the chart <strong>not</strong> as a GDI image, but as a linked object into a Draw Document, like below:</p>
 
<table width="100%"><tr><td align="center"><img src="images/oochart.png" alt="Embedding a Chart in to OO.org Draw" align="middle" title="Embedding a Chart in to OO.org Draw" /></td></tr></table>
 
35,13 → 35,13
<p>After placing the linked object, import using one of the two methods below.</p>
 
<h4>Importing Native OO.org Draw Files</h4>
<p>There are two methods: First is to use the native importer. For most drawings this works very well and I have tested very complex Draw files which imported flawlessly. In some cases, especially with gradients, it may be preferable to test exporting EPS, with the settings further down. You should test both for best quality not only on screen, but exporting a PDF and then zooming is a good quality check. It is important to note Draw 3D objects do not export well, as they are limited to screen resolution. They do not print well in most cases and will appear pixellated at print resolutions. </p>
<p>There are two methods: First is to use the native importer. For most drawings this works very well and I have tested very complex Draw files which imported flawlessly. In some cases, especially with gradients, it may be preferable to test exporting EPS, with the settings further down. You should test both methods for the best results, not only on screen, but exporting a PDF. Then open the PDF in Adobe Acrobat Reader and zooming in is a good quality check. It is important to note Draw 3D objects do not export well, as they are limited to screen resolution. They do not print well in most cases and will appear pixellated at print resolutions. </p>
 
<h4>Importing Formulas</h4>
<p>The most reliable way I have found is to save your formula as desired and Close Math. Then open OO.org Draw and create a new file. Then, <strong>Insert Object > Formula</strong>. You will have a tiny embedded square on Draw's canvas. Then, right click the embedded object > <strong>Edit Object</strong>. Then, Draw will launch Math. In Math, select <strong>Tools > Import Formula</strong> and browse to your saved formula. Then save to close the file and the embedded formula is now scalable in Draw with the context menus. Save this Draw file, then export as EPS and import into Scribus. The formulas and text will import as a grouped objects as scalable vector items. Any text is imported as outlines as well. This will result in formulas which will print with <strong>very</strong> high quality and little worries when exported as PDF. Saving the Draw file and attempting to import the Draw file with embedded objects will fail, as Scribus cannot access those object directly.</p>
<h4>Export Settings from OO.org Draw</h4>
<p>Below are the recommended EPS export settings for all versions of OO.org Draw.</p>
<p>Below are the recommended settings when exporting from all versions of OO.org Draw.</p>
<table width="100%"><tr><td align="center"><img src="images/ooeps1.png" alt="Recommended EPS Export Settings" align="middle" title="Recommended EPS Export Settings" /></td></tr></table>
 
<p>Using the settings above and a recent Ghostscript (8.50+), I have encountered only minor difficulties importing files from OpenOffice.org. Even then, ungrouping the import and minor touching up is easily done. The most noticeable issue I have found is some lines on charts or freehand lines are too thin when viewed as imported EPS in Scribus and a quick adjustment of the size of the line with the Properties Palette sets things right.</p>
<p>Using the settings above and a recent Ghostscript (8.50+), I have encountered only minor difficulties importing files from OpenOffice.org. Even then, ungrouping the import and minor touching up is easily done. The most noticeable issue I have found is some lines on charts or freehand lines are too thin when viewed as imported EPS in Scribus and a quick adjustment of the size of the line with the Properties Palette in Scribus sets things right.</p>
</qt>