]> source.dussan.org Git - xmlgraphics-fop.git/commitdiff
Move some tech information from user to dev document.
authorWilliam Victor Mote <vmote@apache.org>
Sun, 6 Apr 2003 21:55:48 +0000 (21:55 +0000)
committerWilliam Victor Mote <vmote@apache.org>
Sun, 6 Apr 2003 21:55:48 +0000 (21:55 +0000)
Minor changes to the "General" section in user doc.

git-svn-id: https://svn.apache.org/repos/asf/xmlgraphics/fop/trunk@196213 13f79535-47bb-0310-9956-ffa450edef68

src/documentation/content/xdocs/design/renderers.xml
src/documentation/content/xdocs/output.xml

index 01b9e53ccdf6b268d54e5267fc57317f2847c61e..cb39060aa0edb788d83252caf84fbb1bb9dd0f71 100644 (file)
@@ -15,7 +15,7 @@
 <section>
   <title>Introduction</title>
 <p>
-A render is primarily design to convert a given area tree into the output
+A renderer is primarily designed to convert a given area tree into the output
 document format. It should be able to produce pages and fill the pages
 with the text and graphical content. Usually the output is sent to
 an output stream.
@@ -24,6 +24,16 @@ an output stream.
 Some output formats may support extra information that is not available
 from the area tree or depends on the destination of the document.
    </p>
+    <p>
+Each renderer is given an area tree to render to its output format.
+The area tree is simply a representation of the pages and the placement
+of text and graphical objects on those pages.
+    </p>
+    <p>
+The renderer will be given each page as it is ready and an output stream
+to write the data out. The renderer is responsible for managing the
+output format and associated data and flow.
+    </p>
   </section>
 
     </body>
index 0070dac03fc8d23d0a1678ec88989e3902d73bf8..4da2ac66ecc959fdb42b09e49524e21c07e77bfb 100644 (file)
@@ -5,8 +5,7 @@
 <!-- Output Formats: Renderers -->
 <document>
     <header>
-        <title>Output</title>
-        <subtitle>Notes about Output Formats: Renderers</subtitle>
+        <title>FOP Output Options</title>
         <authors>
             <person name="Keiron Liddle" email="keiron@aftexsw.com"/>
             <person name="Art Welch" email=""/>
     </header>
 
     <body>
-<section>
-  <title>Output Formats</title>
     <p>
-FOP supports a number of different output formats. This is achieved by
-using different renderers that create the output.
+FOP supports multiple output formats by using a different renderer for each format.
+The renderers do not all have the same set of capabilities, sometimes because of the output format itself, sometimes because some renderers get more development attention than others.
     </p>
+<section id="general">
+  <title>General Information</title>
+  <section id="general-fonts">
+    <title>Fonts</title>
     <p>
-Here we will explain some information for uses to be able to understand
-what the renderers are doing and what difference there may be between
-different renderers.
+Most FOP renderers use a FOP-specific system for font registration.
+However, the AWT and print renderers use the java awt package, which gets its font information from the operating system registration.
+This can result in several differences, including actually using different fonts, and having different font metrics for the same font.
+The net effect is that the layout of a given FO document can be quite different between renderers that do not use the same font information.
     </p>
-<section>
-  <title>Common Information</title>
-    <p>
-Each renderer is given an area tree to render to its output format.
-The area tree is simply a representation of the pages and the placement
-of text and graphical objects on those pages.
-    </p>
-    <p>
-The renderer will be given each page as it is ready and an output stream
-to write the data out. The renderer is responsible for managing the
-output format and associated data and flow.
-    </p>
-    <p>
-Fonts and Layout - some formats (eg. PDF and AWT) rely on different
-font information. The fonts for these outputs have different sizes
-for the same point size. This means that the layout can be quite
-different for the same FO document.
-    </p>
-    <p>
-DPI - This is an important issue when creating output for printing.
+  </section>
+  <section>
+    <title>Graphics Resolution</title>
+      <p>
+This is an important issue when creating output for printing.
 The dpi is used to convert measurements into points. For example 1in
 = 2.54cm = 72 points. It is also used when determining the size of
 images and the rendering of certain graphics in the output. Currently
 FOP uses a value of 72dpi.
     </p>
+  </section>
+  <section>
+    <title>Output to a Printer or Other Device</title>
+        <p>
+The most obvious way to print your document is to use the FOP <link href="">print renderer</link>, which uses the Java API (AWT).
+However, you can also send output from the Postscript renderer directly to a Postscript device, or output from the PCL renderer directly to a PCL device.
+    </p>
     <p>
-You may want to send your output directly to a printer. The print
-renderer can use the Java API to print the document. You might also be
-able to send the output stream directly to a printer. If your printer
-supports postscript you could send the postscript to the printer. If
-you have a printer that supports PCL you could stream the PCL document
-to your printer.
-On Windows, you can use:
+Here are Windows command-line examples for Postscript and PCL:
     </p>
