pdf library c# free : Extract data out of pdf file software Library dll windows .net azure web forms PDFlib-7-tutorial7-part1862

3.4  Interactive Elements 71
3.4.2 Formatting Options for Text Fields
In Acrobat it is possible to specify various options for formatting the contents of a text 
field, such as monetary amounts, dates, or percentages. This is implemented via custom 
JavaScript code used by Acrobat. PDFlib does not directly support these formatting fea-
tures since they are not specified in the PDF reference. However, for the benefit of 
PDFlib users we present some information below which will allow you to realize format-
ting options for text fields by supplying simple JavaScript code fragements with the 
action option of PDF_create_field( ).
In order to apply formatting to a text field JavaScript snippets are attached to a text 
field as keystroke and format actions. The JavaScript code calls some internal Acrobat 
function where the parameters control details of the formatting.
The following sample creates two keystroke and format actions, and attaches them to 
a form field so that the field contents will be formatted with two decimal places and the 
EUR currency identifier:
keystroke_action = p.create_action("JavaScript",
"script={AFNumber_Keystroke(2, 0, 3, 0, \"EUR \", true); }");
format_action = p.create_action("JavaScript",
"script={AFNumber_Format(2, 0, 0, 0, \"EUR \", true); }");
String optlist =  "font=" + font + " action={keystroke " + keystroke_action +
" format=" + format_action + "}";
p.create_field(50, 500, 250, 600, "price", "textfield", optlist);
Cookbook A full code sample can be found in the Cookbook topic interactive/form_textfield_input_
format.
In order to specify the various formats which are supported in Acrobat you must use ap-
propriate functions in the JavaScript code. Table 3.4 lists the JavaScript function names 
for the keystroke and format actions for all supported formats; the function parameters 
are described in Table 3.5. These functions must be used similarly to the example above.
Table 3.4 JavaScript formatting functions for text fields
format
JavaScript functions to be used for keystroke and format actions
number
AFNumber_Keystroke(nDec, sepStyle, negStyle, currStyle, strCurrency, bCurrencyPrepend)
AFNumber_Format(nDec, sepStyle, negStyle, currStyle, strCurrency, bCurrencyPrepend)
percentage
AFPercent_Keystroke(ndec, sepStyle), AFPercent_Format(ndec, sepStyle)
date
AFDate_KeystrokeEx(cFormat), AFDate_FormatEx(cFormat)
time
AFTime_Keystroke(tFormat), AFTime_FormatEx(cFormat)
special
AFSpecial_Keystroke(psf), AFSpecial_Format(psf)
Table 3.5 Parameters for the JavaScript formatting functions
parameters
explanation and possible values
nDec
Number of decimal places
Extract data out of pdf file - extract form data from PDF in C#.net, ASP.NET, MVC, Ajax, WPF
Help to Read and Extract Field Data from PDF with a Convenient C# Solution
export pdf data to excel; cannot save pdf form in reader
Extract data out of pdf file - VB.NET PDF Form Data Read library: extract form data from PDF in vb.net, ASP.NET, MVC, Ajax, WPF
Convenient VB.NET Solution to Read and Extract Field Data from PDF
html form output to pdf; pdf data extraction open source
72
Chapter 3:  PDFlib Programming
sepStyle
The decimal separator style:
0
1,234.56
1
1234.56
2
1.234,56
3
1234,56
negStyle
Emphasis used for negative numbers:
0
Normal
1
Use red text
2
Show parenthesis
3
both
strCurrency
Currency string to use, e.g. "\u20AC" for the Euro sign
bCurrency-
Prepend
false
do not prepend currency symbol
true
prepend currency symbol
cFormat
A date format string. It may contain the following format placeholders, or any of the time formats listed 
below for tFormat:
d
day of month
dd
day of month with leading zero
ddd
abbreviated day of the week
m
month as number
mm
month as number with leading zero
mmm
abbreviated month name
mmmm
full month name
yyyy
year with four digits
yy
last two digits of year
tFormat
A time format string. It may contain the following format placeholders:
h
hour (0-12)
hh
hour with leading zero (0-12)
H
hour (0-24)
HH
hour with leading zero (0-24)
M
minutes
MM
minutes with leading zero
s
seconds
ss
seconds with leading zero
t
'a' or 'p'
tt
'am' or 'pm'
psf
Describes a few additional formats:
0
Zip Code
1
Zip Code + 4
2
Phone Number
3
Social Security Number
Table 3.5 Parameters for the JavaScript formatting functions
parameters
explanation and possible values
C# PDF Text Extract Library: extract text content from PDF file in
class. Able to extract and get all and partial text content from PDF file. Ability to extract highlighted text out of PDF document.
export pdf form data to excel; extract pdf form data to excel
VB.NET PDF Text Extract Library: extract text content from PDF
NET Programming. Extract and get partial and all text content from PDF file. Extract highlighted text out of PDF document. Image text
extract table data from pdf to excel; how to flatten a pdf form in reader
4.1  Overview
73
4Unicode and Legacy Encodings
4.1 Overview
Unicode support in PDFlib. PDFlib’s text handling is based on the Unicode standard
1
almost identical to ISO 10646. Since most modern development environments support 
the Unicode standard our goal is to make it as easy as possible to use Unicode strings for 
creating PDF output. However, developers who don’t work with Unicode are not re-
quired to switch their application to Unicode since legacy encodings can be used as well. 
In particular, PDFlib supports traditional 8-bit encodings (e.g. Windows ANSI, Latin-1) 
and multi-byte CJK encodings (e.g. Shift-JIS, Big 5).
Although the majority of text will be created on PDF pages, PDFlib’s concepts for 
string handling apply to other areas as well, e.g. text for interactive features such as 
bookmarks.
Many print and online publications cover the Unicode standard; some important 
concepts are summarized in Section 4.2, »Important Unicode Concepts«, page 74.
8-bit encodings. 8-bit encodings (also called single-byte encodings) map each byte in a 
text string to a single character, and are thus limited to 256 different characters at a 
time (the value 0 is generally not used). A common example of an 8-bit encoding is the 
Windows ANSI encoding, which is a superset of ISO 8859-1, also called Latin-1. 8-bit en-
codings are discussed in more detail in Section 4.4, »8-Bit Encodings«, page 81.
Multi-byte CJK encodings. Because of the large number of required characters 8-bit 
encodings are not suitable for Chinese, Japanese, and Korean text. A variety of encoding 
schemes has been developed for use with these scripts, e.g. Shift-JIS and EUC for Japa-
nese, GB and Big5 for Chinese, and KSC for Korean. In PDF several dozens of CJK legacy 
encodings are supported via predefined CMaps.
CJK CMaps are discussed in more detail in Section 4.5, »Encodings for Chinese, Japa-
nese, and Korean Text«, page 85.
1. See www.unicode.org 
C# HTML5 PDF Viewer SDK to view PDF document online in C#.NET
Extract Field Data. Data: Auto Fill-in Field Data. Field: Insert VB.NET convert PDF to text, VB.NET extract PDF pages, VB Support to zoom in and zoom out PDF page
extract data from pdf table; extracting data from pdf to excel
VB.NET PDF- View PDF Online with VB.NET HTML5 PDF Viewer
Extract Field Data. Data: Auto Fill-in Field Data. Field: Insert file & pages edit, C#.NET PDF pages extract, copy, paste Support to zoom in and zoom out PDF page
how to fill in a pdf form in reader; export excel to pdf form
74
Chapter 4:  Unicode and Legacy Encodings
4.2 Important Unicode Concepts
Characters and glyphs. When dealing with text it is important to clearly distinguish 
the following concepts:
>Characters are the smallest units which convey information in a language. Common 
examples are the letters in the Latin alphabet, Chinese ideographs, and Japanese syl-
lables. Characters have a meaning: they are semantic entities.
>Glyphs are different graphical variants which represent one or more particular char-
acters. Glyphs have an appearance: they are representational entities.
There is no one-to-one relationship between characters and glyphs. For example, a liga-
ture is a single glyph which is represented by two or more separate characters. On the 
other hand, a specific glyph may be used to represent different characters depending on 
the context (some characters look identical, see Figure 4.1).
Unicode encoding forms (UTF formats). The Unicode standard assigns a number (code 
point) to each character. In order to use these numbers in computing, they must be rep-
resented in some way. In the Unicode standard this is called an encoding form (former-
ly: transformation format); this term should not be confused with font encodings. Uni-
code defines the following encoding forms:
>UTF-8: This is a variable-width format where code points are represented by 1-4 
bytes. ASCII characters in the range U+0000...U+007F are represented by a single 
byte in the range 00...7F. Latin-1 characters in the range U+00A0...U+00FF are repre-
sented by two bytes, where the first byte is always 0xC2 or 0xC3 (these values repre-
sent Â and Ã in Latin-1).
>UTF-16: Code points in the Basic Multilingual Plane (BMP), i.e. characters in the range 
U+0000...U+FFFF are represented by a single 16-bit value. Code points in the supple-
mentary planes, i.e. in the range U+10000...U+10FFFF, are represented by a pair of 16-
bit values. Such pairs are called surrogate pairs. A surrogate pair consists of a high-
surrogate value in the range D800...DBFF and a low-surrogate value in the range 
DC00...DFFF. High- and low-surrogate values can only appear as parts of surrogate 
pairs, but not in any other context.
>UTF-32: Each code point is represented by a single 32-bit value.
U+0067 LATIN SMALL LETTER G
Characters
Glyphs
U+0066 LATIN SMALL LETTER F +
U+0069 LATIN SMALL LETTER I
U+2126 OHM SIGN    or
U+03A9 GREEK CAPITAL LETTER OMEGA
U+2167 ROMAN NUMERAL EIGHT    or
U+0056 V U+0049 I U+0049 I U+0049 I
Fig. 4.1.
Relationship of glyphs
and characters
C# PDF Form Data fill-in Library: auto fill-in PDF form data in C#
Able to fill out all PDF form field in C# RasterEdge XDoc.PDF SDK package provides PDF field processing features for will learn how to fill-in field data to PDF
vb extract data from pdf; extracting data from pdf files
C# WPF PDF Viewer SDK to view PDF document in C#.NET
Extract Field Data. Data: Auto Fill-in Field Data. Field: Insert & pages edit, C#.NET PDF pages extract, copy, paste, C# Abilities to zoom in and zoom out PDF page
saving pdf forms in acrobat reader; extract data from pdf
4.2  Important Unicode Concepts 75
Cookbook A full code sample can be found in the Cookbook topic text_output/process_utf8.
Unicode encoding schemes and the Byte Order Mark (BOM). Computer architectures 
differ in the ordering of bytes, i.e. whether the bytes constituting a larger value (16- or 
32-bit) are stored with the most significant byte first (big-endian) or the least significant 
byte first (little-endian). A common example for big-endian architectures is PowerPC, 
while the x86 architecture is little-endian. Since UTF-8 and UTF-16 are based on values 
which are larger than a single byte, the byte-ordering issue comes into play here. An en-
coding scheme (note the difference to encoding form above) specifies the encoding 
form plus the byte ordering. For example, UTF-16BE stands for UTF-16 with big-endian 
byte ordering. If the byte ordering is not known in advance it can be specified by means 
of the code point U+FEFF, which is called Byte Order Mark (BOM). Although a BOM is not 
required in UTF-8, it may be present as well, and can be used to identify a stream of 
bytes as UTF-8. Table 4.1 lists the representation of the BOM for various encoding forms.
Table 4.1 Byte order marks for various Unicode encoding forms
Encoding form
Byte order mark (hex)
graphical representation
UTF-8
EF BB BF

