free pdf viewer c# : Export highlighted text from pdf to word application SDK tool html winforms .net online JasperReports-Ultimate-Guide-329-part1358

T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
E
XTENSIONS
S
UPPORT
The JasperReports functionality can be extended in various ways, but is usually done by 
implementing public interfaces that the library already exposes.
The best example is with report data sources. Report data sources are instances of the 
JRDataSource
interface. In cases where reporting data is available in a custom format 
which is not understood by the built-in data source implementations that the 
JasperReports library comes with, the parent application needs to implement that 
JRDataSource
and thus teach the reporting engine how to iterate through that custom 
data and how to get the values of the fields corresponding to each virtual record in that 
virtual data table. By implementing the data source interface that JasperReports exposes, 
the parent application as thus extended the library's functionality.
This is the case with other public interfaces that the library exposes, including, but not 
limited to custom components, query executers, hyperlink producers, chart themes, font 
bundles, etc.
In order to simplify the way JasperReports can be extended and the way those extensions 
are deployed, or made available to a given JasperReports deployment, built-in support 
for extensions was introduced in the library and then various features of the library 
where made extension-friendly and thus transformed into extension points.
Simply put, what the extension support of JasperReports does, is to allow people to 
implement the various interfaces that the library exposes through predefined extension 
points and to put together all those implementation classes in single JAR, which can be 
then added to the classpath of the application where JasperReports runs, making them all 
available to that JasperReports running instance. The only requirement for the 
construction of the JAR file is the presence of a 
jasperreports_extension.properties
file in its root package. This properties file 
is used for describing the content of the JAR.
Basically, at runtime, the JasperReports engine will read this file and try to understand 
what extensions where provided within the JAR, making them available to all interested 
extension points.
E
XTENSION
R
EGISTRY
JasperReports looks for available extensions by loading all the 
jasperreports_extension.properties
files that it can find in the default package. 
Note that many such files can be found, because although they are all having the same 
name and being in the default Java package, they can actually sit in different JAR files 
that are present in the application's classpath.
This special properties file should contain properties in the following format:
net.sf.jasperreports.extension.registry.factory.<registry_id>=<exte
nsion_registry_factory_class>
P
AGE
279
Export highlighted text from pdf to word - extract text content from PDF file in C#.net, ASP.NET, MVC, Ajax, WinForms, WPF
Feel Free to Extract Text from PDF Page, Page Region or the Whole PDF File
copy and paste pdf text; copy text from pdf to word with formatting
Export highlighted text from pdf to word - VB.NET PDF Text Extract Library: extract text content from PDF file in vb.net, ASP.NET, MVC, Ajax, WinForms, WPF
How to Extract Text from PDF with VB.NET Sample Codes in .NET Application
.net extract pdf text; delete text from pdf preview
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
Each such property gives the name of an extension registry factory class and also names 
the extension registry (through the property's suffix). Some extension registry factories 
make use of this suffix. For example, they could use this name of the extension registry 
to look for other properties in the same file, properties that would help configure the 
extension registry factory itself.
The extension registry factory should be an implementation of the 
net.sf.jasperreports.engine.extensions.ExtensionsRegistryFactory 
interface. It produces instances of the 
net.sf.jasperreports.engine.extensions.ExtensionsRegistry
interface, 
based on the 
registry_id
value (the suffix mentioned above) and the properties read 
from the current 
jasperreports_extension.properties
file.
The signature of the single method that this factory interface exposes is as follows:
ExtensionsRegistry createRegistry(String registryId, 
JRPropertiesMap properties);
The extension registry obtained from the factory is able to return a list of actual 
extension point implementations based on extension point class type.
For example, in JasperReports, query executers can be added as extensions in the form of 
query executer bundles. The predefined query executer extension point in JasperReports 
is represented by the 
QueryExecuterFactoryBundle
interface, from which query 
executer implementation are retrieved based on the query language name. The extension 
registry implementation is expected to return a list of query executer factory bundles in 
this case.
Another example of an extension point in JasperReports are the chart themes. They are 
also expected to come in bundles, based on their name, so the associated extension point 
interface for them is the 
ChartThemeBundle
interface. In this case, the extension 
registry implementation is expected to return a list of chart theme bundle instances.
A third example of an extension point is represented by the hyperlink producers. The 
associated extension point interface is the 
JRHyperlinkProducerFactory 
interface 
and thus the extension registry implementation should return a list of those.
More details about how to make use of extension support in JasperReports are given in 
the respective chapters where specific extension points exposed by the library are 
presented.
S
PRING
E
XTENSION
R
EGISTRY
F
ACTORY
JasperReports is shipped with a convenience implementation of the 
ExtensionsRegistryFactory 
interface that can be used to load extensions from a 
Spring bean XML file.
This convenience extension registry factory implementation is the 
net.sf.jasperreports.extensions.SpringExtensionsRegistryFactory 
class 
P
AGE
280
C# PDF Text Highlight Library: add, delete, update PDF text
etc. Able to remove highlighted text in PDF document in C#.NET. Support to change PDF highlight color in Visual C# .NET class. Able
cut and paste text from pdf; extract text from pdf online
C# PDF Convert to Text SDK: Convert PDF to txt files in C#.net
in any fonts, colors and sizes, or highlighted characters are converted by our C# PDF to text converting library as, PDF to HTML converter assembly, PDF to Word
delete text from pdf with acrobat; extract text from pdf file using java
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
and works by loading a Spring beans XML file and using beans of specific types as 
extensions.
The factory requires a property named 
net.sf.jasperreports.extension.<registry_id>.spring.beans.resource
to 
be present in the properties map passed to the 
createRegistry(String, 
JRPropertiesMap)
method. The value of this property must resolve to a resource name 
which is loaded from the context class loader, and parsed as a Spring beans XML file.
Once the Spring beans XML file is loaded, this factory creates a 
net.sf.jasperreports.extensions.SpringExtensionsRegistry
instance which 
will use the bean factory.
This Spring-based extension registry factory is used by the font extensions mechanism 
described in the following section.
F
ONT
E
XTENSIONS
Among the various extension points that JasperReports exposes, there is one which 
allows users to make use of fonts that are not available to the JVM at runtime in normal 
circumstances.
Usually, in order to make a font file available to the JVM, one would need to install that 
font file into the system, or make some configuration changes in the local JVM. But if 
the application ends up being deployed on some other machine, the same font file 
installation process has to be performed on that machine as well.
When designing reports, we are immediately faced with the selection of fonts to be used 
by the various text fields present in the report template. Using fonts that are available 
only on the local JVM where we design and test our reports poses the risk of those fonts 
not being available on the system where the reports are actually generated at runtime. 
When specified fonts are missing on a system, the JVM uses some default fonts as on-
the-fly replacements and these might have totally different properties and font metrics, 
producing various side effects, including but not limited to chunks of text being cut from 
the generated output.
This why it is so important for an application to control and make sure that the fonts used 
in its reports are available at runtime on the machines on which the application is 
running.
The best way to control fonts in JasperReports is to provide the font files as extensions to 
the library. Basically, this involves putting True Type Font files in a JAR file, together 
with an XML file that describes the content of the JAR and the various relationships 
between the fonts and the locales.
JasperReports raises a JRFontNotFoundExceptions in the case where the font used inside 
a report template is not available to the JVM as either as a system font or a font coming 
from a JR font extension. This ensure that all problems caused by font metrics 
P
AGE
281
VB.NET PDF Convert to Text SDK: Convert PDF to txt files in vb.net
text can get from any fonts, colors and sizes, or highlighted characters. is the Visual Basic .NET method for converting a PDF document into a text file.
copy text from pdf; copying text from pdf into word
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
mismatches are avoided and we have an early warning about the inconsistency. 
However, for backward compatibility reasons, this font runtime validation can be turned 
off using the 
net.sf.jasperreports.awt.ignore.missing.font
configuration 
property, which can be employed either globally or at report level.
Note
We strongly encourage people to use in their reports only fonts that are provided in font extensions. 
This is the only way to be sure that the fonts will be available to the application when the reports are executed at 
runtime. Using system fonts always brings the risk that the reports do not  work properly when deployed on a 
machine that does not have those fonts installed.
The font extension point in JasperReports is exposed as the 
net.sf.jasperreports.engine.fonts.FontFamily
public interface. Each font 
family is made out of 4 font faces: normal, bold, italic and bolditalic. Only the normal 
face is required in a font family. Font faces are described by the 
net.sf.jasperreports.engine.fonts.FontFace
interface. Besides the font faces, 
a font family also supports certain locales and tells if it is able to simulate the bold style 
and the italic style in PDF export, in case the corresponding font faces are missing from 
its declaration.
JasperReports is shipped with convenience implementations for the above mentioned 
interfaces, and it is highly unlikely that someone would ever need to implement them on 
their own.
The best way to deploy font files as extensions is to rely on the Spring-based extension 
registry factory shipped with JasperReports and make use of the default font interfaces as 
shown in the following tutorial.
S
IMPLE
F
ONT
E
XTENSION
T
UTORIAL
The samples shipped with the JasperReports project distribution package under the 
/demo/samples
folder make use of two font families called 
DejaVu Sans
and 
DejaVu 
Serif
. These are open source fonts from the 
http://dejavu-fonts.org 
project and 
are made available to the samples as a font extension.
This font extension is found in the 
/demo/fonts
folder of the JasperReports project 
distribution package and consists of the following files:
jasperreports_extension.properties
This file is required by the JasperReports extension mechanism and describes the content 
of any given extension. For more details about JasperReports extensions, please consult 
the “Extensions Support” section, earlier in this chapter.
The first line in this particular properties file specifies that the built-in Spring-based 
extension registry factory is used by the current extension:
P
AGE
282
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
net.sf.jasperreports.extension.registry.factory.fonts=net.sf.jasper
reports.extensions.SpringExtensionsRegistryFactory
net.sf.jasperreports.extension.fonts.spring.beans.resource=fonts.xm
l
The second line gives the name of the Spring XML file required by this Spring-based 
extension factory, containing the Spring bean definitions. For more details about this 
extension registry factory, please read the “Extensions Support” section, as well.
fonts.xml
This Spring XML file contains the beans that are going to be loaded by the Spring-based 
extension registry factory. As mentioned earlier, the font extension point in 
JasperReports is expecting font families, so the beans in our Spring XML file are 
instances of the convenience 
net.sf.jasperreports.engine.fonts.SimpleFontFamily
implementation of the 
FontFamily
interface and introduce two font families: the 
DejaVu Sans
and the 
DejaVu Serif
.
<bean id="dejaVuSansFamily" 
class="net.sf.jasperreports.engine.fonts.SimpleFontFamily">
<property name="name" value="DejaVu Sans"/>
<property name="normal" value="DejaVuSans.ttf"/>
<property name="bold" value="DejaVuSans-Bold.ttf"/>
<property name="italic" value="DejaVuSans-Oblique.ttf"/>
<property name="boldItalic" value="DejaVuSans-BoldOblique.ttf"/>
<property name="pdfEncoding" value="Identity-H"/>
<property name="pdfEmbedded" value="true"/>
</bean>
<bean id="dejaVuSerifFamily" 
class="net.sf.jasperreports.engine.fonts.SimpleFontFamily">
<property name="name" value="DejaVu Serif"/>
<property name="normal" value="DejaVuSerif.ttf"/>
<property name="bold" value="DejaVuSerif-Bold.ttf"/>
<property name="italic" value="DejaVuSerif-Italic.ttf"/>
<property name="boldItalic" value="DejaVuSerif-BoldItalic.ttf"/>
<property name="pdfEncoding" value="Identity-H"/>
<property name="pdfEmbedded" value="true"/>
</bean>
Notice how font families are specifying a name and their different faces. The name and 
the normal face are both required, while the other properties are optional.
The name of the family is required because this is the value that gets used as the 
fontName
attribute of a text element or a style in the report template. The 
fontName 
together with the 
isBold
and 
isItalic
attributes of the text field or style in the report 
help to locate and load the appropriate font face from the family. In case a particular font 
P
AGE
283
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
face is not present or declared in the family whose name was used, then the normal font 
face is used instead and this makes the normal face mandatory in a font family.
Font files usually support only some languages and this is why the font families can 
specify the list of locales that they support. In the example above, no locale was 
specified, meaning that the 
DejaVu Sans
and the 
DejaVu Serif
families would apply 
to all locales (which is not true, but the JasperReports samples that use this font 
extension do not make use of languages that are not supported by this font families, so 
we did not bother to filter on supported locales).
However, locale support in font families is extremely important in cases where font 
families having the same name are made of different TTF files supporting different 
locales.
A very good example is of people using the same 
fontName
value inside their reports 
that sometimes are generated in Chinese and other times in Japanese. They would use a 
set of TTF files that support Chinese and another set of TTF files that support Japanese. 
With them, they would create two font families having the same 
fontName
name, and 
specify Chinese as supported locale for the first one and Japanese for the second. This 
way, depending on the runtime locale, the appropriate font family would be selected, 
with the appropriate TTF files for that locale, although at design time the 
fontName 
attribute was the same for all text fields, regardless of locale.
Below is the extract from a 
fonts.xml
file that would declare a 
DejaVu Serif
font 
family supporting only English and German:
<bean id="dejaVuSerifFamily" 
class="net.sf.jasperreports.engine.fonts.SimpleFontFamily">
<property name="name" value="DejaVu Serif"/>
<property name="locales">
<set>
<value>en_US</value>
<value>de_DE</value>
</set>
</property> <property name="normal" value="DejaVuSerif.ttf"/>
<property name="bold" value="DejaVuSerif-Bold.ttf"/>
<property name="italic" value="DejaVuSerif-Italic.ttf"/>
<property name="boldItalic" value="DejaVuSerif-BoldItalic.ttf"/>
<property name="pdfEncoding" value="Identity-H"/>
<property name="pdfEmbedded" value="true"/>
</bean>
For more details about deploying fonts as extensions, you can take a look at the 
/demo/samples/fonts
sample provided with the JasperReports project distribution 
package, which adds one more font extension for another open source font called 
Gentium
.
P
AGE
284
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
Note
Since we now encourage people to use fonts from extensions, the PDF-related attributes available at 
text element level and style level, as explained in “Report Elements“ on page 114, are somewhat deprecated, 
because they can be specified globally inside the font family declaration.
C
USTOM
C
OMPONENTS
The purpose of this feature is to allow users to extend the functionality of the 
JasperReports engine by plugging-in custom-made visual components that would take 
data as input and produce content that is embedded into the resulting documents. Custom 
made components can be anything from simple barcodes to tables, and professional 
charting packages.
The custom component support is relying on two other major features of the 
JasperReports library: extension support and generic elements. Both are described in 
separate sections of this document and you need to be familiar with them before delving 
into custom components.
A custom component is a custom report element that has a defined structure and 
produces some output in generated reports, just like usual report elements do. 
Just like a normal chart element in a report template will produce an image element in 
the generated document, or just like a crosstab element present in the report template will 
produce a series of frames and text fields that makes up a tabular structure in the 
generated documents, generic custom components declared in a report template could 
generate any combination of simple elements and generic elements as the output of their 
built-in calculation and layout logic.
Custom components are supposed to come in bundles. A component bundle is a package 
comprising of one or several components that share the same XML namespace and 
schema. For example, a chart component bundle can contain multiple chart components, 
one for each type of chart (pie chart component, bar chart component and so on).
C
USTOM
C
OMPONENT
U
SE
C
ASES
E
XAMPLES
In the first use case example, we consider a JasperReports user that wants to replace the 
JFreeChart library (bundled with JasperReports by default for the built-in charting 
support) with some other charting package. 
Following are the few steps required to achieve it:
 A new component bundle is developed. The bundle can contain several 
components, that is, one per chart type.
 An XML schema for the chart components is designed.
 The schema uses a namespace reserved for the chart component implementation.
P
AGE
285
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
 A Java object model is designed for the chart components.
 Chart components can (optionally) use report subdatasets to produce data.
 The component implementation produces 
net.sf.jasperreports.engine.JRPrintImage
instances when the report is 
filled. The images can use a custom image renderer 
(
net.sf.jasperreports.engine.JRRenderable
) implementation.
 The developed component code is bundled into a JAR and placed on the 
application's classpath.
 Report designers can now embed custom charts into JRXMLs.
C
USTOM
C
OMPONENT
I
MPLEMENTATION
O
VERVIEW
A typical implementation of a custom component would involve the following:
 A 
jasperreports_extension.properties
resource which registers an 
extension factory that reads a Spring beans file.
2) The Spring beans file that includes one or more beans of type 
net.sf.jasperreports.engine.component.ComponentsBundle
. Most of the 
time the default implementation 
net.sf.jasperreports.engine.component.DefaultComponentsBundle
is 
used.
A component bundle includes:
 A XML parser object which implements 