-<source><![CDATA[fop ... -ps \\computername\printer or fop ... -pcl \\computername\printer]]></source>
+    <source><![CDATA[fop ... -ps \\computername\printer]]></source>
+    <source><![CDATA[fop ... -pcl \\computername\printer]]></source>
     <p>
-On UNIX:
+Here is some Java code to accomplish the task in UNIX:
     </p>
 <source><![CDATA[proc = Runtime.getRuntime().exec("lp -d" + print_queue + " -o -dp -");
 out = proc.getOutputStream();]]></source>
@@ -69,8 +58,9 @@ out = proc.getOutputStream();]]></source>
 Set the OutputStream (out) to the PCLRenderer and it happily sends the
 PCL to the UNIX printer queue.
     </p>
+  </section>
 </section>
-<section>
+<section id="pdf">
   <title>PDF</title>
     <p>
 PDF is the best supported output format. It is also the most accurate
@@ -95,7 +85,7 @@ guaranteed to be available in all PDF viewer applications."</em>
     </p>
     <p>Note that FOP does not currently support "tagged pdf".</p>
 </section>
-<section>
+<section id="pcl">
   <title>PCL</title>
     <p>
 This format is for the Hewlett-Packard PCL printers.
@@ -109,7 +99,7 @@ in the "HP PCL 5 Printer Language Technical Reference Manual" (copyright 1990).
 This should allow any device fully supporting PCL 5 to be able to
 print the output generated by the PCLRenderer.
     </p>
-    <section>
+    <section id="pcl-limitations">
       <title>Limitations</title>
       <ul>
         <li>Text or graphics outside the left or top of the printable area are not rendered properly. In general things that should print to the left of the printable area are shifted to the right so that they start at the left edge of the printable area and an error message is generated.</li>
@@ -125,7 +115,7 @@ print the output generated by the PCLRenderer.
       </ul>
     </section>
 
-    <section>
+    <section id="pcl-additional">
       <title>Additional Features</title>
       <p>There are some special features that are controlled by some public variables on the PCLRenderer class.</p>
 
@@ -146,7 +136,7 @@ print the output generated by the PCLRenderer.
       </dl>
     </section>
 </section>
-<section>
+<section id="ps">
   <title>PostScript</title>
     <p>
 The PostScript renderer is still in its early stages and therefore still
@@ -155,7 +145,7 @@ Images and SVG are not fully supported, yet. Currently, the PostScript
 renderer generates PostScript Level 3 with most DSC comments. Actually,
 the only Level 3 feature used is FlateDecode, everthing else is Level 2.
     </p>
-    <section>
+    <section id="ps-limitations">
       <title>Limitations</title>
       <ul>
         <li>Images and SVG may not be display correctly. SVG support is far from being complete. No image transparency is available.</li>
@@ -167,7 +157,7 @@ the only Level 3 feature used is FlateDecode, everthing else is Level 2.
       </ul>
     </section>
 </section>
-<section>
+<section id="rtf">
   <title>RTF</title>
     <p>
 This is currently not integrated with FOP but it will soon.
@@ -176,7 +166,7 @@ attempt to contain as much information from the fo document as
 possible.
     </p>
 </section>
-<section>
+<section id="svg">
   <title>SVG</title>
     <p>
 This format creates an SVG document that has links between the pages.
@@ -189,7 +179,7 @@ same way as the AWT viewer, if the svg is view where the fonts are
 different, such as another platform, then the page will appear wrong.
     </p>
 </section>
-<section>
+<section id="xml">
   <title>XML</title>
     <p>
 This is for testing and verification. The XML created is simply
@@ -197,14 +187,14 @@ a representation of the internal area tree put into XML. It does
 not perform any other purpose.
     </p>
 </section>
-<section>
+<section id="print">
   <title>Print</title>
     <p>
 It is possible to directly print the document from the command line.
 This is done with the same code that renders to the AWT renderer.
     </p>
 </section>
-<section>
+<section id="awt">
   <title>AWT</title>
     <p>
 The AWT viewer shows a window with the pages displayed inside a
@@ -213,14 +203,14 @@ The fonts used for the formatting and viewing depend on the fonts
 available to your JRE.
     </p>
 </section>
-<section>
+<section id="mif">
   <title>MIF</title>
     <p>
 This format is the Maker Interchange Format which is used by
 Adobe Framemaker. This is currently not fully implemented.
     </p>
 </section>
-<section>
+<section id="txt">
   <title>TXT</title>
     <p>
 Text as you could imagine does not work very well. It is an output format
@@ -246,7 +236,6 @@ than text, so text will overwrite any graphic element representations.
     </p>
 </section>
 
-</section>
     </body>
 </document>