You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-commits@xmlgraphics.apache.org by vm...@apache.org on 2003/04/06 23:55:48 UTC
cvs commit: xml-fop/src/documentation/content/xdocs/design renderers.xml
vmote 2003/04/06 14:55:48
Modified: src/documentation/content/xdocs output.xml
src/documentation/content/xdocs/design renderers.xml
Log:
Move some tech information from user to dev document.
Minor changes to the "General" section in user doc.
Revision Changes Path
1.7 +43 -54 xml-fop/src/documentation/content/xdocs/output.xml
Index: output.xml
===================================================================
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/output.xml,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -r1.6 -r1.7
--- output.xml 27 Mar 2003 18:38:55 -0000 1.6
+++ output.xml 6 Apr 2003 21:55:48 -0000 1.7
@@ -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=""/>
@@ -14,54 +13,44 @@
</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>
- <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.
- </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 id="general">
+ <title>General Information</title>
+ <section id="general-fonts">
+ <title>Fonts</title>
+ <p>
+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>
+ <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 @@
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 @@
</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 @@
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 @@
</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 @@
</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 @@
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 @@
</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 @@
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 @@
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 @@
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 @@
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 @@
</p>
</section>
-</section>
</body>
</document>
1.3 +11 -1 xml-fop/src/documentation/content/xdocs/design/renderers.xml
Index: renderers.xml
===================================================================
RCS file: /home/cvs/xml-fop/src/documentation/content/xdocs/design/renderers.xml,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- renderers.xml 19 Nov 2002 07:57:28 -0000 1.2
+++ renderers.xml 6 Apr 2003 21:55:48 -0000 1.3
@@ -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 @@
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>
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-cvs-unsubscribe@xml.apache.org
For additional commands, e-mail: fop-cvs-help@xml.apache.org