From 782d185c9ae72fb9caa5eded634470dc2faa647f Mon Sep 17 00:00:00 2001 From: William Victor Mote Date: Sun, 6 Apr 2003 21:55:48 +0000 Subject: [PATCH] Move some tech information from user to dev document. 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 --- .../content/xdocs/design/renderers.xml | 12 ++- src/documentation/content/xdocs/output.xml | 93 ++++++++----------- 2 files changed, 52 insertions(+), 53 deletions(-) diff --git a/src/documentation/content/xdocs/design/renderers.xml b/src/documentation/content/xdocs/design/renderers.xml index 01b9e53cc..cb39060aa 100644 --- a/src/documentation/content/xdocs/design/renderers.xml +++ b/src/documentation/content/xdocs/design/renderers.xml @@ -15,7 +15,7 @@
Introduction

-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.

+

+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. +

+

+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. +

diff --git a/src/documentation/content/xdocs/output.xml b/src/documentation/content/xdocs/output.xml index 0070dac03..4da2ac66e 100644 --- a/src/documentation/content/xdocs/output.xml +++ b/src/documentation/content/xdocs/output.xml @@ -5,8 +5,7 @@
- Output - Notes about Output Formats: Renderers + FOP Output Options @@ -14,54 +13,44 @@
-
- Output Formats

-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.

+
+ General Information +
+ Fonts

-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.

-
- Common Information -

-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. -

-

-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. -

-

-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. -

-

-DPI - This is an important issue when creating output for printing. +

+
+ Graphics Resolution +

+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.

+
+
+ Output to a Printer or Other Device +

+The most obvious way to print your document is to use the FOP print renderer, 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. +

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

- + +

-On UNIX: +Here is some Java code to accomplish the task in UNIX:

@@ -69,8 +58,9 @@ out = proc.getOutputStream();]]> Set the OutputStream (out) to the PCLRenderer and it happily sends the PCL to the UNIX printer queue.

+
-
+
PDF

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."

Note that FOP does not currently support "tagged pdf".

-
+
PCL

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.

-
+
Limitations
  • 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.
  • @@ -125,7 +115,7 @@ print the output generated by the PCLRenderer.
-
+
Additional Features

There are some special features that are controlled by some public variables on the PCLRenderer class.

@@ -146,7 +136,7 @@ print the output generated by the PCLRenderer.
-
+
PostScript

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.

-
+
Limitations
  • Images and SVG may not be display correctly. SVG support is far from being complete. No image transparency is available.
  • @@ -167,7 +157,7 @@ the only Level 3 feature used is FlateDecode, everthing else is Level 2.
-
+
RTF

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.

-
+
SVG

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.

-
+
XML

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.

-
+
Print

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.

-
+
AWT

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.

-
+
MIF

This format is the Maker Interchange Format which is used by Adobe Framemaker. This is currently not fully implemented.

-
+
TXT

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.

-
-- 2.39.5