faq/output.html - gerrit/www.eclipse.org/birt - Git at Google

 <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 transitional//EN">
 <html>

 <head>
 <title>BIRT FAQ</title>
 <link rel="stylesheet" href="../style/compose.css" type="text/css"/>
 <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
 </head>

 <body>

 <p class="head">BIRT FAQ</p>
 <p class="subhead">Installation &amp; Compatibility</p>

 <h1>Output Formats</h1>

 <h2>Q: What report output formats does BIRT support?</div> </h2>
 <p>
 Release 1.0 supports HTML output as a single HTML page. It also supports
 paginated output using XML-FO via the Apache FOP project.
 </div>

 <h1>Unix Printing</h1>

 <h2>Q: Does BIRT support printing on UNIX on non-postscript printers?</div> </h2>
 <p>
 The first release of BIRT will only support printing in PDF format.
 However, postscript printing on Unix could be added in the future.
 <p>
 Our current thought is that almost all major printers support postscript
 or PDF. Even if a printer is claimed to be a PCL printer, the vendor often
 provides a downloadable postscript driver file. If a postscript printing
 system is to be implemented for BIRT, the postscript file will likely be
 generated in the following way:

 <ol>
 <li>The printer driver is parsed and
 printer specific commands (i.e., printer escapes) are generated for
 printer-specific features, such as collation, paper tray, landscape vs.
 portrait, etc.
 <li>Report contents, which are usually drawn in a
 printer-independent way, are generated as printer-independent postscript.
 </ol>
 <p>BIRT is designed to allow seamless extensions. So your formatting and
 protocol modules can be designed as plugins.

 <h1>PDF Output</h1>

 <h2>Q: BIRT uses XML-FO for output. Apache FOP has known performance
 and feature limitations. How does BIRT address these issues?</div> </h2>
 <p>
 A user reported that he'd taken a look at Apache's FOP.  The performance
 was poor for a reasonable sized document.  Also, there
 were concerns about the memory usage while processing these documents
 and whether that would lead to any scalability problems during rendering.
 <p>
 Using FOP for the first release allows us to
 focus on other areas of report generation and rendering. At the same time,
 performance is a key goal. We're running tests to get a good sense of the
 actual issues. XSL:FO is a convenient way to handle conversion and be
 standards-compliant -- if it works. As a result, we intend to generate FO
 that follows CSS standard. However, since FOP does not support many
 features for now, we also allow generation FO that contains some
 workarounds so that the FOP output makes more sense.
 <p>
 The Engine is designed to allow extended converters, so we/others can plug
 in a better converter easily if/when needed.
 <p>
 In the first release, reports are on demand and in a single web page, so
 are expected to be small. In a subsequent release, reports will be stored
 on disk and can be any size. That will be an excellent time to determine
 if we need to reconsider our conversion strategy. One approach is to
 directly go from report design to PDF, as someone already suggested in the
 newsgroup.

 <h1>Non-Latin Characters</h1>

 <h2>Q: I've used Chinese characters in my design, but they don't appear in
 PDF. What do I do?</div> </h2>
 <p>
 BIRT uses
 <a href="http://xml.apache.org/fop/">Apache FOP</a> to generate PDF output,
 so you can consult with FOP
 documents for using Chinese characters. Using Chinese characters in FOP
 needs some customization, such as:

 <ul>
 <li>Create a font metrix file for the font types you used
 <li>Define the font used by FOP
 <li>Embedded the font into PDF
 </ul>

 <p>Font configurations are described in FOP FAQ,
 <ul>
 <li>http://xml.apache.org/fop/faq.html#pdf-characters-menu
 <li>http://xml.apache.org/fop/fonts.html
 <li>http://xml.apache.org/fop/configuration.html
 </ul>
 <p>We might integrate FOP configurations into BIRT configuration. But before
 that is done, you may have to customize FOP by yourself.

 </body>
 </html>
	<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 transitional//EN">
	<html>

	<head>
	<title>BIRT FAQ</title>
	<link rel="stylesheet" href="../style/compose.css" type="text/css"/>
	<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
	</head>

	<body>

	<p class="head">BIRT FAQ</p>
	<p class="subhead">Installation & Compatibility</p>

	<h1>Output Formats</h1>

	<h2>Q: What report output formats does BIRT support?</div> </h2>
	<p>
	Release 1.0 supports HTML output as a single HTML page. It also supports
	paginated output using XML-FO via the Apache FOP project.
	</div>

	<h1>Unix Printing</h1>

	<h2>Q: Does BIRT support printing on UNIX on non-postscript printers?</div> </h2>
	<p>
	The first release of BIRT will only support printing in PDF format.
	However, postscript printing on Unix could be added in the future.
	<p>
	Our current thought is that almost all major printers support postscript
	or PDF. Even if a printer is claimed to be a PCL printer, the vendor often
	provides a downloadable postscript driver file. If a postscript printing
	system is to be implemented for BIRT, the postscript file will likely be
	generated in the following way:

	<ol>
	<li>The printer driver is parsed and
	printer specific commands (i.e., printer escapes) are generated for
	printer-specific features, such as collation, paper tray, landscape vs.
	portrait, etc.
	<li>Report contents, which are usually drawn in a
	printer-independent way, are generated as printer-independent postscript.
	</ol>
	<p>BIRT is designed to allow seamless extensions. So your formatting and
	protocol modules can be designed as plugins.

	<h1>PDF Output</h1>

	<h2>Q: BIRT uses XML-FO for output. Apache FOP has known performance
	and feature limitations. How does BIRT address these issues?</div> </h2>
	<p>
	A user reported that he'd taken a look at Apache's FOP. The performance
	was poor for a reasonable sized document. Also, there
	were concerns about the memory usage while processing these documents
	and whether that would lead to any scalability problems during rendering.
	<p>
	Using FOP for the first release allows us to
	focus on other areas of report generation and rendering. At the same time,
	performance is a key goal. We're running tests to get a good sense of the
	actual issues. XSL:FO is a convenient way to handle conversion and be
	standards-compliant -- if it works. As a result, we intend to generate FO
	that follows CSS standard. However, since FOP does not support many
	features for now, we also allow generation FO that contains some
	workarounds so that the FOP output makes more sense.
	<p>
	The Engine is designed to allow extended converters, so we/others can plug
	in a better converter easily if/when needed.
	<p>
	In the first release, reports are on demand and in a single web page, so
	are expected to be small. In a subsequent release, reports will be stored
	on disk and can be any size. That will be an excellent time to determine
	if we need to reconsider our conversion strategy. One approach is to
	directly go from report design to PDF, as someone already suggested in the
	newsgroup.

	<h1>Non-Latin Characters</h1>

	<h2>Q: I've used Chinese characters in my design, but they don't appear in
	PDF. What do I do?</div> </h2>
	<p>
	BIRT uses
	<a href="http://xml.apache.org/fop/">Apache FOP</a> to generate PDF output,
	so you can consult with FOP
	documents for using Chinese characters. Using Chinese characters in FOP
	needs some customization, such as:

	<ul>
	<li>Create a font metrix file for the font types you used
	<li>Define the font used by FOP
	<li>Embedded the font into PDF
	</ul>

	<p>Font configurations are described in FOP FAQ,
	<ul>
	<li>http://xml.apache.org/fop/faq.html#pdf-characters-menu
	<li>http://xml.apache.org/fop/fonts.html
	<li>http://xml.apache.org/fop/configuration.html
	</ul>
	<p>We might integrate FOP configurations into BIRT configuration. But before
	that is done, you may have to customize FOP by yourself.

	</body>
	</html>