net.sf.jasperreports.engine.component.ComponentsXmlParser
. The 
default 
net.sf.jasperreports.engine.component.DefaultComponentXmlParser 
implementation can be used in most cases. An XML parser provides:
*A namespace to be used for the component bundle.
*An XML schema to validate component XML fragments. The XML schema is 
given as both a public location where it can be accessed, and as an internal 
resource which will be used when parsing reports.
*A 
net.sf.jasperreports.engine.component.XmlDigesterConfigurer 
implementation which registers XML digester rules that are used to transform 
at JRXML parse time component XML fragments into Java objects. In many 
cases, new digester rule classes need to be written.
 One or more component managers, 
net.sf.jasperreports.engine.component.ComponentManager 
implementations, usually instances of 
net.sf.jasperreports.engine.component.DefaultComponentManager
. A 
component manager is an entry point through which the handlers for a single 
component type can be accessed. It contains:
P
AGE
286
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
*A component compiler 
(
net.sf.jasperreports.engine.component.ComponentCompiler 
implementation) that handles a component instance during report compile. It 
contains methods to collect report expressions from a component instance, to 
validate such a component and to create a component object that is included in 
the compiled report.
*A component XML writer 
(
net.sf.jasperreports.engine.component.ComponentXmlWriter 
implementation) which is responsible for producing a XML representation of 
component instances.
*A factory of component fill instances, 
net.sf.jasperreports.engine.component.ComponentFillFactory 
implementation.
*Such a factory would produce custom 
net.sf.jasperreports.engine.component.FillComponent
instances. A 
fill component object is responsible for managing a component at fill time. A 
typical implementation would evaluate a set of expressions and use the results 
to create a print element to be included in the generated report.
 If the component needs to generate an output elements that do not fall into the types 