UTF-16 big-endian
FE FF
UTF-16 little-endian
FF FE
ÿþ
UTF-32 big-endian
00 00 FE FF
? ? 
1
1. There is no standard graphical representation of null bytes.
UTF-32 little-endian
FF FE 00 00
ÿþ ? ?
1
VB.NET PDF - View PDF with WPF PDF Viewer for VB.NET
Extract Field Data. Data: Auto Fill-in Field Data. Field: Insert & pages edit, C#.NET PDF pages extract, copy, paste, C# Abilities to zoom in and zoom out PDF page
pdf form save in reader; can reader edit pdf forms
VB.NET PDF- HTML5 PDF Viewer for VB.NET Project
Extract Field Data. Data: Auto Fill-in Field Data. Field: Insert VB.NET convert PDF to text, VB.NET extract PDF pages, VB PDF page and zoom in or zoom out PDF page
extract data from pdf file; how to make pdf editable form reader
76
Chapter 4:  Unicode and Legacy Encodings
4.3 Strings in PDFlib
4.3.1 String Types in PDFlib
PDF and operating system requirements impose different string handling in PDFlib de-
pending on the purpose of a string. The PDFlib API defines and uses the following string 
types:
>Content strings: these will be used to create genuine page content (page descrip-
tions) according to the encoding chosen by the user for a particular font. All text pa-
rameters of the page content functions fall in this class.
>Hypertext strings: these are mostly used for interactive features such as bookmarks 
and annotations, and are explicitly labeled Hypertext string in the function descrip-
tions. Many parameters and options of the functions for interactive features fall in 
this class, as well as some others.
>Name strings: these are used for external file names, font names, block names, etc., 
and are marked as name string in the function descriptions. They slightly differ from 
Hypertext strings, but only in language bindings which are not Unicode-aware.
Content strings, hypertext strings, and name strings can be used with Unicode and 8-bit 
encodings. Non-Unicode CJK CMaps can only be used in non-Unicode-compatible lan-
guage bindings. The details of string handling depend on the language binding, and are 
discussed in Section 4.3.2, »Strings in Unicode-aware Language Bindings«, page 76 and 
Section 4.3.3, »Strings in non-Unicode-aware Language Bindings«, page 77.
4.3.2 Strings in Unicode-aware Language Bindings
If a development environment supports the string data type, uses Unicode internally, 
and the corresponding PDFlib language wrapper supports the language’s Unicode 
strings we call the binding Unicode-aware. The following PDFlib language bindings are 
Unicode-aware:
>COM
>.NET
>Java
>Python
>REALbasic
>RPG
>Tcl
String handling in these environments is straightforward: all strings will automatically 
be provided to the PDFlib kernel as Unicode strings in native UTF-16 format. The lan-
guage wrappers will correctly deal with Unicode strings provided by the client, and au-
tomatically set certain PDFlib parameters. This has the following consequences:
>The PDFlib language wrapper applies all required conversions so that client-supplied 
hypertext strings will always arrive in PDFlib in utf16 format and unicode encoding.
>Since the language environment always passes strings in UTF-16 to PDFlib, UTF-8 can 
not be used with Unicode-aware languages. It must be converted to UTF-16 before.
>Using unicode encoding for the contents of a page is the easiest way to deal with en-
codings in Unicode-aware languages, but 8-bit encodings and single-byte text for 
symbol fonts can also be used if so desired.
VB.NET PDF - WPF PDF Viewer for VB.NET Program
Field Data. Data: Auto Fill-in Field Data. Field: Insert & pages edit, C#.NET PDF pages extract, copy, paste rotate PDF pages, zoom in or zoom out PDF pages and go
c# read pdf form fields; pdf form save with reader
VB.NET PDF File & Page Process Library SDK for vb.net, ASP.NET
Moreover, when you get a PDF document which is out of order, you need to adding a page into PDF document, deleting unnecessary page from PDF file and changing
extract data from pdf forms; extract data out of pdf file
4.3  Strings in PDFlib 77
>Non-Unicode CMaps for Chinese, Japanese, and Korean text (see Section 4.5, »Encod-
ings for Chinese, Japanese, and Korean Text«, page 85) must be avoided since the 
wrapper will always supply Unicode to the PDFlib core; only Unicode CMaps can be 
used.
The overall effect is that clients can provide plain Unicode strings to PDFlib functions 
without any additional configuration or parameter settings. The distinction between 
hypertext strings and name strings in the function descriptions is not relevant for Uni-
code-aware language bindings.
Unicode conversion functions. If you must deal with strings in other encodings than 
Unicode, you must convert them to Unicode before passing them to PDFlib. The lan-
guage-specific sections in Chapter 2, »PDFlib Language Bindings«, page 25, provide more 
details regarding useful Unicode string conversion methods provided by common lan-
guage environments.
4.3.3 Strings in non-Unicode-aware Language Bindings
The following PDFlib language bindings are not Unicode-aware:
>C (no native string data type available)
>C++
>Cobol (no native string data type available)
>Perl
>PHP
>old-style Python binding for compatibility with PDFlib 6 (see Section 2.9, »Python 
Binding«, page 39, for configuration information)
>Ruby
In language bindings which do not support a native string data type (i.e. C, Cobol) the 
length of UTF-16 strings must be supplied in a separate length parameter. Although Uni-
code text can be used in these languages, handling of the various string types is a bit 
more complicated:
Content strings. Content strings are strings used to create page content. Interpreta-
tion of these strings is controlled by the textformat parameter (detailed below) and the 
encoding parameter of PDF_load_font( ). If textformat=auto (which is the default) utf16 
format will be used for the unicode and glyphid encodings as well as UCS-2 and UTF-16 
CMaps. For all other encodings the format will be bytes. In languages without a native 
string data type (see list above) the length of UTF-16 strings must be supplied in a sepa-
rate length parameter.
Hypertext strings. String interpretation is controlled by the hypertextformat and 
hypertextencoding parameters (detailed below). If hypertextformat=auto (which is the de-
fault) utf16 format will be used if hypertextencoding=unicode, and bytes otherwise. In lan-
guages without a native string data type (see list above) the length of UTF-16 strings 
must be supplied in a separate length parameter.
Name strings. Name strings are interpreted slightly differently from page description 
strings. By default, name strings are interpreted in host encoding. However, if it starts 
with an UTF-8 BOM it will be interpreted as UTF-8 (or as EBCDIC UTF-8 if it starts with an 
78
Chapter 4:  Unicode and Legacy Encodings
EBCDIC UTF-8 BOM). If the usehypertextencoding parameter is true, the encoding speci-
fied in hypertextencoding will be applied to name strings as well. This can be used, for ex-
ample, to specify font or file names in Shift-JIS.
In C the length parameter must be 0 for UTF-8 strings. If it is different from 0 the 
string will be interpreted as UTF-16. In all other non-Unicode-aware language bindings 
there is no length parameter available in the API functions, and name strings must al-
ways be supplied in UTF-8 format. In order to create Unicode name strings in this case 
you can use the PDF_utf16_to_utf8( ) utility function to create UTF-8 (see below).
Unicode conversion functions. In non-Unicode-aware language bindings PDFlib offers 
the PDF_utf16_to_utf8( ), PDF_utf8_to_utf16( ), and PDF_utf32_to_utf16( ) conversion func-
tions which can be used to create UTF-8 or UTF-16 strings for passing them to PDFlib.
The language-specific sections in Chapter 2, »PDFlib Language Bindings«, page 25, 
provide more details regarding useful Unicode string conversion methods provided by 
common language environments.
Text format for content and hypertext strings. Unicode strings in PDFlib can be sup-
plied in the UTF-8, UTF-16, or UTF-32 formats with any byte ordering. The choice of for-
mat can be controlled with the textformat parameter for all text on page descriptions, 
and the hypertextformat parameter for interactive elements. Table 4.2 lists the values 
which are supported for both of these parameters. The default for the [hyper]textformat 
parameter is auto. Use the usehypertextencoding parameter to enforce the same behavior 
for name strings. The default for the hypertextencoding parameter is auto.
Table 4.2 Values for the textformat and hypertextformat parameters
[hyper]textformat
explanation
bytes
One byte in the string corresponds to one character. This is mainly useful for 8-bit encodings and 
symbolic fonts. A UTF-8 BOM at the start of the string will be evaluated and then removed.
utf8
Strings are expected in UTF-8 format. Invalid UTF-8 sequences will trigger an exception if 
glyphcheck=error, or will be deleted otherwise.
ebcdicutf8
Strings are expected in EBCDIC-coded UTF-8 format (only on iSeries and zSeries).
utf16
Strings are expected in UTF-16 format. A Unicode Byte Order Mark (BOM) at the start of the string 
will be evaluated and then removed. If no BOM is present the string is expected in the machine’s 
native byte ordering (on Intel x86 architectures the native byte order is little-endian, while on 
Sparc and PowerPC systems it is big-endian).
utf16be
Strings are expected in UTF-16 format in big-endian byte ordering. There is no special treatment 
for Byte Order Marks.
utf16le
Strings are expected in UTF-16 format in little-endian byte ordering. There is no special treatment 
for Byte Order Marks.
auto
Content strings: equivalent to bytes for 8-bit encodings and non-Unicode CMaps, and utf16 for 
wide-character addressing (unicode, glyphid, or a UCS2 or UTF16 CMap).
Hypertext strings: UTF-8 and UTF-16 strings with BOM will be detected (in C UTF-16 strings must 
be terminated with a double-null). If the string does not start with a BOM, it will be interpreted as 
an 8-bit encoded string according to the hypertextencoding parameter.
This setting will provide proper text interpretation in most environments which do not use Uni-
code natively.
4.3  Strings in PDFlib 79
Although the textformat setting is in effect for all encodings, it will be most useful for 
unicode encoding. Table 4.3 details the interpretation of text strings for various combi-
nations of encodings and textformat settings.
Strings in option lists. Strings within option lists require special attention since in 
non-Unicode-aware language bindings they cannot be expressed as Unicode strings in 
UTF-16 format, but only as byte strings. For this reason UTF-8 is used for Unicode op-
tions. By looking for a BOM at the beginning of an option, PDFlib decides how to inter-
pret it. The BOM will be used to determine the format of the string, and the string type 
(content string, hypertext string, or name string as defined above) will be used to deter-
mine the appropriate encoding. More precisely, interpreting a string option works as 
follows:
>If the option starts with a UTF-8 BOM (0xEF 0xBB 0xBF) it will be interpreted as UTF-8. 
On EBCDIC-based systems: if the option starts with an EBCDIC UTF-8 BOM (0x57 0x8B 
0xAB) it will be interpreted as EBCDIC UTF-8. If no BOM is found, string interpreta-
tion depends on the type of string:
>Content strings will be interpreted according to the applicable encoding option or the 
encoding of the corresponding font (whichever is present).
>Hypertext strings will be interpreted according to the hypertextencoding parameter 
or option.
>Name strings will be interpreted according to the hypertext settings if usehypertext-
encoding=true, and host encoding otherwise.
Note that the characters { and } require special handling within strings in option lists, 
and must be preceded by a \ character if they are used within a string option. This re-
quirement remains for legacy encodings such as Shift-JIS: all occurrences of the byte 
Table 4.3 Relationship of encodings and text format
[hypertext]encoding
textformat=bytes
textformat=utf8, utf16, utf16be, or utf16le
All string types:
auto
see section »Automatic encoding«, page 81
U+XXXX
8-bit codes will be added to the off-
set XXXX to address Unicode values
convert Unicode values to 8-bit codes according to the cho-
sen Unicode offset
unicode and UCS2-
or UTF16 CMaps
8-bit codes are Unicode values from 
U+0000 to U+00FF
any Unicode value, encoded according to the chosen text 
format
1
any other CMap
(not Unicode-based)
any single- or multibyte codes ac-
cording to the chosen CMap
PDFlib will throw an exception
Only content strings:
8-bit and builtin
8-bit codes
Convert Unicode values to 8-bit codes according to the cho-
sen encoding
1
. PDFlib will throw an exception if it is not a 
content string and no 8-bit encoding is found in the font 
(8-bit encodings are available in Type 1 and Type 3 fonts).
1.  If the Unicode character is not available in the font, PDFlib will throw an exception or replace it subject to the glyphcheck option.
glyphid
8-bit codes are glyph ids from 0 to 
255
Unicode values will be interpreted as glyph ids
2
2.  If the glyph id is not available in the font, PDFlib will issue a warning and replace it with glyph id 0.
80
Chapter 4:  Unicode and Legacy Encodings
values 0x7B and 0x7D must be preceded with 0x5C. For this reason the use of UTF-8 for 
options is recommended (instead of Shift-JIS and other legacy encodings).
Documents you may be interested
Documents you may be interested