built into JasperReports (such as texts/images), the component can produce generic 
print elements.
To handle such generic elements at export time, custom generic element handler 
implementations need to be written, as explained in “Report Elements“ on page 
114.
 If the component implementation generates charts, or, more generically, if it needs 
to collect data from several records in the report dataset or from subdatasets, the 
component object model will contain classes derived from abstract JasperReports 
element dataset classes. These classes offer the infrastructure required to collect 
data from report datasets.
More specifically, the following classes would be extended by the component 
implementation:
*net.sf.jasperreports.engine.design.JRDesignElementDataset
, for 
the report design/JRXML parsing stage.
*net.sf.jasperreports.engine.base.JRBaseElementDataset
, to be 
included in compiled reports.
*net.sf.jasperreports.engine.fill.JRFillElementDataset
, to be 
used at fill time.
When implementing custom components, the most helpful information can be found in 
the form of JasperReports API Javadoc and samples. The following samples found in the 
P
AGE
287
T
HE
J
ASPER
R
EPORTS
U
LTIMATE
G
UIDE
/demo/samples 
folder of the JasperReports project distribution package show custom 
components:
Barbecue
: A sample that illustrates the use of the Barbecue component built into 
JasperReports.
Barcode4j
: A sample that displays barcodes using the Barcode4j component built 
into JasperReports.
jchartscomponent
: A chart component implementation that outputs axis charts 
generated by the jCharts library (
http://jcharts.sf.net
).
openflashchart
: A chart component that outputs Open Flash Charts in HTML 
reports (
http://teethgrinder.co.uk/open-flash-chart-2/
).
S
IMPLE
B
ARCODE
C
OMPONENT
T
UTORIAL
We are going to explore the Barbecue component built into JasperReports and describe 
the steps required to write this custom component implementation. The paths of the files 
mentioned in this section are relative to the root of the JasperReports source package. 
The Java classes that we are going to mention belong to the 
net.sf.jasperreports.components.barbecue 
package and the source files are 
located under the 
/src
folder.
First, we need to design the XML schema that we will use for barcode elements. The 
schema can be found in 
src/net/sf/jasperreports/components/components.xsd
. It uses 
http://jasperreports.sourceforge.net/jasperreports/components
as target 
namespace. It includes a definition of a 
barbecue
XML element whose type extends 
jr:componentType
(where 
jr
is a prefix defined for the 
http://jasperreports.sourceforge.net/jasperreports
namespace) and which 
can substitute a 
jr:component
element. Given this definition, the 
barbecue
element 
can be used as a report component. 
The element includes an expression that will provide the text to be encoded as a barcode, 
as well as attributes that specify the barcode type and whether the text is to be rendered 
as part of the barcode image:
<element name="barbecue" substitutionGroup="jr:component">
<complexType>
<complexContent>
<extension base="jr:componentType">
<sequence>
<element ref="bc:codeExpression">
<complexType mixed="true"/>
</element>
</sequence>
<attribute name="type" use="required">
...
</attribute>
P
AGE
288
Documents you may be interested
Documents you may be interested